Валентин Синицын

– Извини, Пух, – сказала САВА. – Тигра сжевал все провода от почтового сервера,

и почта долго никак не приходила...

– Провода, – подумал Пух злобно. – Носки вязать из таких проводов.

Андрей Щербаков

«9600 бод и все-все-все...»

В этой статье мы поговорим о протоколе SOCKS[1]. С его помощью можно решать самые разные задачи: организовывать защищенный доступ к службам, расположенным за межсетевым экраном (firewall), скрывать свой истинный IP-адрес во время работы с недружелюбными сетевыми ресурсами или реализовать универсальный прокси-сервер, поддерживающий любые протоколы прикладного уровня (HTTP, FTP, POP3/SMTP, ICQ и т. д.). К сожалению, несмотря на всю простоту и богатство возможностей SOCKS, многие системные администраторы недостаточно хорошо знакомы с ним и не представляют, чем он может быть полезен. Хочется надеяться, что после прочтения данного материала незаслуженно забытый протокол займет достойное место в их арсенале. Сразу же оговоримся: все последующее изложение будет относиться к пятой версии SOCKS, SOCKS5. Предыдущая, четвертая версия (SOCKS4), все еще имеет хождение в Сети, однако ее возможности ограничены.

К слову сказать, название протокола не имеет ничего общего с упомянутыми в эпиграфе чулочными изделиями и является простым сокращением от «SOCK-et-S» – «гнезда», или, в более привычном уху компьютерного специалиста переводе – «сокеты». Термин был предложен создателями в качестве рабочего варианта, да так и прижился. Как известно, сокеты лежат в основе любого API, реализующего сетевое взаимодействие – UNIX, Winsock и т. п. Чтобы послать данные по сети, приложению достаточно просто записать их в сокет, подобно тому, как это делается при сохранении информации в локальном файле. И в том, и в другом случае программе не приходится заботиться о происходящем «за кулисами». Дополнение пользовательских данных служебной информацией, разбивка на сегменты с их последующей инкапсуляцией в датаграммы и физическая отправка осуществляются другими частями операционной системы – стеком TCP/IP и драйверами устройств, о которых приложению ничего не известно. Такое «разделение труда» позволяет как угодно изменять процедуру доставки сообщений при условии, что интерфейс прикладного программирования остается постоянным. Именно эта особенность и лежит в основе идеологии SOCKS. Основная задача данного протокола – внедрить в «нормальный» процесс обмена данными некоего посредника, называемого SOCKS-сервером или SOCKS-прокси. Когда клиент (поддерживающее SOCKS приложение: веб-браузер Mozilla, клиент ICQ Miranda IM и др., см. ниже) желает отправить какую-либо информацию по сети, он устанавливает соединение не с реальным адресатом, а с SOCKS-сервером, который, в свою очередь, пересылает данные по назначению, но уже от своего имени. С точки зрения «настоящего» сервера (например, веб-узла, который пользователь желает просмотреть в Mozilla Firefox) SOCKS-прокси является самым обыкновенным клиентом. Таким образом, сущность (IP-адрес) истинного клиента оказывается скрытой от обслуживающего его сервера. Это весьма удобное обстоятельство таит в себе потенциальную опасность (можете спрятаться вы, но ведь могут и от вас), поэтому реально существующие SOCKS-сервера имеют развитые схемы контроля доступа (запрет входящих и исходящих соединений по заданному перечню адресов) и поддерживают авторизацию пользователей по паролю (см. ниже).

Отметим, что коль скоро SOCKS работает на более низком по сравнению с прикладным (а именно транспортном) уровне модели OSI, его поддержка не потребует никаких изменений в логике работы клиента, а тем более сервера. Действительно, все что нужно, – это модифицировать реализацию функций, отвечающих за создание сетевого подключения и отправку данных: connect(), bind(), send() и т. п. На практике это обычно достигается перехватом системных вызовов с их последующей подменой поддерживающими SOCKS пользовательскими аналогами. Никаких правок в исходном коде клиентских приложений, а тем более самого доступа к исходным текстам, как правило, не требуется. Эта мощная процедура известна как «соксификация» и будет подробно рассмотрена ниже.

Теперь, когда мы получили общее представление о SOCKS, можно перейти к более детальному рассмотрению данного протокола.