5.3 Preprocessor Configurations

The Snort preprocessors have changed a lot in recent versions. Old, standby preprocessors (like portscan2) are gone, replaced with new methods born out of development work by the open source community and the commercial incarnation of Snort from Sourcefire. It seems that the code for some of these deprecated preprocessors is still there—you could still use some of the old functionality if that is what you are used to. We won't talk about it here, however.

The preprocessors serve a few purposes. They normalize traffic for a variety of services, ensuring that the data in the packets Snort is watching will have the best chance of being in a format that the signatures will recognize. Another function of the preprocessors is self-defense. A variety of attacks have been developed that are designed to confuse or overwhelm an NIDS sensor, so an attacker can do her work unnoticed. The frag2 and stream4 preprocessors are primarily defense mechanisms.

The final benefit provided by the preprocessors is that they extend Snort's ability to detect network anomalies that may be signs of intrusion—not just notice things that are contained in the rule sets. Apart from just the raw performance that Snort offers, the preprocessors serve to differentiate Snort from other NIDS solutions on the market today.

5.3.1 flow

The flow preprocessor is going to be the central storehouse for state keeping in Snort. Right now, there is only one module for flow: flow-portscan (see below). flow watches all traffic and keeps track of connections between unique systems and between unique ports. When a new unique flow is detected, the information is converted to a hash (smaller and faster to keep track of than tracking IP addresses and port numbers) that is stored in a memory-resident table.

The options for the flow preprocessor are:

memcap

You can specify a cap for the memory allocated for flow tracking. By default, flow uses about 10 megabytes of memory. For most applications this is more than enough. If you start noticing dropped packets in the statistic summary when Snort is terminated, or low memory problems on the Snort system itself, you can reduce this number.

rows

You can specify the number of rows in the hash table (the number of unique flows). By default, this is set to 4,099 rows, which should be plenty.

stats_interval

You can dump the statistics of the flow preprocessor to stdout. Its value is an integer that represents the time (in seconds) between dumps. This is useful for testing purposes, but can be disabled by supplying 0 as the value. This information is dumped at shutdown, in any case.

hash

The method used for hashing the information in the table. Can be set to 1 for "hash by byte" or 2 for "hash by integer." Use 2—it's much faster.

Here's a recommended configuration for flow:

preprocessor flow: stats_interval 0 hash 2

5.3.2 frag2

When a packet is travelling from one network to another, it occasionally needs to be broken (fragmented) into a series of smaller packets, because the second network has a limit on packet size that's smaller than the first network. The pieces are reassembled when they reach their destination. A number of network attacks have been based on using very small packets to sneak past firewalls or intrusion detection systems. For example, consider a Snort rule that is looking for the string /users.pwd in the data section of a packet. An attacker might create a fragmented sequence of small packets in which each fragment only contains a few bytes of data: the first fragment might contain /user, and the second might contain s.pwd. These packets won't trigger alert by themselves, because they don't match the rule. The frag2 preprocessor, by reassembling the fragments into a whole, allows snort to see the "big picture" and detect the string /users.pwd.

An attacker can also use fragmentation to cause problems. Some devices do not handle fragmented packets well and can crash as a result. Too many very small packets can cause resource starvation on a system and overlapping packets can confuse others. There's an attack tool called Fragroute that fragments a network stream (discussed in Chapter 4). frag2 has several options that defend against these attacks.

The placement of the Snort sensor has a bearing on whether or not to use the frag2 preprocessor. Some network devices perform fragment reassembly before passing the traffic on. The Cisco PIX firewall is one such device. If the Snort sensor is behind one of these devices, the frag2 preprocessor has almost nothing to do and can likely be disabled altogether, freeing up the resources for other preprocessors.

frag2 has several options:

timeout

The number of seconds before an inactive session is flushed from memory. It defaults to 60 seconds.

memcap

The number of bytes of memory to set aside. The default of 4 Megabytes (4,194,304 bytes) is plenty for most applications.

detect_state_problems

Turns on alerts for some unnatural fragmentation conditions (like overlapping fragments). Since such conditions are very often sign of malicious activity, this should be enabled for most environments.

