SOCKS

SAF International

Socket Secure (SOCKS) - это интернет-протокол, который обменивается сетевыми пакетами между клиентом и сервером через прокси-сервер. SOCKS5 дополнительно обеспечивает аутентификацию, поэтому только авторизованные пользователи могут обращаться к серверу. Практически сервер SOCKS проксирует TCP-соединения на произвольный IP-адрес и предоставляет средства для пересылки UDP-пакетов.

SOCKS выполняет на уровне 5 OSI model (уровень сеанса, промежуточный уровень между уровнем представления и транспортным уровнем). Сервер SOCKS принимает входящее клиентское соединение на TCP-порту 1080.

История SOCKS

Протокол был первоначально разработан Дэвидом Кобласом. После того, как MIPS была принята Silicon Graphics в 1992 году, Коблас представил документ о SOCKS на симпозиуме Usenix в 1992 году, сделав SOCKS общедоступным. Протокол был расширен до версии 4.

Образцовая архитектура и клиент SOCKS принадлежат Permeo Technologies, являются побочным продуктом NEC. (Blue Coat Systems выкупила Permeo Technologies.)

Протокол SOCKS5 изначально был протоколом безопасности, который упрощал управление брандмауэрами и другими продуктами безопасности. Это было одобрено IETF в 1996 году. Протокол был разработан в сотрудничестве с Aventail Corporation, которая продает технологии за пределами Азии.

Использование

SOCKS является стандартом де-факто для шлюзов уровня канала. Другое использование SOCKS - это инструмент обхода, позволяющий трафику обходить фильтрацию Интернета для доступа к контенту, который в противном случае блокируется, например, государством, рабочими местами, школами и веб-службами конкретной страны.

Некоторые SSH-пакеты, такие как OpenSSH, поддерживают динамическую переадресацию портов, что позволяет пользователю создавать локальный прокси-сервер SOCKS. Это может освободить пользователя от ограничений подключения только к предопределенному удаленному порту и серверу. Прокси-сервер Tor onion представляет интерфейс SOCKS своим клиентам.

В киберпреступности SOCKS

Взломанные компьютеры могут быть настроены как прокси-программное обеспечение SOCKS, скрывающее контроль за сетью или оптимизацию мошенничества.

Сравнение с HTTP-проксированием

SOCKS работает на более низком уровне, чем HTTP-прокси: SOCKS использует протокол установления связи, чтобы сообщить прокси-серверу о соединении, которое клиент пытается сделать, а затем действует как можно более прозрачно, тогда как обычный прокси-сервер может интерпретировать и переписывать заголовки (например, использовать другой базовый протокол, такой как FTP, однако прокси-сервер HTTP просто перенаправляет HTTP-запрос на требуемый HTTP-сервер). Хотя HTTP-проксирование имеет другую модель использования, метод CONNECT позволяет пересылать TCP-соединения; однако прокси SOCKS также могут перенаправлять UDP-трафик и работать в обратном порядке, тогда как HTTP-прокси не может этого делать. HTTP-прокси традиционно более осведомлены о протоколе HTTP, выполняя фильтрацию более высокого уровня (хотя это обычно применяется только к методам GET и POST, а не к методу CONNECT).

SOCKS

Василий хочет общаться с Димой через Интернет, но межсетевой экран между ними существует в его сети, где Василий не уполномочен напрямую общаться с Димой. Итак, Василий подключается к прокси-серверу SOCKS в своей сети, сообщая ему о связи, которую он хочет сделать Димой; прокси-сервер SOCKS открывает соединение через брандмауэр и облегчает связь между Василием и Димой.

HTTP

Василий хочет загрузить веб-страницу от Димы, которая управляет веб-сервером. Василий не может напрямую подключиться к серверу Димы, поскольку брандмауэр был установлен в его сети. Чтобы связаться с сервером, Василий подключается к HTTP-прокси сети. Его веб-браузер взаимодействует с прокси-сервером точно так же, как и с сервером Димы, если это возможно; то есть он отправляет стандартный заголовок HTTP-запроса. Прокси-сервер HTTP подключается к серверу Димы, а затем передает Василий любые данные, возвращаемые сервером Димы.

