Patching is a pain...

It does then become an issue of IT procedures to manage individual application patching. Some organisations have adopted “Patch Tuesday” as the night of patch testing and deployment, not only for Microsoft’s software, but to run around all desktops and patch them. For larger installations this isn’t practical; but mass imaging your desktops is. It might sound insane at first, but third party security holes are in many cases such an issue that patching a reference image and then pushing it out to your desktops once a month should be seriously considered as a bit of preventative IT medicine.

There are other common configuration mistakes that can lead to malware issues on your network beyond application patch management. The one I feel is the most critical to reinforce is changing the default settings. The most obvious example for a home user is to change the default settings of their wireless or internet routers. Ever time I see a wireless SSID that says “default” or “Linksys” a part of me dies inside. Worse yet, most of them still use default administrative passwords. Though some default settings prevent a wireless client from accessing the administration panel, others don’t.

It is entirely possible to flash the router in question with something like dd-wrt, change the settings to whatever the defaults were on the original firmware, and plant a rootkit on the router itself. A few hours of wardriving in a major metro and you could have yourself a kilonode botnet. Worse yet, users could try to scan all they want; they’d never find it because it isn’t on their PCs.

Leave firewalls up, even on protected networks. Open services required (such as file sharing) only to your internal subnet, but otherwise leave your shields up. You can’t trust that the other computers on your network aren’t infected by malware any more than you can trust the internet not to infect you. Even if you ran 15 anti-malware scanners on every system on your network (and it consisted entirely of Linux boxes) you could still only say that there was no malware present that you could detect. Better safe than sorry, and firewalls on more than just the edge devices are no longer optional in today’s computing environment.

For those that haven’t already, disable autoplay in Windows; this alone can save you quite a bit of grief. It is absolutely unreal how much trouble autoplay can cause on a Windows system where the user is logged in with administrative privileges.

If your log systems have the ability to email you on error, enable it. If they don’t, then get an application that can do so and install it. Analysing system logs can be the most important part of a systems administrator’s job. Security breaches leave traces, like fingerprints, if you know what to look for you can find out who or what broke in. Even if you don’t know exactly what to look for, when your logs start doing something odd then you know it’s time to do some research or ask for help.

Look into OpenDNS, or if you host DNS of your own look into malwaredomains.com. Incorporating DNS blocking either at the DNS level or the firewall level is an absolutely required element of minimal network caution. If all your other protective measures fail and you do get infected, then there is a really good chance the malware won’t be able to contact its command and control server, effectively neutering it.

Default ports for applications such as SSH, or remote administration applications are a must. It might only slow down a determined attacker, but if you have halfway decent Intrusion Detection System (IDS), they won’t get very far along in port scanning the system looking for holes before they are banned.

To round out your defences, look into network vulnerability scanners like Tenable’s Nessus or GFI’s Languard. (Both offer versions free for home use.) These applications can scan your systems looking for security vulnerabilities or malware activity signatures. Take the time to get to learn a few different vulnerability scanners, and most importantly, actually use them on a regular basis.

This leads me into software that can help you detect when your security is breached in near real-time. IDSes are offered by every internet security firm out there, as well as most major OEMs. Some are installable applications geared towards specific markets; home users, protecting individual servers or running on network edge devices. Others are appliances designed either to sit on the edge of your network or to monitor it silently from the inside.

Regardless of whose IDS you choose, get one. Get several in fact - back up your primary IDS with open source virtual appliances running iptables, snort and squid. Like anti-malware (AM) scanners, no IDS is perfect. Eventually an attacker will figure out how to poke a hole through one, or a piece of malware will have a signature the IDS doesn’t recognise. Multiple layers offer the best defence.

So to summarise the above; it is critical to configure your systems to actually inform you of breaches. RAID card management applications can email when a disk is dropped, even my UPSes email me when the power goes out. Network security breaches require the same sort of scrutiny. From patch management applications to error logs and logfile analysis programs to intrusion detection systems, the greatest tool available to solve network security issues is the systems administrator responsible for that network. In order to work their magic, they need to know first that a problem exists.

Sadly it is perhaps one of the most overlooked features in just about any application; either the developer neglected to include the capability, or the administrator doing system configuration neglected to enable it. Even if the system in your care is Aunt Tilly’s home PC, set it up to email you when there’s a problem - it might help you catch a breach before it really gets out of hand. ®