wp6 by galoctanle

VIEWS: 6 PAGES: 11

									ARGUS SYSTEMS GROUP

PitBull LX
Product Tutorial

White Paper November 16, 2007

PitBull LX Product Tutorial

COPYRIGHT ©2007 Innovative Security Systems, Inc., dba Argus Systems Group, 1809 Woodfield Drive, Savoy, Illinois, 61874 U.S.A. All rights reserved. This product and related documentation are protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of Argus Systems Group and its licensors, if any. DISCLAIMER THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. NOTICE TO USER This publication could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. These changes will be incorporated in new editions of the publication. Argus Systems Group may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time. TRADEMARKS PitBull is a registered trademark of Argus Systems Group. Argus Systems Group and PitBull LX and their respective logos are trademarks of Argus Systems Group. All brand names and product names used in this document are trade names, service marks, trademarks, or registered trademarks of their respective owners.

ii

PitBull LX Product Tutorial

Table of Contents
The Problem .................................................................................................................................... 1 How One Becomes Root ............................................................................................................. 1 A Bug‟s Life ............................................................................................................................... 1 Traditional Security is Not the Answer ...................................................................................... 2 The Solution .................................................................................................................................... 3 PitBull LX: Technology Overview ................................................................................................. 3 Product Definition ....................................................................................................................... 3 LX Tutorial: Processes ................................................................................................................ 4 LX Tutorial: Files ....................................................................................................................... 4 LX Tutorial: Networking ............................................................................................................ 4 LX Tutorial: Users ...................................................................................................................... 5 There‟s More ............................................................................................................................... 5 NetRules.................................................................................................................................. 5 Security Flags.......................................................................................................................... 5 Putting It All Together .................................................................................................................... 6 Technology Summary ..................................................................................................................... 6 Additional Benefits ......................................................................................................................... 7 For more information ...................................................................................................................... 7

iii

PitBull LX Product Tutorial

[This page intentionally left blank.]

iv

PitBull LX Product Tutorial

The Problem
It is no surprise to anyone that today‟s business architecture is fraught with risks and security vulnerabilities. Web-facing servers running bug-filled application software are now sitting between the Internet and back-end servers storing your most sensitive and valuable data. A single security breach on a web-facing server can provide an attacker with an unobstructed path to the corporate jewels. And even if there are a few hurdles blocking the way, today‟s hackers are so sophisticated and determined that in many cases the hurdles are more of a nuisance than a major obstacle. Application software can introduce serious security vulnerabilities into a business. A quick review of recent security headlines illustrates the multiple security flaws (bugs) that exist in popular web-facing software. This is true for both commercial and home-grown applications. The exploit of a single bug can give an attacker administrative control of the business server. Once this control is seized, the kidnapped server becomes a hacker stronghold, from where attacks can be launched against back-end servers and both internal and external networks and systems. On Unix servers this administrative access is referred to as root, or superuser. If an attacker gains superuser status on a Unix server he has access to the entire system, including: Configuration files—by modifying the configuration files an attacker can reroute traffic to his own machine or to systems on an internal network. Content—favorite targets of hackers are a company‟s web page and its private, sensitive data. Networking resources—if only a small crack was open initially, gaining access to networking resources can turn a crack into the Grand Canyon. System files—critical system files can be replaced with trojan horses or other malicious code.

How One Becomes Root
There are many types of exploits designed to take advantage of application security flaws. One of the most common is a buffer overflow attack. Most programs at some point will ask for some type of information input, which is placed in something called a buffer. The information could be as simple as name or address information. At the end of the buffer is a return locator, which tells the program where it should go once the input has been received. In a buffer overflow attack, the attacker enters enough information to overrun the buffer, which in a poorly-written program can allow him to overwrite the return locator. By changing the address of the return locator, the attacker will attempt to re-route his session to another process, possibly one running as root. Once this happens, the attacker will be well on his way to obtaining superuser rights to not only a single server, but possibly to every server on your network.

A Bug’s Life
Application security flaws may often exist for long periods of time before they are ever made public. Since they represent a hacker‟s most common means of breaching a system or network, it is often the hacker community (black hats) that first discovers these vulnerabilities. After hackers

