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 mfratto@nwc.com.
REPORTS
ANALYTICS
Follow 
