Fast Introduction to SOCKS Proxy

Introduction

In the Blue Coat for­ums I often see people ask ques­tions about SOCKS that show they haven’t taken the time to learn what it is. This is a fast intro­duc­tion to what SOCKS is.

Overvew

SOCKS is a pro­tocol that is inten­ded to act a cir­cuit level proxy for applications.

It is very dif­fer­ent from ‘nor­mal’ proxy because they are applic­a­tion prox­ies. For example, when you use a HTTP proxy you are actu­ally for­ward­ing the HTTP request, and the HTTP proxy server then per­forms the request on your behalf. An example of this would be ask­ing someone to pass you the salt at the din­ner table, who then gets the salt shaker, and passes it to you.

The SOCKS pro­tocol is roughly equi­val­ent to set­ting up an IP tun­nel with a fire­wall and the pro­tocol requests are then ini­ti­ated from the firewall.

The cli­ent con­tact the SOCKS proxy server and, by exchan­ging mes­sages defined by the SOCKS pro­tocol, nego­ti­ates a proxy con­nec­tion. When a con­nec­tion is estab­lished, the cli­ent com­mu­nic­ates with the SOCKS server using the SOCKS pro­tocol. The external server com­mu­nic­ates with the SOCKS server as if it were the actual client.

How it works

SOCKS is client/​server. A users’ work­sta­tion must have a SOCKS cli­ent installed, either in the applic­a­tion (such as putty, Firefox), or deep in the TCP/​IP stack where the cli­ent soft­ware will redir­ect pack­ets into a SOCKS tunnel.

The SOCKS cli­ent will ini­ti­ate a con­nec­tion to a SOCKS server. The SOCKS pro­tocol allows for authen­tic­a­tion and log­ging of the con­nec­tion requests.

Here is the con­fus­ing bit:
The SOCKS server then acts as the IP Client for the con­nec­tion request.

This means that the external server is only aware of the SOCKS Server (the proxy).

How is this dif­fer­ent from NAT

SOCKS is a com­pletely dif­fer­ent way of solv­ing the external access prob­lem from NAT.

Consider the fol­low­ing dia­gram using a fire­wall for net­work address translation:

The internal sys­tem for­wards a packet through the fire­wall. The packet is inspec­ted by the fire­wall, and the source address is mod­i­fied (in the header usu­ally, and in the pay­load depend­ing on the applic­a­tion), the external server receives the packet and replies.

Key factors to think of:

• the IP ses­sion ini­ti­ation (three way hand­shake) is dir­ectly from the cli­ent to the server
• the fire­wall mod­i­fies the packet
• there is no authentication
• inspec­tion of the packet /​ applic­a­tion /​ data is much more difficult
• no changes to the cli­ent oper­at­ing sys­tem — it is trans­par­ent to the user.

Why SOCKS ?

SOCKS was ori­gin­ally developed by NEC before NAT was a pos­sible solu­tion. As such, it was often only way to access the Internet.

It has the fol­low­ing key features:

• provides authen­tic­a­tion for pro­to­cols that can­not be authenticated
• by passes default rout­ing in the internal network

Consider that pro­to­cols such as HTTP and Telnet sup­port fire­wall authen­tic­a­tion. Anyone who has con­figured Authenticated Proxy on a Cisco fire­wall will under­stand this. However, encryp­ted pro­to­cols can never be authen­tic­ated by fire­wall, only by a SOCKS Proxy.

However SOCKS can be a prob­lem in real life :

• the cli­ent pro­gram must have a SOCKS cli­ent capability
• the cli­ent oper­at­ing sys­tem must have SOCKS cli­ent cap­ab­il­ity (and ‘inter­cept’ spe­cific net­work requests and divert to the SOCKS proxy)
• you must run and main­tain a SOCKS server (which has been prob­lem in the past)

The Blue Coat SOCKS server is easy to use, and using the same GUI to con­trol and man­age the rules.

