Okena builds a better mousetrap

IDS (Intrusion Detection Systems) do little more than inform administrators of a potential violation of a secured space. And because these systems rely on signatures to identify threats, they are incapable of flagging new or unfamiliar kinds of attacks. As a result, using an IDS is akin to using only the rear-view mirror when driving a car; you can see what hit you, but you can’t avoid the next collision.

IPS (Intrusion Prevention Systems) go beyond mere detection to take a proactive approach to security. Developed by Okena (a company in the process of being acquired by Cisco), StormWatch 3.2 is essentially a network and application firewall that runs locally on servers and workstation systems. Available for Windows and Solaris (and soon for Linux, according to Okena), StormWatch server and desktop agents watch for aberrant network or application activity from within the OS, granting or denying requests to the OS on the basis of policies they receive (at intervals you specify) from the StormWatch Management Server.

StormWatch performed exceedingly well during our testing, stopping every remote and local exploit that we threw at it, from IIS buffer overflow bugs to viruses distributed via e-mail. On a purely functional level, StormWatch is a solid product, deserving our highest rating of “Deploy.” However, StormWatch takes a more intrusive approach to security than network-based solutions. Implementing it will require careful planning and testing before deployment.

Prepping for prevention

To test StormWatch, we used the Nessus open-source security scanner (www.nessus.org) to attempt to exploit the vulnerabilities of a Windows 2000 server, two Windows workstations, and a Solaris server to see if StormWatch was able to thwart the attacks against them. Nessus scans a host for potential remote vulnerabilities, tries to exploit these vulnerabilities, and generates a report on the status of each system tested.

We installed the StormWatch Management Server on a Windows 2000 Advanced Server system, and installed the agent on two Windows 2000 Professional systems, a Solaris 2.8 server, and a Windows 2000 Advanced Server system running IIS and Microsoft SQL 2000. The installation on all platforms was fairly quick and painless, with the StormWatch Management Server installation requiring an MSDE (Microsoft Data Engine) database at minimum and a Microsoft SQL 2000 server for implementations larger than 500 agents.

The agent can be installed on workstations manually by browsing to the StormWatch server and selecting the agent installation links, or automatically via login scripts or other enterprise client management utilities. Deployment via Active Directory group policies may be possible, but StormWatch does not offer MSI installation packages. Solaris is installed via a standard Solaris package applied with pkgadd.

Immediately after the required reboot following the agent installation, the servers stopped responding to ICMP (Internet Control Message Protocol) echo-requests (ping) because the default firewall policies forbid this packet type. Also forbidden by default server policies were SMB (Server Message Block) drive mappings to other systems and RDP (Remote Desktop Protocol) remote-management connections.

The lack of an RDP service definition was surprising, given the number of system administrators that rely on RDP to manage servers. Even if it wasn’t enabled in the default policy, it would be nice to see a predefined RDP rule for easier configuration. On the positive side, this gave us our first opportunity to implement some custom policies and push them to the servers.

The browser-driven StormWatch console is refreshingly utilitarian, providing easy navigation to the various configuration templates, policy rulesets, and reports. Certain functions of the interface can be hard to locate until you become accustomed to looking at the page footer for action buttons, but when you’re in that mindset, navigation is fairly intuitive. Handily, the StormWatch console was fully usable with both Internet Explorer, Safari, and Mozilla browsers.

To implement our RDP connection permission, we first created a new policy called “Permit RDP Connections” and permitted access from the local LAN to TCP port 3389 to permit the connection to occur. The policy was then applied to the specific server and the new rule sets were generated. The server then picked up the policy change at the next polling interval, and RDP access to the server was functional. A nice feature is that when new rule sets are generated, StormWatch also modifies the client installation packages on the StormWatch Management Server so new client installations will have the most current rule sets.

The configuration layout for both application and network policy management is completely modular; by default, a new server object is placed in the Default Servers group, which contains a set of basic policies implementing network firewalling, user authentication auditing, a standard platform module, and a server module. We could have added our RDP connection rule to the standard server policy and achieved the same results, but by implementing the policy separately, we are able to drop the policy only on the servers that require RDP, and not on every server in the group.

The predefined policies are fairly extensive, with individual groups of policies for specific workstation and server functions, from Microsoft SQL, IIS, DNS, and DHCP policies on the server side to the instant messaging, Microsoft Office, and Windows XP Remote Desktop controls included in the desktop group. On the Solaris side, there are default policies to secure the Apache Web server, sendmail, insecure management protocols (such as telnet, rlogin, rsh, and rexec), and policies to restrict network access.

Storming the gates

Finally, it’s time for our Nessus scan. On the first pass, Nessus detected six security holes in the server, several IIS exploits, a NetBIOS null login hole, two SQL-related security holes, and an Etherleak vulnerability. We then applied the StormWatch agent to the system, applied the built-in IIS and Microsoft SQL Server protection policies to that server, and scanned again. This time, only the IIS ISAPI filter extension exploit was noted as vulnerable and then flagged as a potential false alarm because the exploit wasn’t actually attempted. We saw similar results on the Solaris system, with Nessus not reporting the previously seen Apache, sendmail, and remote management protocol exploits. These results back up Okena’s claims that StormWatch provides a tangible measure of security for unpatched servers, allowing administrators plenty of time to test and plan for patch rollouts rather than hurriedly patching servers to prevent a possible intrusion when the next vulnerability is announced.

Next we dove into StormWatch’s local application firewalling. StormWatch’s server and desktop agents inspect every system-level action of a user or process, and determine whether or not that action is permitted by the applied policies. For example, it’s unusual for an application or installer to write to the boot sector, and StormWatch will stop this action or prompt for confirmation if detected. This is similar to other utilities that look for unauthorized modifications to system files and warn the user that a threat exists. StormWatch extends this feature to include the detection and prevention of buffer overflows, and the ability to dictate the action taken when an event occurs. For instance, our attempt to run a common virus-laden e-mail attachment was met with a dialog warning that an application was attempting to alter a resource illegally and gave the option to allow or deny this action.

The common problem with application firewalls is the complex dependencies of system objects and applications; a seemingly benign change to an application policy can wreak havoc if the change was not fully researched. To help alleviate this problem, StormWatch has a Test Mode that can be applied to a workstation or server to test policies without enforcement, simply reporting what would or would not have been permitted by the applied policies.

Perhaps the most useful tool for configuring StormWatch is StormFront, a $9,995 plug-in for the StormWatch Management Server. StormFront is designed to do the heavy lifting required to implement proper application firewalling. It observes an application during normal use and creates policies to permit that application to run unhindered while the system is locked down. This feature is extremely important to the overall viability of application firewalling, given the major time investment to manually document the hooks in any given application and write the requisite policies.

In the know

The other side of IPS is in the reporting. Reports of intrusion attempts can be very large, and contain mountains of irrelevant data obscuring real data on real attacks. StormWatch attempts to combat this problem by providing an event correlation engine that combs through the data logged from the server and workstation agents, and helps determine if an attack actually took place on the basis of events seen within a configurable timeframe. When we used Nessus to simultaneously scan all our machines running the StormWatch agents, StormWatch’s event correlation engine picked up on this and generated a specific event detailing the attacks.

The decision to move to an IPS such as StormWatch cannot be made lightly, as it directly affects every host within the network, and the costs of implementation for large networks may be high. And because protecting servers and workstations in this manner puts the onus of protection on the host itself, rather than on dedicated network hardware, it can impact server performance.

Nevertheless, OkenaStormWatch provides an extreme level of control over security, far more than network-centric firewalling and an IDS. Okena has made significant strides in easing the pain of IPS administration, and StormWatch performed as promised in our tests. Implementing StormWatch does not mean that you no longer need firewalls, but it can dramatically decrease the likelihood of a successful attack on a server or workstation.