Network Security - Standard Proxies Vs Transparent proxies

Network based security devices provide application firewalls and Virus scanning functionality using proxies. Proxies act as servers for client end points and clients for server end points. They typically terminate the connection (UDP or TCP) from clients and make connections to the original servers. In between they do processing on the data such as access control and scanning and take actions based on the processing results.

Proxies are implemented in two ways - Standard and Transparent. In case of standard proxies, both client and server end points know that there is a proxy in between. Client end points are configured with standard proxy address and server sees the connections from the proxy. That is, destination IP address of the packets from client is proxy IP address and source IP of the packets from proxy to server is proxy IP address. In case of transparent proxies, both client and server end points don't know the existence of the proxy in between. In this mode, both source and destination IPs of the packets correspond to client and server end points. At no time, proxy IP address is seen in the packets on the wire.

Advantages of standard proxies:

• Devices with standard proxies need not be in the line of traffic.
  
• Traffic that need not go through the proxies will not have any latency introduced.
  
• Any problem with security device only effects the proxy traffic and not every thing else.
• Single leg mode: Device only need to have one Ethernet port.
• Standard proxies don't require any special support in TCP/IP stack: In Linux and BSD systems, proxies are typically implemented in user space and they use standard socket library to accept connections, make connections, receive and send data. Since, the packets are destined to local IP address, there is no change required in TCP/IP stack or Linux Kernel for this support. In case of transparent proxies, support is required in Linux kernel to redirect the packets to proxy applications.
  

Advantages of transparent proxies:

• No special configuration required in client end points.
• Servers see traffic from client end points. There is no issue if there is any analysis is required on unique clients connecting to servers from logs as logs indicate original client IP address.
• Any other policy based network devices continue to work as there is no change seen in IP addresses of the packets. Example: Traffic shaping devices doing shaping based on IP addresses.
• It does not have any issues with 'Unknown Domain Resolution' DoS attack. Standard proxies typically get the domain name from the protocol fields and does domain name resolution to get the IP address of server. Attackers can DOS the standard proxy by connecting to proxy with invalid server domain names. If the proxy is implemented to create a thread for each connection, then the proxy can easily be DOSed as these threads block on DNS resolution for a long time. Note that the number of threads that can be created in any given system are limited in number. If the proxy is implemented as FSM (finite state machine) without any blocking calls, then this problem may not arise soon, but the memory can be exhausted due to state maintenance. Transparent proxies don't have this problem as it does not do any domain name resolutions.
  

As indicated above, transparent proxies require special support in Linux/BSD kernels to intercept the packets at the IP layer and redirect them to the proxies. This can be implemented as kernel module. I try to give some brief description on the operations of this module.

• Operation:
• Intercept all packets at the IP layer. In case of Linux, it can be done using 'netfilter' hooks.
• If the packet is first packet of the session, it creates a memory block to store the state information (let us call this as session block). Then it checks whether this packet requires to be redirected to local proxy. If so, it notes down the client IP address (source IP address) and server IP address (destination IP address) in the session block and changes the destination IP of the packets to local IP address. Thereby, rest of the TCP/IP stack sends the packets to the proxy. Note : There are no other changes required in TCP/IP stack.
  
• For further packets, it uses the session state information to redirect the packets.
  
• When proxy makes connection to the server, it uses local IP address which is used as source IP. Since, it is required that server sees original client IP, this module does SNAT on Server to proxy connection. It also creates a session to store any state information.
  
• Proxy interface
• This module can be configured with rules for redirection. Either administrator can configure the rules or proxies themselves can configure the rules. For example, web proxy might configure to redirect all HTTP connections coming from a particular subnet to be redirected to it. It can also configure to redirect HTTP connections going to a particular server (Reverse proxy scenario).
  
• This module provides interface to return original server IP address when proxy requests it. Proxy needs this IP address to make connection to the server end point.
• This module provides interface to link client side session to server side session. It is expected that proxy informs this module before connecting to the server. This module prepares itself by creating server side session and populates the session with state information do to the SNAT.