SOCKS протокол

Какое то время тому назад захотелось мне попробовать реализовать прокси сервер для собственных нужд, да такой, который можно было бы в дальнейшем использовать, а также, чтобы размер его был минимален. Естественным вариантом для меня стала реализация с использованием ассемблера. Программка получилась небольшая, удобная и в дальнейшем я очень часто ей пользовался. А вот теперь, по прошествии лет, хотелось бы показать простейшую реализацию одного протокола, SOCKS4. Данный протокол был создан для того, чтобы клиенты, находящиеся в локальной сети за межсетевым экраном могли обращаться во внешнюю сеть. В то же время запросы клиентов в таком случае есть возможность контролировать:) Самым первым, что нужно, при реализации – прочитать документацию с описанием данного протокола, так как мы хотим, чтобы наш протокол понимался стандартными программами, без “подтачивания напильником”. Итак, документация:

Теперь, вооружившись описанием, приступим. Работа прокси сервера состоит в том, чтобы принять от клиента запрос в определенном формате, сформировать сокет и подключить его по адресу запрошенному клиентом, после чего обеспечить обмен данными между двумя сокетами, до их закрытия со стороны сервера, либо клиента. Приступим к реализации.

Макросы и структуры данных, используемые в программе

Сформируем включаемый файл, includes.inc. В данный файл поместим стандартные, при написании Windows программ макросы + структуры для работы с SOCKS4. Здесь я не буду приводить все макросы, я приведу лишь описание и функционал, необходимый для решения основной задачи, все остальное вы найдете в приложенном файле с исходными кодами.
; SOCKS4 – Структура, используемая клиентом, при запросе соединения; на указанный сервер(DSTIP)/порт(DSTPORT) CONNECT_SOCK4 Struc VN Db ? CD Db ? DSTPORT Dw ? DSTIP Dd ? NULL Db ? CONNECT_SOCK4 Ends ; SOCKS4 - ответ прокси-сервера о соединении. RESPONSE_SOCK4 Struc VN Db ? CD Db ? DSTPORT Dw ? DSTIP Dd ? RESPONSE_SOCK4 Ends

По большому счету, структуры CONNECT_SOCK4 и RESPONSE_SOCK4 ничем не отличаются, так как мы реализуем протокол без авторизации. Но я решил все таки оставить их отдельно, чтобы в дальнейшем можно было легко изменить их, для доработки. В самих структурах, в переменной VN – указывается версия протокола, в нашем случае, здесь всегда должно быть 4, в случае с SOCKS5 в данной переменной находится 5 (протокол в принципе похож). Переменная CD используется для возврата клиенту результата запроса прокси сервера к запрошенному клиентом адресу (90 – соединение успешно / 91 – соединение не удалось).
У нас в программе по факту три этапа.
* Первый, инициализируем сокет, слушаем сокет на предмет наличия клиентских запросов, создаем поток обработки.
* Второй этап – анализ запроса клиента, попытка создания и соединения сокета с запрошенным клиентом сервером.
* И окончательный, третий этап – пересылка данных между сокетом клиента и сокетом созданным и соединенным нами с запрошенным адресом.

Реализация первого этапа, инициализация программы:

; Основная процедура, является стартовой для программы WinMain Proc LOCAL ThreadId, hServSock:DWORD LOCAL hostname :BYTE LOCAL _wsa:WSADATA LOCAL _our:sockaddr_in ; Запуск библиотеки работы с сокетами, мы используем функционал версии 1.1, ; запросим его как минимальный invoke WSAStartup, 0101h, ADDR _wsa .if eax == 0 ; Берем свой адрес, подготавливаем структуру, для инициализации серверного сокета invoke gethostname, ADDR hostname, 256 invoke gethostbyname, ADDR hostname .if eax == 0 invoke inet_addr, ADDR hostname .else mov eax, mov eax, mov eax, .endif mov _our.sin_addr, eax invoke inet_ntoa, eax mov _our.sin_family, AF_INET mov _our.sin_addr.S_un.S_addr, INADDR_ANY xor eax, eax ; Вносим порт, на котором хотим слушать входящие сообщения mov ax, SOCKS_PORT invoke htons, eax mov _our.sin_port, ax invoke socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET ; Сохраняем созданный серверный сокет mov hServSock, eax ; Привязываем серверный сокет к нашему адресу и необходимому порту invoke bind, hServSock, ADDR _our, SIZEOF sockaddr_in .if eax != SOCKET_ERROR @@: ; Инициируем сокет на ожидание invoke listen, hServSock, SOMAXCONN .repeat ; Пришел клиент, получаем сокет с пришедшим клиентом invoke accept, hServSock, NULL, NULL .until eax != INVALID_SOCKET ; Создаем поток, в котором будет обрабатываться текущий клиент xchg eax, ebx invoke CreateThread, NULL, NULL, ADDR socketThread, ebx, NULL, ADDR ThreadId ; Уходим на ожидание клиентов jmp @B .endif .endif invoke closesocket, hServSock .endif invoke ExitProcess, 0 WinMain Endp
Это первая наша процедура, я постарался максимально прокомментировать код, чтобы вы могли разобраться, но если все же что-то не понятно – обращайтесь либо ко мне, либо к MSDN. В принципе весь код написан с использованием синтаксиса MASM и WinAPI. Итогом работы приведенной функции должен быть работающий сокет на одном из сетевых адресов вашей машины (локальный адрес, либо внешний адрес если у вас реальный IP) + по соединению клиента функция создает отдельный поток, используемый для работы с пришедшим клиентом. Теперь пойдем дальше...

