Tips Home | ||||
Sambar Server Socks 5 |
SOCKS OverviewSOCKSv5 is an IETF
(Internet Engineering Task Force) approved standard (RFC 1928) generic,
proxy protocol for TCP/IP-based networking applications. The SOCKS
protocol provides a flexible framework for developing secure
communications by easily integrating other security technologies.
SOCKS includes two components, the SOCKS server and the SOCKS client.
The SOCKS server is implemented at the application layer, while the
SOCKS client is implemented between the application and transport layers.
The basic purpose of the protocol is to enable hosts on one side of a
SOCKS server to gain access to hosts on the other side of a SOCKS
Server, without requiring direct IP-reachability. Place in OSI layerWhat is a SOCKS Proxy Server?When an application client needs to connect to an application server, the client connects to a SOCKS proxy server. The proxy server connects to the application server on behalf of the client, and relays data between the client and the application server. For the application server, the proxy server is the client.SOCKS ModelThere are two
versions of the SOCKS protocol, version 4 and version 5, SOCKSv4
and SOCKSv5,
respectively.
The SOCKSv4 protocol performs three functions: makes connection
requests, sets up proxy circuits, and relays application data. The
SOCKSv5 protocol adds authentication. For more information on SOCKS
versions 4 and 5, see: Control flow of SOCKSFigure 1 shows the SOCKSv5 control flow model. The portion within the dashed-line represents SOCKSv4 functionality. Note that SOCKSv5 adds authentication. |
Why SOCKS?Because of its
simplicity and flexibility, SOCKS has been used as a network firewall,
generic application proxy, in virtual private networks (VPN), and for
extranet applications.
SOCKSv5-based applications offer many advantages due to its strong,
yet flexible protocol framework:
For each TCP or UDP communication channel that the SOCKS
protocol establishes, it:
Most tunneling protocols separate the authentication process
and communication channel establishment, making it difficult to
guarantee the integrity of the channels with authenticated users
after multiple channels are established. As a generic proxy, the SOCKS protocol establishes
communication channels, and manages and protects the channel for
any application. As new applications come to market, SOCKS can
protect them without requiring additional development.
IP layer stateful inspection proxies require a new script for
protocol inspection, and application layer proxies require new
proxy software for each new application. IP routers deliver IP packets by routing packets at the IP
layer. Since SOCKS delivers TCP and UDP connections through a
proxy mechanism at the TCP/UDP layer, it works with any
application, and virtually all IP layer technologies, such as
firewalls, NAT, and private IP. SOCKS adds the flexibility to
manage the network through access control policies based on
user, application, and time, in addition to source and
destination addresses. Most IP layer-based proxy mechanisms, such as network address
translation (NAT), only support uni-directional proxy, from the
internal (private IP) network to external network (the
Internet). The proxy establishes the communication channel by
manipulating IP addresses, therefore, the IP addresses must be
routable on the Internet. These proxy mechanisms prevent
applications (i.e. multimedia and collaborative applications)
from establishing required return data channels (from the
Internet to the intranet). In addition, IP layer-based proxy
mechanisms need additional software modules for each application
that uses multiple channels.
SOCKS identifies communication targets through domain names,
overcoming the private IP address restrictions. SOCKS can also
use domain names to establish communication between separate
LANs with redundant IP addresses. Guidelines for networking applications in the SOCKSv5 environmentThis document outlines some programming techniques that network application developers can incorporate into their applications to help ensure that applications function as expected in the SOCKSv5 environment. We recommend that network application developers follow these simple guidelines when developing applications:
Client/server applications that observe these guidelines have a higher probability of inter-operating successfully with the SOCKSv5 server.
Allow the operating system to select the client portAllowing the operating system to select the client port alleviates problems that arise when two clients request the same port number. Although the port may be available on the client machine, it may not be available on the SOCKSv5 server. When the operating system selects the port, the client application binds successfully in the SOCKSv5 environment.UDP clients should use code similar to this fragment:
Do not bind() connecting TCP socketsSome applications bind TCP sockets before connecting. Connecting TCP sockets must allow the connect function to bind the socket. TCP sockets should use code similar to this code segment:
Establish a connection to the server before binding receiving sockets with multi-socket clientsEstablish a connection with the application server to allow it to determine where to bind the remaining sockets before creating sockets that receive data. Problems arise, especially in a multiple SOCKSv5 server environment, when applications create sockets that receive data before they establish a connection to the server.
Use getsockname() to determine local IP address with multi-socket clientsThis guideline pertains to the ftp protocol and other similar protocols that pass the client IP address as part of the protocol. Using gethostname() and gethostbyname() to determine the local IP address fails in the SOCKSv5 environment and on clients with more than one interface.Applications must use getsockname to determine their IP address. Use code similar to this fragment:
Do not use writev() or readv()The current implementation of SOCKSv5 does not include socksified versions of these functions. Applications that use these functions during an encrypted session fail.
Clients must initiate connections with the application serversWhen a SOCKS server protects a client, the client must initiate the connection to the server.The client will not propagate bind requests to the SOCKS server if no other connections exist. For additional information on creating SOCKSv5-Friendly applications, send your requests to: socks5-comments@socks5.com |