Configuring Snort

Getting Snort installed successfully can be a challenge, but it is also only the first step in setting the tool up so you can launch it to start monitoring traffic and generating alerts. To get Snort ready to run, you need to change the default configuration settings file (which is created as part of the Snort installation) to match your local environment and operational preferences. If you accepted the default locations proposed during the Windows installer execution, then the snort.conf file will be located in the directory C:\Snort\etc. The configuration file is plain text, so you can use any text editor to edit it, but Wordpad (or even better, the free Notepad++) is recommended at least for the first time to ensure the proper formatting is maintained (when opening the baseline snort.conf file in Notepad all the text runs together).

When you open the file for viewing or editing, you will see it is organized into nine parts or steps:

  1. Set the network variables
  2. Configure the decoder
  3. Configure the base detection engine
  4. Configure dynamic loaded libraries
  5. Configure preprocessors
  6. Configure output plugins
  7. Customize your rule set
  8. Customize preprocessor and decoder rule set
  9. Customize shared object rule set

As you can see, there are a lot of ways to customize Snort, and making sense of the entire snort.conf file can be a little daunting. To get running for the first time, many of the defaults can be left alone. The following edits are recommended:

  1. Step 1
    1. Change the declaration for HOME_NET to your actual home network IP address range, rather than leaving the default “any”. The simplest way to do this is to use a CIDR format expression, to cover the entire range of relevant addresses (particularly when using Network Address Translation such as in environments protected by gateways or routers.
      1. For a typical home network, the expression will be 192.168.0.1/24 or 192.168.1.1/24 (if you’re not sure whether your third number is a 0 or 1, check your gateway/router documentation or just ping it. If you want to cover all IP addresses beginning with 192.168, then use the expression 192.168.0.0/16
      2. In a typical large office network using network address translation, the expression will be 10.0.0.0/8
      3. In some environments (including home environments connecting to the Internet via cable modem without the use of a gateway or router) the appropriate IP address range to use may be dictated by the ISP from which you get your Internet service.
      4. If you are unsure which IP address range to specify for your home network, you can quickly check to see the IP address assigned to your computer by opening a command shell window and typing ipconfig at the prompt.
      5. Finally, you can leave the HOME_NET declaration as “any” if you are unable to accurately determine a specific IP range to use.
    2. Change the declaration for EXTERNAL_NET to !$HOME_NET – this expression means the external network will be defined as any IP address that is not part of the home network.  Important! If you leave HOME_NET declared as “any” you cannot use !$HOME_NET, as the expression will translate to “not any” and throw an error when you try to start Snort.
    3. Generally speaking, you can leave unchanged all the other server declarations, although if you want you can reduce the list of web server ports declared for HTTP_PORTS.
    4. Change the var RULE_PATH declaration to match the actual location of your rules files. Typically the rules will be stored in c:\Snort\rules, so you can use that full path name or whatever the right location is on your system.
    5. Similarly, change the PREPROC_RULE_PATH to match the appropriate directory location on your system, such as c:\Snort\preproc_rules.
    6. Comment out (meaning put a # character in the first position in the line) the SO_RULE_PATH declaration, as the Windows implementation of Snort doesn’t use shared object rules.
    7. The reputation preprocessor is a relatively recent addition to Snort that allows you to configure trusted or untrusted IP addresses using separately referenced files that list the addresses (whitelist for trusted, blacklist for untrusted). If you intend to enable the reputation preprocessor then the path to the whitelist and blacklist files needs to be provided at the end of step 1. Please note: if you leave the reputation preprocessor enabled, you must create the whitelist and blacklist rules files referenced in the preprocessor configuration, or Snort will generate an error and fail to start. If you want to work with the reputation preprocessor later, be sure to comment it out in step 5.
  2. Step 2
    1. For most users, there are no changes needed to the decoder configurations.
    2. At the end of this section, there is a configuration setting to indicate the default directory where Snort logs should be written. Uncomment this line by deleting the # character in the first position and edit the line to include the c:\Snort\log default directory path.
  3. Step 3
    1. For most users, there are no changes needed to the base detection engine settings, so move on to step 4. These settings are used for performance tuning and reflect memory and processing capabilities.
  4. Step 4
    1. Change the dynamic loaded library path references to reflect their location in Windows, and in the case of the dynamic engine to replace the default Linux filename with the Windows equivalent. Snort references these locations and loads the libraries at start-up.
      1. dynamicpreprocessor directory c:\Snort\lib\snort_dynamicpreprocessor
      2. dynamicengine c:\Snort\lib\snort_dynamicengine\sf_engine.dll
      3. Comment out (put a # in the first position in the line) the dynamicdetection directory declaration.
    2. Note that the dynamic engine is actually pointing to a file, while the other two declarations point to directories. It’s always a good idea to double-check the accuracy of these locations by browsing to them with the file browser or performing directory listings from the command line. Be sure there is no trailing slash character on the dynamic preprocessor directory.
    3. One point to be aware of when configuration is done and you move one to running Snort:  loading the dynamic libraries requires Snort to write to the Windows registry, an action typically requiring administrator privileges. For this reason the command shell should be launched with the “Run as administrator” option from the Windows start menu when preparing to start Snort.
  5. Step 5
    1. Be aware that there are many, many preprocessors for use with Snort, and you very likely will not want or need to have all of them running. Each preprocessor has a separate readme file with configuration options and settings documented in it, so if you want to use a particular preprocessor, you should consult those files or the Snort manual to make sure you set them up properly.
    2. Comment out (put a # in the first position on the line) all the rows in the Inline packet normalization preprocessor. This preprocessor is only used when Snort is implemented in in-line IPS mode, and Snort should ignore it otherwise, but on Windows it will cause an error if left uncommented.
    3. For general-purpose Snort usage, it usually makes sense to disable (comment out) some of the preprocessors, particularly ones like those for normalization listed first in Step 5 that only apply to Snort in in-line mode. Of the others, it is fine to leave default preprocessors active, but at a minimum it is a good idea to keep at least the following preprocessors active (using default configuration settings):
      1. frag3
      2. stream5
      3. http_inspect
      4. ftp_telnet
      5. smtp
      6. dns
      7. ssl
      8. sensitive_data
    4. When you get to the http_inspect preprocessor, find the line near the end of the preprocessor configuration (typically around line 325) that reads “decompress_swf { deflate lzma } \” and delete the “lzma”; it refers to a data compression algorithm that is typically not installed on Windows systems, so leaving this in will usually cause an error when you try to run Snort on Windows. After editing, this line should read, “decompress_swf { deflate } \”.
    5. The most recent releases of Snort include some very interesting new preprocessors, some of which are not included in snort.conf by default. You can learn more about these preprocessors and the configuration syntax used to add them to the file in Step 5 by consulting the Snort documentation or the “readme” file for each preprocessor.
    6. As noted in Step #1 above, if you choose to keep the reputation preprocessor enabled you must create whitelist and blacklist files corresponding to the references in the configuration settings for the reputation preprocessor, which is at the very end of Step #5. You can opt to comment it out for initial setup and come back to it later. Snort by default includes a set of rules in a file called “blacklist.rules” that is not used by the reputation preprocessor. For this reason it is strongly recommended to avoid later confusion that you choose names for the whitelist and blacklist files that do not include “rules” in the names (for example, “white.list” and “black.list”).
  6. Step 6
    1. Typically, only one of the output plugins is used with Snort at any one time. The default in recent releases of Snort is unified2, but as noted above this is not well supported on Windows platforms. If you intend to use syslog, then uncomment that line to activate the syslog output plugin. If you intend to use screen output only, leave all the output plugins commented out.
      1. Uncomment and edit the syslog output line in snort.conf, so it reads like this:
        output alert_syslog: host=127.0.0.1:514, LOG_AUTH LOG_ALERT
      2. Note: If you choose to use syslog output, then you also need to install and run a syslog server; see Installing a Syslog Server.
    2. If you have used previous versions of Snort, you may notice that there are no database output configuration options in the snort.conf file. As of the 2.9.3 version of Snort direct logging to database is no longer supported.
    3. Leave the metadata reference lines at the end of step 6 uncommentedinclude classification.config and include reference.config
  7. Step 7
    1. If you have installed the Snort VRT ruleset, then you can tailor the series of include statements in step 7 to match whatever environment characteristics and types of rules you want. For initial testing, sometimes it can be helpful to reduce the number of rules loaded at start-up, but make sure that the line for “local.rules” remains uncommented, as that is where you will place the rules that you write yourself.
    2. For first-time users, you may want to comment out most of the include statements listed in step 7 until you verify your configuration.
    3. If you choose to use the community ruleset instead of a registered or subscriber release, you need to comment out all of the include statements in Step #7 except for local.rules and add an include statement for community.rules (the community ruleset has all rules in a single file).
    4. If you create your own rules in separate rules files (instead of adding them to local.rules), add an include statement for your custom files following the same syntax you see for all the other statements in step 7.
  8. Step 8
    1. There are not very many settings in step 8, so in general you just want to make sure that you uncomment any rules here that correspond to preprocessors you configured to load in step 5. By default, if you kept the standard settings in step 2 and enabled at least some preprocessors, the uncomment the first two lines in step 8
      1. include $PREPROC_RULE_PATH\preprocessor.rules
      2. include $PREPROC_RULE_PATH\decoder.rules
    2. If you enabled the sensitive_data preprocessor (in step 5), then uncomment the third line in step 8:  include $PREPROC_RULE_PATH\sensitive-data.rules
    3. Make sure the rules you declare in these statements are actually present in the appropriate directory (such as c:\Snort\preproc_rules)
  9. Step 9
    1. The rules referenced in Step #9 are shared object rules, which are different from (although similarly named) the rules listed in Step #7. Because shared object rules are not well supported on Windows, leave all the shared object rules commented out in step 9.
    2. Leave the event thresholding line at the end of step 9 un-commentedinclude threshold.conf