Previous Section  < Day Day Up >  Next Section

Configuring Snort for Maximum Performance

Now that you have Snort up and running and know the basic commands, you need to edit the configuration file to make it a reliable IDS and get the results you want. The default configuration file is snort.conf and by default is at /etc/snort.conf. This file is where you do all of your setup and configuration of Snort. You can change the name of this file as long as you refer to its new file name and path after the –c switch when running Snort. Edit the file using vi, EMACS, or the text editor of your choice. A lot of lines in the file start with # and are followed by various comments. The # is a standard beginning for comment lines, and many languages, such as Perl and shell scripts, ignore lines starting with it. These are used to document a program or to disable old code. You will be using them later to fine-tune your rule set. But for now, the only lines that have any actual effect on the configuration are those without # signs at the beginning. The rest is just there for informational purposes. There are several steps to setting up your config file.

  1. Set your home network.

    You need to tell Snort the addresses that represent your home network so it can correctly interpret attacks coming from outside your network. You do this with the statement

    
    
    
    

    
    var HOME_NET addresses
    
    

    where you replace addresses with the address space of your local network. If there are multiple networks, you can enter them all, separated by commas. You can also enter an interface name and have it use the IP address and net mask assigned to that interface as its HOME_NET. The format for doing this is

    
    
    
    

    
    var HOME_NET $interfacename
    
    

    where you replace interfacename with the interface Snort is listening on such as eth0 or eth1.

    You can also define your external networks with a similar statement, replacing HOME_NET with EXTERNAL_NET. The default entry for both of these variables is any. You can leave it this way or define both. I recommend defining your internal network but leaving external networks set as any.

  2. Set up your internal servers.

    In the configuration file you can define a number of servers, including Web, mail, DNS, SQL, and Telnet. This will limit the false positive alerts for those services on those machines.

    You can also specify port numbers for those services, so unless the attack is on the port you are using it doesn't register an alert. All of these configuration options can help you reduce the number of false positives you get and alert you only to information that has real value. There is also a section to add AIM servers to track usage of AOL Instant Messenger. This is only applicable if you have the Chat rule class enabled.

  3. Configure the Snort decoders and preprocessors.

    A number of switches and settings control the Snort decoders and preprocessors in the config file. These routines run on the traffic before it passes through any rule set, usually to format it properly or deal with a particular kind of traffic that is easier to process upfront than using the rule sets. An example of this type of traffic would be fragmented packets. Snort has a decoder that reassembles fragmented packets. Many attacks attempt to hide their true nature by fragmenting the packets, so this is a valuable feature.

    Another decoder is for port scanning packets. Since these tend to come in groups and in high volume, it is better to process them up front en mass than trying to match each packet to a signature. This also makes the IDS more secure from denial of service. The default settings for these subsystems should be fine, but as you get more experienced with Snort, you can tweak these settings to get better performance and results.

  4. Configure the output modules.

    This is an important step if you want to use a database to manage your output from Snort. This is when you give the program directives on how to handle the alert data. There are several output modules you can use depending on the format you want the data in. They are Syslog, Database, and a new one called Unified, which is a generic binary format useful for importing to various other programs. The general format for configuring the output modules is

    
    
    
    

    
    output module_name: configuration options
    
    

    where module_name is either alert_syslog, database, or alert_unified, depending on the module you want to use.

    The configuration options for each output module are as follows.

    • Syslog

      For UNIX/Linux systems, you should use the following directive:

      
      
      
      

      
      output alert_syslog: LOG_AUTH LOG_ALERT
      
      

      For Windows system, you can use any of the following formats:

      
      
      
      

      
      output alert_syslog: LOG_AUTH LOG_ALERT
      
      output alert_syslog: host=hostname, LOG_AUTH LOG_ALERT
      
      output alert_syslog: host=hostname:port, LOG_AUTH LOG_ALERT
      
      

      where hostname and port are the IP address and port of your Syslog server.

    • Database

      The general format for configuring database output is:

      
      
      
      

      output database: log, database_type, user=user_name password=password dbname=dbname graphics/ccc.gif host=database_address

      where you replace database_type with one of the valid databases for Snort (MySQL, postgresql, unixodbc, or mssql). You also replace user_name with a valid user name on the database box and password with the appropriate password. The dbname variable identifies the name of the database to log to. Finally, database_address is the IP address of your database server. It is not recommended that you try to run Snort and your database on the same server. In addition to being more secure to have your alert data on another box, Snort and a database running on the same machine will slow down performance considerably. While database configuration is not the subject of this book, the basic configuration of a MySQL database for Snort and other programs is discussed in Chapter 8.

    • Unified

      This is a basic binary format for quick logging and storage for future use. The two arguments that are supported are filename and limit. Here is the format:

      
      
      
      

      
      output alert_unified: filename snort.alert, limit 128
      
      

  5. Customize your rule sets.

    You can fine-tune Snort by adding or deleting rule sets. The snort.conf file lets you add or delete entire classes of rules. At the bottom of the file you will see all the alert rule sets listed. You can turn off a whole category of rules by commenting out that line by putting a # sign at the beginning. For example, you could turn off all the icmp-info rules to lower false positives on ping traffic or all the NetBIOS rules if you had no Windows machines on your network. There are also rule sets available publicly that have already been tuned for specific environments.

Once you are done making changes to your config file, save it, and then you are ready to run Snort.

Proper NIDS placement

When deciding where to place your NIDS on your network, you need to consider what you are trying to protect with your NIDS and how to maximize its effectiveness and interoperability with your other network protections. There are several possibilities where you can put your NIDS, and each has distinct advantages and disadvantages.

  • On your local LAN behind your firewall. This is the most common configuration and offers the best protection from both outside and inside threats. By listening on the local wire, you can detect internal activity by your users, such as activity from workstation to workstation or illicit program use. It also backs up your firewall, detecting suspicious activity that somehow manages to make it through your firewall filters. In fact, an IDS can be used to test a firewall to see what it will let through.

    However, this will generate a lot of alerts based on Windows networking traffic, so be prepared to do a lot of tuning in this area. Also, if you are on a switched LAN, you will need the ability to mirror all ports to a monitor port in order to allow your IDS to listen to all LAN traffic.

  • On your DMZ segment. You can put a Snort sensor on your DMZ network to track activity going to your public servers. Since these servers are the most exposed in your enterprise and usually represent valuable resources, it is a good idea to monitor them with an IDS. The problem you will have with this configuration is sorting through all the alerts. While all of them may be valid alerts, with the level of general attack traffic on the Internet these days, any public IP is generally attacked several times daily on a random basis. Reacting to and attempting to track down these alerts would be overkill and counterproductive.

    So how do you tell which ones are just worms bouncing off your server and which ones are actually getting away with something? One way is to reduce the number of signatures to a small number that go off only if the box actually got compromised, for example, rules specific to the applications running on that box, such as MySQL.rules or web-iis rules, or rules relating to administrative logon. You can eliminate most of the reconnaissance type alerts for activity such as ports scans, and so on.

  • Between your ISP and your firewall. This would filter all the traffic going and coming to your LAN and DMZ. The good news is that you will catch anything attacking both your public servers and your internal LAN. The bad news is that you won't see any internal traffic, and the general alert volume may be quite high due to the general background attack traffic.

    Like the previous example, try to narrow down the alerts to the ones that really would show a problem for this network segment and leave those on. Also, you will have to put the sensor in line between your ISP and the firewall, which can create a traffic bottleneck and a single point of failure for your network traffic. A solution would be to install a small hub between the two links and hang the IDS off of that.

These are all valid ways to use an IDS. Of course, there is no reason you can't do all three as long as you have the hardware and time to manage it.


Disabling Rules in Snort