Техническая часть SOCKS

SOCKS4

Типичный запрос соединения SOCKS4 выглядит следующим образом:

Клиент SOCKS для сервера SOCKS:

Поле 1: номер версии SOCKS, 1 байт, должен быть 0x04 для этой версии
Поле 2: код команды, 1 байт:

0x01 = установить соединение потока TCP/IP

0x02 = установить привязку портов TCP/IP

Поле 3: номер порта, 2 байта (в байтовом порядке сети)
Поле 4: IP-адрес, 4 байта (в байтовом порядке сети)
Поле 5: строка идентификатора пользователя, длина переменной, завершенная нулевым (0x00)

Сервер SOCKS для клиента SOCKS:

Поле 1: null байт
Поле 2: статус, 1 байт:

0x5A = запрос предоставлен

0x5B = запрос отклонен или не выполнен

0x5C = запрос не выполнен, потому что клиент не запускает идентификатор (или недоступен с сервера)

0x5D = запрос не выполнен, так как идентификатор клиента не смог подтвердить строку идентификатора пользователя в запросе

Поле 3: 2 произвольных байта, которые следует игнорировать
Поле 4: 4 произвольных байта, которые следует игнорировать

Например, этот запрос SOCKS4 для подключения Fred к 66.102.7.99:80, сервер отвечает «ОК»:

Клиент: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00

Последнее поле это «Fred» в ASCII, за которым следует нулевой байт.

Сервер: 0x00 | 0x5A | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX

0xXX может быть любым байтовым значением. Протокол SOCKS4 указывает, что значения этих байтов следует игнорировать. С этого момента любые данные, отправленные клиентом SOCKS на сервер SOCKS, передаются на 66.102.7.99 и наоборот.

Поле команды может быть 0x01 для «connect» или 0x02 для «bind»; команда «bind» позволяет принимать входящие соединения для таких протоколов, как активный FTP.

SOCKS4a

SOCKS4a расширяет протокол SOCKS4, чтобы клиент мог указать доменное имя получателя, а не IP-адрес, это полезно, когда сам клиент не может разрешить доменное имя хоста назначения на IP-адрес.

Клиент должен установить первые три байта DSTIP в NULL, а последний байт - на ненулевое значение. (Это соответствует IP-адресу 0.0.0.x, с х отличным от нуля, недопустимым адресом назначения, следовательно, никогда не должно возникать, если клиент может разрешить имя домена.) После байта NULL, заканчивающего USERID, клиент должен отправить имя домена назначения и завершает его другим байт NULL. Это используется для запросов «connect» и «bind».

Клиент на сервер SOCKS:

Поле 1: номер версии SOCKS, 1 байт, должен быть 0x04 для этой версии
Поле 2: код команды, 1 байт:

0x01 = установить соединение потока TCP/IP

0x02 = установить привязку портов TCP/IP

Поле 3: номер порта, 2 байта
Поле 4: преднамеренный неверный IP-адрес, 4 байта, первые три должны быть 0x00, а последний не должен быть 0x00
Поле 5: строка идентификатора пользователя, длина переменной, завершенная нулевым (0x00)
Поле 6: имя домена хоста для связи, длина переменной, завершенная нулевым (0x00)

Сервер для клиента SOCKS:

Поле 1: нулевой байт
Поле 2: статус, 1 байт:

0x5A = запрос предоставлен

0x5B = запрос отклонен или не выполнен

0x5C = запрос не выполнен, потому что клиент не запускает идентификатор (или недоступен с сервера)

Поле 3: номер порта, 2 байта (в байтовом порядке сети)
Поле 4: IP-адрес, 4 байта (в байтовом порядке сети)

