If you are struggling with P2P, IM or other dangerous applications that users keep installing, here's an idea: Consider breaking end-to-end IP connectivity from your users' desktops to the Internet. This approach
Most end users only require e-mail and HTTP access to the Internet and many may not even need one or both of these. Why allow them access to everything? Without end-to-end IP connectivity, it becomes a lot more difficult for users to connect to the world in any way you don't want them to. However, a really clever (or malicious) user may still find ways around this, but in many circumstances disconnecting desktops can add a layer of security.
Hopefully, your outgoing firewall rules are just as stringent as your incoming ones. If they aren't, you may want to try to tighten them up before disconnecting desktops from the Internet. Be prepared to take some time to adjust your firewall rules. You may be surprised at how your users are taking advantage of the situation. If your rules are in good shape, all you need for the most basic configuration is your internal mail server, internal DNS server and a Web proxy server. You should configure all your machines to send and receive e-mail via only your internal e-mail server, which is allowed to communicate with your mail relay or the Internet, or whatever.
Likewise, configure clients to use your internal DNS server first. You may be tempted to skip this step if you don't have an internal DNS (e.g. if you use WINS for local resolution). Try not to skip this step, because some malicious programs deliberately attempt to use outgoing port 53/UDP to communicate. If you really must, allow your clients 53/UDP to your upstream DNS servers only. Port 53/TCP is used for zone transfers and very large DNS queries, and for most environments that is not required for end-user machines. Keep this in mind to check your firewall logs if you have a problem, but you probably won't.
That leaves Web browsing. If you don't have a proxy server, there are a number of free ones available that run on any platform and OS you choose. (Privoxy is especially interesting.) Configure your users' browsers to point to the proxy and then set your firewall rules to only allow the proxy to surf the Net. If your users have laptops that they bring home or use at customer sites, a hard coded proxy server setting will probably cause problems. Most browsers have some kind of auto-configuration facility to handle this, so consult your browser documentation.
As you disconnect desktops, you may come across end-user resistance. You probably have at least one VP who claims AOL is necessary for his work. You may have some users who really do require other access to the Internet, such as SSH, FTP or Telnet. You may also have consultants who need to keep in touch with their home office on some specific port (maybe for a terminal server application). And what about you? It's very difficult to troubleshoot network problems without ping, trace route and similar tools.
There is no one solution to these issues; the best answer depends on your architecture and perimeter device capabilities. Some firewalls and proxy servers allow you to authenticate users to the perimeter device, so you can define who can do what based on the user ID, which is ideal. If that solution doesn't work, you may have to assign static IP addresses to some users to allow them the access they need. Smart users might reconfigure their desktops with a static IP in the correct range if this information gets out, so don't rely on security through obscurity. Be careful with your wiring, routing and VLANs, and implement some kind of port-level security if possible.
There is another way to prevent users from running programs and services they shouldn't: Lock down the desktops. If you can, great, but if you can't, disconnecting end-to-end IP connectivity to the Internet will at least allow you to get a better handle on your outbound traffic.
About the author
JP Vossen, CISSP, is the integration manager for Counterpane Internet Security and a technical editor for Information Security magazine. He is involved with various open source projects including Snort. He has previously worked as an information security consultant and systems engineer.
This was first published in February 2004