НОСКИ - SOCKS

Эта статья про интернет-протокол. Для использования в других целях см. Носки (значения).
Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

НОСКИ является Интернет протокол это обменивается сетевые пакеты между клиент и сервер через Прокси сервер. НОСКИ5 опционально предоставляет аутентификация поэтому только авторизованные пользователи могут получить доступ к серверу. Фактически, сервер SOCKS проксирует TCP-соединения с произвольным IP-адресом и предоставляет средства для пересылки UDP-пакетов.

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

История

Протокол был первоначально разработан / спроектирован Дэвидом Кобласом, системным администратором Компьютерные системы MIPS. После того, как MIPS был передан Силиконовая Графика в 1992 году Коблас представил доклад о SOCKS на симпозиуме по безопасности Usenix.[3], делая SOCKS общедоступными.[4] Протокол был расширен до версии 4 Ин-Да Ли из NEC.

Эталонная архитектура и клиент SOCKS принадлежат Permeo Technologies,[5] спин-офф от NEC. (Системы Blue Coat раскуплены Permeo Technologies.)

Протокол SOCKS5 изначально был протоколом безопасности, который брандмауэры и другие продукты безопасности, которые легче администрировать.[1] Он был одобрен IETF в 1996 г. [1] в качестве RFC 1928 (авторы: М. Лич, М. Ганис, Ю. Ли, Р. Курис, Д. Коблас и Л. Джонс). Протокол был разработан в сотрудничестве с Aventail Corporation, которая продает технологию за пределами Азии.[6]

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

НОСКИ это де-факто стандарт за межсетевые шлюзы (шлюзы 5 уровня).[7]

Природа SOCKS на уровне схемы / сеанса делает его универсальным инструментом для пересылки любого трафика TCP (или UDP, начиная с SOCKS5), создавая хороший интерфейс для всех типов инструментов маршрутизации. Его можно использовать как:

  • Инструмент обхода, позволяющий трафику обходить Интернет-фильтрацию для доступа к контенту, который в противном случае заблокирован, например, правительствами, рабочими местами, школами и веб-службами для конкретных стран.[8] Поскольку SOCKS очень легко обнаруживается, общий подход состоит в том, чтобы представить интерфейс SOCKS для более сложных протоколов:
    • В Tor Программное обеспечение onion proxy предоставляет своим клиентам интерфейс SOCKS.[9]
  • Обеспечение аналогичной функциональности виртуальная частная сеть, позволяя перенаправлять соединения в "локальную" сеть сервера:
    • Некоторые пакеты SSH, например OpenSSH, поддерживают динамическую переадресацию портов, которая позволяет пользователю создавать локальный прокси-сервер SOCKS.[10] Это может освободить пользователя от ограничений подключения только к заранее определенному удаленному порту и серверу.

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

НОСКИ работает на более низком уровне, чем HTTP-проксирование: SOCKS использует протокол рукопожатия для информирования программного обеспечения прокси о соединении, которое пытается установить клиент, а затем действует максимально прозрачно, тогда как обычный прокси может интерпретировать и переписывать заголовки (например, для использования другого базового протокола, такого как FTP; однако HTTP-прокси просто перенаправляет HTTP-запрос на желаемый HTTP-сервер). Хотя проксирование HTTP имеет в виду другую модель использования, СОЕДИНЯТЬ метод позволяет пересылать TCP-соединения; однако прокси SOCKS также могут пересылать UDP трафик и работа в обеспечить регресс, а HTTP-прокси - нет. Прокси-серверы HTTP традиционно лучше осведомлены о протоколе HTTP, выполняя фильтрацию более высокого уровня (хотя обычно это относится только к методам GET и POST, а не к методу CONNECT).[нужна цитата ]

НОСКИ

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

Подробнее о технических особенностях протокола SOCKS см. В разделах ниже.

HTTP

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

Протокол

НОСКИ4

Типичный запрос на соединение SOCKS4 выглядит так:

Первый пакет на сервер
VERCMDDSTPORTDSTIPЯ БЫ
Счетчик байтов1124Переменная
VER
Номер версии SOCKS, 0x04 для этой версии
CMD
код команды:
  • 0x01 = установить TCP / IP потоковое соединение
  • 0x02 = установить привязку порта TCP / IP