Сервер, использующий протокол SOCKS4a, должен проверить DSTIP в пакете запроса. Если он представляет адрес 0.0.0.x с ненулевым x, сервер должен прочитать имя домена, которое клиент отправляет в пакете. Сервер должен разрешить имя домена и установить соединение с целевым хостом, если это возможно.

SOCKS5

Протокол SOCKS5 определен стандартом RFC 1928. Он является расширением протокола SOCKS4; он предлагает больше вариантов аутентификации и добавляет поддержку IPv6 и UDP, последний из которых может использоваться для поиска DNS. Первоначальное рукопожатие состоит из следующего:

Клиент подключается и отправляет приветствие, которое включает в себя список поддерживаемых методов проверки подлинности.
Сервер выбирает один из методов (или отправляет ответ об отказе, если ни один из них не является приемлемым).
Теперь несколько сообщений могут проходить между клиентом и сервером в зависимости от выбранного метода аутентификации.
Клиент отправляет запрос на соединение, аналогичный SOCKS4.
Сервер отвечает аналогично SOCKS4.

Поддерживаемые методы аутентификации пронумерованы следующим образом:

0x00: нет аутентификации
0x01: GSSAPI
0x02: имя пользователя/пароль
0x03-0x7F: методы, назначенные IANA
0x80-0xFE: методы, зарезервированные для частного использования

Первоначальное приветствие клиента:

Поле 1: версия SOCKS, 1 байт (0x05 для этой версии)
Поле 2: количество поддерживаемых методов аутентификации, 1 байт
Поле 3: методы проверки подлинности, длина переменной, 1 байт на поддерживаемый метод

Выбор сервера сообщается:

Поле 1: версия SOCKS, 1 байт (0x05 для этой версии)
Поле 2: выбранный метод аутентификации, 1 байт или 0xFF, если не было найдено приемлемых методов

Последующая аутентификация зависит от метода. Идентификация имени пользователя и пароля (метод 0x02) описана в стандарте RFC 1929:

Для аутентификации имени пользователя/пароля клиента:

Поле 1: номер версии, 1 байт (0x01 для текущей версии аутентификации имени пользователя/пароля)
Поле 2: длина имени пользователя, 1 байт
Поле 3: имя пользователя, 1-255 байт
Поле 4: длина пароля, 1 байт
Поле 5: пароль, 1-255 байт

Ответ сервера на аутентификацию имени пользователя/пароля:

Поле 1: версия, 1 байт (0x01 для текущей версии аутентификации имени пользователя/пароля)
Поле 2: код состояния, 1 байт

0x00: успех

Любое другое значение является неисправностью, соединение должно быть закрыто

Запрос на соединение клиента

Поле 1: номер версии SOCKS, 1 байт (0x05 для этой версии)
Поле 2: код команды, 1 байт:

0x01: установить соединение потока TCP/IP

0x02: установить привязку портов TCP/IP

0x03: связать порт UDP

Поле 3: зарезервировано, должно быть 0x00, 1 байт
Поле 4: тип адреса, 1 байт:

0x01: адрес IPv4

0x03: Доменное имя

0x04: адрес IPv6

Поле 5: адрес назначения

4 байта для адреса IPv4

1 байт длины имени, за которым следует 1-255 байт, имя домена

16 байт для адреса IPv6

Поле 6: номер порта в байтовом порядке сети, 2 байта

Ответ сервера:

Поле 1: версия протокола SOCKS, 1 байт (0x05 для этой версии)
Поле 2: статус, 1 байт:

0x00: запрос предоставлен

0x01: общий сбой

0x02: соединение запрещено с помощью набора правил

0x03: недоступна сеть

0x04: недоступен хост

0x05: соединение, отклоненное хостом назначения

0x06: срок действия TTL

0x07: команда не поддерживается/ошибка протокола

0x08: тип адреса не поддерживается

Поле 3: зарезервировано, должно быть 0x00, 1 байт
Поле 4: тип адреса, 1 байт: