SOCKS

SOCKS — сетевой протокол сеансового уровня модели OSI, который позволяет пересылать пакеты от клиента к серверу через прокси-сервер прозрачно (незаметно для них) и таким образом использовать сервисы за межсетевыми экранами (файрволами).

Более поздняя версия SOCKS5 предполагает аутентификацию, так что только авторизованные пользователи получают доступ к серверу.

## Содержание

* 1 Введение
* 2 Протокол SOCKS 4
* 3 Протокол SOCKS 5
* 4 Реализации
* 5 См. также
* 6 Примечания
* 7 Ссылки

## Введение

[править | править код]

Клиенты за межсетевым экраном, нуждающиеся в доступе к внешним серверам, вместо этого могут быть соединены с SOCKS-прокси-сервером. Такой прокси-сервер управляет правами клиента на доступ к внешним ресурсам и передаёт клиентский запрос внешнему серверу. SOCKS может использоваться и противоположным способом, осуществляя управление правами внешних клиентов соединяться с внутренними серверами, находящимися за межсетевым экраном (брандмауэром).

В отличие от HTTP-прокси-серверов, SOCKS передаёт все данные от клиента, ничего не добавляя от себя, то есть, с точки зрения конечного сервера, данные, полученные им от SOCKS-прокси, идентичны данным, которые клиент передал бы напрямую, без проксирования. SOCKS более универсален, он не зависит от конкретных протоколов уровня приложений (7-го уровня модели OSI) и оперирует на уровне TCP-соединений (4‑й уровень модели OSI). Зато HTTP-прокси кэширует данные и может более тщательно фильтровать содержимое передаваемых данных.

Протокол был разработан системным администратором компании MIPS Дэвидом Кобласом (David Koblas). После того, как в 1992 году MIPS вошла в состав корпорации Silicon Graphics, Коблас сделал доклад о SOCKS на Симпозиуме по безопасности Usenix, и SOCKS стал публично доступным. Четвёртую версию протокола разработал Ин-Да Ли (Ying-Da Lee) из NEC.

SOCKS-серверы обычно используют порт 1080[1].

## Протокол SOCKS 4

[править | править код]

SOCKS 4 предназначен для работы через межсетевой экран без аутентификации для приложений типа клиент-сервер, работающих по протоколу TCP, таких, как Telnet, FTP и таких популярных протоколов обмена информацией, как HTTP, WAIS и Gopher. По существу, SOCKS-сервер можно рассматривать как межсетевой экран, поддерживающий протокол SOCKS.

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

Запрос клиента к SOCKS-Серверу:

Размер  | Описание

|

1 байт  | Номер версии SOCKS, 1 байт (для этой версии должен быть 0x04)
1 байт  | Код команды:

* 0x01 = установка TCP/IP соединения
* 0x02 = назначение TCP/IP-порта (binding)

2 байта  | Номер порта
4 байта  | IP-адрес
n+1 байт  | ID пользователя. Строка переменной длины, завершается NUL-байтом (0x00). Поле предназначено для идентификации пользователя (см. Ident)

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

Размер  | Описание

|

1 байт  | Версия кода ответа, которая должна быть равна 0
1 байт  | Код ответа:

* 0x5a = запрос предоставлен
* 0x5b = запрос отклонён или ошибочен
* 0x5c = запрос не удался, потому что не запущен identd (или не доступен с сервера)
* 0x5d = запрос не удался, поскольку клиентский identd не может подтвердить идентификатор пользователя в запросе

2 байта  | Номер порта
4 байта  | IP-адрес

## Протокол SOCKS 5

[править | править код]

SOCKS 5[2] — это несовместимое расширение протокола SOCKS 4. Он добавляет поддержку UDP, обеспечивает универсальные схемы строгой аутентификации и расширяет методы адресации, добавляет поддержку доменных имен и адресов IPv6. Начальная установка связи теперь состоит из следующего:

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

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

0x00 | Аутентификация не требуется

|

0x01 | GSSAPI
0x02 | Имя пользователя / пароль RFC 1929
0x03-0x7F | Зарезервировано IANA
0x03  | CHAP
0x04  | Не занято
0x05  | Вызов-ответ (аутентификация)
0x06  | SSL
0x07  | NDS аутентификация
0x08  | Фреймворк многофакторной аутентификации
0x09  | Блок JSON-параметров
0x0A–0x7F  | Не занято
0x80-0xFE | Зарезервировано для методов частного использования

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

Размер  | Описание

|

