In this article, we are going to look at Snort’s Reputation Preprocessor. We will look at how this preprocessor is used to use IP blacklists and IP whitelists (known together as IP lists) to either block, alert, or allow traffic based on the sender’s and/or recipient’s IP address. I will show you how to configure, test, and troubleshoot the reputation preprocessor and associated IP lists. Finally we will look at how PulledPork can be configured to download blacklists automatically.

History of the Reputation Preprocessor

Before the reputation preprocessor was developed, if you wanted to block or alert on traffic to or from a specific IP address or range, you had to create a rule for that IP address or range of IP addresses. This works well for a very small set of addresses that do not change often. Unfortunately, in today’s environment IP addresses for malicious hosts change rapidly, and there are a very large number of malicious addresses. The administrative overhead of creating and maintaining rules specifically for these addresses became difficult, as well as the problem of the additional processor load on the Snort detection engine with the addition of so many extra rules. The current Talos blacklist has over 40,000 entries, so you can imagine that the effort of using regular Snort rules to block that many IP addresses was difficult, to say the least.

The solution to these difficulties was the reputation preprocessor, first included in the Snort 2.9.1.x release of Snort.

Overview of the Reputation Preprocessor

The reputation preprocessor was created to allow Snort to use a file full of just IP addresses to identify bad hosts and trusted hosts. Malicious IP addresses are stored in blacklists, and trusted IP addresses are stored in whitelists. The reputation preprocessor loads these lists when Snort starts, and compares all traffic against those lists. Snort checks both the sending and receiving IP address in each packet against every entry in the IP lists, and if the IP addresses in the packet matches an IP address on the blacklist, whitelist, or both lists, Snort can take a few different actions: Snort can either generate an alert, block the packet, allow the packet without any other processing (skipping all other rules), or let the packet continue through the rest of the regular rule checks. The action that Snort takes depends on how you have the reputation preprocessor configured, and if Snort is running in IDS or IPS mode (Snort can only drop packets when running in IPS mode, for obvious reasons).

The reputation preprocessor is the first preprocessor that a packet encounters in Snort (after being assembled by the decoder). The reason for this is that since the reputation preprocessor can mark trusted packets to skip the rest of the preprocessors and rule engine, or can drop the packet, it can help to reduce the load on the Snort system.

You can manually create whitelists and blacklists, although you are probably better off using PulledPork to automatically download blacklist files. The good news is that if you are using PulledPork and you’ve got the reputation preprocessor configured correctly, all this just works for you. If you want to change the way things work, are doing something special, or just want to understand Snort better, then the rest this guide is for you.

What Happens When a Packet Matches an Entry in an IP List

Assuming your reputation preprocessor is configured correctly, and you have entries in your whitelist and blacklist files: the reputation preprocessor is the first processor that a packet encounters in Snort after being assembled by the decoder. The reputation preprocessor compares the source and destination IP addresses in the packet against the IP addresses in both the whitelist and blacklist files. If one of the IP addresses (sender or recipient) for the packet is on the blacklist, then an alert is generated (with GID:136, and SID:1) and no further processing is done on the packet (it skips all other processors and the rule engine). If you are running in NIDS mode, only an alert is generated. If you are running inline in IPS mode, then the packet is dropped. If one of the IP addresses is on a whitelist: the packet can either bypass all other preprocessors and the rule engine and continue on, or it can be “unblacked”. When a packet is unblocked, it is treated like a regular packet, being processed by the other preprocessors and rules, even if the address is on the blacklist.

If your Snort server is running as a NIDS (network intrusion detection system) then alerts are generated (we are detecting) for packets that match one of the IP lists. If you are running Snort as a NIPS (network intrusion prevention system), then traffic can be dropped instead of generating alerts when the packet IP address matches an IP in the blacklist . If one IP address is on the whitelist, and the other address is on the blacklist, the action taken will depend on your configuration, namely the priority and white reputation preprocessor options described below.

Configuring the Reputation Preprocessor