Второй этап, анализ запроса клиента

На втором этапе все, что необходимо сделать, это принять структуру CONNECT_SOCK4, создать сокет, попытаться соединить его и отправить клиенту ответ. Реализация:

SocketThread Proc sock:DWORD LOCAL lpMem, _csock, ThreadId, dAmount:DWORD LOCAL Remote:sockaddr_in LOCAL wrFds, rdFds:fd_set LOCAL hResp:RESPONSE_SOCK4 ; Готовимся к чтению данных из сокета invoke FdZero, ADDR rdFds invoke FdSet, sock, ADDR rdFds invoke select, NULL, ADDR rdFds, NULL, NULL, NULL ; Получаем размер ожидающих чтения данных invoke ioctlsocket, sock, FIONREAD, ADDR dAmount ; Резервируем память под данные mov lpMem, @Result(LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, dAmount) ; Читаем данные запроса из сокета invoke recv, sock, lpMem, dAmount, 0 ; Запрос пришел lea edi, hResp mov esi, lpMem ; В Esi лежит пользовательский запрос. Мы обрабатываем (здесь) только версию SOCKS4, ; SOCKS5 можно в принципе здесь же обработать, но это позже... Assume Esi: Ptr CONNECT_SOCK4 Assume Edi: Ptr RESPONSE_SOCK4 .if .VN == 4 ; Реализация протокола СОКС 4 .if .CD == 1 invoke socket, AF_INET, SOCK_STREAM, 0 .if eax != INVALID_SOCKET mov _csock, eax ; Берем данные удаленного хоста, с которым хочет соединиться клиент mov Remote.sin_family, AF_INET mov ax, .DSTPORT mov Remote.sin_port, ax mov eax, .DSTIP mov Remote.sin_addr, eax mov cx, .DSTPORT mov edx, .DSTIP ; В Edi лежит ответ пользователю mov .VN, 0 mov .DSTPORT, cx mov .DSTIP, edx ; Пытаемся соединиться с удаленным сервером invoke connect, _csock, ADDR Remote, SIZEOF Remote .if !eax ; Готовим ответ, что мы соединились mov .CD, 90 ; Отправляем клиенту ответ, содержащий результат попытки соединения invoke send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 ; Формируем структуру с информацией о серверном и; соединенном клиентском сокетах; - под серверным здесь подразумеваю сокет соединенный с клиентом, ; приславшим запрос; - под клиентским подразумеваю сокет соединенный с сервером, ; данные которого запросил клиент mov ebx, @Result(LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, SIZEOF THREAD_DATA) Assume Ebx: Ptr THREAD_DATA mov eax, _csock mov .Server, eax mov eax, sock mov .Client, eax Assume Ebx: Nothing ; Запускаем поток обработки сокетов (читающий из клиентского и; передающий в серверный сокет) invoke CreateThread, NULL, NULL, ADDR ClientSock, ebx, NULL, ADDR ThreadId .else ; Если соединение не получилось - закрываем клиентский сокет invoke closesocket, _csock ; Говорим, что произошла ошибка соединения mov , 91 ; Отправляем клиенту ответ, содержащий результат попытки соединения invoke send, sock, ADDR hResp, SIZEOF RESPONSE_SOCK4, 0 .endif .endif .endif .endif Assume Edi: Nothing Assume Esi: Nothing ; Высвобождаем память, выделенную под запрос invoke LocalFree, lpMem ret socketThread Endp
Результат выполнения данной процедуры – соединенный сокет, а также созданный поток, реализующий обмен данными между двумя сокетами. Все просто. Стоит только уточнить, здесь используется несколько моментов по адресации внутри структур, которые введены в MASM для облегчения жизни программиста. Первый момент, макрос “Assume”.
Строчка Assume Esi: Ptr CONNECT_SOCK4 говорит компилятору о том, что в данном регистре(Esi) находится адрес структуры CONNECT_SOCK4, что в дальнейшем упрощает обращение к переменным внутри данной структуры. Assume Esi:Nothing отменяет привязку. Чтобы лучше понять, возможно будет проще, если я укажу несколько вариантов адресации:
Assume Esi:Ptr CONNECT_SOCK4 mov al, .VN ; Помещаем в AL значение байта из переменной VN структуры mov al, .CD ; Помещение в AL переменной CD mov ax. .DSTPORT ; Помещение в AX переменной DSTPORT Assume Esi:Nothing
либо
mov al, ; Помещаем в AL значение байта из переменной VN mov al, ; Помещение в AL переменной CD mov ax, ; Помещение в AX переменной DSTPORT
либо
mov al, byte ptr ; Помещение в AL переменной VN mov al, byte ptr ; Помещение в AL переменной CD mov ax, word ptr ; Помещение в AX переменной DSTPORT

