Snort Configuration : Linux

Configuring Snort on a Linux System

The process of installing Snort on a Linux system is very close to the process on a Windows system. The primary difference is that the default (relative) paths in the snort.conf file are much more likely to work without modification on the Linux system. You will need to download the latest version of Snort that is appropriate for your system. If you are using Fedora Core 5, this is as simple as typing yum install snort, or you could download and install the.rpm from snort.org.

Configuring Snort Options

The next step is to configure the various options that determine how Snort will behave using the Snort configuration file. The configuration file is excellently documented and very easy to use. To get Snort working the way you want it to, follow these simple steps.

1. Start by opening the main Snort configuration file. By default it will be located at /etc/snort/snort.conf.

2. Configure the HOME_NET variable, if desired, by removing the # from the line you need. # is a commend indicator in the Snort configuration file. The HOME_NET variable defines which networks are the "trusted" internal networks. This is used with the signatures to determine when the internal network is being attacked. By default, HOME_NET is set to any network with the var HOME_NET any line in the snort.conf. Setting this to accurately reflect your internal address space will reduce the number of false positive alerts you receive. A common example would be var HOME_NET 192.168.1.0/ 24 or perhaps var HOME_NET [192.168.1.0/24,192.168.2.0/24].

3. Configure the EXTERNAL_NET variable if desired. This is the network you expect attacks to come from. The recommendation is to set this to everything except your HOME_NET using the following: var EXTERNAL_NET !$HOME_NET. (Default: var EXTERNAL_ NET any.)

4. Next, define what servers are running specific services. For example, by setting HTTP_SERVERS to only specific servers, Snort will only watch for HTTP attacks targeted at those servers. If you wish to see attacks targeting servers that are not running the affected services, leave the defaults, which are to watch for attacks directed towards any internal servers. (Default: var DNS_SERVERS $HOME_NET) If you had a Web server running on 192.168.1.11 and 192.168.1.12, you could tell Snort to only look for HTTP attacks targeting that server by setting the following variable: var HTTP_SERVERS [192.168.1.11/32,192.168.1.12/32].

5. If desired, configure the specific ports that services are available on. For example, the default for HTTP is defined on the following line: var HTTP_PORTS 80. Similar to defining the servers in the preceding section, this will tell Snort to only look for attacks targeting specific ports. With the default configuration, Snort would ignore an HTTP attack to port 8080. Again, this setting will help focus where Snort looks for different types of attacks to occur.

6. If you are interested in detecting the usage of AOL Instant Messenger (AIM), the various IP addresses of the AIM servers are defined in the snort.conf file. This is done because the IP addresses change frequently, and by using a variable, the rules don't have to be updated each time the IP address changes. If you don't wish to trigger based off AIM usage, don't worry about changing these IP addresses.

7. Download the Snort rules from http://www.snort.org/rules. Click Download Rules on the right-hand side of the page. On the Download Rules page, scroll down to the section labeled Sourcefire VRT Certified Rules (unregistered user release). Download the latest ruleset.

8. Extract the rules (and /docs) to the location of your choice, typically /etc/snort/rules and /etc/snort/docs.

9. Configure the RULE_PATH variable, which tells Snort where to find the rules used for triggering events. You can use a relative path such as var RULE_PATH ../rules or an absolute path such as /etc/ snort/rules.

10. The next section has some commented out lines to disable certain detections of some infrequently seen types of traffic. Unless you are having some issues with those alerts or your IDS is very low on resources, it's probably fine to just leave those at the default (enabled) configuration.

11. The last few lines of the "step 1" section enable you to configure the detection engine for systems with limited resources. Unless you are having issues, you can leave this option alone.

12. After that the "step 2" and "step 3" sections of the configuration file allow you to enable or disable specific functionality and detect particular types of attack, such as fragmentation attacks, stateful inspection, and stream reassembly options. Delving into the specifics of each of those options is beyond the scope of this chapter and for many, the default setting will serve them well.

13. The section labeled Step #4 contains output options for Snort. Uncomment output alert_syslog: LOG_AUTH LOG_ALERT (the default). Despite what facility and severity you configure here, the snort alerts will be generated as auth.info. You also need to include the –s switch on the command line to enable syslog logging. We will discuss syslog in more detail in the next chapter. If you don't have a syslog server to log to yet, just make note of the setting and come back to it when your syslog server is set up.

    Using the preceding example of LOG_AUTH and LOG_ALERT, you would need the following in your syslog.conf file to log to a syslog server at 192.168.1.99:

    auth.info @managmentserverIP
    
    

    If you are using syslog-ng, you would need a logging destination defined, a filter that specifies what events to capture, and a log statement in the syslog-ng.conf file. An example of this configuration would be the following:

    destination d_lab { udp ("192.168.1.99" port(514)); };
    
    filter f_most { level(info..emerg); };
    
    log { source(s_sys); filter(f_most); destination(d_lab); };
    
    
    
    