SOCKS Versions

There are only two ver­sion of SOCKS. The main dif­fer­ences between SOCKS V5 and SOCKS V4 are:

SOCKS V4 does not sup­port authen­tic­a­tion. SOCKS V5 sup­ports a vari­ety of authen­tic­a­tion methods.

SOCKS V4 does not sup­port UDP proxy. SOCKS V5 does.

There is no interoperability.

SOCKS V4 DNS look­ups must resolve the external hosts. SOCKS5 cli­ents can passing the un-​​resolvable host names to SOCKS serv­ers and the serv­ers will try to resolve those names.

Why choose SOCKS ? A little his­tory lesson

Around 1999 /​ 2000 SOCKS was the pre-​​eminent secure remote access tech­no­logy, espe­cially for Unix sys­tem admin­is­trat­ors. It effect­ively provided for secure SSH Gateways with log­ging and access con­trol. There were a num­ber of SOCKS cli­ents in pro­duc­tion (such as the free WinSOCK in Windows 95/​98, and Hummingbird) but they were expens­ive and licensed on a per cli­ent basis. The worst part of the SOCKS was that MS Windows (of the time) had such a lousy TCP/​IP stack that get­ting the cli­ents to be reli­able was almost impossible. This led to a poor repu­ta­tion for SOCKS that it never really shook off.

IPSec /​ PPTP /​ L2TP were just begin­ning to pen­et­rate the mar­ket. Most IT folks chose IPSec for remote access because it could applied uni­ver­sally and required no modi­fic­a­tions to the cli­ent applications.

From a NEC press release: in 1999.

The SOCKS Protocol

SOCKS v5, the cur­rent ver­sion of SOCKS, is an approved IETF stand­ard and is rap­idly gain­ing accept­ance among pro­viders of Internet-​​based client/​server solu­tions. SOCKS provides secur­ity, reli­ab­il­ity and account­ab­il­ity and enhances net­work con­trol and man­age­ab­il­ity. SOCKS v5 is unique in its abil­ity to inter­op­er­ate with a wide range of emer­ging secur­ity mod­els such as IPSec and PPTP/​L2TP. This ease of inter­op­er­ab­il­ity allows SOCKS-​​based solu­tions to be deployed imme­di­ately, while tak­ing advant­age of the latest advances in authen­tic­a­tion and cryp­to­graphy tech­no­lo­gies offered by these emer­ging stand­ards. With these new cap­ab­il­it­ies, SOCKS v5 can handle even the most demand­ing enterprise-​​level intranet and Internet applic­a­tions. SOCKS v5-​​based products are cur­rently offered or sup­por­ted by a num­ber of lead­ing Internet solu­tions vendors such as Attachmate Corporation, Aventail Corporation, Bay Networks, Inc., Hummingbird Communications, Ltd., IBM Corporation, Netscape Communications Corporation, Network Appliance, Inc., Oracle Corporation, and others.

Conclusion

At the time of writ­ing, SOCKS is used mostly by IT per­son­nel to provide dir­ect Internet access for troubleshoot­ing and test­ing. Some organ­isa­tions use SOCKS to provide IM cli­ents access since they all have SOCKS cap­ab­il­it­ies how­ever this is chan­ging as the IM Clients need to be inspec­ted and logged.

Its hard to see that SOCKS will return to its former glory since it does (inherently)not inspect the con­tent, it mostly allows con­trolled access (authen­tic­a­tion and some author­iz­a­tion) but it is very use­ful for Engineers and Sysadmins for provid­ing an altern­ate path to the Internet or external net­works that is mod­er­ately secure. This is use­ful when you don’t have con­trol of the fire­wall to allow dir­ect access, or your secur­ity policy does not allow dir­ect access.

Reference

List of SOCKS Clients I pos­ted a while back

Please rate this post:

(4 votes, average: 9.25 out of 10)

 Loading ...