Я думаю, вам очевидно так же как и мне, что быстрее, удобней и наглядней использовать первый вариант. Хотя если необходимо обратиться к одной переменной структуры – имеет право на существование и второй вариант. Третий же вариант думаю лучше использовать в случаях, когда данные по адресу не структурированы. Но, как известно, на вкус и цвет, каждый сам себе тамбовский волк. Пользуйтесь тем методом, который вам удобней.
Еще один момент, который стоит уточнить. Макрос Result . Данный макрос написан, чтобы можно было одной строкой вызвать функцию WinAPI и занести результат исполнения в регистр или память. Так строка:
mov lpMem, @Result(LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, dAmount)
Выполняет сначала вызов такого вида:
invoke LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, dAmount
а уже после выполнения данного вызова результат исполнения (Eax) заносит в переменную lpMem. В данном конкретном случае, будет выделена память, а в переменную будет записан адрес, по которому находится выделенный для нас участок.

Этап третий, передача данных

Итак, выполнены два самых сложных этапа. Клиент пришел, мы соединили его с удаленным сервером и настал черед простейшей “обезьяньей” работы. Передачи данных между двумя сокетами. Сделаем это просто, по-быстрому:
; Поток читающий из клиентского и передающий в серверный сокет.... ClientSock Proc Param:DWORD LOCAL sserver, sclient:DWORD LOCAL rdFds:fd_set LOCAL dAmount, lpBuf: DWORD ; В Param у нас находится информация о сокетах сервера и клиента, ; переносим в локальные переменные mov ebx, Param Assume Ebx: Ptr THREAD_DATA mov eax, .Server mov sserver, eax mov eax, .Client mov sclient, eax Assume Ebx: Nothing ; Не забудем высвободить память invoke LocalFree, Param @@: invoke FdZero, ADDR rdFds invoke FdSet, sserver, ADDR rdFds invoke FdSet, sclient, ADDR rdFds invoke select, NULL, ADDR rdFds, NULL, NULL, NULL ; Проверяем, есть ли данные для чтения.if eax == SOCKET_ERROR || eax == 0 ; Данных нет - выходим jmp @F .endif ; Есть ли данные от сервера, которые нужно передать клиенту? invoke FdIsSet, sserver, ADDR rdFds .if eax ; Получаем размер ожидающих чтения данных invoke ioctlsocket, sserver, FIONREAD, ADDR dAmount ; Резервируем память под данные mov lpBuf, @Result(LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, dAmount) invoke recv, sserver, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif invoke send, sclient, lpBuf, eax, 0 invoke LocalFree, lpBuf .endif ; Есть ли данные от клиента для отправки серверному сокету? invoke FdIsSet, sclient, ADDR rdFds .if eax ; Получаем размер ожидающих чтения данных invoke ioctlsocket, sclient, FIONREAD, ADDR dAmount ; Резервируем память под данные mov lpBuf, @Result(LocalAlloc, LMEM_FIXED or LMEM_ZEROINIT, dAmount) invoke recv, sclient, lpBuf, dAmount, 0 .if eax == SOCKET_ERROR || eax == 0 jmp @F .endif invoke send, sserver, lpBuf, eax, 0 invoke LocalFree, lpBuf .endif ; Идем на новый цикл jmp @B @@: ; Закрываем сокеты invoke closesocket, sserver invoke closesocket, sclient ; Выходим из потока invoke ExitThread, 0 ClientSock Endp
Первоначально в данной процедуре производится инициализация внутренних переменных из переданной в поток структуры, чтобы их было удобнее использовать. Затем, в цикле производится проверка, есть ли данные на чтение из сокетов, затем двумя кусками кода (фактически копипаст, здесь я не заморачивался выносом функции и оптимизацией ибо так наглядней) делается чтение из одного сокета и отправка во второй.
Все, ура! Компилируем и пробуем. В принципе самый хороший вариант – FireFox. В настройках подключения указываем, что нужно использовать прокси сервер SOCKS4. Указываем его адрес и порт, на котором он у нас находится. После этого, сохраняем настройки и наслаждаемся интернетом, прошедшим, через наш прокси, размером 3,5 кбайт))) Да, уточню. Для компиляции жлательно наличие установленного пакета