min_ttl

Sets the minimum time to live (ttl) accepted by the preprocessor. Set to 0 by default.

ttl_limit

Sets the maximum variance of ttl between packets of a network stream. This should not vary too much and a wide variance may be a sign of nefarious activity on the network. Defaults to a value of 5.

Here's a recommended configuration for frag2. It's very simple. Because no options are used, the colon can be omitted:

preprocessor frag2

5.3.3 stream4

stream4 was initially written to protect Snort from a new class of attacks that attacked an environment's NIDS sensors by overwhelming them with packets containing strings likely to trigger alerts. These attacks came to light with the release of two tools called stick and snot, previously mentioned in our discussion of IDS evasion techniques (Chapter 4). Stick actually uses the Snort rules to create packets that match the characteristics that Snort is watching for (it will also probably generate alerts for other IDS solutions), thus flooding it with alerts. Since a network conversation (at least a TCP session) is started by a three-way handshake with a server, if there was a way to track the active conversations that were set up correctly, it would be possible to eliminate these stick packets since they are not part of an active conversation.

stream4 has two goals: stateful inspection and awareness and session reassembly. Session reassembly is handled by the stream4_reassemble preprocessor. For accurate function of stream4, stream4_reassemble should be enabled.

Along with providing a defense against tools such as stick and snot, tracking the state of a network conversation provides additional benefit. We will discuss this in much more detail in Chapter 7, but stream4 gives us the ability to build rules that watch a particular side of a conversation using the flow keyword (not to be confused with the flow preprocessor). This helps reduce false positives. To activate this stateful inspection by rules, use the -z option at the command line. It used to be necessary to use -z est to enable this, but the "est" is deprecated and no longer needed (in fact, it causes an error).

The default settings for stream4 do a decent job, but consider tuning things further to suit your environment (and to further reduce false positives). The options for the stream4 preprocessor are:

detect_scans

Disabled by default. This directive tells stream4 to generate an alert when a portscan is detected. stream4 detects portscans that use nonstandard methods to identify listening ports. For instance, if a packet is sent to a port on a host with the FIN flag set, the host responds with a RST packet if the port is closed and replies with nothing if the port is open and listening. These are referred to as stealth scans and can take a variety of forms. Include this parameter if you are interested in detecting stealth scans.

detect_state_problems

Disabled by default. This generates an alert when a problem with the state of a conversation is detected. This option generates a large number of alerts and generally remains disabled in most environments. Networks with Windows systems generate a large number of these alerts. High-latency environments experience a large number of false positives, since a system that transmits packets after an ACK is sent causes alerts to be generated.

disable_evasion_alerts

Disabled by default, too. If enabled, this option may detect attackers trying to confuse the IDS by sending retransmissions of packets, thinking that the second one would make it through. It is also possible to send a data payload with a SYN packet. Since a SYN packet is often used to initiate a TCP connection, it does not carry a data payload by design. Generally, it is best to keep this option enabled.

min_ttl

Sets a minimum time to live (ttl) setting for packets accepted into the stream4 preprocessor. Some attacks may have an artificially low ttl so that they make it to the IDS (overwhelming it), while the packet does not make it to the actual server. This situation is fairly rare, and it's usually acceptable not to set a value for this option. This option defaults to 1.

ttl_limit

Sets the maximum amount the time to live setting can vary in a network conversation. Every time a packet travels through a router, the ttl setting is decremented by one. During a network conversation, the packets traveling between the two hosts follow generally the same path across the network and the ttl should be fairly constant in each direction. If an attacker is trying to insert packets into a network conversation, the ttl may change, indicating an attack is underway. Since routing is dynamic (thus, a change in ttl might not be something nefarious), it is difficult to decide on a value for this option (a flapping route might cause false positive alerts, too). Most sources indicate that a value between 10 and 15 is reasonable. This option defaults to 5.

keepstats [machine, binary]

Disabled by default. If enabled, it outputs statistics on each session tracked in one of two modes: machine dumps to a text file; binary outputs a unified binary format useable by tools like Barnyard.

noinspect

