0blivion nº2:(SOCKS.txt):15/03/2000 << Back To 0blivion nº 2

<< Prev file: smb.txt

Next file: TCP.txt >>

_____________________________________________________ / Oblivion Underground Magazine \ / Issue 2 15/04/2000 \ ▌ Socks ▌ \ by Slider / \_____________________________________________________/ - SOF - - SOCKS SOCKS is a standard for circuit-level gateways. It does not require the overhead of a more conventional proxy server where a user has to consciously connect to the firewall first before requesting the second connection to the destination. The user starts a client application with the destination server IP address. Instead of directly starting a session with the destination server, the client initiates a session to the SOCKS server on the firewall. The SOCKS server then validates that the source address and user ID are permitted to establish onward connection into the nonsecure network, and then creates the second session. SOCKS needs to have new versions of the client code (called SOCKSified clients) and a separate set of configuration profiles on the firewall. However, the server machine does not need modification; indeed it is unaware that the session is being relayed by the SOCKS server. Both the client and the SOCKS server need to have SOCKS code. The SOCKS server acts as an application-level router between the client and the real application server. SOCKSv4 is for outbound TCP sessions only. It is simpler for the private network user, but does not have secure password delivery so it is not intended for sessions between public network users and private network applications. SOCKSv5 provides for several authentication methods and can therefore be used for inbound connections as well, though these should be used with caution. SOCKSv5 also supports UDP-based applications and protocols. The majority of Web browsers are SOCKSified and you can get SOCKSified TCP/IP stacks for most platforms. - SOCKS Version 5 (SOCKSv5) SOCKS version 5 is a proposed standard protocol with a status of elective. Application-level gateways provide secure connections for some applications such as TELNET, FTP and SMTP. However, it is not easy to write proxy code for each new application. Generally, the proxy service becomes available after some time even if the service can be used directly and application level gateways do not allow UDP connections. SOCKSv5 satisfies all these shortcomings and requirements with a strong authentication mechanism and the hiding of addresses from a non-secure network. Although, supporting UDP might seem to be vulnerable, it can be configured to pass UDP for particular users and particular applications only. The SOCKSv5 concept is based on SOCKSv4 with some extensions such as UDP support, new and various sophisticated authentication methods and extended addressing schemes to cover domain-name and IPv6. SOCKSv5 supports a range of authentication methods, including: 1. Username/password authentication 2. One-time password generators 3. Kerberos 4. Remote Authentication Dial-In User Services (RADIUS) 5. Password Authentication Protocol (PAP) 6. IPSEC Authentication method SOCKSv5 also supports the following encryption standards: 1. DES 2. Triple DES 3. IPSEC The following tunneling protocols are supported: 1. PPTP 2. L2F 3. L2TP The following key management systems are supported: 1. SKIP 2. ISAKMP/Oakley The SOCKSv5 server listens for connections on port 1080. According to the connection type (TCP or UDP), the steps discussed in the following sections are taken to establish a connection. - SOCKSv5 TCP Connection To establish a connection using TCP, the client first sends a TCP packet which contains session request information via port 1080 to the server. If the access permissions allow this operation and the connection request succeeds, the client enters an authentication negotiation. In this state, the authentication type is determined, after which the client sends a relay request. The SOCKSv5 server evaluates the request and either establishes the connection or rejects it. The client sends the following message which contains a version identifier and method options. Where: VER Indicates the version of SOCKS. For SOCKSv5, the value is hexadecimal X'05'. NMETHODS Indicates the number of the methods appeared in the methods field. METHODS Indicates the supported authentication and encapsulation methods The server responds by the following message. The hexadecimal values for current standard METHODS are as follows; X'00' NO AUTHENTICATION REQUIRED X'01' GSSAPI X'02' USERNAME/PASSWORD X'03' to X'7F' IANA ASSIGNED X'80' to X'FE' RESERVED FOR PRIVATE METHODS X'FF' NO ACCEPTABLE METHODS All implementations should support USERNAME/PASSWORD and GSSAPI authentication methods. Once authentication is completed successfully, the client sends the request details. If an encapsulation method is negotiated during the method negotiation, the selected encapsulation method must be applied for the following messages. The detail request message format issued by the client is as follows: Where: VER Socks protocol version. For SOCKSv5, the value is hexadecimal X'05'. CMD SOCKS command in octets. X'01' CONNECT X'02' BIND X'03' UDP ASSOCIATE RSV Reserved for future use. ATYP Address types in octets. X'01' IPv4 address X'03' Domain-name X'04' IPv6 address DST.ADDR Desired destination address. DST.PORT Desired destination port in network octet order. The server evaluates the request detail message and replies with one or more messages. Where: VER Socks protocol version. For SOCKSv5, the value is hexadecimal X'05'. REP Reply field: X'00' Succeeded X'01' General SOCKS server failure X'02' Connection not allowed by ruleset X'03' Network unreachable X'04' Host unreachable X'05' Connection refused X'06' TTL expired X'07' Command not supported X'08' Address type not supported X'09' to X'FF' Unassigned RSV Reserved for future use. ATYP Address types in octets. X'01' IPv4 address X'03' Domain name X'04' IPv6 address BND.ADDR Server bound address. BND.PORT Server bound port in network octet order. - SOCKSv5 UDP Connection To be able use a UDP connection over a SOCKS server, the client first issues the UDP ASSOCIATE command to the SOCKSv5 server. The SOCKSv5 server then assigns a UDP port to which the client sends all UDP datagrams. Each UDP datagram has a UDP request header. The UDP request header format is as follows: Where: RSV Reserved for future use. All bytes are zero. FRAG Current fragment number. ATYP Address types in octets. X'01' IPv4 address X'03' Domain-name X'04' IPv6 address DST.ADDR Desired destination address. DST.PORT Desired destination port in network octet order. DATA User data. The UDP relay server gets the IP address of the client which sends UDP datagrams to the port specified by DST.PORT. It will then discard any datagram that comes from another source. Slider - EOF - Written with the help of Caffine, and lack of sleep. And to those fuckers that somehow killed my telephone line, you bastards nearly made this text not possible. Shouts : To everyone that knows me.