При работе с прокси очень важно выбрать правильный тип прокси под ваши задачи, чтобы избежать возможных проблем и достигнуть поставленных целей. Чаще всего используются HTTP прокси и Socks5 прокси. Отличия между ними заключаются в степени анонимности, используемому протоколу, способу передачи данных, используемых при работе прокси, а также в некоторых дополнительных функциях. Давайте разберём каждый тип прокси отдельно.

Особенности HTTP прокси

Начнём с HTTP прокси. При своей работе они используют HTTP протокол, который предназначен для посещения сайтов, загрузки и передачи файлов, и при работе с некоторыми программами, которые используют этот протокол для соединения через прокси. Запросы, выполняемые при работе с HTTP прокси серверами, не отправляются напрямую, а используют прокси сервер как посредника, отправляя запросы от его имени.

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

Прокси этого протокола отличаются по степени анонимности. Выделяются следующие типы HTTP прокси по анонимности:

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

Анонимные Прокси. Передают информацию о том, что используются прокси, однако, ваш IP адрес маскируется и подменяется другим IP адресом, предоставляя надёжный уровень безопасности.

Элитные прокси. Скрывают использование прокси, а также надёжно маскируют IP адрес, что делает их самыми безопасными среди HTTP прокси. Сервер, к которому вы попытаетесь получить доступ будет считать, что ваше подключение осуществляется напрямую, без использования прокси сервера.

Отдельно стоит выделить HTTPS прокси, которые используют протокол SSL. Они представляют собой подвид HTTP протокола, который использует защищённое соединение. Сетевой трафик, передаваемый этими прокси надёжно зашифрован, что гарантирует высочайший уровень анонимности. Как правило, такие прокси используются для обеспечения безопасности банковских сетей, в коммерческих организациях для создания безопасных корпоративных сетей и в прочих подключениях, требующих безопасности. Остальные особенности такие же, как и у HTTP протокола.

Особенности Socks5 прокси

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

Socks5 прокси, поддерживают следующие сетевые протоколы: HTTP, HTTPS, FTP и их особенности: кеширование, SSL соединение, аутентификация. Помимо этого, прокси протокола Socks5 используют UDP и TPC соединения, что расширяет сферу их применения и делает их наиболее функциональными из современных прокси серверов. Изначально Socks5 протокол предназначался для работы с программным обеспечением. По этой причине, большинство программ поддерживает этот протокол для подключения через прокси. А ещё прокси сервера Socks5 имеют приятную особенность, которая позволяет выстраивать цепочки из прокси серверов, что полезно для решения некоторых задач при работе в интернете.

Если сравнивать прокси HTTP и Socks5, то предпочтительней использовать вторые. Так как они анонимней, поддерживают больше функций, а также работают с любыми сайтами и программами, поддерживающие соединение через прокси. вы можете у нас на сайте, оформив заказ в личном кабинете.

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

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

Этот протокол был разработан Дэвидом Кобласом (David Koblas), системным администратором MIPS Computer Systems. После того, как в году MIPS вошла в состав Silicon Graphics (SGI), Коблас сделал доклад о SOCKS на Симпозиуме по Безопасности Usenix (Usenix Security Symposium), и SOCKS стал публично доступным. Протокол был расширен до четвёртой версии Ин-Да Ли (Ying-Da Lee) из NEC Systems Laboratory.

Протокол SOCKS 4

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

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

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

• поле 1: номер версии SOCKS, 1 байт (должен быть 0x04 для этой версии)
• поле 2: код команды, 1 байт:
  • 0x02 = назначение TCP/IP порта (binding)
• поле 3: номер порта, 2 байта
• поле 4: IP-адрес , 4 байта
• поле 5: ID пользователя, строки переменной длины, завершается null-байтом (0x00). Поле предназначено для идентификации пользователя (см. Ident)

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

