Tips Home

Sambar Server Socks 5

 


Hoe belangrijk is Socks5 en wat kun je er mee doen lees het onderstaande,

SOCKS Overview

SOCKSv5 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 layer

image

What 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 Model

There 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:

SOCKSv4
SOCKSv5

Control flow of SOCKS

Figure 1 shows the SOCKSv5 control flow model. The portion within the dashed-line represents SOCKSv4 functionality. Note that SOCKSv5 adds authentication.

V4/V5 Comparison Diagram
Figure 1

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:

  • Transparent network access across multiple proxy servers
  • Easy deployment of authentication and encryption methods
  • Rapid deployment of new network applications
  • Simple network security policy management

Unique features and benefits with SOCKS

A single communication protocol authenticates users and establishes the communication channel

For each TCP or UDP communication channel that the SOCKS protocol establishes, it:

  • transfers user information from the SOCKS client to the SOCKS server for user authentication
  • authenticates the user and the channel, and
  • guarantees the integrity of TCP and UDP channels

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.

Application-Independent Proxy

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.

Flexible protection through a variety of access control policies

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.

Bi-directional proxy support

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 environment

This 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 port

Allowing 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:

int socket_handle;
struct sockaddr_in client_addr;
if ((socket_handle = socket(PF_INET, SOCK_DGRAM)) < 0) {
/* error handler */ }
memset((char *) &client_addr, 0, sizeof(client_addr));
client_addr.sin_family = PF_INET;
client_addr.sin_addr.s_addr = htonl(INADDR_ANY);
client_addr.sin_port = htons(0); /* let the OS select */
if (bind(socket_handle, (struct sockaddr *) &client_addr, sizeof(client_addr) < 0) {
/* error handler */ }
Many multimedia applications use multiple sockets. They send commands to one socket and receive data from other sockets. When the operating system selects the ports for the receiving sockets, the application must communicate the port to the server. The application can use the getsockname function to retrieve the operating system assigned port number. For multi-socket applications, use code similar to this fragment:
int socket_handle, len;
struct sockaddr_in client_addr_control, client_addr_data;
/* assume control session is established */
memset((char *) &client_addr_data, 0, sizeof(client_addr_data));
client_addr_data.sin_family = PF_INET;
client_addr_data.sin_addr.s_addr = htonl(INADDR_ANY);
client_addr_data.sin_port = htons(0); /* let the OS select */
if (bind(socket_handle, (struct sockaddr *) &client_addr_data, sizeof(client_addr_data) < 0) {
/* error handler */ }
len = sizeof(client_addr_data);
if (getsockname(socket_handle, (struct sockaddr *) &client_addr_data, &len) < 0)

Do not bind() connecting TCP sockets

Some 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:
int socket, socket_data, len;
struct sockaddr_in client_addr, client_addr_data;
/* establish socket */
if ((socket = socket(PF_INET, SOCK_STREAM)) < 0)
{ /* error handler */ }
memset((char *) &client_addr, 0, sizeof(client_addr));
client_addr.sin_family = PF_INET;
client_addr.sin_addr.s_addr = htonl(SERVER_ADDR);
client_addr.sin_port = htons(SERVER_PORT);
if (connect(socket, (struct sockaddr *) &client_addr, sizeof(client_addr)) < 0) {
/* error handler */ }

Establish a connection to the server before binding receiving sockets with multi-socket clients

Establish 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.
/* SOCKSv5 Friendly Example */
int socket_control, socket_data, len;
struct sockaddr_in client_addr_control, client_addr_data;
/* establish control socket */
if ((socket_control = socket(PF_INET, SOCK_STREAM)) < 0) {
/* error handler */ }
memset((char *) &client_addr_control, 0, sizeof(client_addr_control));
client_addr_control.sin_family = PF_INET;
client_addr_control.sin_addr.s_addr = htonl(SERVER_ADDR);
client_addr_control.sin_port = htons(SERVER_PORT);
if (connect(socket_control, (struct sockaddr *) &client_addr_control, sizeof(client_addr_control)) < 0) {
/* error handler */ }
/* connection to server established */
/* SOCKS can determine where to bind the data socket */
/* setup data socket */
if ((socket_data = socket(PF_INET, SOCK_DGRAM)) < 0) { /* could also be SOCK_STREAM */
/* error handler */ }
memset((char *) &client_addr_data, 0, sizeof(client_addr_data));
client_addr_data.sin_family = PF_INET;
client_addr_data.sin_addr.s_addr = htonl(INADDR_ANY);
client_addr_data.sin_port = htons(0); /* let the OS select */
if (bind(socket_data, (struct sockaddr *) &client_addr_data, sizeof(client_addr_data) < 0) {
/* error handler */ }
len = sizeof(client_addr_data);
if (getsockname(socket_data, (struct sockaddr *) &client_addr_data, &len) < 0)
/* start application protocol */

Use getsockname() to determine local IP address with multi-socket clients

This 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:

/* A SOCKSv5 Friendly Example */
/* Client needs to bind to a port and tell the */
/* application server where to make connection. */
int socket_control, socket_data;
struct sockaddr_in client_addr_control, client_addr_data;
/* Assume control session is established */
/* For multi-homed clients, bind to the same interface */
/* the control session uses, or bind may fail. */
len = sizeof(client_addr_control);
memset((char *) &client_addr_control, 0, sizeof(client_addr_control));
if (getsockname(socket_control, (struct sockaddr *) &client_addr_control, &len) < 0) {
/* error handler */ }
/* the struct client_addr_control now has the local IP addr */
if ((socket_data = socket(PF_INET, SOCK_DGRAM)) < 0) { /* could also be SOCK_STREAM */
/* error handler */ }
memset((char *) &client_addr_data, 0, sizeof(client_addr_data));
client_addr_data.sin_family = PF_INET;
client_addr_data.sin_addr.s_addr = client_addr_control.sin_addr.s_addr; /* same as control session */
client_addr_data.sin_port = htons(0); /* let the OS select */
if (bind(socket_data, (struct sockaddr *) &client_addr_data, sizeof(client_addr_data) < 0) {
/* error handler */ }
len = sizeof(client_addr_data);
if (getsockname(socket_data, (struct sockaddr *) &client_addr_data, &len) < 0)
/* the struct client_addr_data now has the correct */
/* IP address and port number */

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 servers

When 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


 

Polie Systems © 2003


Algemene gebruiksvoorwaarden