Penetrate the UDP of SOCKS5

In network programming, UDP is used as the data transmission protocol for scenarios with high real-time data transmission requirements, in the TCP/IP protocol family, UDP protocol requires less network system resources than TCP protocol. However, in enterprise applications, due to network security reasons, IP data other than specific ports cannot pass through dedicated routes or gateways. To support such applications, a special socks4/socsk5 protocol is developed to support socks connections. The SOCKS protocol allows the proxy software that implements such functions to allow the firewall (the name of the firewall and the proxy in the following content can be equivalent to that in this article) to allow internal customers to access the outside through the firewall, you can even wait for external connections. For software clients inside the firewall, they only negotiate with the firewall, get in touch with the firewall's specific port, and then exchange data, while the firewall's external programs directly exchange data with the firewall, the firewall's intranet is invisible to the outside, which enables firewall monitoring and meets the needs of most applications that exchange data through frequently-used (such as http ftp) ports. How can an application inside the firewall transmit UDP data to the outside of the firewall through the firewall and accept external UDP data packets? This is the so-called UDP programming through socks proxy.

Rfc1928 describes the SOCKS protocol details and tells us how the customer program negotiates with the socks proxy to obtain the external transmission path through the Protocol. The English URL is "Hangzhou" (but the translator is still worthy of respect), but it is not good for E. You can refer to http://www.china-pub.com/computers/emook/0541/info.htm. We recommend that you first read the above link and then read the following content.

Generally, the agent software implements two versions of socks protocols-socks4 and SOCKS5. The SOCKS5 protocol supports UDP packet transmission and multiple verification methods. This Protocol also takes into account IP development needs, IPv6 is supported.

TCP supports two methods through proxy: bind and connection. Connection refers to a service program that actively connects to the agent outside the client. In this way, the agent will replace the client program to initiate a real connection to the external service program, and transmit the data that needs to be communicated back and forth in this connection. The bind method is used in the protocols that require the client to accept the connection to the server, for example, in addition to setting up a client-server connection Report status for the FTP protocol, you also need to establish a server-client connection to transmit actual data (of course, note that the FTP protocol is used to connect to a remote host through socks, rather than through the FTP Proxy protocol ). UDP packet transmission means that the proxy acts as the intermediary for UDP data transmission, transmits the data of hosts in the firewall to external entities, and transfers the UDP data packets that need to be introduced into the firewall to the firewall-specific hosts. There are many discussions and examples about TCP penetration (an example of implementation: http://www.codeproject.com/internet/casyncproxysocket.asp), so I will not talk about it much. Here I will focus on How to Implement UDP data penetration through the SOCKS5 proxy.

For the convenience of testing, I simply wrote a service process with an IP address of 192 outside the proxy. 168. 0. 250 listens to the udp8100 port, receives a UDP datagram, and returns the current time on the server to the client that sends the UDP packet. The proxy uses Wingate, Which is 192. 168. 0. 1. The socks standard port 1080 is used to run the service listener. My machine is 192. 168. 0. 10. You can see that I cannot directly contact the machine running the time service. I will ask the proxy to forward UDP data packets. The proxy software selects Wingate, and does not need to verify the customer's verification method for the sake of simplicity. Now, after explaining the background, let's start our journey through proxy.

For TCP or UDP, contact the proxy first. To ensure smooth data transmission in the first stage, the Protocol stipulates that the client uses TCP to connect to the proxy server.

Once the customer connects to port 1080 of the proxy, the customer first needs to send a version ID/method selection TCP packet to the proxy server. The specific format is:

　　Version Number(1 byte) |Available authentication methods(1 byte) |Method Sequence(1-255 bytes)

For the socks4 protocol, the version number is 0x04, But UDP SOCKS5 is supported here, so it is a byte of 0x05. This description also applies to the versions of the subsequent Message format interpretation.

SOCKS Protocol defines five proxy authentication methods:

0x00 no verification required

0x01 universal security service application interface (gssapi)

0x02 user name/password (username/password)

0x03 to X '7f' IANA allocation (IANA assigned)

0x80 to X 'fe 'private method reserved for private methods)

