Прокси сервис

Socks-прокси, принцип работы Socks4 и Socks5

Для чего предназначены Socks-прокси?

Socks в переводе с английского - носки. На самом деле, это сокращение или аббревиатура от sockets. В официальной спецификации описана проблема, связанная с изоляцией внутренних сетей организаций с помощью firewall. Протокол разработан для возможности доступа к сервисам внутренней сети извне, равно как и наоборот, как сказано в первоисточнике - "для прозрачного и безопасного прохождения файрволла". Стандартный порт таких прокси - 1080, но часто используются другие значения.

Socks это носки по нашему

SOCKS5 является протоколом транспортного уровня и SOCKS-прокси должен уметь корректно работать как с TCP, так и с UDP. Другие протоколы, в частности ICMP, используемый утилитами ping и tracert, находится ниже транспортного уровня, и потому не поддерживается (Хотя, существуют нестандартные решения, позволяющие это сделать). В настоящее время распространены прокси-серверы, работающие по протоколу Socks4 и Socks5 (4 и 5 версия протокола соответственно). Полное описание функций можно найти на английском в статьях SOCKS: A protocol for TCP proxy across firewalls и RFC1928, а также в немногочисленных переводах на другие языки.

Какие приложения можно завернуть через Socks?

Для работы с Socks proxy приложение должно поддерживать подключения по этому протоколу. В настоящее время, он поддерживается большинством браузеров (Firefox, IE, Opera), Skype, ICQ клиентом QIP, Mail.ru Agent, клиентом OpenVPN, а также большинством opensource программ.

Приложения, в которых подержка Socks изначально отсутствует, можно заставить работать через прокси с помощью "соксификации". Она заключается в перехвате вызовов функций connect(), bind(), send() и других, с их последующей подменой поддерживающими SOCKS аналогами. Никаких правок в исходном коде приложений и доступа к исходным текстам обычно не требуется.

Принцип работы

Клиент, поддерживающий доступ через прокси, подключается по TCP к прокси и проходит авторизацию на SOCKS-сервере: сначала отправляет серверу номера поддерживаемых им методов аутентификации, SOCKS-сервер выбирает один из методов по своему усмотрению и сообщает его номер клиенту. Наиболее популярные методы авторизации - свободный доступ без авторизации и доступ по логину и паролю. Остальные методы (CHAP, GSSAPI и др.) мы рассматривать пока не будем. Следует разве что отметить, что при обычной авторизации все данные передаются в незашифрованном виде, CHAP позволяет зашифровать только пароль, а GSSAPI - также весь траффик, но большинством серверов эти методы не поддерживаются. После успешной авторизации клиент получает возможность посылать запросы (команды), устанавливать исходящие или принимать входящие соединения.

Протокол версии 4 считается устаревшим и поддерживает только 2 метода - CONNECT и BIND, позволяющие, соответственно, установить подключение к удаленному узлу, или открыть "слушающий" порт на прокси. Устаревший он потому, что поддерживает только TCP соединения, и не поддерживает всех тех фишек с авторизацией, описанных выше. Отметим, что socks серверы условно делятся на 3 вида - поддерживающие только старый 4й протокол (называются Socks4-прокси), поддерживающие только 5й протокол (они же Socks5-прокси), и поддерживающие оба протокола (их называют либо 4/5 либо просто определяют как Socks5).

Протокол версии 5 в настоящее время используется большинством прокси. Кроме методов CONNECT и BIND, испольщуемых для подключений по TCP, есть еще метод UDP ASSOCIATE, предназначенный для передачи UDP траффика. Следует, однако, отметить что множества реализаций протокола являются упрощенными и могут поддерживать только CONNECT и BIND либо вообще только CONNECT.

Запрос методом CONNECT содержит адрес целевого компьютера и порт, к которому будет осуществляться подключение. Для идентификации получателя могут использоваться как адреса IPv4 или IPv6, так и доменные имена. В этом случае, прокси используется также и в качестве DNS-сервера. Однако, автор статьи лично сталкивался с популярным в сети исходником, содержащим критическую ошибку, не позволявшую нормально работать с доменными именами. Скорее всего, во множестве старых реализаций отсутствует также и поддержка адресов IPv6.
В ответном сообщении SOCKS-сервер сообщает код ошибки либо 0 если операция прошла успешно, IP-адрес и TCP-порт, которые будут использоваться для фактической связи с запрошенным узлом (в случае нескольких сетевых интерфейсов, этот адрес может отличаться от адреса прокси). Наиболее часто возникающие ошибки - доступ запрещен правилами прокси, либо невозможно подключиться к целевому узлу. После установки соединения, прокси сервер начинает прозрачную передачу данных в обе стороны.

Запрос методом BIND содержит адрес прокси и порт, который должен быть открыт, либо нули если он оставляется на усмотрение прокси-сервера. После получения такого запроса сервер открывает указанный либо выбранный сервером порт. Клиенту уходит ответ - код ошибки либо 0 если операция прошла успешно, IP-адрес и открытый TCP-порт. После этого с указанным портом можно устанавливать соединения. Чаще всего, данный метод применяется для FTP.

Доступ по протоколу UDP через Socks5 сервер мало востребован, информацию о методе UDP ASSOCIATE Вы можете получить из спецификации протокола.

Безопасность

Даже при использовании цепочек socks серверов, есть один серьезный недостаток в плане безопасности. Если Вы используете прокси для доступа к серверу по протоколу без шифрования - все запросы и данные передаются в открытом виде. Кроме того, в любом случае и администратор прокси, и все "уши" на магистралях между клиентом и прокси знают и откуда было подключение, и куда оно направлено. В случае ушей между прокси и целевым сервером - адрес клиента как правило не передается. Как правило - в том смысле если софт клиента настроен правильно и он не передает свой адрес сам (такие утечки возможны при использовании FTP, почтовых серверов, браузеров с плагинами Java и Flash) и не только. Для достижения более серьезной безопасности рекомендую пользоваться прокси в связке с SSL или VPN.

Вернуться