1

PitBull LX Product Tutorial

have „had their fun‟ (at someone else‟s expense) the bug will often get posted on one of the popular bug-tracking sites. Eventually the software manufacturer will release a patch to plug the hole, and will notify its customers. The patch may or may not be applied by the end-user. The lesson to learn is that even if a company is diligent about applying patches and plugging security holes, it is still vulnerable—in some cases for months or even years before a bug is made public and a patch can be applied.

Traditional Security is Not the Answer
Security experts will often say that the solution to this problem is to stay constantly on the alert, monitoring your applications for security holes and applying patches and bug fixes when they immediately become available. Although this is good advice, for many companies this is a daunting task. Hundreds of servers running a myriad of applications can make this difficult, if not impossible to fully carry out. Many IT and information security departments are already understaffed and overworked. Staying 100% up-to-date on all patches is not their highest priority. And even if it was, the magnitude of the task alone makes it impractical. Plus, no amount of diligence will protect an organization against bugs that have not yet been made public, or where a fix has not yet been released. This is similar to a disease, where people first have to be infected before a vaccine can be developed. Hoping that someone else gets infected before you do is no way to run a business, especially when preventive security solutions are available today. Leading-edge security practitioners are already benefiting from these new technologies via lowered risks and reduced administrative efforts. Another common response to application security flaws is to add more and more costly layers of perimeter security such as firewalls and intrusion detection systems. Although these technologies can provide valuable security functionality, they do not address the problem. Firewalls may limit direct access to back-end networks or servers, but they do allow access to web applications. In fact, the minute a company connects a web server to the Internet at www.company.com, visitors to that website are by definition beyond the perimeter firewall. If bugs exist in those web applications, your sensitive internal systems and data are vulnerable to successful buffer overflow attacks, worms, and a variety of other exploits. Intrusion detection systems (IDS) are also limited due to their mode of operation. Most IDS look for known attack patterns, and when they recognize an attack, send out alarms so the attack can be thwarted. Often, by the time IDS responds to an attack, it is too late—the damage has already been done. Plus, IDS (even active IDS or host-based IDS) provides little to no protection against unknown attacks or for encrypted channels. New attack methods can penetrate even a properlyconfigured intrusion detection system. Traditional security (firewalls and IDS) is focused primarily on protecting the perimeter of a company‟s network. All protection stops once an attacker gains access to a business server. Plus, perimeter-based security provides no protection against disgruntled insiders, who by default are already beyond the perimeter. Based on the volume of successful security breaches today, and the widespread use of traditional security mechanisms, it is clear that new security technologies are needed.

2

PitBull LX Product Tutorial

The Solution
A new category of security solutions has arisen to address the serious problem caused by application bugs. Known as Application Security, these solutions place security where it is needed most—on the servers that are storing the sensitive data and delivering the mission-critical services. A robust application security solution will protect the four main elements of a system: processes (running programs), files, networking resources, and users. PitBull LX, an application security solution from Argus Systems Group, is the leading solution that delivers this type of protection. PitBull LX has the ability to isolate processes in separate security compartments. By placing applications into these compartments they can be completely isolated from one another. On a PitBull-enhanced system, a successful bug exploit in one application will not lead to attacks on any other applications or systems. Instead, it is as if the attacker is locked inside a jail cell with no way out. In a web server environment it is important to protect the integrity of web pages. Web files are favorite targets of hackers as they earn „bragging rights‟ for defacing web pages. PitBull LX protects files by restricting the actions that processes can perform on specific files. For example, in only a few simple steps, the web server can be configured so that it can only read its web pages. Unable to write to or execute the web page files, the web pages are completely protected from defacement. LX access controls cannot be circumvented, even by UID 0 (root). These principles can be used to protect files of all types. PitBull LX provides secure communications through its ability to assign network traffic to specific applications (and vice versa). For example, let‟s assume that a server is running two web server applications, each in separate security compartments. Only one of these web server applications should be able to communicate with an application server on the same network. The other web application must be totally isolated from the application server for security reasons. This is no problem for PitBull LX. Once again, it can provide networking-level security in just a few simple steps. User-level protection is provided by PitBull LX via its ability to restrict users (or groups of users) to specific security compartments. Administrators, even those with superuser access, can also be restricted to specific compartments. Restricting user access rights provides valuable protection in a network-based environment.

PitBull LX: Technology Overview
Product Definition
PitBull LX is an award-winning application security solution. Its unique Secure Application Environment (SAE) protects against security flaws in application software by isolating applications into separate security compartments. Exploited software bugs which in the past could grant an attacker system-wide access, are now relegated to a single security compartment. PitBull‟s Secure Application Environment is made possible by a concept called domain-based access control (DBAC). DBAC is used to create and enforce the separate security compartments that make SAE possible. In PitBull LX terminology, these compartments are referred to as
3

PitBull LX Product Tutorial

domains (or subsystems). Processes, files, users, and network interfaces can be confined to separate domains that can be completely isolated from other domains. Multiple domains can be created on a machine, converting a single server into a system supporting hundreds of „virtual machines,‟ each with its own Secure Application Environment supporting secure applications, services, files and systems.

LX Tutorial: Processes
DBAC consists of two types of domains, file domains and network domains. One purpose of file domains is to isolate processes (running programs) from one another. If two web applications are running on the same server, and the goal is to disallow any communication between them, file domains can be used to accomplish this. By assigning one application the file domain name of „yellow‟ and the second application the domain name of „grey,‟ communication between these applications has been blocked.

LX Tutorial: Files
There is much more to file domains than simply isolating processes. To best understand the full benefit of file domains, a brief background discussion is helpful. Computers consist of both subjects and objects. A subject initiates an action, whereas an object is the recipient of an action. Subjects may perform three types of actions upon objects: read, write and execute. These are known as access permissions. In our example of a web server and its web pages, the web server is the subject and the web pages (or web files) are the objects. The action to be performed is the reading of the web pages by the web server. It is important that the web server has only read access to the web pages. This protects the web pages from defacement. In order to satisfy this security goal, the following file domains should be assigned. Web server: grey(r--) Domain name = grey Access permissions = read only Web pages: grey(rwx) Domain name = grey Access permissions = read, write, and execute In this example, the web server is only allowed to read the web pages since the web server only has the read permission bit. The web pages (the object in this example) require read, write, and execute permissions. What this means is that the web pages can restrict all three types of access. But since the web server has the read permission bit in its file domain, which is what the web pages require, it is allowed to read the pages. If the web pages had a domain name of grey(-w-), they would only be able to restrict write access. Any process (subject) could read or execute the file. The web pages would have no ability to prohibit these types of access.

LX Tutorial: Networking
PitBull LX protect/restricts communication between processes through the use of network domains. Similar to file domains, network domains apply to both networking objects and

4

PitBull LX Product Tutorial

processes. Network domains are presented as domain_name(net). For two processes to communicate with one another they simply need to have one network domain in common. For example, let‟s assume that a business architecture includes a web server application, an application server, and a database application. Traffic from the Internet should be given access to the web server application, but should not be able to directly communicate with anything else. By the same token, the web server should be able to access the application server, but not the database application. Finally the application server must be able to communicate with the database. To facilitate this type of secure communication the following network domains could be assigned.

LX Tutorial: Users
File domains have at least one more use that has not yet been chronicled—restricting the access rights of users. In conjunction with Pluggable Authentication Modules (PAMs), file domains are assigned to users upon login which dictates where users can go and what activities they are allowed to perform. For example: Rob: eng(rwx) - Based upon this assignment, Rob is restricted to the eng (Engineering) domain, but is granted read, write, and execute permissions. Liz: hr(rwx) - Liz is restricted to the hr (Human Resources) domain and is allowed read, write, and execute permissions. Multiple file domains can be assigned to each user based upon the corporate security policy. These domains restrict the actions of all users, including superuser (root). Root cannot override PitBull LX‟s domain-based restrictions.

There’s More
In addition to DBAC, there are two other features of PitBull LX that add valuable security and administration attributes: NetRules and Security Flags.