The easiest way to limit your alert traffic is to turn off rules that don't apply to your system. You can do this by going into your Snort box and finding the rules directory (usually under the directory you installed Snort in). In that directory there are many files with a .rules extension. Each of these contains many rules grouped by category. You can disable a whole class of rules by commenting it out in the configuration file, or you can disable individual rules if you still want the protection from the other rules in that class. You comment out a rule by finding it in the appropriate .rules files and placing a # in front of the line for that rule. Note that it is generally better to disable a single rule than a whole class of rules unless that whole class doesn't apply to you. Table 7.3 lists all the file names for Snort rule classes and describes them briefly.

Table 7.3. Snort Rule Classes File Names

Rule Classes

Descriptions

attack-responses.rule

These are alerts for common response packets after an attack is successful. They should rarely report false positives and should be left on in most cases.

backdoor.rule

These are common signs a backdoor or Trojan horse program is in use. They will rarely be false positive.

bad-traffic.rule

These rules represent nonstandard network traffic that should not typically be seen on most networks.

chat.rules

Look for standard sign-ons for many popular chat programs. If chat is allowed explicitly or implicitly, then these alerts should be turned off. Also, note that these are not silver bullets for chats and will not detect all types of chat traffic. Still, they can be helpful in ferreting out the worst offenders.

ddos.rule

Look for standard distributed denial of service types of attacks. On a DMZ and WAN, these alerts don't serve much purpose, because if you are under a distributed denial of service you will probably know it right away. However, they can be very useful inside the LAN to see if you have zombie machine participating unknowingly in a DDOS attack on another network.

dns.rules

Look for some standard exploits against DNS servers. If you aren't running your own DNS, you can turn these off.

dos.rules

Similar to the ddos.rule set above.

experimental.rules

These are turned off by default. These are generally used only for testing new rules until they are moved into one of the other categories.

exploit.rules

These are for standard exploit traffic and should always be enabled.

finger.rules

These rules flag traffic having to do with finger servers. If you are not running finger anywhere, you could probably turn these off. However, finger servers often are running hidden from the system administrator, so you could leave these on as they shouldn't generate false positives if you don't have any.

ftp.rules

Same as finger.rules but looking for FTP exploits. Again, there is no harm in leaving them enabled even if you don't have FTP servers since it will alert you to any rogue FTP servers you may have.

icmp-info.rules

These rules track the use of ICMP messages crossing your network, for example, pings. These are often the cause of false positives, and you may want to disable the whole lot unless you want to keep a close eye on ICMP traffic on your network. Another class for known bad ICMP traffic, icmp.rules catches ports scans and the like.

icmp.rules

Cover bad or suspicious ICMP traffic such as port scans, and are less likely to generate false positives. However, it is possible they will be triggered often on a busy network with lots of diagnostic services running.

imap.rules

Rules regarding the use of Internet Message Access Protocol (IMAP) on your network.

info.rules

Trap miscellaneous error messages on your network from Web, FTP, and other servers.

local.rules

You add your own custom signatures for your network in this file. This file is empty by default. See the section at the end of the chapter for information on writing a custom Snort rule.

misc.rules

Rules that don't fit under one of the other categories or don't warrant their own sections are in this file. An example would be older alerts like Gopher server exploits.

multimedia.rules

Track usage of streaming video type software. If you allow streaming video applications or use video conferencing on your network, then you will want to disable these rules.

mysql.rules

Watch for administrator access and other important files in a MySQL database. If you don't run MySQL, then you can probably disable these alerts. Also, if your MySQL database is under development, these might trigger a lot of false positives.

Netbios.rules

This class of rules alerts you to various NetBIOS activity on your LAN. Some of them are obvious exploits. However, others, such as the NULL session alerts, may happen normally on a Windows LAN. You will have to play with this section to figure out the rules that are appropriate for your LAN.

nntp.rules

News server–related rules. If you don't run network news on your servers, you can probably turn these off.

oracle.rules

Oracle database server rules. Again, if you don't run it, turn it off.

other-ids.rules

These rules are related to exploits on other IDS manufacturers' boxes. Chances are that you don't have any NIDS on your LAN, but if you do, leave these on.

p2p.rules

Rules governing peer-to-peer file sharing software use. These rules will create alerts during normal use of these products, so if you allow this software then you will need to turn these off.

policy.rules

This file contains various alerts relating to allowed activity on the LAN, such as Go-to-my-pc and other programs. You should review these and enable only the ones that apply to your internal policies.

pop2.rules pop3.rules

Both files to mail servers. Most companies, if using POP, will be using a POP3 server. If you have either of these types of servers, leave these rules on; if not, disable them.

porn.rules

These are some rudimentary traps for pornography-related Web surfing. These are by no means a replacement for a good content-filtering system, but can catch some of the more egregious violators.

rpc.rules

This class handles remote procedure call (RPC) alerts. Even though you may not think you are running any of these services, they often run as part of other programs, so it is important to be aware when this is happening on your LAN. RPC can enable remote code execution and is often used in Trojans and exploits.

rservices.rules

Track use of various remote services programs, such as rlogin and rsh. These are insecure services in general, but if you have to use them, they can be tracked closely with this rule set.

scan.rules

Alert you to use of port scanning programs. Ports scans are a good indication of illicit activity. If you use port scanners, you will want to either turn off Snort during those times or disable the particular rule for your scanner machine.

shellcode.rules

This class looks for packets containing assembly code, low-level commands also known as shell code. These commands are often integral to many exploits such as buffer overflows. Catching a chunk of shell code flying by is often a pretty good indication that an attack is underway.

smtp.rules

Govern alerts for mail server use on the LAN. This section will need some fine-tuning, as many normal mail server activities will set off rules in this section.

sql.rules

Rules for various SQL database programs. If you don't run any databases you can turn these off, but it's not a bad idea to leave them on just in case there are SQL databases running that you don't know about.

telnet.rules

Track Telnet use on the network. Telnet is often used on routers or other command line devices, so it is a good thing to track even if you don't run Telnet on your servers.

tftp.rules

TFTP (trivial FTP) is an alternate FTP server often run on routers. It can be used to upload new configurations and therefore is worth keeping an eye on.

virus.rules

Contain signatures of some common worms and viruses. This list is not complete and is not maintained regularly. It is not a replacement for virus scanning software but can catch some network-aware worms.

web-attacks.rules web-cgi.rules web-client.rules web-coldfusion.rules web-frontpage.rules web-iis.rules web-php.rules

All these classes refer to various kinds of suspicious Web activity. Some are generic, such as the web-attacks class. Others, like web-iis and web-frontpage, are specific to a particular Web server platform. However, even if you don't think you run a Microsoft Web server or use PHP, it is worth leaving them all running to uncover any of this kind of activity on your LAN you may be unaware of. You will have to do some fine-tuning of the rule sets, especially if your Web servers are in active development.

X11.rules

Track the use of the X11 graphical environment on your network.


Running Snort as a Service

If you are going to be running Snort on a server that is intended to be up 24/7, then you will want to run Snort immediately upon boot up so that if the box goes down, it will reload Snort and your IDS will continue to protect your LAN. One way to do this is to have a little script that runs Snort with the command line parameters in your startup routines. In Linux, you can place a line in the rc.local file in the /etc/rc.d directory with your command line arguments to run Snort. An example is:






snort –h 192.168.1.0/24 –c /etc/snort/snort.conf &


The & (ampersand) on the end means to run Snort as a background process. You can also run Snort as a service using the service snort start command.

Snort Webmin Interface: A Graphical Interface for Snort


Doing all the configuration for Snort from the command line can get a little tedious. While there isn't a native graphical interface for Snort yet, there is a module for the popular Web management tool Webmin. This lets you do all of your fine-tuning and configuration from any Web browser. Some of the benefits of this system are:

  • Form-based access to Snort configuration files

  • User access levels that allow you to set up different users with different rights

  • Point-and-click ability to enable and disable rule sets

  • Status indicator for all rules and rule sets

  • Embedded links to external database such as archNIDS, CVE, and Bugtraq

  • Logging of changes

  • International language capability

  • Support for running Snort as a service using rc.d files

  • Secure remote administration via SSL (if enabled)