The reputation preprocessor is configured in your snort.conf. Many standard Snort installations place this file at /etc/snort/snort.conf. Open this snort configuration file and find the section for the reputation preprocessor. This should be around line number 506 if you haven’t changed your snort.conf much. If the preprocessor is disabled with the hash symbol (#) at the beginning of each line for the preprocessor, you can enable it by removing the hash symbol from the beginning of each line. The preprocessor configuration should look similar to the following when enabled:

# Reputation preprocessor. For more information see README.reputation
preprocessor reputation: \
   memcap 500, \
   priority whitelist, \
   nested_ip inner, \
   whitelist $WHITE_LIST_PATH/white_list.rules, \
   blacklist $BLACK_LIST_PATH/black_list.rules 

There are a few other lines in your snort.conf that relate to IP lists as well. The following two lines tell Snort where the folder is that stores the whitelists and blacklists:

var WHITE_LIST_PATH /etc/snort/rules/iplists		# line 113 in snort.conf
var BLACK_LIST_PATH /etc/snort/rules/iplists		# line 114 in snort.conf

note that you could just use an absolute path for WHITE_LIST_PATH and BLACK_LIST_PATH rater than using the $BLACK_LIST_PATH/filename as in the above two examples.

We also need a folder to hold your IP lists, and the empty whitelist and blacklist. These three items are what we told Snort to use in the above two sections of the snort.conf (create these if they don’t exist, based on your preprocessor configuration):

# these commands will create your whitelist and blacklist files as configured in the above example
sudo mkdir /etc/snort/rules/iplists
sudo touch /etc/snort/rules/iplists/black_list.rules
sudo touch /etc/snort/rules/iplists/white_list.rules

Since you’ve edited your snort.conf, it’s always a good idea to test that you didn’t create any errors. A simple test (change for your system as needed) and make sure no issues are reported:

sudo snort -T -c /etc/snort/snort.conf -i eth0

Manually Adding Entries to IP Lists

If you want to build your own whitelists and blacklists, this is easy. Snort can easily load multiple whitelists and blacklists (see the section below for instructions). The list should be a text document with either plain IP addresses (specifying a single host), or IP addresses in CIDR format, with one entry per line. You can have full-line and inline comments by using the hash (#) symbol. An example of all these options is below:

# This is a full-line comment
# This list could be a whitelist or a blacklist, it only depends on what you tell Snort to treat it as

# Add these single hosts to this list:
10.0.0.120    
10.0.0.222       # This is an inline comment.

# Add these entire subnets (in CIDR format) to the list:
10.2.0.0/24
224.0.0.0/4      # add the entire multicast subnet to this list

Allowing Local IP Addresses

If you want the reputation preprocessor to recognize (not ignore) private network addresses (the ones on your home or internal network) which all fall in the local ranges:

• 10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
• 172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
• 192.168.0.0 – 192.168.255.255 (192.168.0.0/16)

then add the scan_local option to the reputation preprocessor, as show below in line 6:

# Reputation preprocessor. For more information see README.reputation
preprocessor reputation: \
   memcap 500, \
   priority whitelist, \
   nested_ip inner, \
   scan_local, \
   whitelist $WHITE_LIST_PATH/white_list.rules, \
   blacklist $BLACK_LIST_PATH/black_list.rules 

This option allows you to test the reputation preprocessor with private addresses (alert on traffic from the 10.0.0.0/24 subnet for example). Without this option, all IP addresses in your IP lists from a private address will be not be compared against the IP lists.

Configuring IP List Actions and Precedence

The two reputation preprocessor configuration options that determine how IP lists affect the processing of packets are priority and white.

priority: When a packet has one IP on a blacklist and the other IP on a whitelist (sender IP address and receiver IP address), this option determines which is more important. If this is set to blacklist, then the packet will generate an alert. If this is set to whitelist, then the process will be allowed to pass. An example of this setting (truncated for simplicity):

preprocessor reputation: \
   priority whitelist, \
   ...

white: this option can be set to either unblack or trust. When set to unblack, if the packet also has an address that is in the IP blacklist (say the source IP address is in the whitelist and the destination ip address of that same packet is in the blacklist), then the packet will continue to process through the other preprocessors as if it was not on the blacklist. Note that for the packet to continue to be processed, the priority must be set to whitelist. When white is set to trust, then the packet is implicitly trusted and bypasses all further processing. An example of this:

preprocessor reputation: \
   white unblack, \
   ...

Setting up local.rules to Generate Alerts for Blacklist Events

If you are not using PulledPork to manage your rulesets, and have manually configured your whitelists and / or blacklists, you need to tell Snort to generate an alert when it sees packets that match these IP lists.

You need a local.rules file loaded by Snort with the following rules (if you need help setting this up, please see my article here):

alert ( msg: "REPUTATION_EVENT_BLACKLIST"; sid: 1; gid: 136; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )
alert ( msg: "REPUTATION_EVENT_WHITELIST"; sid: 2; gid: 136; rev: 1; metadata: rule-type preproc ; classtype:bad-unknown; )

NOTE: if you are using PulledPork to manage rules, you don’t need the above lines, it will add these rules automatically.

Rules with GID 136 are rules triggered by the reputation preprocessor. There are 3 SID’s for that processor:

1. Packets are blacklisted
2. Packets are whitelisted
3. Packets are inspected

We don’t want to create a rule with a SID of 3 because that would be a lot of alerts (essentially all packets).

There is an easy way to test the reputation processor works. First, make sure your reputation preprocessor is properly configured, and you have the two rules listed above in your local.rules file (and make sure that Snort is loading your local.rules).

Next, add the IP address of a second host on your network (other than your snort host) to your black_list.rules file. This IP address will be the address that Snort generates alerts on, due to the IP address being in the blacklist file.

Start Snort with the following command (change for your specific system settings). This will generate alerts to the console:

sudo /usr/local/bin/snort -A console -q -c /etc/snort/snort.conf -i eth0

If you now ping your Snort server from the system that is in your blacklist, you should see alerts display on the console. Use Ctrl-C to stop Snort from running. In the example below, the first alert is from me ssh-ing into the Snort server from the blacklisted computer. Next I pinged the Snort server 8 times, then used wget to try to pull a webpage from the Snort server:

12/09-20:25:10.423907  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.0.0.72:51312 -> 10.0.0.101:22
12/09-20:25:15.355331  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105
12/09-20:25:15.355375  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101
12/09-20:25:16.355231  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105
12/09-20:25:16.355270  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101
12/09-20:25:17.355272  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105
12/09-20:25:17.355310  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101
12/09-20:25:18.355293  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.101 -> 10.0.0.105
12/09-20:25:18.355319  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {ICMP} 10.0.0.105 -> 10.0.0.101
12/09-20:25:26.194898  [**] [136:1:1] (spp_reputation) packets blacklisted [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 10.0.0.101:52671 -> 10.0.0.105:80
^C*** Caught Int-Signal

If you are wondering how I’m able to remote into the server from a blacklisted host, remember that we have configured Snort as an IDS (intrusion detection system), it only detects and alerts for malicious traffic. We have not configured Snort as an IPS (intrusion prevention system). More information on running Snort as an IPS here.

If you don’t see any alerts like above, run the below command to test your snort.conf,

sudo snort -T -c /etc/snort/snort.conf -i eth0

If Snort verifies the configuration file successfully (indicated in the final few lines of output), then scroll up through the output up to see if any IP addresses show in the reputation portion of the output (see line 6 below for our one IP address loaded from the blacklist file):

Reputation config: 
	WARNING: /etc/snort/snort.conf(512) => Keyword priority for whitelist is not applied when white action is unblack.
	    Processing whitelist file /etc/snort/rules/iplists/default.whitelist
	    Reputation entries loaded: 0, invalid: 0, re-defined: 0 (from file /etc/snort/rules/iplists/default.whitelist)
	    Processing blacklist file /etc/snort/rules/iplists/default.blacklist
	    Reputation entries loaded: 1, invalid: 0, re-defined: 0 (from file /etc/snort/rules/iplists/default.blacklist)
	    Reputation total memory usage: 329636 bytes
	    Reputation total entries loaded: 1, invalid: 0, re-defined: 0
	    Memcap: 500 (Default) M bytes 
	    Scan local network: DISABLED (Default)
	    Reputation priority:  whitelist(Default) 
	    Nested IP: inner (Default) 
	    White action: unblack (Default) 
	    Shared memory is Not supported.

You will also want to verify that our two rules (from local.rules) have loaded in the rules section of the output (note that they are recognized as preprocessor rules):

+++++++++++++++++++++++++++++++++++++++++++++++++++
Initializing rule chains...
2 Snort rules read
    0 detection rules
    0 decoder rules
    2 preprocessor rules
2 Option Chains linked into 1 Chain Headers
0 Dynamic rules
+++++++++++++++++++++++++++++++++++++++++++++++++++

+-------------------[Rule Port Counts]---------------------------------------
|             tcp     udp    icmp      ip
|     src       0       0       0       0
|     dst       0       0       0       0
|     any       2       0       0       0
|      nc       2       0       0       0
|     s+d       0       0       0       0
+----------------------------------------------------------------------------

if both of those are correct, start looking at your IP addresses to verify that you have everything correct. If you are using private IP addresses (like 10.x.x.x) then remember that you need to enable scan_local in the reputation preprocessor.

Understanding nested_ip

Packets are often encapsulated in other packets, such as GRE or IP in IP tunnels. If Snort can see the IP header information of the encapsulated (internal) packet, you can choose to compare the inner packet, outer packet, or both inner and outer IP headers against your IP lists, by setting the nested_ip option to one of the following: inner, outer, or both, which tells the reputation preprocessor to check the inner IP address, the outer IP address, or to check both IP addresses (both inner and outer). One example is below:

preprocessor reputation: \
   nested_ip inner, \
   ...

PulledPork and Blacklists

PulledPork can automatically download blacklists (but not whitelists), and is configured to do so by default. When configuring pulledpork.conf (usually located in /etc/snort/), you will need to have the following lines configured correctly.

First we need to tell PulledPork which IP blacklist to download. By default we download the Talos blacklist, which is found at line 24 of pulledpork.conf. No changes are required to this line, since it’s enabled by default:

# pulledpork.conf - Line 24
rule_url=http://talosintel.com/feeds/ip-filter.blf|IPBLACKLIST|open

Line 141 in PulledPork.conf points to local file where you will save the blacklist that you download. This will be the same file you configured in the reputation preprocessor with the directive: BLACK_LIST_PATH in your snort.conf. This is the where PulledPork will write the blacklists to:

# pulledpork.conf - Line 141
black_list=/etc/snort/rules/iplists/black_list.rules

The other configuration item in PulledPork.conf that is related to blacklists is line 150. This is used to have Snort reload the IP lists without a reboot (although that requires a lot more configuration, and re-compiling snort with -enable-shared-rep and –enable-control-socket, which isn’t covered here). You just need to make sure this folder path points to your iplists folder so there are no errors, although we won’t be using this feature:

# pulledpork.conf - Line 150
IPRVersion=/etc/snort/rules/iplists

after running PulledPork, you should see the black_list.rules file be populated with a number of IP addresses (over 40,000 at this time from the Talos blacklist).

Using Multiple IP Lists

You can have the reputation preprocessor load multiple whitelists and blacklists. This is good if you have a personal blacklist that you don’t want overwritten by PulledPork. An example or the reputation preprocessor configured with two whitelists and two blacklists:

preprocessor reputation: \
   memcap 500, \
   priority whitelist, \
   nested_ip inner, \
   whitelist $WHITE_LIST_PATH/white_list.rules, \
   whitelist etc/snort/rules/iplists/some_whitelist.rules, \
   blacklist /etc/snort/rules/iplists/some_blacklist.rules, \
   blacklist $BLACK_LIST_PATH/black_list.rules 

Useful References

Snort’s guide on the reputation preprocessor is here. This explains every option for the preprocessor in detail.
README.reputation: the Snort overview of the reputation preprocessor.

Conclusion

I hope this has been a good overview of the reputation preprocessor in Snort. I wrote this article because I found most of the information on the web to be scattered, incomplete, and sometimes contradictory (as things tend to often be on the internet). I am hoping this article helps to explain the reputation preprocessor at a high-enough level as to make you wiser, as well as deeply enough that you can bend it to your will. If you have any questions or recommendations, please contact me. I can’t always answer questions right away, but I will do my best to get back to you. I welcome all recommendations and corrections.