220 Chapter 7 • Intrusion Detection Systemsget more for your hardware dollar with the UNIX version, the Windows version is not just a side project—it is actually developed by the core Sn
Trang 1Figure 7.3 Webmin Snort Edit Ruleset Page
Trang 2220 Chapter 7 • Intrusion Detection Systems
get more for your hardware dollar with the UNIX version, the Windows version is not just
a side project—it is actually developed by the core Snort group and kept fairly current with the UNIX version It also allows you to take advantage of point-and-click installation as well as some of the other niceties in Windows 2000 and XP such as built-in IPSec support It’s nice to see an open source project that realizes there are many Windows-only based companies that would still like to take advantage of this great open source IDS
Requirements for Windows Snorting
Snort for Windows requires Windows 2000 or XP; it won’t run on NT, 98, or 95 You will also need the WinPcap libraries installed If you loaded them for a program described earlier in this book, such as Ethereal or WinDump, then you are all set Otherwise, you can get them at:
netgroup-serv.polito.it/winpcap You will also want the MySQL database if you plan on importing your results into a database Specific configuration of MySQL for this purpose is covered in Chapter 8 You will need more powerful hardware for your Windows Snort box than the UNIX version to get similar performance A 700MHz machine is the minimum, and you’ll
Figure 7.4 Webmin Snort Module Access Control
Trang 3probably do better with a processor in the gigahertz range You will also want to make sure your Windows server is locked down appropriately with a minimum of services run-ning, taking extra care to uninstall processor hogs such as IIS Use the Services window under Administrative tools to make sure you aren’t running anything you absolutely don’t need to
Installing Snort for Windows
To get going with Snort for Windows, get the binary file from the book’s CD-ROM or from www.snort.org Double-click on it and it will automatically install for you It prompts you to choose if you want certain database or add-on modules such as the flex-response module
Setting Up Snort for Windows
The process for setting up the Windows version is very similar to the UNIX setup All the config and rules files are in the same relative subdirectories as the UNIX version Go into the Snort.conf file in the /etc subdirectories of your Snort installation Make the changes and edits to the snort.conf file as suggested in the UNIX section Then go into the rules files and make your changes there Then you are ready to run Snort Refer to the UNIX
“Running Snort” section for more details on how to use Windows Snort, as all the com-mands are the same Fine-tuning and placement rules of thumb are also the same as the native UNIX version
Flamey the Tech Coders Corner:
Writing Custom Snort Rules
While the standard rule sets that Snort comes with provide adequate protection from known attack signatures, you can craft some custom rules specific to your network to get the most out of your IDS You can write rules to:
• Track access to or from particular servers
• Look for certain file types or file names specific to your organization
• Watch for particular types of traffic that don’t belong on your network Snorts rule writing is fairly easy to learn and allows you to quickly add functionality
to the program without a lot of programming knowledge As you have seen, all the Snort rules are simply text statements within one of the rules files
If you want to have Snort look for some unique behavior that would be sus-picious on your network, you can code a rule quickly and be testing for behavior in short order The format of a Snort rule is basically a single text line starting with an
Trang 4222 Chapter 7 • Intrusion Detection Systems
action (usually “alert”) and followed by several arguments In the newest version (2.0 and higher), you can add multiple lines simply by appending a / (slash) to the end of each line You can also call other programs using an include statement for more complexity But in its basic form, a Snort rule has two parts: a rule header and the rule options Below is an example of a rule
alert tcp any any 192.168.0.0/24 / (content:"|00 05 A4 6F 2E|";msg:"Test Alert";)
The alert header is the part before the first parenthesis This statement con-tains the action (alert in this case), the protocol, and destination and source addresses and ports The action is what this rule will do if it is true In this exam-ple, it will generate an alert Other options for actions are Log, Pass, Activate, and Dynamic
The protocols can be tcp, udp, icmp, or ip, which means any IP protocol (In the future non-IP-based protocols such as IPX may be supported.) The source and destination ports are self-explanatory The source address is first, listed in standard slash notation for IP ranges You can also list multiple individual ad-dresses and networks by separating them with a comma, no spaces, and encap-sulating the statement in brackets, for example:
alert tcp any <> [192.168.1.1,192.168.1.5,192.168.1.10] 80 / (content:"|00 05 A4 6F 2E|";msg:"Test Alert";)
This statement focuses on traffic coming from any addresses bound for the machines at 192.168.1.1, 192.168.1.5, and 192.168.1.10 on port 80 Assuming these are your Web servers, this would look for traffic going to them that contained the hex data in the content section
The second part of a Snort alert is the alert options This is where you specify further details about the kind of traffic you are looking for You can search on the many fields in the TCP/IP header (see Chapter 6 for descriptions) or simply search the packet payload Each option command should be followed by quotes and the value you are searching for Multiple options can be added by separating them with a semicolon The following are valid option commands
Pass Ignore the packet This is the default action on packets that don’t
match the rule
Activate Alert, then activate a dynamic rule
Dynamic Remain idle until activated by a dynamic rule, then act as a log rule
Trang 5msg Provide the text description of an alert.
logto Log the packet to a user-specified filename instead of the standard
output file
ttl Test the IP header's TTL field value
tos Test the IP header's TOS field value
id Test the IP header's fragment ID field for a specific value
ipoption Watch the IP option fields for specific codes
fragbits Test the fragmentation bits of the IP header
dsize Test the packet's payload size against a value
flags Test the TCP flags for certain values
seq Test the TCP sequence number field for a specific value
ack Test the TCP acknowledgment field for a specific value
itype Test the ICMP type field against a specific value
icode Test the ICMP code field against a specific value
icmp_id Test the ICMP ECHO ID field against a specific value
icmp_seq Test the ICMP ECHO sequence number against a specific value content Search for a pattern in the packet's payload
content-list Search for a set of patterns in the packet's payload
offset Modifier for the content option Sets the offset to begin attempting a
pattern match
depth Modifier for the content option Sets the maximum search depth for a
pattern match attempt
nocase Match the preceding content string with case insensitivity
session Dump the application layer information for a given session
rpc Watch RPC services for specific application/procedure calls
resp Active response Closes the connection down (for example, take
down connections)
react Active response Respond with a set of scripted behavior (for
exam-ple, block certain Web sites)
reference External attack reference IDs
rev Rule revision number
Trang 6224 Chapter 7 • Intrusion Detection Systems
See the man pages for details on each specific rule option The following are some examples of using these options to create custom Snort rules
Sample Custom Rule 1
Let’s say you have a set of accounting servers that should never be accessed by anyone outside your network You could write a Snort rule to flag traffic coming from any IP that was not on your home network going to these servers Assuming your accounting servers are on the IP addresses 192.168.1.10, 192.168.1.11, and 192.168.1.12, and your home network is 192.168.2.0/24, the rule would look something like this:
alert tcp !192.168.1.0/24 any /
<>[192.168.1.10,192.168.1.11,192.168.1.12] any / (msg:”Accounting Server Access from outside”;)
The ! (exclamation mark) operator here is the NOT operator for Boolean opera-tions This basically says to issue an alert on any TCP traffic that is not coming from the 192.168.1.0/24 network that is bound for these servers There are no options set other than msg, which is the label that shows up in the alert logs This
is because you are concerned with any traffic on any port This would show you any access coming from the outside world to your accounting servers, because it assumes that any outside traffic to them should be considered bad
classtype Rule classification identifier
priority Rule severity identifier
uricontent Search for a pattern in the URI portion of a packet
tag Advanced logging actions for rules
ip_proto IP header's protocol value
sameip Determines if source IP equals the destination IP
stateless Valid regardless of stream state
regex Wildcard pattern matching
byte_test Numerical evaluation
distance Forcing relative pattern matching to skip a certain number of bytes
into the packet
byte_test Numerical pattern testing
byte_jump Numerical pattern testing and offset adjustment
Trang 7Sample Custom Rule 2
Building off of the scenario described in rule example 1, assume you have to allow some outside access to these servers, but still want to make sure no one was copying certain files Let’s say there is a file called payroll.xls that has all of the payroll figures (a very sensitive file for both inside and outside the company) You could write a rule that looked for any traffic, internal or external, coming from these servers that contained those words You could do this using the content option, which searches the actual content of the packet This rule would look something like this:
alert tcp ![192.168.1.10,192.168.1.11,192.168.1.12] any <> / [192.168.1.10,192.168.1.11,192.168.1.12] any
(content:”payroll.xls”;/ msg:”Payroll File Access”;)
Notice that the ! operator again signifies that you want traffic from anywhere other than these servers, bound for these servers This would avoid flagging server-to-server traffic You also use / to continue the alert onto multiple lines, and the content option to search for the text payroll.xls in any packet This way, that machine can still access the Internet but if that particular file is ever downloaded from it, you will be notified
With all the other alert options, you can write rules to find just about any kind
of traffic If your rule is something that other companies would be able to use, you might want to submit it to the Snort developers list to have it incorporated into the official set of rules that is distributed If you decide to do this, make sure you take advantage of all the documentation options such as msg, sid, rev, classtype, and priority Also, thoroughly test your rule to make sure it really catches all occurrences of the activity you are trying to trap and doesn’t go off erroneously
Host-Based Intrusion Detection
We have spent a lot of time on network-based intrusion detection However, there are other ways of finding intrusion attempts One alternative method is to load software to look for signs of intrusion on the system itself If a machine has been exploited, often certain sys-tem files will be altered For example, the password file may be changed, users may be added, system configuration files may be modified, or file permissions might be altered Normally these system files shouldn’t change much By looking for modifications in these files, you can detect an intrusion or other unusual activity
This method of intrusion detection can be much more accurate, producing fewer false positives since it doesn’t go off unless a system is actually affected It is a little more trou-ble to maintain since you have to load software on each system to be protected, but it might be well worth the time and effort to use both host-based and network-based intru-sion detection to protect misintru-sion-critical systems
Trang 8226 Chapter 7 • Intrusion Detection Systems
Advantages of Host-Based Intrusion Detection Methods
• Fewer false positives
• Activities rather than signatures are tracked, so you don’t need constant signature updates
• Less prone to being tricked
• Less tending and tuning needed
Disadvantages of Host-Based Intrusion Detection Methods
• Have to load and manage software on every box to be protected
• The alert comes after an attack has been successful; IDS sometimes provides earlier warning
Tripwire is another great example of open source software that has made the transi-tion to a commercial platform Tripwire was originally purely open source Eventually, the founders formed a company to sell and support it commercially However, they took the original code base and released it under the GPL license so that development could con-tinue in the open source community The open source version has been updated from ver-sion 2.2.1 released in October of 2000 to the current verver-sion of 2.3
There are significant differences between the commercial and the open source versions The biggest is that the commercial version isn’t open source and supports more platforms The open source version currently is available only on Linux, while the com-mercial version is available on several platforms including Windows Another difference
is that the commercial version comes with a program called twagent, which is a utility for managing multiple installations of Tripwire The commercial version also has a nice GUI for managing your databases and configurations
Both versions of Tripwire operate by creating a database of baseline attributes of important files you want to track, so you can check the actual attributes at any given time against the baseline to see if anything has changed This is good for keeping track of your system’s binary files One of the favorite tricks of hackers once they’ve gotten into a sys-tem is to replace key binary files with trojanized versions of their own That way, when
T r i p w i r e : A F i l e - I n t e g r i t y C h e c k i n g P r o g r a m
Tripwire
Author/primary contact: Dr Eugene Spafford and Gene Kim
Web site: www.tripwire.org
License: GPL
Version reviewed: V 2.3.47
Trang 9you use commands like ls or ps, you don’t see their illicit files or processes running You can also use Tripwire during a forensic investigation to find out where an intruder has been; it’s like following digital footprints
Installing Tripwire
1.To install Tripwire, get the files from the CD-ROM, or download either the RPM
or the tar files from the Tripwire Web site to compile from source
There are also RPMs available for some distributions (the RPMs for Man-drake and RedHat are on the CD-ROM) Just click on the RPM file to install the program If you don’t have an RPM for your operating system, you can download the source tar file (or “tarball” as they are sometimes known) to compile it Unzip the tar file and cd into the src directory
2.From the src directory, type the following:
make all This will compile Tripwire and get it ready for further configuration
3.Open the install.cfg file and check to make sure all the defaults are correct for your system This file governs where program files are installed and other system-level variables Most of the defaults should be fine for most systems Make sure your mail client is specified correctly
4.Once you have your environment variables set, cd to the /etc/tripwire directory and type twinstall.sh
This displays the license agreement You must type accept, and then the install script will copy the files to their appropriate places and prompt you for site and local pass-phrases These are the passwords that will unlock your Tripwire database, so they are very important
Picking strong pass-phrases and keeping them in a safe place is important, as this will encrypt your databases and configuration files and keep them safe from tampering If you lose these or forget them, you won’t be able to use Tripwire when you need it most
This completes the Tripware installation process
Configuring Tripwire
The final step before running Tripwire is to set your policy The policy file is a very impor-tant file for Tripwire operation: it tells Tripwire what files to keep an eye on and what level
of detail to go into You can find the main policy file, twpol.txt, in the main Tripwire direc-tory This is not the policy file itself but a copy of the encrypted version that the program actually uses For better security, you should make a copy and delete the unencrypted copy, twpol.txt, once you have set and tested your policy
Trang 10228 Chapter 7 • Intrusion Detection Systems
The policy file contains some system variables at the top, and then it has a listing of various files and directories and the policy directives for them These directives are
repre-sented by either code letters or variable names They are called property masks and
rep-resent the properties that Tripwire is tracking Table 7.4 lists the items that can be tracked for each file and their code letters
Table 7.4 Tripwire Property Masks
Code Letters Attributes Tracked
d Device ID on which the integrated node (INode ) resides
p Read/write/execute permissions on the file and mode