|Скачиваем||Регистрация||Сервис||SP в каталогах||Форум||Карта сайта|
|Сборник статей||Настройка||Примеры настройки приложений||Конфигурирование пользователей||Автозапуск
Управление системным сервисом
|Ограничение скорости (шейпер)||Ограничение трафика||Ограничение времени доступа к порту|
SmallProxy - SOCKS: From Wikipedia, the free encyclopedia
|Сборник статей||Использование различных видов Socks прокси серверов||Авторское название статьи "Всё о прокси"||Анонимность в Internet: анонимайзеры, прокси, socks||Сокс прокси|
|SOCKS: A protocol for TCP proxy across firewalls (eng)||SOCKS: Материал из Википедии — свободной энциклопедии||SOCKS: From Wikipedia, the free encyclopedia (eng)||SOCKS Protocol Version 5 (eng)||RFC 1928 - Протокол SOCKS 5|
|Определение разрыва TCP-соединения||Winsock (для UNIX, Windows-95, -NT, -98 и -XP)||Сниффер: щит и меч|
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"
Clients behind a firewall, needing to access exterior servers, may connect to a SOCKS proxy server instead. Such a proxy server controls the eligibility of the client to access the external server and passes the request on to the server. SOCKS can also be used in the opposite way, allowing the clients outside the firewall ("exterior clients") to connect to servers inside the firewall (internal servers).
The protocol was originally developed by David Koblas, a system administrator of MIPS Computer Systems. After MIPS was taken over by Silicon Graphics in 1992, Koblas presented a paper on SOCKS at that year's Usenix Security Symposium and SOCKS became publicly available. The protocol was extended to version 4 by Ying-Da Lee of NEC.
The SOCKS reference architecture and client are owned by Permeo Technologies, (note that Permeo Technologies has been bought out by Blue Coat Systems) a spin-off from NEC
SOCKS performs at Layer 5 of the OSI model - the Session Layer (an intermediate layer between the presentation layer and the transport layer).
A typical SOCKS 4 connection request looks like this (each number is one byte):
Client to SOCKS Server:
Server to SOCKS client:
This is a SOCKS 4 request to connect Fred to 184.108.40.206:80, the server replies with an "OK".
From this point on any data sent from the SOCKS client to the SOCKS server will be relayed to 220.127.116.11 and vice versa.
The command field can be 0x01 for "connect" or 0x02 for "bind". "bind" allows incoming connections for protocols like active FTP.
SOCKS 4a is a simple extension to SOCKS 4 protocol that allows a client that cannot resolve the destination host's domain name to specify it.
The client should set the first three bytes of DSTIP to NULL and the last byte to a non-zero value (This corresponds to IP address 0.0.0.x, with x nonzero, an inadmissible destination address and thus should never occur if the client can resolve the domain name). Following the NULL byte terminating USERID, the client must send the destination domain name and terminate it with another NULL byte. This is used for both "connect" and "bind" requests.
Client to Socks Server:
Server to SOCKS client:
A server using protocol 4A must check the DSTIP in the request packet. If it represents address 0.0.0.x with nonzero x, the server must read in the domain name that the client sends in the packet. The server should resolve the domain name and make connection to the destination host if it can.
The SOCKS 5 protocol, an extension of the SOCKS 4 protocol that offers more choices of authentication, is defined in RFC 1928. The initial handshake now consists of the following:
The authentication methods supported are numbered as follows:
The initial greeting from the client is:
The server's choice is communicated:
The subsequent authentication is method-dependent.
The client's connection request is: