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.

Read this full article at Network Computing

Only registered users can write comments.
Please login or register.

Powered by AkoComment!