Protect against external threats

Outside threats (eavesdropping, password guessing, misconfigurations, information slips) are real and many; follow these simple steps to reduce your risk

In a previous column, I revealed how the vast majority of computer security threats facing your environment live on the client side and require end-user involvement. Users have to be socially engineered to click an item on their desktop (an e-mail, a file attachment, a URL, or an application) that they should not have. This is not to say that truly remote exploits aren't a threat. They are.

[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

Remote buffer overflow and DoS attacks remain a serious threat against the computers under your control. Although they are less prevalent than client-side attacks, the idea that a remote attacker can launch a series of bytes against your computers, then gain control over them always brings the greatest fear to administrators and captures the biggest headlines. But there are other sorts of remote attacks against listening services and daemons as well.

A gauntlet of remote exploits
The simplest attack type is the availability of another remote access entry point. Many services and daemons (such as FTP, Telnet, HTTP, SSH, RDP, RLogin) provide the perfect place for malicious hackers to guess logon credentials, either manually, one at a time, or using automated tools such as Hydra. Since most administrators never check their logs and use neither strong passwords nor account lockout mechanisms, it's not all that hard to guess at passwords. Find a remote logon portal and guess away. Even if the password is long and complex, chances are the system doesn't monitor logs, lock out accounts, or force password changes, so the hacker can guess at it for months or years without being detected.

Many services and daemons are subject to MitM (man in the middle) attacks and eavesdropping. Far too many services do not require end-point authentication or use encryption. With eavesdropping, unauthorized parties can learn logon credentials or confidential information.

Inappropriate information disclosure is another threat. It takes only a little Google hacking to scare the crap out of you. You'll find logon credentials in plain view, and it won't be much longer before you find real top-secret and confidential documents.

Many services and daemons are often misconfigured, allowing anonymous privileged access from the Internet. Last year while teaching a class on Google hacking, I found an entire (U.S.) state's health and social welfare database accessible on the Internet, no logon credentials required. It included names, Social Security numbers, phone numbers, and addresses -- everything an identity thief would need to be successful.

Many services and daemons remain unpatched, but exposed to the Internet. Just last week, database security expert David Litchfield found hundreds to thousands of unpatched Microsoft SQL Server and Oracle databases on the Internet unprotected by a firewall. Some did not have patches for vulnerabilities that had been fixed more than three years ago. Some new operating systems are knowingly released with outdated libraries and vulnerable binaries. You can download every patch the vendor has to offer and you're still exploitable.

What can you do?
Follow all the normal security defense advice. Here are some summary recommendations:

* Inventory your network and get a list of all listening services and daemons running on each computer. 

* Disable and remove unneeded services. I've yet to scan a network that didn't run tons of unneeded (and often malicious, or at least potentially dangerous) services the IT support team didn't know of.

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.

Join the discussion
Be the first to comment on this article. Our Commenting Policies