Normally defaults to off. Tells stream4 to disable stateful inspection of all packets that are destined for ports not included in the stream4_reassemble's ports option. (See Section 5.3.4 below for details on the ports option). You might not be concerned with traffic destined for ports that you are not listening on. In general, you can leave this option off.

timeout

Normally, when a TCP connection is torn down, it is pruned from the session table. If the connection is not torn down or is improperly torn down, this timeout setting prunes the session from the table after an indicated period of time has passed without activity. Essentially, it acts as an idle timer. This option defaults to a value of 30 seconds—kind of short, for most environments. Since the memory requirements are fairly low (on the order of a few kilobytes) for the session table, setting this to 60 seconds is not a bad idea.

log_flushed_streams

If a packet in a monitored stream causes an alert, you can dump the session information from stream4 to disk. This only works if you are logging in pcap mode. This option does carry some overhead and is not commonly enabled. The packet logs it generates are difficult to work with.

memcap

This looks for a number of bytes sets a limit on the amount of memory allocated to stream4. Normally, the default value works fine, but if you have the memory or are operating in an enterprise-class environment with a dedicated sensor, you could ratchet this value up. Keep in mind that the option is looking for a number of bytes, not Megabytes. This option defaults to 8 Megabytes (8,388,608 bytes).

Here's a suggested setting for stream4:

preprocessor stream4: detect scans, disable_evasion_alerts, timeout 60, ttl_limit 10

5.3.4 stream4_reassemble

Snort relies on being able to match strings of characters in a network packet to a string of characters in a signature. If an attacker could split the characters that would normally match the signature across multiple packets, Snort may not trigger an alert—much like what happens with fragmented packets. stream4_reassemble acts to reassemble network traffic that is part of a stream of conversation between two systems, increasing the chance of matching a signature.

Network conversations between highly interactive services (very often command-line services like Telnet, FTP, and SMTP) can cause content to be spread across multiple packets in the same way. Reassembly of traffic generated by these services is essential to prevent missed alerts (false negatives).

Another attack IDS evasion technique is to inject packets in the middle of an attack with characteristics (like invalid checksums) that cause the injected packets to be dropped by the target system. stream4_reassemble looks past these injected packets, finding the attack signature in the traffic stream.

There are a number of options for the stream4_reassemble preprocessor:

clientonly

Only performs reassembly on the client side of the conversation stream. If your sensor is having performance issues, you might want to watch only one side—perhaps you are watching an internal network that contains only clients and does not offer services to the public Internet. In this case, you may want to enable the clientonly option. This option is enabled by default.

serveronly

Only performs reassembly on the server side of the conversation stream. If your sensor is having performance issues, you might want to only watch the one side. If your internal network only contains server systems offering services to the Internet, you might want to enable the serveronly option.

both

Performs reassembly on both sides of the conversation. If your Snort sensor is watching both clients and servers, you might want to enable this option.

noalerts

Reassembly is performed, but alerts are not generated for reassembly attacks and evasions. Unless you are seeing a large number of false positives, do not disable alerts for stream4_reassembly.

ports [ list]

Specifies a list of ports that are reassembled. This greatly limits the overhead of performing this task and normalizes traffic on services that often have their content spread across multiple packets. The ports are simply typed out with a space between them (for example: 21 22 23 25 110 143 1433). By default the ports that are reassembled are 21, 23, 25, 53, 80, 110, 111,143, 513, and 1433.

Here's a suggested setting for stream4_reassemble:

preprocessor stream4_reassemble: both

5.3.5 HTTP Inspect Preprocessor

There are a wide variety of ways that information can formatted in an HTTP session. There are also a very large number of different types on information that can be a part of an HTTP session (multimedia, .xml, .HTML, .asp, .php, .java, and so on). As a result, Snort must "massage" the content of HTTP conversations so that the data is in a format that has the best chance of being matched to the signatures. The http_inspect preprocessor performs this task (http_inspect takes the place of http_decode, found in previous versions of Snort).

There are two types of http_inspect configuration: global and server. The global configuration makes changes that affect all HTTP traffic. The server configuration contains settings for a single server or a group of similar servers. Since the different web servers encode things and operate in different ways, you can configure the http_inspect_server preprocessor to suit the needs of particular types of web servers—most commonly, Microsoft Internet Information Server (IIS) or Apache.

Note that you can only have one configuration line for http_inspect (which is the global setting), but you can have multiple http_inspect_server lines. It is also important to be aware that http_inspect is not aware of the state of a packet it is examining. It relies on other preprocessors to handle reassembly of traffic. Rumor has it that stateful inspection will be added in the future.

5.3.5.1 http_inspect (global)

This preprocessor contains settings that affect the inspection of all HTTP traffic. The global http_inspect preprocessor has three options:

iis_unicode_map < filename> [codemap < integer>]

This option is actually not optional. It needs to be included or an error results. By default, the location of the map file (called unicode.map) is included with the rules you downloaded and extracted. It tells the preprocessor how to map Unicode characters into ASCII text that can be matched to the signatures. You must specify the normal code map to use (1252 is the ANSI- Latin I code map that is used in English).

detect_anomalous_servers

Generates an alert if standard HTTP traffic is detected on nonstandard ports. Since many devices and services offer a web-based interface on potentially nonstandard ports, this can be a source of numerous false positives. This is not commonly enabled.

proxy_alert

If you are using a proxy server to regulate your Internet users, this option generates alerts for users that are not using the proxy. It does not detect blind firewall proxies, however. If you don't use a proxy server in your environment (or are confident that people can't get around your proxy), this has the potential of generating a very large number of false positives.

Here's a suggested setting for http_inspect global:

preprocessor http_inspect: global iis_unicode_map unicode.map 1252

5.3.5.2 http_inspect_server

http_inspect_server is the server configuration portion of the http_inspect preprocessor. You can specify settings for the specific type of server or servers in your environment. Most administrators have a server configuration for their IIS servers and another for their Apache servers. At the end of this section, I will include a sample of each.

There are many options for this preprocessor and at first it can seem overwhelming. Start with the suggested settings and modify them as you see them in action. Setting an option to "no" prevents that option from generating alerts, but doesn't disable the option—the processing still takes place. There are two types of http_inspect_server configurations: "default" and "by IP address." The "default" configuration configures the inspection of all web traffic that is not associated with a specifically configured IP address. The "by IP address" configuration specifies the settings for a specific IP address or range of addresses. The options for the http_inspect_server preprocessor are:

default or < IP address>

Supply either the word "default" or an IP address (or CIDR block of addresses).

profile <all|apache|iis>

Since there are so many settings, you can choose a preconfigured set of options by selecting apache or iis. Select all to make a custom configuration. Choose all for the default configuration and select iis or apache for specific servers or groups of servers. If a profile is used, you cannot change the settings that are part of the profile. This leaves only four settings available for you to change: ports, iis_unicode_map, allow_proxy_use, and flow_depth.The settings configured by the three profile options are shown in Table 5-2, Table 5-3, and Table 5-4.

Table 5-2. Settings for profile "all"

Option	Setting
flow_depth	300
chunk_encoding	Alert on chunks larger than 500,000 bytes
lis_unicode_map	The map used in the global configuration
ascii	No
non_refc_char	On
multi_slash	No
directory	No
apache_whitespace	Yes
double_decode	Yes
j_encode	Yes
bare_byte	Yes
lis_unicode	Yes
lis_backslash	No
lis_delimiter	Yes

Table 5-3. Settings for profile "apache"

Option	Setting
flow_depth	300
chunk_encoding	Alert on chunks larger than 500,000 bytes
ascii	No
non_rfc_char	On
multi_slash	No
directory	No
apache_whitespace	Yes
utf_8	No
non_strict	On

Table 5-4. Settings for profile "iis"

Option	Setting
flow_depth	300
lis_unicode_map	The map used inthe global configuration
ascii	No
multi_slash	No
directory	No
double-decode	Yes
u_encode	Yes
bare_byte	Yes
lis_unicode	Yes
lis_backslash	No
lis_delimiter	Yes
apache_whitespace	Yes

ports {< port list>}

Lists the ports (separated by spaces and contained in the curly brackets) on which HTTP services are offered.

iis_unicode_map < filename> [codemap < integer>]

Identical to the configuration for the global configuration. It's actually not optional; it needs to be included or an error results. By default, the location of the map file (called unicode.map) is included with the rules you downloaded and extracted. It tells the preprocessor how to map Unicode characters into ASCII text that can be matched to the signatures. You must specify the normal code map you will use (1252 is the ANSI- Latin I code map that is used in English).

flow_depth < integer>

Since most signatures alert in the first 150-300 bytes of an HTTP packet's payload, we don't need to look past that point. This greatly reduces the overhead of http_inspect.

ascii <yes/no>

It is normal to see ASCII encoding in URLs. Disabling alerting is recommended on this option.

utf_8 <yes/no>

Apache uses UTF-8 encoding as a part of normal operation. It is usually best to disable alerts on the presence of UTF-8 encoding.

u_encode <yes/no>

Since there aren't any known web clients that use this method of encoding, it is best to enable alerting when this encoding is detected.

bare_byte <yes/no>

This is a tricky way to identify IIS servers by how they react to a particular set of non-ASCII characters used in UTF-8 encoding. The short story is that no legitimate clients use this encoding and alerting should be enabled.

base36 <yes/no>

Enables the decode of base_36 characters. Commonly left off.

iis_unicode <yes/no>

Unicode traffic usually indicates an attempted attack and alerting should be enabled.

double_decode <yes/no>

Alerts on an IIS attack trick that encodes Unicode with Unicode, tricking the web server into doing bad things. Alerting should be enabled since this is always naughty traffic.

non_rfc_char {< list of bytes>}

This option allows you to alert on certain non-RFC character (designated as a list of space-delimited bytes contained in curly brackets). Be careful. If you specify a commonly used character, you could end up generating a large number of false positives.

multi_slash <yes/no>

Some web servers allow malicious activity if a URL is obfuscated by including multiple directory slashes in a row. This would usually indicate a malicious request and should be generate an alert.

iis_backslash <yes/no>

If you want an alert when a Windows-style blackslash is used instead of a normal foreward slash, set this to yes. Either way, http_inspect normalizes these slashes.

directory <yes/no>

Using strange strings of characters, some attackers can trick a web server into performing a directory traversal. Characters such as "/../" and "_/" are normalized to "/" by http_inspect. If you want an alert for such traversal attempts, set this to yes.

apache_whitespace <yes/no>

Some Apache servers may be vulnerable to the replacement of a space with a tab character. While enabling alerting may give you warning of an attempted attack, it happens often enough that you may generate a large number of false positives.

iis_delimeter <yes/no>

Most web servers accept this delimiter without problem. There is likely no need to alert on it.

chunk_length <non-zero positive integer>

Over-large chunk lengths may be a method of attack. A setting of 500,000 bytes usually provides adequate discrimination between attacks and tunneling protocols that use chunked encoding across HTTP.

no_pipeline_req

Turns inspection of pipeline encoding off. This should really only be disabled if you are experiencing performance problems.

non_strict

Some servers allow broken URIs (Apache, for instance). If you have Apache servers, enable this option.

allow_proxy_use

Allows proxy use on the specified web server. This option suppresses alerts generated by this server for unauthorized proxy use (if enabled).

no_alerts

Turns off all alerts generated by http_inspect.

oversize_dir_length < non-zero positive integer>

If the directory length in a URL is over the size specified, an alert is generated. Some application servers generate huge URLs that can be a source of false positives. A setting of 300 should be sufficient.

inspect_uri_only

If you are having performance issues, you can limit http_inspect to watching only the URI portion of the HTTP request (which catches 90-95% of the actual attacks).

Here's a setting for a default http_inspect_server configuration (this acts as a catch-all for servers not specifically enumerated):

preprocessor http_inspect_server: server default profile all ports {80 8080}

Here's a setting for a server http_inspect_server configuration for an IIS server (this tunes the options to best match the characteristics of traffic to and from an IIS server):

preprocessor http_inspect_server: server 10.10.10.100 profile iis ports {80 8080}