DSTPORT
2-байтовый номер порта (в сетевой порядок байтов )
DESTIP
IPv4 Адрес, 4 байта (в сетевом порядке байтов)
Я БЫ
строка идентификатора пользователя переменной длины, оканчивающийся нулем.
Пакет ответа от сервера
VNREPDSTPORTDSTIP
Счетчик байтов1124
VN
версия ответа, нулевой байт
REP
код ответа
БайтСмысл
0x5AЗапрос выполнен
0x5BЗапрос отклонен или не выполнен
0x5CЗапрос не удался, потому что клиент не работает с идентификатором (или недоступен с сервера)
0x5DЗапрос не удался, поскольку идентификатор клиента не смог подтвердить идентификатор пользователя в запросе
DSTPORT
порт назначения, имеет значение, если предоставлено в BIND, в противном случае игнорируется
DSTIP
IP-адрес назначения, как указано выше - ip: порт, к которому должен привязаться клиент

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

  • Клиент: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
    • Последнее поле - "Фред" в ASCII, за которым следует нулевой байт.
  • Сервер: 0x00 | 0x5A | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
    • 0xXX может быть любым байтовым значением. Протокол SOCKS4 указывает, что значения этих байтов следует игнорировать.

С этого момента любые данные, отправляемые от клиента SOCKS на сервер SOCKS, ретранслируются на 66.102.7.99 и наоборот.

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

SOCKS4a

SOCKS4a расширяет протокол SOCKS4, позволяя клиенту указывать доменное имя назначения, а не IP-адрес; это полезно, когда сам клиент не может преобразовать доменное имя целевого хоста в IP-адрес. Его предложил Ин-Да Ли, автор SOCKS4.[12]

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

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

Первый пакет на сервер
SOCKS4_CДОМЕН
Счетчик байтов8 + переменнаяПеременная
SOCKS4_C
Пакет подтверждения клиента SOCKS4 (см. Выше)
ДОМЕН
доменное имя хоста, с которым нужно связаться, переменной длины, нулевое (0x00) завершено

От сервера к клиенту SOCKS: (То же, что и SOCKS4)

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

НОСКИ5

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

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

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

Приветствие клиента
VERНАУТAUTH
Количество байтов11Переменная
VER
Версия SOCKS (0x05)
НАУТ
Количество поддерживаемых методов аутентификации, uint8
AUTH
Методы аутентификации, 1 байт на каждый поддерживаемый метод
Поддерживаемые методы аутентификации пронумерованы следующим образом:
  • 0x00: без аутентификации
  • 0x01: GSSAPI[13]
  • 0x02: Имя пользователя / пароль[14]
  • 0x03–0x7F: методы, назначенные IANA[15]
    • 0x03: протокол аутентификации вызов-рукопожатие
    • 0x04: не назначено
    • 0x05: Метод аутентификации запрос-ответ
    • 0x06: Уровень защищенных сокетов
    • 0x07: Аутентификация NDS
    • 0x08: Платформа мульти-аутентификации
    • 0x09: блок параметров JSON
    • 0x0A – 0x7F: не назначено
  • 0x80–0xFE: методы зарезервированы для частного использования
Выбор сервера
VERОСТОРОЖНО
Количество байтов11
VER
Версия SOCKS (0x05)
ОСТОРОЖНО
выбранный метод аутентификации или 0xFF, если приемлемые методы не были предложены

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

Запрос аутентификации клиента, 0x02
VERIDLENЯ БЫPWLENPW
Количество байтов11(1-255)1(1-255)
VER
0x01 для текущей версии аутентификации по имени пользователя и паролю
IDLEN, ID
Длина имени пользователя, uint8; имя пользователя как байтовая строка
PWLEN, PW
Длина пароля, uint8; пароль как байтовая строка
Ответ сервера, 0x02
VERПОЛОЖЕНИЕ ДЕЛ
Количество байтов11
VER
0x01 для текущей версии аутентификации по имени пользователя и паролю
ПОЛОЖЕНИЕ ДЕЛ
0x00 успех, иначе сбой, соединение должно быть закрыто

После аутентификации соединение может продолжаться. Сначала мы определяем тип данных адреса как:

