Today I'll show you guys how to change kali linux terminal header text.
I often see people ask questions about SOCKS that show they haven’t taken the time to learn what it is. This is a fast introduction to what SOCKS is.
Overview
SOCKS is a protocol that is intended to act a circuit level proxy for applications.
It is very different from ‘normal’ proxy because they are application proxies. For example, when you use a HTTP proxy you are actually forwarding the HTTP request, and the HTTP proxy server then performs the request on your behalf. An example of this would be asking someone to pass you the salt at the dinner table, who then gets the salt shaker, and passes it to you.
The SOCKS protocol is roughly equivalent to setting up an IP tunnel with a firewall and the protocol requests are then initiated from the firewall.
The client contact the SOCKS proxy server and, by exchanging messages defined by the SOCKS protocol, negotiates a proxy connection. When a connection is established, the client communicates with the SOCKS server using the SOCKS protocol. The external server communicates with the SOCKS server as if it were the actual client.
How it works
SOCKS is client/server. A users’ workstation must have a SOCKS client installed, either in the application (such as putty, Firefox), or deep in the TCP/IP stack where the client software will redirect packets into a SOCKS tunnel.
The SOCKS client will initiate a connection to a SOCKS server. The SOCKS protocol allows for authentication and logging of the connection requests.
Here is the confusing bit:
The SOCKS server then acts as the IP Client for the connection request.
This means that the external server is only aware of the SOCKS Server (the proxy).
How is this different from NAT
SOCKS is a completely different way of solving the external access problem from NAT.
Consider the following diagram using a firewall for network address translation:
The internal system forwards a packet through the firewall. The packet is inspected by the firewall, and the source address is modified (in the header usually, and in the payload depending on the application), the external server receives the packet and replies.
Key factors to think of:
the IP session initiation (three way handshake) is directly from the client to the server
the firewall modifies the packet
there is no authentication
inspection of the packet / application / data is much more difficult
no changes to the client operating system – it is transparent to the user.
Why SOCKS ?
SOCKS was originally developed by NEC before NAT was a possible solution. As such, it was often only way to access the Internet.
It has the following key features:
provides authentication for protocols that cannot be authenticated
by passes default routing in the internal network
Consider that protocols such as HTTP and Telnet support firewall authentication. Anyone who has configured Authenticated Proxy on a Cisco firewall will understand this. However, encrypted protocols can never be authenticated by firewall, only by a SOCKS Proxy.
However SOCKS can be a problem in real life :
the client program must have a SOCKS client capability
the client operating system must have SOCKS client capability (and ‘intercept’ specific network requests and divert to the SOCKS proxy)
you must run and maintain a SOCKS server (which has been problem in the past)
The Blue Coat SOCKS server is easy to use, and using the same GUI to control and manage the rules.
SOCKS Versions
There are only two version of SOCKS. The main differences between SOCKS V5 and SOCKS V4 are:
SOCKS V4 does not support authentication. SOCKS V5 supports a variety of authentication methods.
SOCKS V4 does not support UDP proxy. SOCKS V5 does.
There is no interoperability.
SOCKS V4 DNS lookups must resolve the external hosts. SOCKS5 clients can passing the un-resolvable host names to SOCKS servers and the servers will try to resolve those names.
Why choose SOCKS ? A little history lesson
Around 1999 / 2000 SOCKS was the pre-eminent secure remote access technology, especially for Unix system administrators. It effectively provided for secure SSH Gateways with logging and access control. There were a number of SOCKS clients in production (such as the free WinSOCK in Windows 95/98, and Hummingbird) but they were expensive and licensed on a per client basis. The worst part of the SOCKS was that MS Windows (of the time) had such a lousy TCP/IP stack that getting the clients to be reliable was almost impossible. This led to a poor reputation for SOCKS that it never really shook off.
IPSec / PPTP / L2TP were just beginning to penetrate the market. Most IT folks chose IPSec for remote access because it could applied universally and required no modifications to the client applications.
From a NEC press release: in 1999.
The SOCKS Protocol
SOCKS v5, the current version of SOCKS, is an approved IETF standard and is rapidly gaining acceptance among providers of Internet-based client/server solutions. SOCKS provides security, reliability and accountability and enhances network control and manageability. SOCKS v5 is unique in its ability to interoperate with a wide range of emerging security models such as IPSec and PPTP/L2TP. This ease of interoperability allows SOCKS-based solutions to be deployed immediately, while taking advantage of the latest advances in authentication and cryptography technologies offered by these emerging standards. With these new capabilities, SOCKS v5 can handle even the most demanding enterprise-level intranet and Internet applications. SOCKS v5-based products are currently offered or supported by a number of leading Internet solutions 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 writing, SOCKS is used mostly by IT personnel to provide direct Internet access for troubleshooting and testing. Some organisations use SOCKS to provide IM clients access since they all have SOCKS capabilities however this is changing as the IM Clients need to be inspected and logged.
Its hard to see that SOCKS will return to its former glory since it does (inherently)not inspect the content, it mostly allows controlled access (authentication and some authorization) but it is very useful for Engineers and Sysadmins for providing an alternate path to the Internet or external networks that is moderately secure. This is useful when you don’t have control of the firewall to allow direct access, or your security policy does not allow direct access.
Overview
SOCKS is a protocol that is intended to act a circuit level proxy for applications.
It is very different from ‘normal’ proxy because they are application proxies. For example, when you use a HTTP proxy you are actually forwarding the HTTP request, and the HTTP proxy server then performs the request on your behalf. An example of this would be asking someone to pass you the salt at the dinner table, who then gets the salt shaker, and passes it to you.
The SOCKS protocol is roughly equivalent to setting up an IP tunnel with a firewall and the protocol requests are then initiated from the firewall.
The client contact the SOCKS proxy server and, by exchanging messages defined by the SOCKS protocol, negotiates a proxy connection. When a connection is established, the client communicates with the SOCKS server using the SOCKS protocol. The external server communicates with the SOCKS server as if it were the actual client.
How it works
SOCKS is client/server. A users’ workstation must have a SOCKS client installed, either in the application (such as putty, Firefox), or deep in the TCP/IP stack where the client software will redirect packets into a SOCKS tunnel.
The SOCKS client will initiate a connection to a SOCKS server. The SOCKS protocol allows for authentication and logging of the connection requests.
Here is the confusing bit:
The SOCKS server then acts as the IP Client for the connection request.
This means that the external server is only aware of the SOCKS Server (the proxy).
How is this different from NAT
SOCKS is a completely different way of solving the external access problem from NAT.
Consider the following diagram using a firewall for network address translation:
The internal system forwards a packet through the firewall. The packet is inspected by the firewall, and the source address is modified (in the header usually, and in the payload depending on the application), the external server receives the packet and replies.
Key factors to think of:
the IP session initiation (three way handshake) is directly from the client to the server
the firewall modifies the packet
there is no authentication
inspection of the packet / application / data is much more difficult
no changes to the client operating system – it is transparent to the user.
Why SOCKS ?
SOCKS was originally developed by NEC before NAT was a possible solution. As such, it was often only way to access the Internet.
It has the following key features:
provides authentication for protocols that cannot be authenticated
by passes default routing in the internal network
Consider that protocols such as HTTP and Telnet support firewall authentication. Anyone who has configured Authenticated Proxy on a Cisco firewall will understand this. However, encrypted protocols can never be authenticated by firewall, only by a SOCKS Proxy.
However SOCKS can be a problem in real life :
the client program must have a SOCKS client capability
the client operating system must have SOCKS client capability (and ‘intercept’ specific network requests and divert to the SOCKS proxy)
you must run and maintain a SOCKS server (which has been problem in the past)
The Blue Coat SOCKS server is easy to use, and using the same GUI to control and manage the rules.
SOCKS Versions
There are only two version of SOCKS. The main differences between SOCKS V5 and SOCKS V4 are:
SOCKS V4 does not support authentication. SOCKS V5 supports a variety of authentication methods.
SOCKS V4 does not support UDP proxy. SOCKS V5 does.
There is no interoperability.
SOCKS V4 DNS lookups must resolve the external hosts. SOCKS5 clients can passing the un-resolvable host names to SOCKS servers and the servers will try to resolve those names.
Why choose SOCKS ? A little history lesson
Around 1999 / 2000 SOCKS was the pre-eminent secure remote access technology, especially for Unix system administrators. It effectively provided for secure SSH Gateways with logging and access control. There were a number of SOCKS clients in production (such as the free WinSOCK in Windows 95/98, and Hummingbird) but they were expensive and licensed on a per client basis. The worst part of the SOCKS was that MS Windows (of the time) had such a lousy TCP/IP stack that getting the clients to be reliable was almost impossible. This led to a poor reputation for SOCKS that it never really shook off.
IPSec / PPTP / L2TP were just beginning to penetrate the market. Most IT folks chose IPSec for remote access because it could applied universally and required no modifications to the client applications.
From a NEC press release: in 1999.
The SOCKS Protocol
SOCKS v5, the current version of SOCKS, is an approved IETF standard and is rapidly gaining acceptance among providers of Internet-based client/server solutions. SOCKS provides security, reliability and accountability and enhances network control and manageability. SOCKS v5 is unique in its ability to interoperate with a wide range of emerging security models such as IPSec and PPTP/L2TP. This ease of interoperability allows SOCKS-based solutions to be deployed immediately, while taking advantage of the latest advances in authentication and cryptography technologies offered by these emerging standards. With these new capabilities, SOCKS v5 can handle even the most demanding enterprise-level intranet and Internet applications. SOCKS v5-based products are currently offered or supported by a number of leading Internet solutions 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 writing, SOCKS is used mostly by IT personnel to provide direct Internet access for troubleshooting and testing. Some organisations use SOCKS to provide IM clients access since they all have SOCKS capabilities however this is changing as the IM Clients need to be inspected and logged.
Its hard to see that SOCKS will return to its former glory since it does (inherently)not inspect the content, it mostly allows controlled access (authentication and some authorization) but it is very useful for Engineers and Sysadmins for providing an alternate path to the Internet or external networks that is moderately secure. This is useful when you don’t have control of the firewall to allow direct access, or your security policy does not allow direct access.
[if you have any question? Comment Please]
Comments
Post a Comment