Infected Hosts? Put 'Em In Jail!

How do you patch a machine too badly infected to allow on your network? Here are two approaches.

By Charlie Schluting | Posted Jul 29, 2005
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Virus-laden computers are always a burden on IT folk. Here's a different approach to dealing with them.

The main goal of this maneuver is to isolate infected hosts from the rest of your network and stop them from spreading malware to other machines. This is simple enough: Just turn off their net access. But what if there were a way to allow the owners of the infected computers to visit Windows Update and their favorite antivirus vendor's website, while protecting your network from them at the same time? There is, and it isn't too difficult to set up.

This article will discuss two different methods, but because of space constraints it isn't possible to show configuration examples. Most of the concepts, e.g. "set up NAT," are well-documented for whatever operating system you happen to be using.

Two different approaches are possible, and both of them place infected computers in a "jail." The first involves placing the end-system in its own VLAN and using a proxy server and firewall to restrict access to all but a few Internet sites and internal servers. We'll call this the Layer 2 solution. The second method, a Layer 3 solution, requires that routers identify which host is "jailed" and route all its traffic to a proxy server. This isn't as easy as it first sounds, because routers cannot do this easily. It means they will have to peek at the source IP address of all packets, and this requires Policy Routing to be enabled. Let's explore some conceptual and practical concepts behind both of these configurations.

In the Layer 2 solution a few hurdles exist. First, you will have to place the subject's switch port in a new VLAN. This is largely a manual process that involves logging into the switch, unless you're really good at scripting and understanding SNMPv3. Second, you have to give them an IP address via DHCP. Of course this means the computer will be unusable until it renews its DHCP lease. Thankfully Windows XP will generally renew the lease if you leave the port disabled for a few seconds and then reenable it. This is still disruptive to users, since their IP address will change, but it is better than having to simply disable all of their network access.

A "jail server" should be running the DHCP server mentioned above. It also needs to route traffic for the jailed hosts. A slick way to do this is to use NAT, and transparently redirect certain ports to a proxy server. The basic idea for the firewall rules should be to block everything, except a few services (DNS, DHCP), but redirect web traffic to the proxy server. Using squid as the proxy server, you can define what is allowed to pass and what isn't. The true trickiness is here: We need to have some way of notifying the jailed user that they need to clean up the system or call for help. Redirecting web traffic destined for non-approved sites to a Web server running on the jail computer will allow you to display the web page containing such a notice.

Squid itself doesn't have the ability to redirect users to websites, but it does have an interface for this. You'll have to run another program; our favorite is the squirm redirector service. The configuration file allows you to list regular expressions and URLs. If the regular expression matches, the user will be redirected to the URL. This is commonly used to block websites that contain certain addresses, but in this case we want to block everything. To put all this together, we simply need to tell squid to use the redirector service for all URLs except the approved ones. This is quite simple, since squid also has regular expressions. Want to allow everything on Microsoft's website? Simply use "^http://*.microsoft.com*" in the list of things that don't get passed to the redirector. The squid and squirm documentation explains how to set this up.

The Layer 3 solution is similar. It has the advantage that users aren't left disabled while the computer renews its IP address. On the negative side, this also means that we'll be leaving infected computers on their home subnet, and they can still infect other people. They won't be able to infect other subnets or the Internet, and this method is sometimes easier to configure, so it has its advantages.

The concept of Policy Routing means that routers will look at things they normally don't bother with, namely the source IP address. Configuring Policy Routing with a Cisco router is fairly straightforward. We need to route all traffic sourced from a list of IP addresses (the jailed hosts) to the proxy server. This is achieved with a route-map, which lists the IP addresses that are not allowed through. When "ip policy-routing" is turned on for a router interface, it will consult the route-map specified to figure out what needs to be done.

In both solutions, some problems do exist. Squid doesn't transparently proxy https websites, since that means it would be performing a man-in-the-middle-attack. They probably wanted to avoid legal issues with this, so we're left without a clean way to do it. With a test implementation of the Layer 2 solution, we ended up simply allowing all https traffic through the NAT firewall without redirecting it to squid. It would be easy enough to allow large IP address ranges belonging to Microsoft or antivirus vendors and block everything else. Another problem is with Windows Update. It fails unless the computer knows it is supposed to be using a proxy server. Configuring this is a manual process for the user, and instructions can be placed in the notification page to run "proxycfg -p <IP address of proxy server>."

Amidst all the hand-waving above, implementation details were certainly left out. We hope this article will mainly serve to provide a spark for those who need to implement such a solution.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter