Hip Check

We invited Argus Systems Group, Armored Server, Computer Associates, Entercept Security Technologies, Harris Corp., Network-1, Okena, Tiny Software, Tivoli and WatchGuard to participate in our tests of HIP products. Tiny Software was unable to get us a product in time. Network-1 said it didn't have a product fitting our criteria and Tivoli just refused to come play in our sandbox.

That left Argus' PitBull LX and Protector, CA's eTrust Access Control, Entercept's Web Server Edition, Harris' STAT Neutralizer, Okena's StormWatch and StormFront, and WatchGuard's ServerLock and AppLock/Web for testing in our Syracuse University Real-World Labs®.

These products run the gamut from all-encompassing systems--such as CA's Access Control, Harris' STAT Neutralizer and Okena's StormWatch, that protect a wide range of applications--to products like Argus PitBull Protector and WatchGuard AppLock/Web that are targeted at Web server protection.

All the products install as kernel-level modules, or in the case of Argus PitBull LX on Solaris, as a kernel and shared library replacement, to trap or modify system calls. The products process the access requests via policy engines before passing them on to the system for execution. Access requests that are denied never get to the underlying operating system; the server hums along unaffected and the attack becomes water under the bridge.

Although we expected different types of configuration options depending on OSs supported, we were surprised to find disparities such as those in CA Access Control, in which you can limit the actions servers are allowed to take on Unix but not on Microsoft Windows 2000, or in Argus PitBull Protector, which is highly configurable on Unix, but not on Windows 2000. A few products, including Entercept, Argus PitBull LX and CA Access Control, allowed user-based access-control rules that let us create policies specifying which users can write or update files while blocking all other writing.

Our ideal product would let us centrally manage and enforce a host-security policy that limits access to only those system resources required to run the application. For example, Web servers need to read configuration files or registry keys, read documents from the webroot, execute scripts from a cgi-bin directory, and bind to Ports 80 and 443. You should be able to block the ability to overwrite or modify critical OS files except where necessary for normal system operation, a block all the products we tested allowed.We also want to build policies for any server-based application. While prepackaged protection is helpful for deployment, tons of enterprise applications--including collaboration, Web application, ERP (enterprise-resource planning) and groupware servers--can harm the underlying OS and provide an avenue of attack. Of course, profiling the required resources and the types of access per resource means you have to thoroughly exercise the application, log all the resource requests and develop the policy. Only Okena StormFront tracked application activity and developed what it thinks is a reasonable policy based on the events logged. We still had to modify and test the generated policy through several cycles, but the initial resource discovery by StormFront shortened our policy-development cycle considerably.

The types of objects to which you can control access, and the types of access per object, are important: Attacks happen both locally and remotely. If you limit the ability of servers to read, write and execute files, you prevent them from running a shell or shell commands. But that may not stop an attacker who can walk up to the console and load a Trojan or backdoor from a floppy disk. You want to control access to the file system, network ports, I/O ports and other means of communicating with external resources. In addition, blocking stack and heap buffer overflows provides another layer of protection. Only Okena StormWatch, Argus PitBull LX and CA Access Control on Unix let us regulate file and network access, while the products from all the others except Harris provided buffer-overflow protection.

The more precisely we can define an application's access requirements, the more likely we can contain successful attacks against the OS. That includes being able to specify access based on user name or group affiliation. Argus PitBull LX on Unix and CA's Access Control let us set user-based access control so we could create a user group that could modify or create files only in webroot--and nowhere else. Administration of the Web server would be granted to a group that wouldn't need write access to HTML, ASL or PHP files and CGI executables.

After a month and a half of testing and hours of poking and prodding (punctuated by bursts of salty language), we gave our Editor's Choice award to Okena StormWatch. It's a complicated product--expect to spend some time swimming through various policy options--but it grants nearly everything on our wish list. It cannot make policy decisions based on user IDs, and though arguably that's not the problem Okena is solving with StormWatch, such a capability would add that extra touch.

If you don't need an all-in-one tool like StormWatch, CA Access Control or Argus PitBull LX on Unix, but would rather have a more targeted HIP product, Entercept, Argus PitBull Protector and Harris STAT Neutralizer are good choices. WatchGuard ServerLock, however, lacks many of the features offered by rivals, including read and execute access, support for multiple applications and network control.

StormWatch takes our Editor's Choice because of the breadth and depth of its configurable options. The more options, the tighter you can lock down applications and services, which is what these products are all about. Add in stack-buffer-overflow protection, a robust policy-definition system, multiagent management, including policy and software updates, detailed logging and auditing, and tiered management, and you're looking at one powerfully HIP product. But Okena should be feeling the heat from Argus on the Unix front and CA on both Unix and Windows because these vendors offer user-based, in addition to host-based, access control. Additionally, Okena's lack of support for Linux is shortsighted.Servers that are protected by StormWatch are grouped, and one or more policies are applied to the group. For example, the default groups for both Unix and Windows have policies that protect critical system resources common to the platform and the StormWatch files. If you want to protect IIS also, you simply add that policy to the default group.

StormWatch is focused on protecting system resources, and its policies are defined according to what resources applications can access and how they can access them. Policies are defined per application and contain rules that allow or deny access to resources or groups of resources. In the case of StormWatch, system resources can be files, registry keys, network addresses, network services or COM objects. Groups of resources are defined in resource sets and may contain fully qualified definitions, such as "c:winntsystem32 cmd.exe," that match just that file, or they may contain wild cards like "**winntsystem**," with file names matching *.dll, which matches anything on any drive, in the path beginning with winntsystem, and finally matching any DLL file in that path. The other object types, of course, would have their own syntax and wild-card definitions.

Application classes are similar to resource sets, except that they define the executable files that are used by an application. Application classes can be defined using the resource sets: For example, the system applications class is defined using the system executable file-resource set. Policies can take one of three paths when a rule triggers: allow the action, deny the action or query the user for permission to run. Finally, application classes, resource sets and actions are used in the policies to define the resources an application may or may not access. Rules are ordered automatically by StormWatch and are processed from the top of the list down. Actions are taken on the first match.

Determining the resources an application needs is a complicated business. For example, applications open and close files and network ports dynamically during run time. Less frequently used resources, such as registry keys, may be activated only once. When profiling an application, it's important to fully exercise the application from start-up, through every possible action, and then shut down, logging every access. The process of building the rules then begins. Unlike the other products that allow custom-policy building, Okena has a product--StormFront--that monitors and logs an application's activity and then builds a policy. You review the policy, make changes and corrections as necessary, apply the policy and test it. You keep testing and tweaking the policy until it is properly configured. StormFront automates the bulk of the resource discovery and all that is left are minor adjustments--how much adjusting you do depends on the application you're profiling. StormFront is necessarily very literal when building a policy. When we profiled the SSH server, the policy allowed only read/write access to the directory the user logged into. Of course, we had to broaden that access.

While flexibility equals complexity, the StormWatch manager is well-thought-out and offers easy access to all relevant details. If you are examining a policy, you can click a link to see which groups it is applied to. You can move through policy elements easily via dialog pop-ups and drop-down menus. The logging is very detailed, including links to the event details and to the rule that triggered the log entry. The log is filterable, and can include or exclude events based on event text. There is also a separate audit log detailing administrative events.Okena has set the bar high with its robust policy development, decent discovery tools, easy-to-use management and detailed logging. If the company would support a wider variety of OSs and include user-based access control, StormWatch would be truly cooking. We expect big things from this product in the years to come.

Okena StormWatch 3.0, $1,800 per server, $85 per desktop; StormFront 2.0, $220 per server and $10 per desktop, Okena, (781) 209-3200. www.okena.com

Computer Associates eTrust Access Control 5.1 | Harris STAT Neutralizer 1.2 | Entercept Security Technologies Web Server Edition 2.5 | Argus PitBull LX 1.1 and PitBull Protector for IIS | WatchGuard Technologies ServerLock and AppLock/Web

Computer Associates eTrust Access Control 5.1



Access Control comes in a strong second, especially on Unix, largely because of its user-based access-control approach and the breadth of platforms it runs on. However, we were unable to adequately lock down Microsoft IIS and other services running on SystemLocal because doing so would essentially stop the system from running. What makes Access Control for Unix so strong is that you can lock down a service very tightly while still letting administrators make configuration changes. The product's management is not as well designed as that of Okena StormWatch, and its logging, while detailed, is a bit cumbersome to use. For the hard-core geek, Access Control has a well-defined CLI (command-line interface) that gives you access to everything in the GUI, and you can even shell out to the local system to run commands.

Access Control is designed around user-based access control. Users can be imported from the local system or on a PDC (primary domain controller) or on Active Directory machines, from the domain, or they can be added directly in Access Control. In fact, if you use the product to manage users, you should add them via Access Control, which will in turn add them to the local user store. On Unix, services typically run under unique user IDs, which is what lets you configure a service's access control. For example, if you're running the Apache Web server as user "apache," you can import that user into Access Control, define the access control for the "apache" user, and therefore restrict the HTTPD server's access. If you must use run services that run under privileged user IDs, such as root, or run multiple services that run under the same user ID, Access Control can assign a virtual user ID to that specific program and restrict access according to the defined policy. Unfortunately, that functionality is not available for Windows.

Discovering the resources an application uses is a manual process requiring you to know at least the executable program path and name. Administrators bear the burden of discovery by applying the default policy to the server in "warning" mode, which means all access will be allowed and logged. The admin then must audit all activity from the user running the process. For example, we profiled the Apache Web server on Solaris by auditing the "apache" user, starting the server, downloading pages and stopping the service. Then we went through the audit log and created access rules for the files and directories the user accessed. Once we had the configuration complete, we applied the policy and tried to start the Web server. If it failed to start, we checked the logs for denials, tweaked the policy, and tried to run it again. Rinse and repeat until done. It took us and an SE about two hours to complete the discovery and create a policy. We also profiled our WU-FTP server, and that took us nearly six hours. Not a bad day's work, but not nearly as simple as using Okena StormFront.

CA's Access Control is a strong contender if you're running some uncommon operating systems. In fact, if you're running anything other than Windows, Solaris or Linux, it's your only option. If Access Control for Windows adds the same functionality as its Unix counterpart, Okena will have some competition.eTrust Access Control 5.1, $3,500 per server. Computer Associates International, (800) 225-5224, (631) 342-6000. www.ca.com

Harris STAT Neutralizer 1.2

Like StormWatch and Access Control, Neutralizer offers a robust set of protection options at a very low price point. The bad news is you're limited to Windows NT/2000. The good news is Neutralizer can protect any application and ships with preconfigured policies that you can apply. You can also build your own, though as with Access Control, discovering an application's resource requirements is a daunting task.

Unlike rule-building in Okena and CA products, each rule in Neutralizer has to be created by hand. You can define variables for environment strings or Registry keys, but for everything else you have to type them or try to determine the appropriate registry key to look in. Rules are based on access to a file-system object or a registry key and by a process, a user or both. The rule definition is simple if you can weave regular expressions; otherwise, pick up a book on regular expressions and keep it handy (a good tutorial is at etext.lib.virginia.edu/helpsheets/regex.html).Once we had our policies defined, we applied them to the agents and ran some attacks, which were successful. After some more testing, head scratching and calls to Harris, we were told we shouldn't need to reboot the computer after the agent is installed, but alas, we must because the agent needs to see the service start before it will monitor access. Harris is working on this problem. Once we rebooted, we could modify the policy without a problem.

Creating rules to protect applications is difficult. For example, we installed SQL Server 2000 on our test machines and wanted to restrict its access to required services only. Since there was no defined template for SQL Server, we created a monitor rule to track all activity. We rebooted the server to see exactly what happened on boot up and found more than 600 events logged. Many of these were registry-key entries, but because the logging is not very detailed, we couldn't tell immediately if the events were reads, writes or what. To make matters worse, there was no way to filter the log after the fact, so we could search just for file reads or filter out other events. Harris needs to provide some filtering capabilities on logging. A wizard to discover the resources an application accesses would be helpful too.

Neutralizer works well once it is installed and properly configured, but getting the policies built is a trying task and really burns up the hours. Then again, at just $25.95 per workstation agent, you can afford to spend some extra time developing policies.

STAT Neutralizer 1.2, $2,595 for 100 workstation agents, $7,650 for 10 server agents. Harris, (888) 725-7828. www.statonline.com

Entercept Security Technologies Web Server Edition 2.5

Entercept Web Server is unique in several ways. First, it uses both behavioral and signature detection to block attacks. Second, the standard agent protects the OS and blocks generic buffer-overflow attacks and privilege escalation. It also protects IIS on Windows, and Apache, Netscape Enterprise and iPlanet Web servers. However, you're limited to the specific applications that Entercept supports unless you pay for professional services to build custom policies for you. At $1,850 per person per day, that's a pricey proposition.

We installed Entercept standard on a Windows 2000 SP0 computer and ran a number of common exploits against IIS. Notably, all the buffer-overflow attacks failed because of the product's stack-buffer-overflow protection. However, application-layer attacks against IIS, including directory traversal and unicode directory traversal, worked--as we expected they would. Once we installed Web Server Edition, however, we were unable to run any attacks successfully against IIS. One nit: If Entercept's automatic protection blocked access that we wanted to allow, we had to create an exception to the rule using a wizard.

Unlike with Okena, we were able to define users who were allowed to modify the configuration of IIS. First we defined a new group, called Web Admins, in Windows 2000 and added users. Then we added that user group in the IIS configuration for authorized IIS operators and created a series of exceptions on all the IIS shielding signatures in Entercept so that the users in the Web Admins group would be able to make configuration changes.

Bottom line, Entercept Web Server Edition, while not as full featured as rivals, is tightly focused on specific applications and is simple to install and manage.Entercept Web Server Edition 2.5, $1,295 to $2,995 per agent; $4,995 console. Entercept Security Technologies, (800) 599-3200, (408) 467-4600. www.entercept.com

Argus PitBull LX 1.1 and PitBull Protector for IIS