Chapter 3 covered loading Webmin for your firewall administration. You can also use this add-on module to configure Snort. Refer back to Chapter 3 if you haven't loaded Webmin yet.

graphics/cd_icon_icon.gif

The Snort module requires version 0.87 of Webmin or later. You can use the Snort Webmin file on the CD-ROM, download the Snort module using the Webmin interface, or download the file separately and load it locally. The location to get the software is:


www.msbnetworks.com/snort/download/snort-1.1wbm

To load the Snort module from the Webmin interface, take the following steps.

  1. Go into the Webmin main page. Log in using the username and password you set up when installing Webmin.

  2. Click on the Webmin configuration tab. Click on Modules, and select either Local file or Ftp URL, depending on whether you have already downloaded it to your machine or want to have Webmin get it from the Web site.

  3. Click on Install module, and it will install the Snort module file. The Snort module will appear as an icon on your Webmin main page. Click on this icon to display the Webmin Snort interface (see Figure 7.2).

    Figure 7.2. Webmin Snort Module

    graphics/07fig02.jpg


Once you log onto the Snort page, you can see it has each major section of the config file, such as network settings, preprocessor settings, and your logging options, at the top of the screen. By clicking on any of the configuration options, you can enter your information in a form and Webmin will make the changes to the appropriate Snort configuration files.

All the rule sets are listed below that, and you can see which ones are enabled or disabled. Those with a check are currently enabled and those with an X mark are disabled. You can easily disable the entire rule set by double-clicking on the Action field. If you want to view that rule set and modify an individual rule, click on the blue underlined text and it will take you to the Edit Ruleset page (see Figure 7.3). Here you can see all the active rules within that set. You can also take actions on each rule such as disabling, enabling, or deleting it from the rule set. If there are any references to external databases within the alert, such as Common Vulnerability or Exploit (CVE) numbers, you can click a hyperlink to take you to more detail on what that alert does. Using this interface can make fine-tuning your alert rule set much easier.

Figure 7.3. Webmin Snort Edit Ruleset Page

graphics/07fig03.gif


With the Webmin Snort module, you can also control which users can access which settings (see Figure 7.4). On the Webmin users page you can set a variety of options for each user (assuming you are the administrator on Webmin). You can give certain users access to edit rules but not to edit configuration files. You can control which configuration files they can access. Or you can just let them view the files without editing or disabling them. As you can see, the Webmin Snort module gives you very granular access control so that you can delegate daily tuning duties to a lower-level technician while retaining configuration and change control.

Figure 7.4. Webmin Snort Module Access Control

graphics/07fig04.gif


Snort for Windows: An Open Source IDS for Windows


For those of you who can't or won't install the UNIX version of Snort, thankfully there is a fully supported version for the Windows platform. While it is true that you will 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 probably 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 running, 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

graphics/cd_icon_icon.gif

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 flexresponse 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 commands are the same. Fine-tuning and placement rules of thumb are also the same as the native UNIX version.

graphics/fire_head_icon.gif

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 suspicious 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 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 contains 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 example, it will generate an alert. Other options for actions are Log, Pass, Activate, and Dynamic.

Log

Just log the packet.

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.


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 addresses and networks by separating them with a comma, no spaces, and encapsulating 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.

msg

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 example, block certain Web sites).

reference

External attack reference IDs.

sid

Snort rule ID.

rev

Rule revision number.

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.


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 operations. 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.

Sample 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 graphics/ccc.gif.168.1.10,192.168.1.11,192.168.1.12] any (content:"payroll.xls";/ graphics/ccc.gif 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, class type, 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.


    Previous Section  < Day Day Up >  Next Section