Start with high-risk and high-value assets. If the service or daemon isn't needed, turn it off. When in doubt, research it. There are lots of helpful resources and guides available for free on the Internet. If you can't find a definitive answer, contact the vendor. If you're still not sure, disable the program and restore it if something ends up broken.
* Make sure all your systems are fully patched, both OS and applications. This single step will significantly reduce the number of properly configured services that can be exploited. Most administrators do an excellent job of applying OS patches, but they don't do as well making sure applications are patched. In this particular column, I'm only concerned about patching applications that run listening services.
* Make sure remaining services and daemons are running in a least-privileged context. The days of running all your services as root or domain admin should be coming to a close. Create and use more limited service accounts. In Windows, if you have to use a highly privileged account, go with LocalSystem instead of domain admin. Contrary to popular belief, running a service under LocalSystem is less risky than running it as a domain admin. LocalSystem doesn't have a password that can be retrieved and used across the Active Directory forest.
* Require that all service/daemon accounts use strong passwords. This means long and/or complex -- 15 characters or more. If you use strong passwords, you'll have to change them less frequently, and you won't need account lockout (because the hackers will never be successful).
* Google-hack your own network. It never hurts to find out if your network is releasing sensitive information. One of my favorite tools is Foundstone's Site Digger. It essentially automates the Google-hacking process and adds many of Foundstone's own checks.
* Install services on nondefault ports if they aren't absolutely needed on the default ports; this is one of my favorite recommendations. Put SSH on something other than port 22. Put RDP on something other than 3389. With the exception of FTP, I've been able to run most services (that aren't needed by the general public) on nondefault ports, where hackers rarely find them.
Of course, consider testing your network with a vulnerability analysis scanner, either the free or commercial variety. There are many excellent ones that find the low-hanging fruit. Always have management permission first, test during off-hours, and accept the risk that you'll probably knock some important service offline during the scan. If you're really paranoid and want to go past publicly disclosed vulnerabilities, use a fuzzer to look for undisclosured zero day exploits. I've been playing with a commercial one these days (keep an eye on the InfoWorld Test Center for my review) against various security appliances, and the fuzzer is finding things I suspect the vendors don't know about.
And of course, don't forget that your risk of malicious exploits mainly comes from client-side attacks.
Roger A. Grimes is contributing editor of the InfoWorld Test Center. He also writes the Security Adviser blog and the Security Adviser column.


Talkback
E-mail
Printer Friendly
Reprints