Argus PitBull offers significantly different feature sets between Unix and Windows, so, like CA Access Control, we scored them separately. On the Unix side, Sun Solaris and Linux are supported, and the granular access control is on par with CA's Access Control. PitBull Protector on Windows 2000 has a much more limited feature set, allowing directory and file write and execute protection as well as stack-overflow protection. Unfortunately, PitBull Protector doesn't support policy customization, as do PitBull LX and Okena StormWatch.

PitBull LX installs on Solaris and Linux as loadable modules and does require you to recompile the Linux kernel and rebuild the modules. On Solaris, it replaces the kernel and shared libraries. PitBull modifies the system call functions so that security processing occurs prior to the system call being executed. On Windows 2000, Protector is a kernel-level module that is launched at run time and traps system calls.Although you can use PitBull LX for user-based access control, it is more accurate to say that access control is enforced by domains. A domain is a label applied to system objects, such as files. Users and processes are assigned process domains when they log in or start up, respectively. A user or process can access an object if its process domain dominates, or contains, all the target object's domains. Objects, processes and users can be members of multiple domains, so you can create very detailed and complex access controls across a system. PitBull LX has a difficult learning curve, and for the CLI-challenged, the lack of a GUI as well as the dearth of centralized management are drawbacks. You can set policies across multiple servers using scripting, but that means each system has to be nearly identical.

PitBull Protector, comparatively speaking, is a simple-to-configure application. Install it on the server, set it to learn mode, start IIS and exercise your applications. Protector tracks what IIS does and generates the appropriate rules for write and execute access. Turn off learn mode, and inetinfo.exe can do only what Protector has learned. There is an advanced configuration that lets you set individual directory and file write modes if you need further customization.

If you have seasoned Unix administrators, PitBull LX might be a good choice because it is robust and targeted at access control. PitBull Protector is targeted at Windows 2000 and IIS and is very easy to use, though less feature rich than Entercept Web Server Edition.

PitBull LX 1.1, starts at $3,000; PitBull Protector for IIS, $795. Argus Systems Group, (800) 95ARGUS, (217) 355-6308. www.argus-systems.com

WatchGuard Technologies ServerLock and AppLock/Web

ServerLock and AppLock/Web are simple applications that protect against the creation and modification of files and registry keys. Not nearly as robust as other products in this review, ServerLock and AppLock/Web, which is a pared-down version of ServerLock that is targeted at IIS, will protect against common attacks, including Web defacements, and any exploit that requires writing to the file system, provided that part of the file system is write-protected. If an attacker can cause a server to write files arbitrarily, there is a good chance that the attacker will be able to break in. This protection is rudimentary and there are no provisions to block the reading or execution of files.

We found a potential problem with the product's stack-buffer-overflow guard protection. We used two separate tools that exploited the .printer ISAPI Extension Buffer Overflow vulnerability (Bugttraq id 2674) to test the stack protection. "Jill.c" by dark spirit was successfully blocked, while eEye Digital Security's iishack2000.exe proof of concept worked every time. WatchGuard's stack protection doesn't block the buffer overflow, but it does block operations, such as code execution, from performing on the stack. The vendor's initial opinion was that iishack2000.exe causes inetinfo.exe to write a file on the C drive rather than execute a program from the stack.

For what you'd pay for ServerLock, you'd be better off with one of the other products we tested.

ServerLock NT/2000 2.0, $1,295; ServerLock for Solaris, $1,695; ServerLock Manager, $4,995 to $14,995. WatchGuard Technologies, (877) 232-3531, (206) 521-8340. www.watchguard.com Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®. He covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Write to him at [email protected].

For our host machines, we installed Sun Microsystems Solaris 8 on an Ultra 10, Windows 2000 Server on Dell OptiPlex GX1s and Red Hat Linux 7.1 on a Dell OptiPlex GX1. We didn't patch or apply service packs to any of the systems we were protecting. We searched through various archives, including SecurityFocus (online.securityfocus.com/bid) and Packet Storm (packetstormsecurity. org), for tools that would let us exploit known application vulnerabilities on our target operating systems. We found many to choose from, including remote buffer overflows, directory traversal tricks and local exploits.

Our goal for Windows 2000 and IIS as well as for Solaris 8 with Apache was to let the Web server have read access only to webroot, and no write access. That stops most attacks that try to break out of webroot or attempt to copy or execute files, such as command shells. We even assumed the attacker had access to the console and could add software to the system locally. For example, copying command.exe into c:inetpubscripts so that it could be reached by using http://server.ip/scripts/command.exe/c+

R E V I E W

Host-Intrusion Prevention Software

Sorry,
your browser
is not Java
enabled

Welcome to

NETWORK COMPUTING's Interactive Report Card, v2. To launch it, click on the Interactive Report Card ® icon

above. The program components take a few moments to load.Once launched, enter your own product feature weights and click the Recalc button. The Interactive Report Card ® will re-sort (and re-grade!) the products based on the new category weights you entered.

Click here for more information about our Interactive Report Card ®.