SOCKS5 адрес
ТИПADDR
Счетчик байтов1Переменная
ТИП
тип адреса. Один из:
  • 0x01: IPv4-адрес
  • 0x03: доменное имя
  • 0x04: IPv6-адрес
ADDR
следующие адресные данные. В зависимости от типа:
  • 4 байта для IPv4-адреса
  • 1 байт длины имени, за которым следуют 1–255 байтов для имени домена.
  • 16 байт для IPv6-адреса
Запрос на подключение клиента
VERCMDRSVDSTADDRDSTPORT
Счетчик байтов111Переменная2
VER
Версия SOCKS (0x05)
CMD
код команды:
  • 0x01: установить соединение потока TCP / IP
  • 0x02: установить привязку порта TCP / IP
  • 0x03: связать порт UDP
RSV
зарезервировано, должно быть 0x00
DSTADDR
адрес назначения, см. структуру адресов выше.
DSTPORT
номер порта в сетевой порядок байтов
Пакет ответа от сервера
VERПОЛОЖЕНИЕ ДЕЛRSVBNDADDRBNDPORT
Счетчик байтов111Переменная2
VER
Версия SOCKS (0x05)
ПОЛОЖЕНИЕ ДЕЛ
код состояния:
  • 0x00: запрос выполнен
  • 0x01: общий сбой
  • 0x02: соединение не разрешено набором правил
  • 0x03: сеть недоступна
  • 0x04: хост недоступен
  • 0x05: соединение отклонено хостом назначения
  • 0x06: TTL истекший
  • 0x07: команда не поддерживается / ошибка протокола
  • 0x08: тип адреса не поддерживается
RSV
зарезервировано, должно быть 0x00
BNDADDR
привязанный к серверу адрес[16], в указанном выше формате "адрес SOCKS5"
BNDPORT
номер порта привязанного к серверу сетевой порядок байтов

Поскольку клиентам разрешено использовать либо разрешенные адреса, либо доменные имена, соглашение от cURL существует для обозначения варианта доменного имени SOCKS5 «socks5h», а другой - просто «socks5». Аналогичное соглашение существует между SOCKS4a и SOCKS4.[17]

Программного обеспечения

Серверы

Реализации прокси-сервера SOCKS

  • Веб-прокси-сервер Sun Java System - это кэширующий прокси-сервер, работающий на серверах Solaris, Linux и Windows, которые поддерживают HTTPS, фильтры ввода-вывода NSAPI, динамическую реконфигурацию, SOCKSv5 и обратный прокси.
  • WinGate - это многопротокольный прокси-сервер и SOCKS-сервер для Microsoft Windows, который поддерживает SOCKS4, SOCKS4a и SOCKS5 (включая UDP-ASSOCIATE и GSSAPI auth). Он также поддерживает передачу SOCKS-соединений прокси-серверу HTTP, поэтому может кэшировать и сканировать HTTP через SOCKS.
  • Socksgate5 SocksGate5 - это межсетевой экран SOCKS для приложений с функцией проверки на уровне 7 модели OSI, уровне приложений. Поскольку пакеты проверяются на уровне 7 OSI, межсетевой экран SOCKS приложения может искать несоответствие протокола и блокировать указанный контент.
  • Данте - это сервер SOCKS на уровне схемы, который можно использовать для обеспечения удобного и безопасного сетевого подключения, требуя, чтобы только хост, на котором работает Dante, имел подключение к внешней сети.[нужна цитата ]

Другие программы, обеспечивающие интерфейс сервера SOCKS

  • OpenSSH позволяет динамически создавать туннели, указанные с помощью подмножества протокола SOCKS, поддерживающего команду CONNECT.
  • PuTTY является клиентом Win32 SSH, который поддерживает локальное создание туннелей SOCKS (динамических) через удаленные серверы SSH.
  • ShimmerCat[18] - это веб-сервер, который использует SOCKS5 для моделирования внутренней сети, позволяя веб-разработчикам тестировать свои локальные сайты без изменения их / etc / hosts файл.
  • Tor это система, предназначенная для обеспечения анонимности в Интернете. Tor предлагает своим клиентам интерфейс сервера SOCKS только для TCP.
  • Shadowsocks это инструмент обхода цензуры. Он предоставляет интерфейс SOCKS5.

