|
|
|
|
Keep Out
|
 |
|
October 21, 2002
By Mike Fratto
|
|
"Expect the unexpected" may be a cliché, but it's a smart network security strategy nonetheless. Vendors and security professionals, despite claims to the contrary, cannot pinpoint with certainty the next threat to your virtual existence any more than you can. Of course, you can lower your exposure by installing security devices, such as firewalls, VPNs, virus scanners and IDSs, and implementing operational procedures, like OS hardening and enhanced authentication and access control. But the reality is that you must provide server access to employees and other users, and the risk of attack mushrooms when you open your door to the Internet at large.
Here are a few hard truths: All products have security vulnerabilities. Someone will find those vulnerabilities. Regardless of whether the discoverer tells the vendor about the vulnerability, publishes it or keeps it to him or herself, you're exposed to attack until the vendor issues a patch to close the hole and your administrators install said patch.
|
|
On the subject of patches, please repeat after us: "I must keep abreast of the patch cycle." (For a review of products to help you do that, see "PatchLink Helps Keep Windows Closed".) Still, you must test patches and hot fixes before applying them to production servers to make sure they don't break existing functionality, so even with a program in place, your servers could be days or weeks behind the patch-update curve.
Patches, while important, are reactive. The problem is precious little software is built with security in mind. General-purpose operating systems are designed primarily to manage multiple users and provide seamless access to system resources. Depending on the permissions bits or ACLs (access-control lists) placed on files and users' ownership or group affiliations, some will get more access than others. For example, the root user on Unix or the administrator in Windows NT/2000 have almost unfettered access to resources. More important, many system services run as highly privileged users. Each server requires only a limited, and often definable, set of resources to function properly, but there is no way to restrict services' access to required resources. Because these services provide direct access to your servers and, subsequently, other places in your organization, host OSs need to be protected from vulnerable programs.
Preemptive Protection
You need a way to proactively protect your servers from malicious attacks. Host intrusion prevention, or HIP, is a way to do just that. Using a variety of different methods, HIP products restrict a program's or a user's access to system resources, safeguarding the underlying OS from attacks that take advantage of poorly written code.
For example, most attacks that give remote access do so by letting a server run commands on behalf of a remote user. It doesn't matter if the attack is a buffer overflow or a malformed URL--the salient point is that commands are run remotely. For example, on a Microsoft Internet Information Server (IIS) Web server with no service packs or hot fixes applied, there are way too many ways that a command shell can be invoked through inetinfo.exe, the IIS process (see "How We Tested Host Intrusion Prevention," for details). Yet, there is no reason for inetinfo.exe to be invoking a shell. Knowing that attacks often call a shell, and knowing that inetinfo.exe shouldn't be able to invoke a shell, we can now formulate a security policy. HIP products enforce that policy.
HIP is a relatively new security space, and while we didn't do a thorough security audit on the products we tested, we did attack servers remotely, both as an attacker would do and while logged on as administrator or root. We could not successfully penetrate systems where HIP applications were installed and properly configured. Because we don't know what assaults attackers will dream up next, we won't go so far as to state that these products are attack-proof, but we are confident in saying that they do provide the protection they claim.
|
|
|
|
|
|
|
|
RSS
