Clean up Those Dirty Connections

It's a funny thing about security: As soon as you think you've got your computer (or network, or enterprise, for that matter) locked down, another vulnerability pops up. Indeed, there's no such thing as a completely secure computer. Rather, security is an ongoing process. We must be ever vigilant in keeping up with security hotfixes, virus definitions and the like. And we are. I don't know a single administrator who isn't constantly striving to stay ahead of potential security breaches.

Still, despite our best efforts, sometimes a security hole appears—and often in the most obvious place, a place that was just somehow overlooked. This month, we're going to look at one possible vulnerability and use the Devcon.exe tool we learned about last month to tighten it up. The problem: Computers with "dirty" network connections.

Virtually all modern computers—especially notebooks—have more than one network-capable connection. Some have built-in wireless networking devices. They almost certainly have onboard modems. That means if your office is anywhere near an external wireless network or has (gasp!) analog phone lines, much of your network security could be compromised by the presence of a "dirty" connection. Of course, if your users always follow security guidelines and never, ever open potentially unsafe attachments, feel free to move on to the next column. If, on the other hand, you have ever been left scratching your head wondering "What the heck was that user thinking?" read on.

Baard Schøyen, a Mr. Script reader from Norway, sent me this script that uses Devcon.exe to disable dirty connections when the computer is connected to the corporate (private) network.

Room for Improvement This script does quite a lot, especially considering that it must "shell out" the command prompt operation of devcon.exe. Still, there are some areas where enhancements could be made. First, it requires WINS. Since Active Directory relies primarily on DNS, this might be a problem for you. Also, it can only detect one "dirty" interface. If you happen to have two modems or a dirty wireless zone nearby, you may not be fully protected—even if you run the script twice.

Even with these limitations, the script adds another vital layer of security to help ensure that your corporate firewall isn't rendered moot. In order to be certain it's working, I recommend setting it up to run at every startup for any client machine that has a potentially dirty NIC, such as notebooks. If you're not connected to your corporate network, all interfaces will work fine and you can surf to your heart's content. Once you connect to your corporate network, it finds and disables the unsecured "dirty" NIC, forcing all of your network communication through your "clean" connection, making it subject to all firewall and network security rules.