A sample setting for a server http_inspect_server configuration for an Apache server (this greatly aids accurate alerting for Apache-based web servers):

preprocessor http_inspect_server: server 10.10.10.200 profile apache ports {80 8080}

5.3.6 rpc_decode

RPC's traffic can be spread across multiple packets and encoded in a variety of ways. The rpc_decode preprocessor normalizes this traffic so that it is formatted in a consistant manner that Snort can compare against the signature lists. A list of ports that RPC services are running on is provided on the configuration line. There are four additional options for rpc_decode:

alert_fragments

Generates alerts for any fragmented RPC traffic. It is likely to generate only false positives.

no_alert_multiple_requests

Specifies that no alert be generated when more than one RPC request is contained in a packet. By default, alerts are generated. Normally, it is desirable to generate alerts when this happens. If in the course of running Snort you find many false positives, you have the option of disabling these alerts. Sometimes the combination of stream4_reassembly coupled with rpc_decode can be a source of false positives.

no_alert_large_fragments

RPC fragments can be larger than the current fragment size. If you are seeing false positives, you have the option for disabling these alerts.

no_alert_incomplete

RPC messages can be very large—sometimes larger than the MTU of the network they are traversing. This can be a cause of many false positives for some RPC network services. If you are seeing many false positives, consider disabling these alerts.

Here's a suggested setting for rpc_decode:

preprocessor rpc_decode:111 32771 1024

5.3.7 bo

Back Orifice was created by a cracker organization called the Cult of the Dead Cow (regulars at DefCon). It is used for remote control of client systems. It is actually very full-featured and includes the ability encrypt the data stream. The encryption mechanism was not the most robust and can actually be brute-forced on the fly by the bo preprocessor (with a significant CPU penalty). With the now ubiquitous presence of antivirus software in most environments and Back Orifice on the list of proscribed applications, it is not nearly the problem it once was.

This preprocessor was created to watch for Back Orifice traffic and decrypt it on the fly. It takes no arguments. Many administrators disable the preprocessor altogether by commenting out the line with a # character at the beginning of the line.

Here's a suggested setting for bo:

# preprocessor bo

5.3.8 telnet_decode

This preprocessor normalizes nonstandard characters and session negotiation strings in Telnet and FTP traffic. It does not generate alerts and has no options.

Here's a suggested setting for telnet_decode:

preprocessor telnet_decode

5.3.9 flow-portscan

This (very complicated) preprocessor is brand new. Documentation is thin and bug fixes are still being introduced. flow-portscan relies on the flow preprocessor being configured and operational to function (see the description of flow, above).

flow-portscan takes the place of the portscan2 and conversation preprocessors. You might be familiar with these (in fact, the support is still there, for time being); but it's time to let go and move on. flow-portscan has many advantages over the old ways—better performance, lower memory costs, and a significant increase in configuration options.

There are three basic components of flow-portscan:

Scoreboards

There are two indices that track the types of servers that Snort sees transmitting on your network, called scoreboards. They track two different types of host, talkers and scanners. A talker is any host that is active on your network. A scanner is a host that makes a connection to a port on a server in the network you have designated as the network containing your servers (called the server watch net). Not every incoming packet is a scan, just a potential scan.

Uniqueness tracker

Tracks if a network connection is unique. To be unique, it must have one of the following characteristics different from other network traffic already detected: source IP address, destination IP address, IP protocol, or destination port.

Server statistics tracker

Used to track the number of times a particular service on a server in your server watch net has had a connection made to it. This hit count is tracked by destination IP address, destination port, and IP protocol.

This preprocessor develops a picture of how your servers are used in the normal course of business. Ports that are consistently (and legitimately) used are added to a list of ports that can be ignored as potential portscan-generated connections. If a server is recognized as performing business on port 80, connections to that port will not be tallied. This ignore list also affects how the scoreboards are tracked.

There are a large number of configuration options for this preprocessor. They set time limits on how long certain metrics are tracked, what networks contain servers, how much memory flow-portscan can use, what kind and how much output flow-portscan generates, and what networks and hosts can be ignored either as talkers or scanners.

