Many sites wish to enforce certain security policies on network traffic. This can range from "scan all inbound POP traffic for viruses" to "block HTTP requests to this list of servers" or "strip header information from all outgoing e-mail." Unfortunately, this can be difficult to impossible for administrators to manage. Often times, control of the desktops and network itself is fragmented, as roaming users require special configuration. One solution to this is to enforce policy at the network gateways, typically in the form of "edge" routers and firewalls.
The advantage to transparently intercepting and managing network traffic to and from clients is that the client does not need any special software or configuration to make it work. This means that roaming users will not be adversely affected by strange settings and newly installed desktops cannot accidentally circumvent security policy due to a lack of software or configuration. Additionally, this centralizes policy management and administration functions, and the system can be designed to fail "closed" rather then failing open (designing fail "closed" systems when multiple desktops are involved is a non trivial task).
The first step is to configure your firewall or router. For example, with a Cisco router (running IOS 11.1 or later) you first create a route to the proxy, then an access list to trap the traffic you wish to intercept (e.g. HTTP) and finally a policy that directs all that traffic to the proxy.
!
route-map proxy-redirect permit 10
match ip address 110
set ip next-hop 1.2.3.4
!
!
access-list 110 deny tcp any any neq www
access-list 110 deny tcp host 1 2 3.4 any
access-list 110 permit tcp any any
!
!
interface Ethernet0
ip policy route-map proxy-redirect
!
On a Linux system with IPTables, and the proxy software installed locally you would simply need:
iptables -A PREROUTING -s 10.0.0.0/255.255.255.0 -p tcp -m tcp --dport 80 -j
REDIRECT --to-ports 3128
Or if the proxy is on a different system:
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to
1.2.3.4:3128
As you can see, it is quite trivial to redirect any network traffic from TCP and UDP to ICMP and IGMP. The main issue that can arise with transparent proxying has to do with applications capable of handling the traffic properly, especially if authentication is involved. For HTTP there are a number of proxies, some popular ones being Apache, Squid and Cisco. Since the Web is largely stateless, it is much easier to transparently proxy connections. For protocols such as SMTP, most normal cases can be handled by a server such as Postfix with relaying allowed from internal hosts. However, with features such as SMTP-AUTH and SMTP-TLS in use, proxying can break, and there is no way to differentiate between "normal" SMTP traffic and SMTP traffic using SMTP-AUTH on most firewalls or routers.
The current bottleneck with transparently proxying most protocols is not the firewall or the router, but instead the lack of a good application-level proxying software, with the primary problem being support for authentication protocols. Fortunately, more products -- especially antivirus-scanning products -- are starting to support transparent proxying more effectively. Other uses of transparent proxying include forcing unencrypted data over encrypted links or VPNs or allowing the use of rate-limiting software to prevent applications such as peer-to-peer clients from taking up too much bandwidth or shunting the traffic to less important network links.
About the author
Kurt Seifried is a network security administrator. Visit his Web site at http://seifried.org/security/