14. Edit the paths for the dynamically loaded libraries in section #2 to point to the proper path. Depending on your Linux distribution and installation method, these paths may not be the default. For example, on Fedora Core 5, using yum to install Snort, the settings would use the following paths: dynamicpreprocessor directory /usr/lib/snort/dynamicpreprocessor and dynamicengine /usr/lib/snort/libsf_engine.so. If you receive an error when you try to run Snort, along the lines of Unknown rule type: dynamicpreprocessor directory or Unknown rule type: dynamicengine, then your installation of Snort is not configured to use dynamically loaded processors. In this case, simply place a # in front of both of those lines to comment them out.

15. The last section (Step #6), contains various include statements that specify the rulesets to be checked. Some rules are disabled by default, such as chat.rules, which is triggered by the use of various instant messaging clients. To enable or disable a given ruleset, simply add or remove a # at the beginning of the include line. This entry can be left as a relative path (for example, include $RULE_PATH/ local.rules) because the RULE_PATH variable will be expanded to make it an absolute path.

16. If you need any custom rules that are not included with the standard Snort release, you can download rules provided by the Snort community from the Rules page on the Snort Web site. If you are looking for something unusual, you might find it there without having to create the rule yourself.

You are now ready to start up Snort and see what it looks like in action. When you start Snort you can specify the interface to listen on using the –i switch such as –i eth0. If you don't specify, it will use the first interface. Use the –c option to tell Snort which configuration file to use. It can be useful to have multiple configuration files configured so you can quickly switch configurations for special circumstances. You could prepare different configuration files to home in on certain issues, segments, or more in-depth logging. Another important option is –A, which tells Snort what type of alerts to generate. The options are fast, full, console, or none.

The following command example would start Snort listening on the first interface (no –i used), with alerts going to the console only, using the configuration file at /etc/snort/snort.conf. The –l switch tells Snort where the logging directory is located. The –K switch tells Snort what types of logs to generate. ASCII logs are easier for a human to read, but they take a little more time to log. If speed isn't a concern, the ASCII logs will probably be the easiest to read and analyze.

snort --A console --c /etc/snort/snort.conf --l /etc/snort/log --K ascii

You should see any triggered rules produce a message on the console and logged to your syslog server. If you add the –s switch to the end of the line, it will tell snort to log to the syslog server you have configured in the snort.conf file; however, it will not also display on the snort console. If you want to create a rule for testing purposes to see what the results look like, create a test rule file, such as TESTING.rules, and place it in the rules folder (/etc/snort/rules, in this example). In this file you could place the following line, which would trigger on any attempts to ping another system.

Alert icmp any any -> any any (msg:"TEST rule";sid: 1000001;)

Edit the snort.conf to read your new rule by inserting the following statement towards the end of the file: include $RULE_PATH/TESTING.rules. . As a last step, edit the snort\stc\sidmsg.map file. This file provides a mapping between snort alert messages and alert IDs or numbers. Custom alerts should use an ID number of more than one million. Add the following line at the end of the file:

1000001

Placing the ID number is the minimum requirement for Snort not to output an error. You can certainly fill in all the other fields, following the existing message maps as a guideline. When this is done, you will need to stop and restart Snort. Here is a partial display of the console output of a single ping and the reply.

10/12-21:29:35.911089 [**] [1:0:0] TEST rule [**] [Priority: 0] {ICMP}

192.168.1.99 -> 192.168.1.103

08/10-18:22:20.284438 [**] [1:0:0] TEST rule [**] [Priority: 0] {ICMP}

192.168.1.103 -> 192.168.1.99

You can also add your own custom rules to the local.rules file. When you open the file, you will find it is essentially empty, existing solely for you to place your custom rules in it. The local.rule is "included" in the snort.conf by default, so you will not need to add it there. You will, however, still need to edit the sid-msg.map file for any rules placed in local.rules.

The –A option will alter the display of the alerts on the console, while the –K option controls how the alerts are logged to the log directory. You should experiment with the different display formats to find the one that provides adequate information with the minimal strain on the Snort host. For day-to-day operations you would probably want to use fast alerts in your log files, which look like the ones that are sent to the console with the console option. Available alert modes and logging formats are outlined here for handy reference.

• -A console Logs to the console in the following format:

  10/12-21:29:35.911089 [**] [1:0:0] TEST rule [**] [Priority: 0] {ICMP}
  
  192.168.1.99 -> 192.168.1.103
  
  

• -A fast Logs in the same format as console, but writes the alerts to a /snort/alert file with no output to the console.

• -A full Logs to the /snort/alert file in the following format:

  [**] [1:0:0] TEST rule [**]
  
  [Priority: 0]
  
  10/12-21:38:53.741606 192.168.1.103 -> 192.168.1.99
  
  ICMP TTL:64 TOS:0x0 ID:6350 IpLen:20 DgmLen:60
  
  Type:0 Code:0 ID:512 Seq:7936 ECHO REPLY
  
  

• –K pcap This is the default mode if you don't specify an alternate format on the command line. This file will contain the alert packets in their entirety. You can open this file using a network sniffer such as Wireshark.

• –K ascii Will create a folder under /log for each IP address. Within that folder each rule will create a log file. The log entries will be the same format as the "full" alert format.

• –K none No log file will be created.

Congratulations! You now have a working IDS. Figure 4.14 shows the syslog alerts from the TESTING.rule in the Kiwi Syslog Daemon console.

Figure 4.14: Snort Alerts in Kiwi Syslog Daemon Console

Using a GUI Front End for Snort

Like the Windows version of Snort, some have felt the administration of Snort could be improved upon by implementing a more robust GUI interface. There are several Snort GUIs to choose from aimed at both the configuration of Snort, as well as the interpretation of the Snort alerts. Some really only offer buttons to configure options on the Snort command line, and offer very little additional functionality, while others bring some very powerful additional features to the table. We will discuss the operation of some of the better offerings in the next section.

Basic Analysis and Security Engine

Basic Analysis and Security Engine (BASE) is available for download from http://www.base.secureideas.net/about.php. The purpose of BASE is to provide a Web-based front end for analyzing the alerts generated by Snort. Base was derived from the ACID project (Analysis Console for Intrusion Databases). Whereas ACID is more of a general-purpose front end for viewing and searching for events, BASE is a Snort-specific utility. The instructions to configure BASE assume you have already installed and configured Snort. Snort must be installed with the —with-mysql switch because Snort does not support MySQL output by default. The Snort Web site has RPM packages with MySQL support already included for some operating systems. This is the list of dependencies for running BASE: httpd, Snort (with MySQL support), MySQL, php-gd, pcre, php-mysql, php-pdo, php-pear-Image-GraphViz, graphviz, and php-adodb. Follow these steps to get BASE up and running.

1. Download and install MySQL and BASE

2. Edit the /snort/snort.conf file. Uncomment and edit the following line:

   output database: log, mysql, user=snort password=snortpass dbname=snort
   
   host=localhost
   
   

3. The next few steps are related to setting up the MySQL database and settings. After you install MySQL, enter the MySQL commands by typing mysql on the command line. This will place you in an interactive command mode. All commands must have a semicolon at the end of the line. By default, the MySQL installation will not have a password set at all. You should add a default password with the following commands.

   mysql
   
   mysql> SET PASSWORD FOR root@localhost=PASSWORD('somepassword');
   
   

   After you have assigned a password to the root account, simply entering mysql will not enable you to access the interactive command mode. After a password has been assigned, use mysql –u <username> –p. You will then be prompted to enter the password for the user you specified (typically root).

4. The next step is to create the Snort database.

   mysql> create database snort;
   
   

5. You now need to give the Snort user permissions to add the needed tables to the Snort database. Use these commands:

   mysql> grant INSERT, SELECT on root.* to snort@localhost;
   
   

6. You should now set the password for the Snort user to the same password you used in the Snort configuration file.

   mysql> SET PASSWORD FOR snort@localhost=PASSWORD('snortpass');
   
   

7. The next step is to add some additional permissions for the Snort database using the following commands:

   
   
   mysql> grant ALL on snort.* to snort@localhost;
   
   mysql> grant ALL to snort;
   
   mysql> exit
   
   

8. Now that the database has been created, you need to populate it with the tables Snort uses. Use the following command to create the tables:

   mysql --u root --p < /etc/snort/schemas/create_mysql snort
   
   

   When the command completes, it will not give any indication of its success; therefore, it will be necessary to manually verify that the tables were created.

   Tip

   If the package you installed did not include the /snort/schemas/ directory, you can download the source package and extract the directory from there. With Fedora Core 5, for some reason installing the Snort with MySQL support did not include the schemas directory.

9. Verify the MySQL tables were created in the Snort database by entering the following commands. You should see output similar to that shown in the following example:

   mysql --u root --p
   
   show databases;
   
   +----------+
   
   | Database |
   
   +----------+
   
   | mysql    |
   
   | snort    |
   
   | test     |
   
   +----------+
   
   use snort;
   
   show tables;
   
   +------------------+
   
   | Tables_in_snort  |
   
   +------------------+
   
   | data             |
   
   | detail           |
   
   | encoding         |
   
   | event            |
   
   | icmphdr          |
   
   | iphdr            |
   
   | opt              |
   
   | reference        |
   
   | reference_system |
   
   | schema           |
   
   | sensor           |
   
   | sig_class        |
   
   | sig_reference    |
   
   | signature        |
   
   | tcphdr           |
   
   | udphdr           |
   
   +------------------+
   
   exit
   
   

   The list of databases is not significant, as long as the Snort database exists, of course. The table listing must be accurate. If any are missing, Snort will generate an error when you run it.

10. Install php-gd, which is used to generate the graphs in BASE. On Fedora Core 5 you can just type yum install php-gd.

11. Install ADODB, which is a database abstraction library for PHP. On Fedora you can simply enter yum install php-adodb.

12. It's now time to configure BASE itself. Edit the /usr/share/basephp4/base_conf.php file to ensure that the following lines are configured with paths and settings appropriate for your configuration.

    $BASE_urlpath = '/base';
    
    $DBlib_path = '/usr/share/ododb';
    
    $DBtype         = 'mysql';
    
    $alert_dbname   = 'snort';
    
    $alert_host     = 'localhost';
    
    $alert_port     = '';
    
    $alert_user     = 'snort';
    
    $alert_password = 'snortpass';
    
    

    You should not be able to access the BASE Web page at the following URL: http://localhost/base/.

    Tools & Traps…

    Troubleshooting Tips

    • You can enable debugging in BASE by editing the /usr/share/base-php4/base-php4.conf file.

      $debug_mode = 2;
      
      

    • Use chkconfig to make sure that MySQL, Snort, and httpd are running.

      Chkconfig --list | grep snort
      
      Snortd      0:off 1:off 2:on 3:on 4:on 5:on 6:on
      
      

      If all entries say "off," then that service is configured not to start. Try service snortd start.

    • Httpd may need to be restarted for some configuration changes to take effect; when in doubt, restart it just to be safe: service httpd restart.

    • The httpd access log and error log can be found at /etc/httpd/logs.

    • You can control the logging level of the httpd by editing /etc/httpd/conf/httpd.conf.

      LogLevel debug
      
      

    • If you are having issues with the URLs not being found, the /etc/httpd/conf.d/base-php4.conf file tells the Web server to alias /base/ with the directory /usr/share/base-php4/.

    The very first time you start up BASE, none of the database tables have been created. You will see something like the page shown in Figure 4.15.

    
    Figure 4.15: BASE Setup

13. Click on the Setup page link.

14. Click the Create BASE AG button on the right-hand side. You see several success messages as shown in Figure 4.16.

    
    Figure 4.16: BASE Success

15. Click the Main Page link. This should take you to the primary BASE interface as shown in Figure 4.17.

Figure 4.17: BASE Main Page

Although this window may not be too flashy, there is a wealth of information you can discover. Most of the fields are actually links. By clicking to the right of Today's alerts, for example, you can get a sorted list of unique alerts, a listing of all alerts, or a list sorted by source IP address or destination IP address. The other headings along the left side offer similar functionality. Of particular note are the links for the Most Frequent 15 addresses by source address. This would enable you to quickly see which systems are generating the majority of your alerts. If you open that window (shown in Figure 4.18) there are several additional fields that are also hyperlinked.

Figure 4.18: BASE Most Frequent by Source IP

Note the field at the bottom labeled ACTION. This enables you to configure the alert groups. Alert groups are basically shortcuts to enable you to view a subset of alerts quickly, without having to navigate through the various menus to get there. For example, suppose you want to know anytime that 192.168.1.1 generates an alert. You can check the check box to the left of 192.168.1.1, and then use the {action} drop-down box to select Create AG (by Name). In the action column, enter .1_ALERTS to use as the alert group name. Finally, click Selected.

The next screen enables you to enter a description for the newly created alert group. Enter a meaningful text description for the group and click Save Changes. The next screen will be a listing of all alerts from 192.168.1.1. This screen is the alert group. In the future, if you want to quickly see this group of alerts, you can click Alert Group Maintenance at the bottom of each page, and then click the alert group you want to view. In this way, any subset of alerts is only two clicks away, sort of like a shortcut straight to a particular set of filtering criteria.

Another feature of note is the Administration link at the bottom of each page. This will take you to a screen where you can configure users for BASE. There are four options on the administration screen: list users, create a user, list roles, and create a role. These screens enable you to create users and assign them to various roles. If you click List Roles, you can see the four predefined roles. If you want to assign a user in the administrator role, simple click Create a user. Enter the login name, a full name or description, and a password. Use the drop-down box to select a role and then click Submit Query. None of the settings here will take effect until you edit the base_conf.php file and change the value of $Use_Auth_System = 1;. A value of 0 (the default) means the authentication is disabled and everyone has full access to BASE. Only the admin role has access to the administration screen.

Tip

Remember the different logging options for Snort on the command line. Previously, we used –A console, which would log Snort events to the Snort terminal. If you are going to be using a different front end for viewing Snort alerts, there isn't much value in also logging to the console. You can use –A none when starting Snort, which will c