Detecting stealthy portscans is very difficult (this is the reason for the extreme measures taken to detect them accurately). An attacker can use a number of strategies beyond messing with the SYN/ACK/FIN flags. An attacker can:

• Not attack ports in order

• Insert varying delays between probes for particular ports

• Interleave scans for several machines on your network

• Originate the scans from thousands of fictional addresses on his network or different networks

• All of the above

We'll look at the options available for the flow-portscan and then see some examples. The flow-portscan defaults are a very good place to start. They are, for the most part, very reasonable, and it is likely you will never need to change them. If you find that you are missing scans or that you are generating too many false positives, start tinkering. Now, on to the options:

scoreboard-memcap-talker < bytes>

Defaults to 24 megabytes (25,165,824 bytes). It specifies how much memory is used to track talkers.

scoreboard-rows-talker < count>

Defaults to 1,000,000 and specifies the number of rows in the talker table.

scoreboard-rows-scanner < count>

Defaults to 250,000 and specifies the number of rows in the scanner table.

scoreboard-memcap-scanner < bytes>

Defaults to 6 megabytes (6,291,456 bytes) and specifies how much memory is used to track scanners.

scanner-fixed-threshold < integer>

Defaults to 15 and sets the number of points that a scanner must accumulate in the scanner-fixed-threshold time range.

scanner-sliding-threshold < integer>

Defaults to 40 and sets the number of points that a scanner must accumulate in the scanner-sliding-threshold time range.

scanner-fixed-window < integer>

Defaults to 15 and sets the number of seconds should elapse before resetting the fixed scanner score.

scanner-sliding-window < integer>

Defaults to 30 and sets the number of seconds that should elapse before resetting the sliding scanner score.

scanner-sliding-scale-factor < float>

Defaults to 0.5 and specifies the factor by which the sliding window should be increased when a new sliding scanner entry is made.

talker-fixed-threshold < integer>

Defaults to 15 and sets the number of points that a scanner must accumulate in the talker-fixed-threshold time range.

talker-sliding-threshold < integer>

Defaults to 30 and sets the number of points that a scanner must accumulate in the talker-sliding-threshold time range.

talker-fixed-window < integer>

Defaults to 30 and sets the number of seconds should elapse before resetting the fixed talker score.

talker-sliding-window < integer>

Defaults to 30 and sets the number of seconds that should elapse before resetting the sliding talker score.

talker-sliding-scale-factor < float>

Defaults to 0.5 and specifies the factor by which the sliding window should be increased when a new sliding talker entry is made.

unique-memcap < bytes>

Defaults to 24 megabytes (25,165,824 bytes). It specifies how much memory is used to track uniqueness.

unique-rows < integer>

Defaults to 1,000,000 and specifies how many rows to have in the uniqueness tracking table.

server-memcap < bytes>

Defaults to 2 megabytes (2,097,152 bytes). It specifies how much memory is used to track servers.

server-rows < integer>

Defaults to 65,536 and specifies how many rows to have in the server tracking table.

server-watchnet < ip list in Snort notation>

Specifies a list of IP addresses using the same format as that used when configuring variables, above (the HOME_NET variable, for example). It should specify where servers that offer services to the external networks reside. This helps map how your servers are used and allow Snort to only alert on anomalous activity. Increases the accuracy of flow-portscan significantly.

src-ignore-net < ip list in Snort notation>

Uses the same IP address list format as server-watchnet, but specifies a range of addresses that flow-portscan can ignore as source addresses.

dst-ignore-net < ip list in Snort notation>

Uses the same IP address list format as server-watchnet, but specifies a range of addresses that flow-portscan can ignore as destination addresses.

tcp-penalties <on|off>

Defaults to on and when enabled, allowing flow-portscan to give strange TCP flag settings additional weight on the scoreboard. For example, if the SYN and FIN flags are both set in a packet, this counts as three points on the scoreboard since it is almost always someone trying to be cute with a portscan.

server-learning-time < seconds>

Defaults to 28,800 and is the amount of time that flow-portscan keeps the counters for server port activity.

server-ignore-limit < hit count>

Defaults to 500 and specifies how many legitimate connections to a service flow-portscan must see before ignoring it as a possible portscan.