0xff unacceptable method (no acceptable methods)

Obviously, neither the client initiating a SOCKS request or the proxy responsible for forwarding socks data can fully implement all (at least not yet) methods, therefore, the client needs to list the methods that can be supported by the proxy server. If no verification is supported, the byte sequence of the message is: 0x05 0x01 0x00. 0x01 indicates that the client only supports one verification, 0x00 indicates that the supported method is 0x00 (without verification. If the client also supports user name/password authentication, the message should be: 0x05 0x02 0x00 0x02.

When the proxy receives a request from the customer, it will tell the customer which method is used for verification based on the implementation of its own system. The returned warranty format is:

 Version Number|Method selected by the server

If the server only supports verification without verification, it returns the byte sequence: 0x05 0x00. The back-and-forth response of the data packets of the client and the proxy is the selection phase of the SOCKS protocol authentication method.

The next step is to verify the customer's identity based on the selected method. Although we do not need to verify it here, let's briefly talk about the format of the message sent by the client using the username/password of 0x02:

0x01 |Username Length(1 byte) |User Name(Length is specified based on the username length field) |Password Length(1 byte) |Password(The length is specified by the password length field)

It is unclear why the first byte of the packet is 0x01 (it should be 0x05 by Convention ). The length of the entire message is determined by the actual length of the user name and password. The user name and password do not need to end with '/0. The server verifies the information provided and returns the following bytes sequence image:

0x01 |Verification Result flag

The verification result flag can be: 0x00, And the rest indicate a fault. You cannot proceed to the next protocol step.

After the verification step is passed, the next step is to determine the UDP transmission port. Two important ports must be identified: 1,Client sendingUDPLocal port of dataOn the one hand, you can specify a port for sending data, and on the other hand, tell the proxy that if data is returned, it is passed to the port to form a UDP Transmission Loop. 2,The port on which the customer sends the messageUDPDatagramAs the requester of an external UDP socket, both parties negotiate to determine a port through which data can be continuously sent to the external host, you can also use this port to receive UDP data from the external host by the proxy, and then send it to the UDP sending request client through this port. The client sends the TCP Data byte sequence in the following format:

Protocol version|SocksCommand|Reserved bytes|Address type|Specific address|Specific Port

There are three socks commands: connect (0x01) bind (0x02) UDP (0x03)

The reserved byte length is 1, which is 0x00.

There are three address types:

0x01 The address is an IPv4 address with a length of 4 8-bit bytes.

0x03 this address contains a complete domain name. The first 8-bit byte contains the number of 8 bits in the subsequent name, but does not abort '/0 '.

0x04 this address is an IPv6 address with a length of 16 8-bit bytes.

A specific address is generally meaningful to hosts with multiple IP addresses. If you do not initiate or do not care about which IP address initiates UDP data transmission, you can enter 0. 0. 0. 0. Select 0x01 as the address type. The most important thing is the UDP port from which UDP transmission will be initiated. Generally, in order to avoid a conflict caused by a hard port, a UDP socket is first formed and the established port of the socket is used as the port for UDP transmission, the proxy server is notified through this step. For example, to generate a UDP socket temporarily, select the port for UDP

2233 is used as the local port for UDP data transmission, so this packet is: 0x05 0x03 0x00 0x00 0x00 0x00 0x00 0x08 0xb9 where 0x08 0xb9 is converted into a 10 hexadecimal value of 2233.

The proxy server will provide a response byte sequence for the proxy server port based on the port usage, telling the customer that UDP data can be sent to this address and port, to Implement UDP penetration proxy. The returned byte sequence is:

Version|Proxy response|Retained1Bytes|Address type|Proxy server address|Bound proxy Port

The proxy response can be a value:

0x00 negotiation successful

0x01 common socks faults

0x02 connection Not Allowed

0x03 The network is not reachable

0x04 The host cannot arrive

0x05 Connection Reset

0x06 TTL invalid

The 0x07 command is not supported.

0x08 address type not supported

0x09 till 0xff are retained

The proxy address refers to the IP address that the client needs to send, and the bound port refers to the port on which the proxy will receive and forward data for the customer. For the address type and address, refer to the above explanation.

After the preceding TCP negotiation steps, the client now makes it clear that it sends the UDP data to a port of an IP address of the proxy server. The proxy server also knows which IP address sends a datagram to itself. If a datagram is received from the remote target host because the UDP datagram is forwarded, he needs to return the received datagram to the customer's specific port according to the protocol. This specific port is the proxy port bound to the byte sequence in this step.

During UDP data transmission, because UDP data is transmitted through a proxy, it needs to be packaged in a certain format. Add a header before the data to be transmitted, specifically:

Retain 2Byte 0|Indicates whether the data is segmented and reorganized.|Address type|Target address to be sent out of proxy|Port of the remote target host|Data to be transmitted by proxy

Whether the packet segment reorganization flag is 0 indicates that the data packet is independent and does not need to be combined. Others indicate the specific serial number to facilitate UDP message integration.

The address here is the server address outside the proxy that finally receives the UDP data. In this example, It is 192. 168. 0. 250. Port 8100. The starting position of data to be transmitted varies depending on the address type. If it is IPv4, the data starts from 10 bytes of the UDP message. If the domain name is specified, the data starts from 262, the IPv6 address type starts from 20 as a data field. We need to pay attention to these issues during actual data transmission. If you want to transmit 10 bytes of data 9 to port 1024 of 96.96.96.96, the transmitted data byte sequence is roughly:

00 0000 0160 60 60 6004 0009 09 ....... 09

Whether to segment and reorganize IPv4 96.96.96.96 destination host IP port 1024 as data

After that, if data is returned from the remote target host, the proxy server will encapsulate the data when it returns the data to the UDP client, that is, add a header. The client needs to receive this header, but it also explicitly notifies the UDP client which server sends the datagram back.

Let's take a look at the code: See the appendix project. I will write UDP that supports SOCKS5 into a Java class for your reference. For more information, see the comments section.

Through the above analysis, we can summarize the following points of attention for UDP programming through SOCKS5:

1. Authentication for SOCKS5 Programming

Because the firewall almost isolates internal and external abnormal connections, and the socket can connect to the external through any port, as an improvement to socket4, socket5 adds the function of verifying SOCKET protocol access. These verification functions do not specify the methods to be used. Generally, it depends on the firewall's own support and what methods the client can support, this means that the client must inform the proxy server of the methods it supports at the beginning of the negotiation phase, and the proxy server selects a specific method to reply to the client based on the authentication method already supported. This means that different proxy servers and different clients may have different verification methods, depending on the specific application environment. These added

The programming of the socket5 client and the proxy server software is difficult, but the security is enhanced. 2. TCP persistence importance To send UDP data packets that penetrate the proxy server, you must first establish a TCP connection from the client to the proxy server through a series of interactions, only after obtaining the permission from the proxy server can it be sent out (the proxy server also records the Client IP addresses and ports connected to the SOCKS5 service ), it also ensures that the data sent from the remote end can be inspired back to a UDP client through the proxy service (because it registers a path ing about socket UDP ). Therefore, to send UDP data, you must establish and maintain this TCP data. Rfc1928 also mentioned that TCP Connections cannot be closed after the proxy server channel is obtained. Otherwise, the proxy server assumes that the UDP socket request via proxy has ended and does not need to keep the UDP external socket ing record, as a result, every time UDP is sent, it is necessary to re-establish the TCP connection to negotiate the UDP ing, increasing unnecessary troubles. Therefore, we need to keep the TCP connection from the UDP client to the proxy server persistent and do not need to close it explicitly. 3. UDP local port selection Most UDP ports are related to specific ports. Therefore, you must inform the client of the UDP port when negotiating the UDP ing with the proxy server. This allows the proxy server to receive and forward UDP data by binding UDP to a port, second, it also tells the proxy server that the feedback data obtained after a port is sent out will also be returned to the customer by line. This is very important. I have made a mistake here, leading to a waste of time. 4. dual nature of TCP/UDP connections It can be seen that the use of SOCKS5 occupies at least one TCP connection, which leads to a heavy burden on the proxy server. Therefore, in specific applications, you need to consider the server load of the proxy server.