SOCKS standard overview
To properly configure a SOCKS server or client it is helpful to have a basic understanding of the SOCKS protocol and the operations it supports.
There are two versions of the SOCKS standard that are in common usage: SOCKS version 4 and SOCKS version 5. The first is more loosely defined than the second, for which there exists several RFCs (see the documentation page for an overview). There are some differences between the two protocol versions, but the basic operation is the same.
A SOCKS server works as a generic proxy that allows most application protocols to work through it, as opposed to application specific proxies, which are generally limited to a single application (such as HTTP, FTP, SIP, etc.). Whether an application can be supported or not depends both on the networking protocols it uses and how it uses them.
Most Internet-based networking applications use TCP and UDP, either as clients, servers, or both. A client application primarily sends requests to servers, and servers receive requests from clients. Some applications, such as P2P-applications and FTP clients using active mode, do both.
TCP-based client applications are not likely to experience any significant limitations by using the SOCKS protocol, while UDP-based applications may have some problems, depending on the SOCKS protocol. Servers can be supported, but less easily.
The functionality available in the two SOCKS protocol standard versions is as shown in the table below (note that this table shows what is available in the SOCKS protocol; SOCKS implementations might not support all the available functionality, i.e., the Dante 1.3.x implementation does not support IPv6):
Version 4 of the protocol does not support UDP, which is normally required to resolve symbolic host names to their IP address. Version 4A provides a work around for this, where the DNS resolution is performed in the SOCKS server rather than in the client, but this is not part of the version 4 protocol.
In general, SOCKS V4 works best if the client has direct access to a DNS server, and only needs to use the SOCKS proxy to open outgoing TCP connections, after having resolved the remote host address internally. Some DNS servers support TCP also however. If available, a SOCKS v4 client can resolve host names through these.
Version 5 of the SOCKS protocol has generic UDP support and does not suffer from the above limitations. Clients can communication via the SOCKS server with DNS-servers via UDP (or TCP). Having the SOCKS server resolve the host names in the same way as for SOCKS version 4A is also possible. Other UDP based protocols can additionally be used, which is not possible with SOCKS V4.
The two primary protocol operations are sending and receiving traffic. This corresponds to initiating and receiving connections for TCP, and sending and receiving packets for UDP. The SOCKS protocol is not really designed for the type of traffic reception found in servers, where an arbitrary number of clients connect to a single server port, but rather to the type of traffic reception found in some applications, such as active-mode FTP, where a single connection is expected from a known source. However, some SOCKS servers (such as Dante) support extensions to the SOCKS protocol that allow ordinary server applications to accept client requests via the SOCKS server.
Both version 4 and version 5 of the protocol allow the expected address of the host that will connect to a bound address to be provided to the server, which can then block connection attempts from other addresses. In practice, this does not work well because hosts can have multiple IP-addresses, causing the address of the actually received request to be unpredictable. For this reason, many SOCKS implementations are based on a liberal interpretation of this part of the SOCKS standard. The address of the remote host is however provided to the client, which can verify that it is from a host it wishes to communicate with, in the same way as if it was not running through a SOCKS server.
For TCP, a standard SOCKS BIND operation can only accept a single client, while a server based bind operation would allow new clients to be accepted as long as the SOCKS client was willing to receive them.
For UDP, bind operations are not supported. The SOCKS client must send the first UDP packet. The SOCKS client also has no direct way to know what address the SOCKS server uses to forward the UDP packets it sends. The support for the different protocol operations in the two protocols is as follows:
SOCKS V5 has the broadest support, and essentially support all TCP operations except generic server binding (the Dante SOCKS server has an extension which can be used to support this). The UDP support in the SOCKS protocol is more limited, but still adequate for many application types.
SOCKS server access control
Access control in the server can occur at three points. First, when clients connect to the SOCKS server, but before any protocol processing is performed. The information available in this case is the IP-address and port number of the client, and potentially a username obtained via RFC931 if it is used. Second, after SOCKS protocol processing, when authentication information such as a username and password provided by the client might be available. Third, for the BIND and UDPASSOCIATE operations, when a remote host attempts to connect or send a UDP packet to the SOCKS client via an association previously created by the client.
Different SOCKS server may differ in what level of detail and at what points access control can be applies. The Dante server supports application of access control at all three points mentioned above. A fourth point could also be possible, for inspection of the data traffic. We are not aware of any SOCKS servers providing inspection of data traffic, but it is conceivable to add it. (The Dante server can log the data traffic, but it does not actually inspect it from a security point of view.)
A SOCKS server can use the above information to control each of these operations. Depending on what the server supports, it is additionally possible to control traffic based on resource usage (i.e., bandwidth or number of simultaneous connections initiated by a specific user), content (data inspection), and other things.
UDP replies have the least possible number of alternatives for access control. The only access control that can be applied is based on the IP address, which can easily be faked in the UDP packet.