server-scanner-limit < hit count>

Defaults to 500 and specifies how many requests on a port on an IP address in the server-watchnet flow-portscan must see before labeling it as a talker.

alert-mode <once|all>

Defaults to once and triggers either a single alert for a detected portscan or for each time a packet goes past thresholds. You are strongly advised to use once here. all is tremendously noisy.

output-mode <msg|pktkludge>

Defaults to msg and specifies how flow-portscan outputs its information. msg generates a variable text message with appropriate scores included. pktkludge generates a fake packet and use the logging output system. This generates some strange data in the output mechanism. msg is preferable in most circumstances.

base-score < integer>

Set to 1 by default. The only real reason to change this value is for debugging changes to settings. Keep it set to 1.

dumpall <1>

If you specify this option (with the value 1), Snort dumps the contents of the server and uniqueness tables when it exits, as well as the scoreboards. This might be interesting when tinkering with settings, but generally is not that useful.

Here is a sample configuration for flow-portscan (remember that the flow preprocessor must be configured and running for flow-portscan to work):

preprocessor flow-portscan: server-watchnet [10.10.10.0/24,10.10.20.0/24]

5.3.10 arpspoof

arpspoof is an experimental preprocessor designed to detect nefarious activity on the local network. It watches for the signs of someone using a tool such as Ettercap or arpspoof that fools two hosts into letting a host perform man-in-the-middle attacks on a conversation between them. It is disabled by default. If the Snort sensor is not on the same local network as the hosts it is protecting (there's a routing device between them), then having this enabled provides no value and only generates false positives and consumes resources. This preprocessor requires the administrator to enter a static list of IP addresses and their proper MAC addresses—the very definition of labor intensive and administrative overhead. It makes Snort a nice tool for rooting out suspected network attacks in progress, but the return is not worth the labor involved in configuring the arpspoof preprocessor (a capable network engineer can get this information from a network devices's logs much easier).

Here's a suggessted setting for arpspoof:

# preprocessor arpspoof

# preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00

5.3.11 perfmonitor

One of the more highly touted features of the latest Snort is its ability to monitor its own operational status. perfmonitor measures Snort's real-time and theoretical maximum performance. When this preprocessor is turned on, it should also have an output mode enabled. This is either "console", which prints statistics to the console window, or "file", where the data is stored to a specified filename. The default statistics that are processed are real-time variables of Snort's performance. These include the following options:

Packets received

Packets dropped

Percentage of packets dropped

Packets Received

Kpackets per second

Average bytes per packets

Mbits per second (wire)

Mbits per second (rebuilt) (average Mbits Snort injects after rebuilding packets)

Mbits per second (total)

Pattern-matching percent (average percent of data received that Snort processes

in pattern matching)

CPU usage (user time, system time, idle time)

Alerts per second

SYN packets per second

SYN/ACK packet per second

New sessions per second

Deleted sessions per second

Total sessions

Max sessions during time interval

Stream flushes per second

Stream faults per second

Stream timeouts

Frag completes per second

Frag inserts per second

Frag deletes per second

Frag flushes per second

Frag timeouts

Frag faults

When the keyword "flow" is enabled, it prints out the statistics regarding the type of traffic and protocol distributions seen by Snort. The keyword "events" turns on event reporting and prints statistics about the number of signatures matched by the setwise pattern matcher and the number of those matches that were verified with the signature flags. These are called nonqualified and qualified events. It shows if there is a problem with the user's rule set.

The keyword "max" turns on the theoretical maximum performance that Snort calculates given the processor speed and current performance. This is only valid for uniprocessor machines, since many operating systems don't keep accurate kernel statistics for multiple CPUs. The keyword "pktcnt" adjusts the number of packets to process before checking for the time sample. This boosts performance since checking the time sample reduces Snort's effectiveness. By default, this level is set at 10,000.

Here are some examples of how to configure and enable the perfmonitor preprocessor:

preprocessor perfmonitor: time 30 events flow file stats.profile max \

console pktcnt 10000

preprocessor perfmonitor: time 300 file /var/tmp/snortstat pktcnt 10000