1 байт  | Номер версии SOCKS (должен быть 0x05 для этой версии)
1 байт  | Количество поддерживаемых методов аутентификации
n байт  | Номера методов аутентификации, переменная длина, 1 байт для каждого поддерживаемого метода

Сервер сообщает о своём выборе:

Размер  | Описание

|

1 байт  | Номер версии SOCKS (должен быть 0x05 для этой версии)
1 байт  | Выбранный метод аутентификации или 0xFF, если не было предложено приемлемого метода

Последующая идентификация зависит от выбранного метода.

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

Размер  | Описание

|

1 байт  | Номер версии SOCKS (должен быть 0x05 для этой версии)
1 байт  | Код команды:

* 0x01 = установка TCP/IP-соединения
* 0x02 = назначение TCP/IP-порта (binding)
* 0x03 = ассоциирование UDP-порта

1 байт  | Зарезервированный байт, должен быть 0x00
1 байт  | Тип адреса:

* 0x01 = адрес IPv4
* 0x03 = имя домена
* 0x04 = адрес IPv6

Зависит от типа адреса  | Назначение адреса:

* 4 байта для адреса IPv4
* Первый байт — длина имени, затем следует имя домена без завершающего нуля на конце
* 16 байт для адреса IPv6

2 байта  | Номер порта, в порядке от старшего к младшему (big-endian)

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

Размер  | Описание

|

1 байт  | Номер версии SOCKS (0x05 для этой версии)
1 байт  | Код ответа:

* 0x00 = запрос предоставлен
* 0x01 = ошибка SOCKS-сервера
* 0x02 = соединение запрещено набором правил
* 0x03 = сеть недоступна
* 0x04 = хост недоступен
* 0x05 = отказ в соединении
* 0x06 = истечение TTL
* 0x07 = команда не поддерживается / ошибка протокола
* 0x08 = тип адреса не поддерживается

1 байт  | Байт зарезервирован, должен быть 0x00
1 байт  | Тип последующего адреса:

* 0x01 = адрес IPv4
* 0x03 = имя домена
* 0x04 = адрес IPv6

Зависит от типа адреса  | Назначение адреса:

* 4 байта для адреса IPv4
* Первый байт — длина имени, затем следует имя домена без завершающего нуля на конце
* 16 байт для адреса IPv6

2 байта  | Номер порта, в порядке от старшего к младшему (big-endian)

## Реализации

[править | править код]

Список примеров в этой статье не основывается на авторитетных источниках, посвящённых непосредственно предмету статьи.

Добавьте ссылки на источники, предметом рассмотрения которых является тема настоящей статьи (или раздела) в целом, а не отдельные элементы списка. В противном случае список примеров может быть удалён.

|

* Sun Java System Web Proxy Server[англ.] — кеширующий прокси сервер для Solaris, Linux, Windows, поддерживает HTTPS, фильтры NSAPI I/O, динамическую реконфигурацию и обратный прокси.
* DeleGate — многофункциональный шлюз прикладного уровня и прокси-сервер, работающий на различных платформах, кроме SOCKS также поддерживает HTTP(S), FTP, NNTP, SMTP, POP3, IMAP, LDAP, Telnet, DNS и другие протоколы.
* 3proxy — лёгкий прокси-сервер с поддержкой SOCKS-proxy
* WinGate — многопротокольный прокси-сервер с поддержкой SOCKS для Windows.
* OpenSSH позволяет динамически создавать туннели, заданные через подмножество протокола SOCKS.
* Dante \- сервер SOCKS-прокси для Linux.

## См. также

[править | править код]

* Tor — анонимная сеть луковой маршрутизации с SOCKS-интерфейсом.

## Примечания

[править | править код]

1. ↑ Service Name and Transport Protocol Port Number Registry (неопр.). IANA. Дата обращения: 8 января 2016. Архивировано 3 марта 2016 года.
2. ↑ Marcus Leech <mleech@bnr.ca>. SOCKS Protocol Version 5 (англ.). tools.ietf.org. Дата обращения: 6 июня 2020. Архивировано 18 октября 2020 года.

## Ссылки

[править | править код]

* RFC 1928 (англ.) — SOCKS Protocol Version 5
* RFC 1929 (англ.) — Username/Password Authentication for SOCKS V5
* RFC 1961 (англ.) — GSS-API Authentication Method for SOCKS Version 5
* SOCKS: A protocol for TCP proxy across firewalls (англ.). — Протокол SOCKS 4. Архивировано из оригинала 17 июля 2023 года.