Клиенты

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

Носки

Соксификаторы позволяют приложениям получать доступ к сетям для использования прокси без необходимости поддержки каких-либо протоколов прокси. Наиболее распространенный способ - настроить виртуальный сетевой адаптер и соответствующие таблицы маршрутизации для отправки трафика через адаптер.

  • Win2Socks, который позволяет приложениям получать доступ к сети через SOCKS5, HTTPS или Shadowsocks.
  • tun2socks, инструмент с открытым исходным кодом, который создает виртуальные адаптеры TCP TUN из прокси-сервера SOCKS. Работает в Linux и Windows,[19] имеет порт macOS и повторную реализацию с поддержкой UDP в Голанг.
  • proxychains, программа Unix, которая заставляет TCP-трафик через SOCKS или HTTP-прокси в (динамически связанных) программах, которые она запускает. Работает на различных Unix-подобный системы.[20]

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

  • Polipo, прокси-сервер HTTP / 1.1 для пересылки и кеширования с IPv4 поддерживать. Открытый исходный код, работающий на GNU /Linux, OpenWrt, Windows, Mac OS X, и FreeBSD. Его может использовать практически любой веб-браузер.
  • Privoxy, не кэширующий прокси-сервер SOCKS-to-HTTP.

На основе докеров

  • многоводы [21], подход, основанный на Docker, который будет работать на любой платформе, на которой запущен Docker, с использованием клиента, сервера или того и другого для перевода прокси.

Рекомендации

  1. ^ а б c RFC 1928
  2. ^ «Реестр имени службы и номера порта транспортного протокола». Управление по присвоению номеров в Интернете. 19 мая 2017. Получено 23 мая 2017.
  3. ^ Коблас, Давид; Коблас, Мишель Р. НОСКИ (PDF). Симпозиум по безопасности USENIX UNIX III. Получено 16 ноября 2019.
  4. ^ Дармохрей, Тина. "Файерволы и сказки ".; ВХОД: Том 30, № 1.
  5. ^ Индекс архива на Wayback Machine
  6. ^ CNET: киберпространство из космоса
  7. ^ Опплигер, Рольф (2003). «Шлюзы контуров». Технологии безопасности для всемирной паутины (2-е изд.). Артек Хаус. ISBN  1580533485. Получено 21 января 2020.
  8. ^ «Отчет об использовании средств обхода за 2010 г.» (PDF). Центр Беркмана по Интернету и обществу при Гарвардском университете. Октябрь 2010 г.
  9. ^ "Tor FAQ".
  10. ^ "OpenSSH FAQ". Архивировано из оригинал на 2002-02-01.
  11. ^ «Протокол передачи гипертекста (HTTP / 1.1): синтаксис сообщений и маршрутизация». Получено 2014-08-01.
  12. ^ Инь-Да Ли. «SOCKS 4A: простое расширение протокола SOCKS 4». OpenSSH. Получено 2013-04-03.
  13. ^ «RFC 1961». Tools.ietf.org. Получено 2009-06-19.
  14. ^ «RFC 1929». Tools.ietf.org. Получено 2009-06-19.
  15. ^ IANA.org
  16. ^ «RFC 1928 - протокол SOCKS версии 5». Tools.ietf.org. Получено 2020-05-10.
  17. ^ "CURLOPT_PROXY". curl.se. Получено 20 января 2020.
  18. ^ «Easy Net с SOCKS5». shimmercat.com. ShimmerCat. Архивировано из оригинал на 2018-09-13. Получено 20 апреля 2016.
  19. ^ Бизжак, Амброз (20 января 2020 г.). "ambrop72 / badvpn: язык сценариев NCD, проксификатор tun2socks, P2P VPN". GitHub. Получено 20 января 2020.
  20. ^ Хамсик, Адам (20 января 2020 г.). "proxychains: инструмент, который заставляет любое TCP-соединение, созданное любым данным приложением, следовать через прокси, например TOR или любой другой прокси SOCKS4, SOCKS5 или HTTP (S)". GitHub. Получено 20 января 2020.
  21. ^ Мама, Грегорио (2020-08-24), gregoriomomm / docker-multsocks, получено 2020-08-29

внешняя ссылка