• поле 1: null-байт
• поле 2: код ответа, 1 байт:
  • 0x5a = запрос предоставлен
  • 0x5b = запрос отклонён или ошибочен
  • 0x5c = запрос не удался, потому что не запущен identd (или не доступен с сервера)
  • 0x5d = запрос не удался, поскольку клиентский identd не может подтвердить идентификатор пользователя в запросе
• поле 3: 2 произвольных байта, должны быть проигнорированы
• поле 4: 4 произвольных байта, должны быть проигнорированы

Протокол SOCKS 5

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

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

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

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

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

• поле 2: количество поддерживаемых методов аутентификации, 1 байт
• поле 3: номера методы аутентификации, переменная длина, 1 байт для каждого поддерживаемого метода

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

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

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

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

• поле 1: номер версии SOCKS (должен быть 0x05 для этой версии)
• поле 2: код команды, 1 байт:
  • 0x01 = установка TCP/IP соединения
  • 0x02 = назначение TCP/IP порта (binding)
  • 0x03 = ассоциирование UDP-порта
• поле 3: зарезервированный байт, должен быть 0x00
• поле 4: тип адреса, 1 байт:
  • 0x01 = адрес IPv4
  • 0x03 = имя домена
  • 0x04 = адрес IPv6
• поле 5: назначение адреса
  • 4 байта для адреса IPv4
  • 16 байт для адреса IPv6
• поле 6: номер порта, 2 байта

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

• поле 1: номер версии SOCKS, 1 байт (0x05 для этой версии)
• поле 2: код ответа, 1 байт:
  • 0x00 = запрос предоставлен
  • 0x01 = ошибка SOCKS-сервера
  • 0x02 = соединение запрещено набором правил
  • 0x03 = сеть недоступна
  • 0x04 = хост недоступен
  • 0x05 = отказ в соединении
  • 0x06 = истечение TTL
  • 0x07 = команда не поддерживается / ошибка протокола
  • 0x08 = тип адреса не поддерживается
• поле 3: байт зарезервирован, должен быть 0x00
• поле 4: тип последующего адреса, 1 байт:
  • 0x01 = адрес IPv4
  • 0x03 = имя домена
  • 0x04 = адрес IPv6
• поле 5: назначение адреса
  • 4 байта для адреса IPv4
  • первый байт - длина имени, затем следует имя домена без завершающего нуля на конце
  • 16 байт для адреса IPv6
• поле 6: номер порта, 2 байта

Реализации

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

См. также

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

Ссылки

• RFC 1928 (англ.) - SOCKS Protocol Version 5
• RFC 1928 (рус.) - Протокол SOCKS 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

Wikimedia Foundation . 2010 .

Смотреть что такое "SOCKS" в других словарях:

SOCKS - is an Internet protocol that allows client server applications to transparently use the services of a network firewall. SOCKS is an abbreviation for SOCKetS [ ]… … Wikipedia

SOCKS - Saltar a navegación, búsqueda SOCKS es un protocolo de Internet que permite a las aplicaciones Cliente servidor usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de SOCKetS . Los clientes que hay detrás… … Wikipedia Español

Сетевой протокол, который позволяет клиент серверным приложениям прозрачно использовать сервисы за межсетевыми экранами (фаерволами). SOCKS это сокращение от «SOCKetS» (сокеты, гнёзда). Клиенты за межсетевым экраном, нуждающиеся в доступе к… … Википедия

Socks - im Briefing Room des Weißen Hauses Betty Currie und Socks … Deutsch Wikipedia

Socks - sobre el pupitre de la Sala de Prensa de la Casa Blanca. Socks (en español: Calcetines, marzo de 1989 20 de febrero de 2009) fue el gato de la familia del Presidente de los Estados Unidos Bill Clinton durante su presidencia. Fue la única mascota… … Wikipedia Español

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

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

Общее и подробное описание SOCKS

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

Он передает данные, полученные от первого клиента второму и обратно. В отличии от , через SOCKS прокси можно пустить любой трафик (скажем, ). Кроме того SOCKS передает "чистые" данные, не добавляя от себя ничего лишнего, поэтому его сложнее выявить.

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

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

Послесловие

Вот такие дела. Надеюсь теперь Вам хотя бы примерно понятно, что это такое вообще и зачем оно в общем и целом может быть необходим.

О том, как конкретно работать с SOCKS и прочими прокси для скрытия своего IP будет написано в отдельной статье, если конечно она кому-то будет нужна и интересна.

Как и всегда, если остались какие-то вопросы, мысли, дополнения и всё такое прочее, то добро пожаловать в комментарии к этому материалу.