NetRules
NetRules work in tandem with network domains, providing an even finer-grained method of network access. NetRules can be assigned on any combination of the following: destination address, destination port, source address, source port, interface and protocol. For example, let‟s consider a web server that has a network domain of web(net), that should only be able to accept traffic from port 80. Under PitBull LX we can assign a NetRule that will allow all port 80 traffic to reach the web server by assigning all ports other than 80 a different network domain, such as Netdenied(net). Any traffic now coming in from port 2000, for example, will be assigned the Netdenied(net) domain and will be automatically dropped.

Security Flags
File security flags are special flags that can be placed on files to dictate certain behaviors. These behaviors can tell PitBull LX whether it is protecting a file, whether PitBull LX security should automatically be placed on files that are created in a particular directory, as well as cause special security actions to be taken when a file is executed. Many different security flags are available.

5

PitBull LX Product Tutorial

They are designed to provide a flexible way of applying system-wide security with minimal effort. Security flags can also be associated with processes and networking objects. Security flags are one of the key tools used to restrict superuser privileges. One example of this feature is the security flag ASG_SEC_ACC_FS. This flag restricts access to files that are not protected by PitBull LX. If this flag was applied to a web server, the web server would not be allowed to access any file system object on the server that was not LX-aware. The benefit of this flag is that through one simple step hundreds of files can be isolated from an application or process without having to make any changes or modifications to the files themselves.

Putting It All Together
With PitBull LX, locking down an Apache web server can be accomplished with four simple steps. 1. Create file domains: Assign the same file domain (httpd) to both the web server and the web files. The web server should be given only read access (httpd(r--)) so that it cannot write to or execute the web pages. This protects the web pages from defacement. The web page files should be given read, write, and execute access permissions (httpd(rwx)) so they can restrict these types of access when necessary. 2. Run Argus lockdown script for Apache: An Apache lockdown script is delivered with the PitBull LX software. This script basically does two things: a) assigns the web server a network domain of net_httpd(net); b) applies a security flag to the web server that will not allow Apache to access any file system object that is not protected by LX. This flag protects every file on the system without having to apply LX security to each and every file. Now the web server can only do one thing; read its web pages. 3. Apply NetRules: One NetRule needs to be applied, which allows the web server to only communicate on port 80. Traffic from any other port will be automatically assigned a netdenies(net) network domain. This single NetRule blocks all communication except that which comes in on port 80. 4. Assign an Administrator: By placing an entry in the /etc/argus/users database, an administrator can be defined for the web domain by assigning him the file domain of httpd(rwx).

Technology Summary
PitBull LX delivers robust application security for the most sensitive servers and applications in a business architecture. It is ideal for securing web servers, application servers, database servers, DNS servers, mail servers, ftp servers, and e-commerce servers. PitBull LX‟s Domain-Based Access Control—which grants the right type of access to those that need it, and denies access to others—supports the creation of Secure Application Environments (SAEs) that cannot be circumvented, even by users with superuser access. These SAEs can be used to isolate applications, processes, users, networking objects and files into separate security compartments. Application security flaws, walled in by SAEs, cannot be used to launch attacks against back-end servers or sensitive data.
6

PitBull LX Product Tutorial

Additional Benefits
PitBull LX was designed from the ground up to be easy to install and administer. It installs as a system upgrade to standard Solaris operating systems. Since it is 100% compatible with the underlying API (application programming interface), it is completely transparent to all applications. PitBull LX is scalable, and is supported on machines from desktops to large, multiprocessor systems. It can be applied to only the areas of a system that need to be secured. The remainder of the system behaves like a normal Unix or Linux environment. The strength and flexibility of PitBull LX can often lead to simplified business architectures. PitBull‟s Secure Application Environment can lead to server consolidation, which reduces both costs and complexity. In many web-facing environments the use of PitBull LX can lead to the elimination of costly perimeter security technologies, greatly simplifying the overall business infrastructure.

For more information
For more information about Argus Systems Group and its market-leading suite of trusted operating systems technology: Email: Tel: Fax: info@argus-systems.com +1 217-355-6308 +1 217-355-1433

Website: www.argus-systems.com

Address: Argus Systems Group 1809 Woodfield Drive Savoy, IL 61874 USA

7


								
To top