Subsections

# 2.2 Preprocessors

Preprocessors were introduced in version 1.5 of Snort. They allow the functionality of Snort to be extended by allowing users and programmers to drop modular plugins into Snort fairly easily. Preprocessor code is run before the detection engine is called, but after the packet has been decoded. The packet can be modified or analyzed in an out-of-band manner using this mechanism.

Preprocessors are loaded and configured using the preprocessor keyword. The format of the preprocessor directive in the Snort config file is:

    preprocessor <name>: <options>


## 2.2.1 Frag3

The frag3 preprocessor is a target-based IP defragmentation module for Snort. Frag3 is designed with the following goals:

6.
Fast execution with less complex data management.
7.
Target-based host modeling anti-evasion techniques.

Frag3 uses the sfxhash data structure and linked lists for data handling internally which allows it to have much more predictable and deterministic performance in any environment which should aid us in managing heavily fragmented environments.

Target-based analysis is a relatively new concept in network-based intrusion detection. The idea of a target-based system is to model the actual targets on the network instead of merely modeling the protocols and looking for attacks within them. When IP stacks are written for different operating systems, they are usually implemented by people who read the RFCs and then write their interpretation of what the RFC outlines into code. Unfortunately, there are ambiguities in the way that the RFCs define some of the edge conditions that may occur and when this happens different people implement certain aspects of their IP stacks differently. For an IDS this is a big problem.

In an environment where the attacker can determine what style of IP defragmentation is being used on a particular target, the attacker can try to fragment packets such that the target will put them back together in a specific manner while any passive systems trying to model the host traffic have to guess which way the target OS is going to handle the overlaps and retransmits. As I like to say, if the attacker has more information about the targets on a network than the IDS does, it is possible to evade the IDS. This is where the idea for target-based IDS'' came from. For more detail on this issue and how it affects IDS, check out the famous Ptacek & Newsham paper at http://www.snort.org/docs/idspaper/.

The basic idea behind target-based IDS is that we tell the IDS information about hosts on the network so that it can avoid Ptacek & Newsham style evasion attacks based on information about how an individual target IP stack operates. Vern Paxson and Umesh Shankar did a great paper on this very topic in 2003 that detailed mapping the hosts on a network and determining how their various IP stack implementations handled the types of problems seen in IP defragmentation and TCP stream reassembly. Check it out at http://www.icir.org/vern/papers/activemap-oak03.pdf.

We can also present the IDS with topology information to avoid TTL-based evasions and a variety of other issues, but that's a topic for another day. Once we have this information we can start to really change the game for these complex modeling problems.

Frag3 was implemented to showcase and prototype a target-based module within Snort to test this idea.

### 2.2.1.1 Frag 3 Configuration

There are at least two preprocessor directives required to activate frag3, a global configuration directive and an engine instantiation. There can be an arbitrary number of engines defined at startup with their own configuration, but only one global configuration.

Global Configuration

• Preprocessor name: frag3_global

• Available options: NOTE: Global configuration options are comma separated.

• max_frags number - Maximum simultaneous fragments to track. Default is 8192.

• memcap bytes - Memory cap for self preservation. Default is 4MB.

• prealloc_memcap bytes - alternate memory management mode, use preallocated fragment nodes based on a memory cap (faster in some situations).

• prealloc_frags number - Alternate memory management mode, use preallocated fragment nodes (faster in some situations).

• disabled - This optional keyword is allowed with any policy to avoid packet processing. This option disables the preprocessor for this config, but not for other instances of multiple configurations. Use the disable keyword in the base configuration to specify values for the options memcap, prealloc_memcap, and prealloc_frags without having the preprocessor inspect traffic for traffic applying to the base configuration. The other options are parsed but not used. Any valid configuration may have "disabled" added to it.

Engine Configuration

• Preprocessor name: frag3_engine

• Available options: NOTE: Engine configuration options are space separated.

• timeout seconds - Timeout for fragments. Fragments in the engine for longer than this period will be automatically dropped. Default is 60 seconds.

• min_ttl value - Minimum acceptable TTL value for a fragment packet. Default is 1. The accepted range for this option is 1 - 255.

• detect_anomalies - Detect fragment anomalies.

• bind_to ip_list - IP List to bind this engine to. This engine will only run for packets with destination addresses contained within the IP List. Default value is all.

• overlap_limit <number> - Limits the number of overlapping fragments per packet. The default is "0" (unlimited). This config option takes values equal to or greater than zero. This is an optional parameter. detect_anomalies option must be configured for this option to take effect.

• min_fragment_length <number> - Defines smallest fragment size (payload size) that should be considered valid. Fragments smaller than or equal to this limit are considered malicious and an event is raised, if detect_anomalies is also configured. The default is "0" (unlimited), the minimum is "0". This is an optional parameter. detect_anomalies option must be configured for this option to take effect.

• policy type - Select a target-based defragmentation mode. Available types are first, last, bsd, bsd-right, linux, windows and solaris. Default type is bsd.

The Paxson Active Mapping paper introduced the terminology frag3 is using to describe policy types. The known mappings are as follows. Anyone who develops more mappings and would like to add to this list please feel free to send us an email!

Platform Type
AIX 2 BSD
AIX 4.3 8.9.3 BSD
Cisco IOS Last
FreeBSD BSD
HP JetDirect (printer) BSD-right
HP-UX B.10.20 BSD
HP-UX 11.00 First
IRIX 4.0.5F BSD
IRIX 6.2 BSD
IRIX 6.3 BSD
IRIX64 6.4 BSD
Linux 2.2.10 linux
Linux 2.2.14-5.0 linux
Linux 2.2.16-3 linux
Linux 2.2.19-6.2.10smp linux
Linux 2.4.7-10 linux
Linux 2.4.9-31SGI 1.0.2smp linux
Linux 2.4 (RedHat 7.1-7.3) linux
MacOS (version unknown) First
NCD Thin Clients BSD
OpenBSD (version unknown) linux
OpenBSD (version unknown) linux
OpenVMS 7.1 BSD
OS/2 (version unknown) BSD
OSF1 V3.0 BSD
OSF1 V3.2 BSD
OSF1 V4.0,5.0,5.1 BSD
SunOS 4.1.4 BSD
SunOS 5.5.1,5.6,5.7,5.8 First
Tru64 Unix V5.0A,V5.1 BSD
Vax/VMS BSD
Windows (95/98/NT4/W2K/XP) Windows

### 2.2.1.2 Format

Note in the advanced configuration below that there are three engines specified running with Linux, first and last policies assigned. The first two engines are bound to specific IP address ranges and the last one applies to all other traffic. Packets that don't fall within the address requirements of the first two engines automatically fall through to the third one.

#### 2.2.1.2.1 Basic Configuration

    preprocessor frag3_global
preprocessor frag3_engine


    preprocessor frag3_global: prealloc_nodes 8192
preprocessor frag3_engine: policy linux bind_to 192.168.1.0/24
preprocessor frag3_engine: policy first bind_to [10.1.47.0/24,172.16.8.0/24]
preprocessor frag3_engine: policy last detect_anomalies


### 2.2.1.3 Frag 3 Alert Output

Frag3 is capable of detecting eight different types of anomalies. Its event output is packet-based so it will work with all output modes of Snort. Read the documentation in the doc/signatures directory with filenames that begin with 123-'' for information on the different event types.

## 2.2.2 Session

The Session preprocessor is a global stream session management module for Snort. It is derived from the session management functions that were part of the Stream5 preprocessor.

Since Session implements part of the functionality and API that was previously in Stream5 it cannot be used with Stream5 but must be used in conjunction with the new Stream preprocessor. Similarly, due to the API changes, the other preprocessors in Snort 2.9.7 work only with the new Session and Stream preprocessers.

### 2.2.2.1 Session API

Session provides an API to enable the creation and management of the session control block for a flow and the management of data and state that may be associated with that flow by service and application preprocessors (most of these functions were previously supported by the Stream5 API). These methods are called to identify sessions that may be ignored (large data transfers, etc), and update the identifying information about the session (application protocol, direction, etc) that can later be used by rules. API methods to enable preprocessors to register for dispatch for ports and services for which they should be called to process the packet have been added to the Session API. Session is required for the use of the 'flow' and 'flowbits' keywords.

### 2.2.2.2 Session Global Configuration

Global settings for the Session preprocessor.

    preprocessor stream5_global: \
[track_tcp <yes|no>], [max_tcp <number>], \
[memcap <number bytes>], \
[track_udp <yes|no>], [max_udp <number>], \
[track_icmp <yes|no>], [max_icmp <number>], \
[track_ip <yes|no>], [max_ip <number>], \
[prune_log_max <number bytes>], [disabled], \
[enable_ha]


Option Description
track_tcp <yes|no>

Track sessions for TCP. The default is "yes".

max_tcp <num sessions>

Maximum simultaneous TCP sessions tracked. The default is "262144", maximum is "1048576", minimum is "2".

memcap <num bytes>

Memcap for TCP packet storage. The default is "8388608" (8MB), maximum is "1073741824" (1GB), minimum is "32768" (32KB).

track_udp <yes|no>

Track sessions for UDP. The default is "yes".

max_udp <num sessions>

Maximum simultaneous UDP sessions tracked. The default is "131072", maximum is "1048576", minimum is "1".

track_icmp <yes|no>

Track sessions for ICMP. The default is "no".

max_icmp <num sessions>

Maximum simultaneous ICMP sessions tracked. The default is "65536", maximum is "1048576", minimum is "1".

track_ip <yes|no>

Track sessions for IP. The default is "no". Note that "IP" includes all non-TCP/UDP traffic over IP including ICMP if ICMP not otherwise configured.

max_ip <num sessions>

Maximum simultaneous IP sessions tracked. The default is "16384", maximum is "1048576", minimum is "1".

disabled

Option to disable the stream5 tracking. By default this option is turned off. When the preprocessor is disabled only the options memcap, max_tcp, max_udp and max_icmp are applied when specified with the configuration.

Backwards compatibility. Flush a TCP stream when an alert is generated on that stream. The default is set to off.

show_rebuilt_packets

Print/display packet after rebuilt (for debugging). The default is set to off.

prune_log_max <num bytes>

Print a message when a session terminates that was consuming more than the specified number of bytes. The default is "1048576" (1MB), minimum can be either "0" (disabled) or if not disabled the minimum is "1024" and maximum is "1073741824".

enable_ha

Enable High Availability state sharing. The default is set to off.

### 2.2.2.3 Session HA Configuration

Configuration for HA session state sharing.

    preprocessor stream5_ha: [min_session_lifetime <num millisecs>], \
[min_sync_interval <num millisecs>], [startup_input_file <filename>], \
[runtime_output_file <filename>], [use_side_channel]


Option Description

Minimum session liftime in milliseconds. HA update messages will only be generated once a session has existed for at least this long. The default is 0, the minimum is 0, and the maximum is 65535.

min_sync_interval <num millisecs>

Minimum synchronization interval in milliseconds. HA update messages will not be generated more often than once per interval on a given session. The default is 0, the minimum is 0, and the maximum is 65535.

startup_input_file <filename>

The name of a file for snort to read HA messages from at startup.

runtime_output_file <filename>

The name of a file to which Snort will write all HA messages that are generated while it is running.

use_side_channel

Indicates that all HA messages should also be sent to the side channel for processing.

### 2.2.2.4 Example Configurations

1. This example configuration sets a maximum number of TCP session control blocks to 8192, enables tracking of TCP and UPD sessions, and disables tracking of ICMP sessions. The number of UDP session control blocks will be set to the compiled default.

    preprocessor stream5_global: \
max_tcp 8192, track_tcp yes, track_udp yes, track_icmp no

preprocessor stream5_tcp: \
policy first, use_static_footprint_sizes

preprocessor stream5_udp: \
ignore_any_rules


## 2.2.3 Stream

The Stream preprocessor is a target-based TCP reassembly module for Snort. It is capable of tracking sessions for both TCP and UDP.

### 2.2.3.1 Transport Protocols

TCP sessions are identified via the classic TCP "connection". UDP sessions are established as the result of a series of UDP packets from two end points via the same set of ports. ICMP messages are tracked for the purposes of checking for unreachable and service unavailable messages, which effectively terminate a TCP or UDP session.

### 2.2.3.2 Target-Based

Stream, like Frag3, introduces target-based actions for handling of overlapping data and other TCP anomalies. The methods for handling overlapping data, TCP Timestamps, Data on SYN, FIN and Reset sequence numbers, etc. and the policies supported by Stream are the results of extensive research with many target operating systems.

### 2.2.3.3 Stream API

Stream supports the modified Stream API that is now focused on functions specific to reassembly and protocol aware flushing operations. Session management functions have been moved to the Session API. The remaining API functions enable other protocol normalizers/preprocessors to dynamically configure reassembly behavior as required by the application layer protocol.

### 2.2.3.4 Anomaly Detection

TCP protocol anomalies, such as data on SYN packets, data received outside the TCP window, etc are configured via the detect_anomalies option to the TCP configuration. Some of these anomalies are detected on a per-target basis. For example, a few operating systems allow data in TCP SYN packets, while others do not.

### 2.2.3.5 Protocol Aware Flushing

Protocol aware flushing of HTTP, SMB and DCE/RPC can be enabled with this option:

config paf_max: <max-pdu>


where <max-pdu> is between zero (off) and 63780. This allows Snort to statefully scan a stream and reassemble a complete PDU regardless of segmentation. For example, multiple PDUs within a single TCP segment, as well as one PDU spanning multiple TCP segments will be reassembled into one PDU per packet for each PDU. PDUs larger than the configured maximum will be split into multiple packets.

### 2.2.3.6 Stream TCP Configuration

Provides a means on a per IP address target to configure TCP policy. This can have multiple occurrences, per policy that is bound to an IP address or network. One default policy must be specified, and that policy is not bound to an IP address or network.

    preprocessor stream5_tcp: \
[log_asymmetric_traffic <yes|no>], \
[timeout <number secs>], [policy <policy_id>], \
[overlap_limit <number>], [max_window <number>], \
[require_3whs [<number secs>]], [detect_anomalies], \
[check_session_hijacking], [use_static_footprint_sizes], \
[dont_store_large_packets], [dont_reassemble_async], \
[max_queued_bytes <bytes>], [max_queued_segs <number segs>], \
[small_segments <number> bytes <number> [ignore_ports number [number]*]],  \
[ports <client|server|both> <all|number|!number [number]* [!number]*>], \
[protocol <client|server|both> <all|service name [service name]*>], \
[ignore_any_rules], [flush_factor <number segs>]


Option Description

IP address or network for this policy. The default is set to any.

timeout <num seconds>

Session timeout. The default is "30", the minimum is "1", and the maximum is "86400" (approximately 1 day).

policy <policy_id>

The Operating System policy for the target OS. The policy_id can be one of the following:

 Policy Name Operating Systems. first Favor first overlapped segment. last Favor last overlapped segment. bsd FresBSD 4.x and newer, NetBSD 2.x and newer, OpenBSD 3.x and newer linux Linux 2.4 and newer old-linux Linux 2.2 and earlier windows Windows 2000, Windows XP, Windows 95/98/ME win2003 Windows 2003 Server vista Windows Vista solaris Solaris 9.x and newer hpux HPUX 11 and newer hpux10 HPUX 10 irix IRIX 6 and newer macos MacOS 10.3 and newer

overlap_limit <number>

Limits the number of overlapping packets per session. The default is "0" (unlimited), the minimum is "0", and the maximum is "255".

max_window <number>

Maximum TCP window allowed. The default is "0" (unlimited), the minimum is "0", and the maximum is "1073725440" (65535 left shift 14). That is the highest possible TCP window per RFCs. This option is intended to prevent a DoS against Stream by an attacker using an abnormally large window, so using a value near the maximum is discouraged.

require_3whs [<number seconds>]

Establish sessions only on completion of a SYN/SYN-ACK/ACK handshake. The default is set to off. The optional number of seconds specifies a startup timeout. This allows a grace period for existing sessions to be considered established during that interval immediately after Snort is started. The default is "0" (don't consider existing sessions established), the minimum is "0", and the maximum is "86400" (approximately 1 day).

detect_anomalies

Detect and alert on TCP protocol anomalies. The default is set to off.

check_session_hijacking

Check for TCP session hijacking. This check validates the hardware (MAC) address from both sides of the connect - as established on the 3-way handshake against subsequent packets received on the session. If an ethernet layer is not part of the protocol stack received by Snort, there are no checks performed. Alerts are generated (per 'detect_anomalies' option) for either the client or server when the MAC address for one side or the other does not match. The default is set to off.

use_static_footprint_sizes

Use static values for determining when to build a reassembled packet to allow for repeatable tests. This option should not be used production environments. The default is set to off.

dont_store_large_packets

Performance improvement to not queue large packets in reassembly buffer. The default is set to off. Using this option may result in missed attacks.

dont_reassemble_async

Don't queue packets for reassembly if traffic has not been seen in both directions. The default is set to queue packets.

max_queued_bytes <bytes>

Limit the number of bytes queued for reassembly on a given TCP session to bytes. Default is "1048576" (1MB). A value of "0" means unlimited, with a non-zero minimum of "1024", and a maximum of "1073741824" (1GB). A message is written to console/syslog when this limit is enforced.

max_queued_segs <num>

Limit the number of segments queued for reassembly on a given TCP session. The default is "2621", derived based on an average size of 400 bytes. A value of "0" means unlimited, with a non-zero minimum of "2", and a maximum of "1073741824" (1GB). A message is written to console/syslog when this limit is enforced.

small_segments <number> bytes <number> [ignore_ports <number(s)> ]

Configure the maximum small segments queued. This feature requires that detect_anomalies be enabled. The first number is the number of consecutive segments that will trigger the detection rule. The default value is "0" (disabled), with a maximum of "2048". The second number is the minimum bytes for a segment to be considered "small". The default value is "0" (disabled), with a maximum of "2048". ignore_ports is optional, defines the list of ports in which will be ignored for this rule. The number of ports can be up to "65535". A message is written to console/syslog when this limit is enforced.

ports <client|server|both> <all|number(s)|!number(s)>

Specify the client, server, or both and list of ports in which to perform reassembly. This can appear more than once in a given config. The default settings are ports client 21 23 25 42 53 80 110 111 135 136 137 139 143 445 513 514 1433 1521 2401 3306. The minimum port allowed is "1" and the maximum allowed is "65535". To disable reassembly for a port specifiy the port number preceeded by an '!', e.g. !8080 !25

protocol <client|server|both> <all|service name(s)>

Specify the client, server, or both and list of services in which to perform reassembly. This can appear more than once in a given config. The default settings are ports client ftp telnet smtp nameserver dns http pop3 sunrpc dcerpc netbios-ssn imap login shell mssql oracle cvs mysql. The service names can be any of those used in the host attribute table (see ), including any of the internal defaults (see ) or others specific to the network.

ignore_any_rules

Don't process any -> any (ports) rules for TCP that attempt to match payload if there are no port specific rules for the src or destination port. Rules that have flow or flowbits will never be ignored. This is a performance improvement and may result in missed attacks. Using this does not affect rules that look at protocol headers, only those with content, PCRE, or byte test options. The default is "off". This option can be used only in default policy.

flush_factor

Useful in ips mode to flush upon seeing a drop in segment size after N segments of non-decreasing size. The drop in size often indicates an end of request or response.

 Note:   If no options are specified for a given TCP policy, that is the default TCP policy. If only a bind_to option is used with no other options that TCP policy uses all of the default values.

### 2.2.3.7 Stream UDP Configuration

Configuration for UDP session tracking. Since there is no target based binding, there should be only one occurrence of the UDP configuration.

    preprocessor stream5_udp: [timeout <number secs>], [ignore_any_rules]


Option Description
timeout <num seconds>

Session timeout. The default is "30", the minimum is "1", and the maximum is "86400" (approximately 1 day).

ignore_any_rules

Don't process any -> any (ports) rules for UDP that attempt to match payload if there are no port specific rules for the src or destination port. Rules that have flow or flowbits will never be ignored. This is a performance improvement and may result in missed attacks. Using this does not affect rules that look at protocol headers, only those with content, PCRE, or byte test options. The default is "off".

 Note:   With the ignore_any_rules option, a UDP rule will be ignored except when there is another port specific rule that may be applied to the traffic. For example, if a UDP rule specifies destination port 53, the 'ignored' any -> any rule will be applied to traffic to/from port 53, but NOT to any other source or destination port. A list of rule SIDs affected by this option are printed at Snort's startup.

 Note:   With the ignore_any_rules option, if a UDP rule that uses any -> any ports includes either flow or flowbits, the ignore_any_rules option is effectively pointless. Because of the potential impact of disabling a flowbits rule, the ignore_any_rules option will be disabled in this case.

### 2.2.3.8 Stream ICMP Configuration

Configuration for ICMP session tracking. Since there is no target based binding, there should be only one occurrence of the ICMP configuration.

 Note:   ICMP is currently untested, in minimal code form and is NOT ready for use in production networks. It is not turned on by default.

    preprocessor stream5_icmp: [timeout <number secs>]


Option Description
timeout <num seconds>

Session timeout. The default is "30", the minimum is "1", and the maximum is "86400" (approximately 1 day).

### 2.2.3.9 Stream IP Configuration

Configuration for IP session tracking. Since there is no target based binding, there should be only one occurrence of the IP configuration.

 Note:   "IP" includes all non-TCP/UDP traffic over IP including ICMP if ICMP not otherwise configured. It is not turned on by default.

    preprocessor stream5_ip: [timeout <number secs>]


Option Description
timeout <num seconds>

Session timeout. The default is "30", the minimum is "1", and the maximum is "86400" (approximately 1 day).

### 2.2.3.10 Example Configurations

1. This example configuration is the default configuration in snort.conf and can be used for repeatable tests of stream reassembly in readback mode.

    preprocessor stream5_global: \
max_tcp 8192, track_tcp yes, track_udp yes, track_icmp no

preprocessor stream5_tcp: \
policy first, use_static_footprint_sizes

preprocessor stream5_udp: \
ignore_any_rules


2. This configuration maps two network segments to different OS policies, one for Windows and one for Linux, with all other traffic going to the default policy of Solaris.

    preprocessor stream5_global: track_tcp yes
preprocessor stream5_tcp: bind_to 192.168.1.0/24, policy windows
preprocessor stream5_tcp: bind_to 10.1.1.0/24, policy linux
preprocessor stream5_tcp: policy solaris


## 2.2.4 sfPortscan

The sfPortscan module, developed by Sourcefire, is designed to detect the first phase in a network attack: Reconnaissance. In the Reconnaissance phase, an attacker determines what types of network protocols or services a host supports. This is the traditional place where a portscan takes place. This phase assumes the attacking host has no prior knowledge of what protocols or services are supported by the target; otherwise, this phase would not be necessary.

As the attacker has no beforehand knowledge of its intended target, most queries sent by the attacker will be negative (meaning that the service ports are closed). In the nature of legitimate network communications, negative responses from hosts are rare, and rarer still are multiple negative responses within a given amount of time. Our primary objective in detecting portscans is to detect and track these negative responses.

One of the most common portscanning tools in use today is Nmap. Nmap encompasses many, if not all, of the current portscanning techniques. sfPortscan was designed to be able to detect the different types of scans Nmap can produce.

sfPortscan will currently alert for the following types of Nmap scans:

• TCP Portscan
• UDP Portscan
• IP Portscan

These alerts are for oneone portscans, which are the traditional types of scans; one host scans multiple ports on another host. Most of the port queries will be negative, since most hosts have relatively few services available.

sfPortscan also alerts for the following types of decoy portscans:

• TCP Decoy Portscan
• UDP Decoy Portscan
• IP Decoy Portscan

Decoy portscans are much like the Nmap portscans described above, only the attacker has a spoofed source address inter-mixed with the real scanning address. This tactic helps hide the true identity of the attacker.

sfPortscan alerts for the following types of distributed portscans:

• TCP Distributed Portscan
• UDP Distributed Portscan
• IP Distributed Portscan

These are manyone portscans. Distributed portscans occur when multiple hosts query one host for open services. This is used to evade an IDS and obfuscate command and control hosts.

 Note:   Negative queries will be distributed among scanning hosts, so we track this type of scan through the scanned host.

sfPortscan alerts for the following types of portsweeps:

• TCP Portsweep
• UDP Portsweep
• IP Portsweep
• ICMP Portsweep

These alerts are for onemany portsweeps. One host scans a single port on multiple hosts. This usually occurs when a new exploit comes out and the attacker is looking for a specific service.

 Note:   The characteristics of a portsweep scan may not result in many negative responses. For example, if an attacker portsweeps a web farm for port 80, we will most likely not see many negative responses.

sfPortscan alerts on the following filtered portscans and portsweeps:

• TCP Filtered Portscan
• UDP Filtered Portscan
• IP Filtered Portscan

• TCP Filtered Decoy Portscan
• UDP Filtered Decoy Portscan
• IP Filtered Decoy Portscan

• TCP Filtered Portsweep
• UDP Filtered Portsweep
• IP Filtered Portsweep
• ICMP Filtered Portsweep

• TCP Filtered Distributed Portscan
• UDP Filtered Distributed Portscan
• IP Filtered Distributed Portscan

Filtered'' alerts indicate that there were no network errors (ICMP unreachables or TCP RSTs) or responses on closed ports have been suppressed. It's also a good indicator of whether the alert is just a very active legitimate host. Active hosts, such as NATs, can trigger these alerts because they can send out many connection attempts within a very small amount of time. A filtered alert may go off before responses from the remote hosts are received.

sfPortscan only generates one alert for each host pair in question during the time window (more on windows below). On TCP scan alerts, sfPortscan will also display any open ports that were scanned. On TCP sweep alerts however, sfPortscan will only track open ports after the alert has been triggered. Open port events are not individual alerts, but tags based on the original scan alert.

### 2.2.4.1 sfPortscan Configuration

Use of the Stream preprocessor is required for sfPortscan. Stream gives portscan direction in the case of connectionless protocols like ICMP and UDP. You should enable the Stream preprocessor in your snort.conf, as described in Section .

The parameters you can use to configure the portscan module are:

8.
proto protocol

Available options:

• TCP
• UDP
• ICMP
• ip_proto
• all

9.
scan_type scan_type

Available options:

• portscan
• portsweep
• decoy_portscan
• distributed_portscan
• all

10.
sense_level level

Available options:

• low - Low'' alerts are only generated on error packets sent from the target host, and because of the nature of error responses, this setting should see very few false positives. However, this setting will never trigger a Filtered Scan alert because of a lack of error responses. This setting is based on a static time window of 60 seconds, after which this window is reset.

• medium - Medium'' alerts track connection counts, and so will generate filtered scan alerts. This setting may false positive on active hosts (NATs, proxies, DNS caches, etc), so the user may need to deploy the use of Ignore directives to properly tune this directive.

• high - High'' alerts continuously track hosts on a network using a time window to evaluate portscan statistics for that host. A "High" setting will catch some slow scans because of the continuous monitoring, but is very sensitive to active hosts. This most definitely will require the user to tune sfPortscan.

11.
watch_ip ip1ip2/cidr[ [portport2-port3]]

Defines which IPs, networks, and specific ports on those hosts to watch. The list is a comma separated list of IP addresses, IP address using CIDR notation. Optionally, ports are specified after the IP address/CIDR using a space and can be either a single port or a range denoted by a dash. IPs or networks not falling into this range are ignored if this option is used.

12.
ignore_scanners ip1ip2/cidr[ [portport2-port3]]

Ignores the source of scan alerts. The parameter is the same format as that of watch_ip.

13.
ignore_scanned ip1ip2/cidr[ [portport2-port3]]

Ignores the destination of scan alerts. The parameter is the same format as that of watch_ip.

14.
logfile file

This option will output portscan events to the file specified. If file does not contain a leading slash, this file will be placed in the Snort config dir.

15.
include_midstream

This option will include sessions picked up in midstream by Stream. This can lead to false alerts, especially under heavy load with dropped packets; which is why the option is off by default.

16.
detect_ack_scans

This option will include sessions picked up in midstream by the stream module, which is necessary to detect ACK scans. However, this can lead to false alerts, especially under heavy load with dropped packets; which is why the option is off by default.

17.
disabled

This optional keyword is allowed with any policy to avoid packet processing. This option disables the preprocessor. When the preprocessor is disabled only the memcap option is applied when specified with the configuration. The other options are parsed but not used. Any valid configuration may have "disabled" added to it.

### 2.2.4.2 Format

    preprocessor sfportscan: proto <protocols> \
scan_type <portscan|portsweep|decoy_portscan|distributed_portscan|all> \
sense_level <low|medium|high> \
watch_ip <IP or IP/CIDR> \
ignore_scanners <IP list> \
ignore_scanned <IP list> \
logfile <path and filename> \
disabled


### 2.2.4.3 Example

    preprocessor flow: stats_interval 0 hash 2
preprocessor sfportscan:\
proto { all } \
scan_type { all } \
sense_level { low }


#### 2.2.4.4.1 Unified Output

In order to get all the portscan information logged with the alert, snort generates a pseudo-packet and uses the payload portion to store the additional portscan information of priority count, connection count, IP count, port count, IP range, and port range. The characteristics of the packet are:

    Src/Dst MAC Addr == MACDAD
IP Protocol == 255
IP TTL == 0


Other than that, the packet looks like the IP portion of the packet that caused the portscan alert to be generated. This includes any IP options, etc. The payload and payload size of the packet are equal to the length of the additional portscan information that is logged. The size tends to be around 100 - 200 bytes.

Open port alerts differ from the other portscan alerts, because open port alerts utilize the tagged packet output system. This means that if an output system that doesn't print tagged packets is used, then the user won't see open port alerts. The open port information is stored in the IP payload and contains the port that is open.

The sfPortscan alert output was designed to work with unified2 packet logging, so it is possible to extend favorite Snort GUIs to display portscan alerts and the additional information in the IP payload using the above packet characteristics.

#### 2.2.4.4.2 Log File Output

Log file output is displayed in the following format, and explained further below:

    Time: 09/08-15:07:31.603880
event_id: 2
192.168.169.3 -> 192.168.169.5 (portscan) TCP Filtered Portscan
Priority Count: 0
Connection Count: 200
IP Count: 2
Scanner IP Range: 192.168.169.3:192.168.169.4
Port/Proto Count: 200
Port/Proto Range: 20:47557


If there are open ports on the target, one or more additional tagged packet(s) will be appended:

    Time: 09/08-15:07:31.603881
event_ref: 2
192.168.169.3 -> 192.168.169.5 (portscan) Open Port
Open Port: 38458


18.
Event_id/Event_ref

These fields are used to link an alert with the corresponding Open Port tagged packet

19.
Priority Count

Priority Count keeps track of bad responses (resets, unreachables). The higher the priority count, the more bad responses have been received.

20.
Connection Count

Connection Count lists how many connections are active on the hosts (src or dst). This is accurate for connection-based protocols, and is more of an estimate for others. Whether or not a portscan was filtered is determined here. High connection count and low priority count would indicate filtered (no response received from target).

21.
IP Count

IP Count keeps track of the last IP to contact a host, and increments the count if the next IP is different. For one-to-one scans, this is a low number. For active hosts this number will be high regardless, and one-to-one scans may appear as a distributed scan.

22.
Scanned/Scanner IP Range

This field changes depending on the type of alert. Portsweep (one-to-many) scans display the scanned IP range; Portscans (one-to-one) display the scanner IP.

23.
Port Count

Port Count keeps track of the last port contacted and increments this number when that changes. We use this count (along with IP Count) to determine the difference between one-to-one portscans and one-to-one decoys.

### 2.2.4.5 Tuning sfPortscan

The most important aspect in detecting portscans is tuning the detection engine for your network(s). Here are some tuning tips:

24.
Use the watch_ip, ignore_scanners, and ignore_scanned options.

It's important to correctly set these options. The watch_ip option is easy to understand. The analyst should set this option to the list of CIDR blocks and IPs that they want to watch. If no watch_ip is defined, sfPortscan will watch all network traffic.

The ignore_scanners and ignore_scanned options come into play in weeding out legitimate hosts that are very active on your network. Some of the most common examples are NAT IPs, DNS cache servers, syslog servers, and nfs servers. sfPortscan may not generate false positives for these types of hosts, but be aware when first tuning sfPortscan for these IPs. Depending on the type of alert that the host generates, the analyst will know which to ignore it as. If the host is generating portsweep events, then add it to the ignore_scanners option. If the host is generating portscan alerts (and is the host that is being scanned), add it to the ignore_scanned option.

25.
Filtered scan alerts are much more prone to false positives.

When determining false positives, the alert type is very important. Most of the false positives that sfPortscan may generate are of the filtered scan alert type. So be much more suspicious of filtered portscans. Many times this just indicates that a host was very active during the time period in question. If the host continually generates these types of alerts, add it to the ignore_scanners list or use a lower sensitivity level.

26.
Make use of the Priority Count, Connection Count, IP Count, Port Count, IP Range, and Port Range to determine false positives.

The portscan alert details are vital in determining the scope of a portscan and also the confidence of the portscan. In the future, we hope to automate much of this analysis in assigning a scope level and confidence level, but for now the user must manually do this. The easiest way to determine false positives is through simple ratio estimations. The following is a list of ratios to estimate and the associated values that indicate a legitimate scan and not a false positive.

Connection Count / IP Count: This ratio indicates an estimated average of connections per IP. For portscans, this ratio should be high, the higher the better. For portsweeps, this ratio should be low.

Port Count / IP Count: This ratio indicates an estimated average of ports connected to per IP. For portscans, this ratio should be high and indicates that the scanned host's ports were connected to by fewer IPs. For portsweeps, this ratio should be low, indicating that the scanning host connected to few ports but on many hosts.

Connection Count / Port Count: This ratio indicates an estimated average of connections per port. For portscans, this ratio should be low. This indicates that each connection was to a different port. For portsweeps, this ratio should be high. This indicates that there were many connections to the same port.

The reason that Priority Count is not included, is because the priority count is included in the connection count and the above comparisons take that into consideration. The Priority Count play an important role in tuning because the higher the priority count the more likely it is a real portscan or portsweep (unless the host is firewalled).

27.
If all else fails, lower the sensitivity level.

If none of these other tuning techniques work or the analyst doesn't have the time for tuning, lower the sensitivity level. You get the best protection the higher the sensitivity level, but it's also important that the portscan detection engine generate alerts that the analyst will find informative. The low sensitivity level only generates alerts based on error responses. These responses indicate a portscan and the alerts generated by the low sensitivity level are highly accurate and require the least tuning. The low sensitivity level does not catch filtered scans; since these are more prone to false positives.

## 2.2.5 RPC Decode

The rpc_decode preprocessor normalizes RPC multiple fragmented records into a single un-fragmented record. It does this by normalizing the packet into the packet buffer. If stream5 is enabled, it will only process client-side traffic. By default, it runs against traffic on ports 111 and 32771.

### 2.2.5.1 Format

    preprocessor rpc_decode: \


Option Description

Alert on any fragmented RPC record.

Don't alert when there are multiple records in one packet.

Don't alert when the sum of fragmented records exceeds one packet.

Don't alert when a single fragment record exceeds the size of one packet.

## 2.2.6 Performance Monitor

This preprocessor measures Snort's real-time and theoretical maximum performance. Whenever this preprocessor is turned on, it should have an output mode enabled, either console'' which prints statistics to the console window or file'' with a file name, where statistics get printed to the specified file name. By default, Snort's real-time statistics are processed. This includes:

• Time Stamp
• Drop Rate
• Mbits/Sec (wire) [duplicated below for easy comparison with other rates]
• K-Pkts/Sec (wire) [duplicated below for easy comparison with other rates]
• Avg Bytes/Pkt (wire) [duplicated below for easy comparison with other rates]
• Pat-Matched [percent of data received that Snort processes in pattern matching]
• Syns/Sec
• SynAcks/Sec
• New Sessions Cached/Sec
• Sessions Del fr Cache/Sec
• Current Cached Sessions
• Max Cached Sessions
• Stream Flushes/Sec
• Stream Session Cache Faults
• Stream Session Cache Timeouts
• New Frag Trackers/Sec
• Frag-Completes/Sec
• Frag-Inserts/Sec
• Frag-Deletes/Sec
• Frag-Auto Deletes/Sec [memory DoS protection]
• Frag-Flushes/Sec
• Frag-Current [number of current Frag Trackers]
• Frag-Max [max number of Frag Trackers at any time]
• Frag-Timeouts
• Frag-Faults
• Number of CPUs [*** Only if compiled with LINUX_SMP ***, the next three appear for each CPU]
• CPU usage (user)
• CPU usage (sys)
• CPU usage (Idle)
• Mbits/Sec (wire) [average mbits of total traffic]
• Mbits/Sec (ipfrag) [average mbits of IP fragmented traffic]
• Mbits/Sec (ipreass) [average mbits Snort injects after IP reassembly]
• Mbits/Sec (tcprebuilt) [average mbits Snort injects after TCP reassembly]
• Mbits/Sec (applayer) [average mbits seen by rules and protocol decoders]
• Avg Bytes/Pkt (wire)
• Avg Bytes/Pkt (ipfrag)
• Avg Bytes/Pkt (ipreass)
• Avg Bytes/Pkt (tcprebuilt)
• Avg Bytes/Pkt (applayer)
• K-Pkts/Sec (wire)
• K-Pkts/Sec (ipfrag)
• K-Pkts/Sec (ipreass)
• K-Pkts/Sec (tcprebuilt)
• K-Pkts/Sec (applayer)
• Total Packets Dropped (not processed)
• Total Packets Blocked (inline)
• Percentage of Packets Dropped
• Total Filtered TCP Packets
• Total Filtered UDP Packets
• Midstream TCP Sessions/Sec
• Closed TCP Sessions/Sec
• Pruned TCP Sessions/Sec
• TimedOut TCP Sessions/Sec
• Dropped Async TCP Sessions/Sec
• TCP Sessions Initializing
• TCP Sessions Established
• TCP Sessions Closing
• Max TCP Sessions (interval)
• New Cached UDP Sessions/Sec
• Cached UDP Ssns Del/Sec
• Current Cached UDP Sessions
• Max Cached UDP Sessions
• Current Attribute Table Hosts (Target Based)
• Attribute Table Reloads (Target Based)
• Mbits/Sec (Snort)
• Mbits/Sec (sniffing)
• Mbits/Sec (combined)
• uSeconds/Pkt (Snort)
• uSeconds/Pkt (sniffing)
• uSeconds/Pkt (combined)
• KPkts/Sec (Snort)
• KPkts/Sec (sniffing)
• KPkts/Sec (combined)

There are over 100 individual statistics included. A header line is output at startup and rollover that labels each column.

The following options can be used with the performance monitor:

• flow - Prints out statistics about the type and amount of traffic and protocol distributions that Snort is seeing. This option can produce large amounts of output.

• flow-file - Prints flow statistics in a comma-delimited format to the file that is specified.
• Timestamp
• Total % TCP bytes
• Total % UDP bytes
• Total % ICMP bytes
• Total % OTHER bytes
• Number of Packet length entries
• Packet length entries - bytes,%total
• Number of TCP port flow entries
• TCP port flow entries : port,%total,%src,%dst
• % TCP high port to high port
• Number of UDP port flow entries
• UDP port flow entries : port,%total,%src,%dst
• % UDP high port to high port
• Number of ICMP type entries
• ICMP type entries : type,%total
Specifying this option implicitly enables flow statistics.

• events - Turns on event reporting. This prints out statistics as to the number of rules that were evaluated and didn't match (non-qualified events) vs. the number of rules that were evaluated and matched (qualified events). A high non-qualified event to qualified event ratio can indicate there are many rules with either minimal content or no content that are being evaluated without success. The fast pattern matcher is used to select a set of rules for evaluation based on the longest content or a content modified with the fast_pattern rule option in a rule. Rules with short, generic contents are more likely to be selected for evaluation than those with longer, more unique contents. Rules without content are not filtered via the fast pattern matcher and are always evaluated, so if possible, adding a content rule option to those rules can decrease the number of times they need to be evaluated and improve performance.

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

• console - Prints statistics at the console.

• file - Prints statistics in a comma-delimited format to the file that is specified. Not all statistics are output to this file. You may also use snortfile which will output into your defined Snort log directory. Both of these directives can be overridden on the command line with the -Z or -perfmon-file options. At startup, Snort will log a distinctive line to this file with a timestamp to all readers to easily identify gaps in the stats caused by Snort not running.

• 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 performance. By default, this is 10000.

• time - Represents the number of seconds between intervals.

• accumulate or reset - Defines which type of drop statistics are kept by the operating system. By default, reset is used.

• atexitonly - Dump stats for entire life of Snort. One or more of the following arguments can be given to specify specific statistic types to dump at exit:
• base-stats
• flow-stats
• flow-ip-stats
• events-stats
Without any arguments, all enabled stats will be dumped only when Snort exits.

• max_file_size - Defines the maximum size of the comma-delimited file. Before the file exceeds this size, it will be rolled into a new date stamped file of the format YYYY-MM-DD, followed by YYYY-MM-DD.x, where x will be incremented each time the comma delimited file is rolled over. The minimum is 4096 bytes and the maximum is 2147483648 bytes (2GB). The default is the same as the maximum.

• flow-ip - Collects IP traffic distribution statistics based on host pairs. For each pair of hosts for which IP traffic has been seen, the following statistics are collected for both directions (A to B and B to A):
• TCP Packets
• TCP Traffic in Bytes
• TCP Sessions Established
• TCP Sessions Closed
• UDP Packets
• UDP Traffic in Bytes
• UDP Sessions Created
• Other IP Packets
• Other IP Traffic in Bytes
These statistics are printed and reset at the end of each interval.

• flow-ip-file - Prints the flow IP statistics in a comma-delimited format to the file that is specified. All of the statistics mentioned above, as well as the IP addresses of the host pairs in human-readable format, are included.

Each line in the file will have its values correspond (in order) to those below:

• TCP Packets from A to B
• TCP Traffic in Bytes from A to B
• TCP Packets from B to A
• TCP Traffic in Bytes from B to A
• UDP Packets from A to B
• UDP Traffic in Bytes from A to B
• UDP Packets from B to A
• UDP Traffic in Bytes from B to A
• Other IP Packets from A to B
• Other IP Traffic in Bytes from A to B
• Other IP Packets from B to A
• Other IP Traffic in Bytes from B to A
• TCP Sessions Established
• TCP Sessions Closed
• UDP Sessions Created

• flow-ip-memcap - Sets the memory cap on the hash table used to store IP traffic statistics for host pairs. Once the cap has been reached, the table will start to prune the statistics for the least recently seen host pairs to free memory. This value is in bytes and the default value is 52428800 (50MB).

### 2.2.6.1 Examples

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

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

preprocessor perfmonitor: \
time 30 flow-ip flow-ip-file flow-ip-stats.csv pktcnt 1000

preprocessor perfmonitor: \
time 30 pktcnt 1000 snortfile base.csv flow-file flows.csv atexitonly flow-stats

preprocessor perfmonitor: \
time 30 pktcnt 1000 flow events atexitonly base-stats flow-stats console


## 2.2.7 HTTP Inspect

HTTP Inspect is a generic HTTP decoder for user applications. Given a data buffer, HTTP Inspect will decode the buffer, find HTTP fields, and normalize the fields. HTTP Inspect works on both client requests and server responses.

HTTP Inspect has a very rich'' user configuration. Users can configure individual HTTP servers with a variety of options, which should allow the user to emulate any type of web server. Within HTTP Inspect, there are two areas of configuration: global and server.

### 2.2.7.1 Global Configuration

The global configuration deals with configuration options that determine the global functioning of HTTP Inspect. The following example gives the generic global configuration format:

### 2.2.7.2 Format

    preprocessor http_inspect: \
global \
iis_unicode_map <map_filename> \
codemap <integer> \
[detect_anomalous_servers] \
[max_gzip_mem <num>] \
[compress_depth <num>] [decompress_depth <num>] \
[memcap <num>] \
disabled


You can only have a single global configuration, you'll get an error if you try otherwise.

#### 2.2.7.2.1 Configuration

28.
iis_unicode_map map_filename [codemap integer]

This is the global iis_unicode_map file. The iis_unicode_map is a required configuration parameter. The map file can reside in the same directory as snort.conf or be specified via a fully-qualified path to the map file.

The iis_unicode_map file is a Unicode codepoint map which tells HTTP Inspect which codepage to use when decoding Unicode characters. For US servers, the codemap is usually 1252.

A Microsoft US Unicode codepoint map is provided in the Snort source etc directory by default. It is called unicode.map and should be used if no other codepoint map is available. A tool is supplied with Snort to generate custom Unicode maps-ms_unicode_generator.c, which is available at http://www.snort.org/dl/contrib/.

 Note:   Remember that this configuration is for the global IIS Unicode map, individual servers can reference their own IIS Unicode map.

29.
detect_anomalous_servers

This global configuration option enables generic HTTP server traffic inspection on non-HTTP configured ports, and alerts if HTTP traffic is seen. Don't turn this on if you don't have a default server configuration that encompasses all of the HTTP server ports that your users might access. In the future, we want to limit this to specific networks so it's more useful, but for right now, this inspects all network traffic. This option is turned off by default.

30.

This enables global alerting on HTTP server proxy usage. By configuring HTTP Inspect servers and enabling allow_proxy_use, you will only receive proxy use alerts for web users that aren't using the configured proxies or are using a rogue proxy server.

Please note that if users aren't required to configure web proxy use, then you may get a lot of proxy alerts. So, please only use this feature with traditional proxy environments. Blind firewall proxies don't count.

31.
compress_depth integer This option specifies the maximum amount of packet payload to decompress. This value can be set from 1 to 65535. The default for this option is 1460.

 Note:   Please note, in case of multiple policies, the value specified in the default policy is used and this value overwrites the values specified in the other policies. In case of unlimited_decompress this should be set to its max value. This value should be specified in the default policy even when the HTTP inspect preprocessor is turned off using the disabled keyword.

32.
decompress_depth integer This option specifies the maximum amount of decompressed data to obtain from the compressed packet payload. This value can be set from 1 to 65535. The default for this option is 2920.

 Note:   Please note, in case of multiple policies, the value specified in the default policy is used and this value overwrites the values specified in the other policies. In case of unlimited_decompress this should be set to its max value. This value should be specified in the default policy even when the HTTP inspect preprocessor is turned off using the disabled keyword.

33.
max_gzip_mem integer

This option determines (in bytes) the maximum amount of memory the HTTP Inspect preprocessor will use for decompression. The minimum allowed value for this option is 3276 bytes. This option determines the number of concurrent sessions that can be decompressed at any given instant. The default value for this option is 838860.

This value is also used for the optional SWF/PDF file decompression. If these modes are enabled this same value sets the maximum about of memory used for file decompression session state information.

 Note:   This value should be specified in the default policy even when the HTTP inspect preprocessor is turned off using the disabled keyword.

34.
memcap integer

This option determines (in bytes) the maximum amount of memory the HTTP Inspect preprocessor will use for logging the URI and Hostname data. This value can be set from 2304 to 603979776 (576 MB). This option along with the maximum uri and hostname logging size (which is defined in snort) will determine the maximum HTTP sessions that will log the URI and hostname data at any given instant. The maximum size for logging URI data is 2048 and for hostname is 256. The default value for this option is 150994944 (144 MB).

 Note:   This value should be specified in the default policy even when the HTTP inspect preprocessor is turned off using the disabled keyword. In case of multiple policies, the value specified in the default policy will overwrite the value specified in other policies. max http sessions logged = memcap /( max uri logging size + max hostname logging size ) max uri logging size defined in snort : 2048 max hostname logging size defined in snort : 256

35.
disabled

This optional keyword is allowed with any policy to avoid packet processing. This option disables the preprocessor. When the preprocessor is disabled only the "memcap", "max_gzip_mem", "compress_depth" and "decompress_depth" options are applied when specified with the configuration. Other options are parsed but not used. Any valid configuration may have "disabled" added to it.

### 2.2.7.3 Example Global Configuration

    preprocessor http_inspect: \
global iis_unicode_map unicode.map 1252


### 2.2.7.4 Server Configuration

There are two types of server configurations: default and by IP address.

#### 2.2.7.4.1 Default

This configuration supplies the default server configuration for any server that is not individually configured. Most of your web servers will most likely end up using the default configuration.

### 2.2.7.5 Example Default Configuration

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


#### 2.2.7.5.1 Configuration by IP Address

This format is very similar to default'', the only difference being that specific IPs can be configured.

### 2.2.7.6 Example IP Configuration

    preprocessor http_inspect_server: \
server 10.1.1.1 profile all ports { 80 }


#### 2.2.7.6.1 Configuration by Multiple IP Addresses

This format is very similar to Configuration by IP Address'', the only difference being that multiple IPs can be specified via a space separated list. There is a limit of 40 IP addresses or CIDR notations per http_inspect_server line.

### 2.2.7.7 Example Multiple IP Configuration

    preprocessor http_inspect_server: \
server { 10.1.1.1 10.2.2.0/24 } profile all ports { 80 }


### 2.2.7.8 Server Configuration Options

Important: Some configuration options have an argument of yes' or no'. This argument specifies whether the user wants the configuration option to generate an HTTP Inspect alert or not. The yes/no' argument does not specify whether the configuration option itself is on or off, only the alerting functionality. In other words, whether set to yes' or 'no', HTTP normalization will still occur, and rules based on HTTP traffic will still trigger.

36.
profile allapacheiisiis5_0iis4_0

Users can configure HTTP Inspect by using pre-defined HTTP server profiles. Profiles allow the user to easily configure the preprocessor for a certain type of server, but are not required for proper operation.

There are five profiles available: all, apache, iis, iis5_0, and iis4_0.

35-A.
all

The all profile is meant to normalize the URI using most of the common tricks available. We alert on the more serious forms of evasions. This is a great profile for detecting all types of attacks, regardless of the HTTP server. profile all sets the configuration options described in Table .

Table: Options for the all'' Profile
Option Setting
server_flow_depth 300
client_flow_depth 300
post_depth 0
chunk encoding alert on chunks larger than 500000 bytes
iis_unicode_map codepoint map in the global configuration
bare byte decoding on, alert on
iis unicode codepoints on, alert on
non_strict URL parsing on
tab_uri_delimiter is set
max_spaces 200

35-B.
apache

The apache profile is used for Apache web servers. This differs from the iis profile by only accepting UTF-8 standard Unicode encoding and not accepting backslashes as legitimate slashes, like IIS does. Apache also accepts tabs as whitespace. profile apache sets the configuration options described in Table .

Table: Options for the apache Profile
Option Setting
server_flow_depth 300
client_flow_depth 300
post_depth 0
chunk encoding alert on chunks larger than 500000 bytes
non_strict url parsing on
tab_uri_delimiter is set
max_spaces 200

35-C.
iis

The iis profile mimics IIS servers. So that means we use IIS Unicode codemaps for each server, %u encoding, bare-byte encoding, double decoding, backslashes, etc. profile iis sets the configuration options described in Table .

Table: Options for the iis Profile
Option Setting
server_flow_depth 300
client_flow_depth 300
post_depth -1
chunk encoding alert on chunks larger than 500000 bytes
iis_unicode_map codepoint map in the global configuration
bare byte decoding on, alert on
iis unicode codepoints on, alert on
non_strict URL parsing on
max_spaces 200

35-D.
iis4_0, iis5_0

In IIS 4.0 and IIS 5.0, there was a double decoding vulnerability. These two profiles are identical to iis, except they will alert by default if a URL has a double encoding. Double decode is not supported in IIS 5.1 and beyond, so it's disabled by default.

35-E.
default, no profile

The default options used by HTTP Inspect do not use a profile and are described in Table .

Table: Default HTTP Inspect Options
Option Setting
port 80
server_flow_depth 300
client_flow_depth 300
post_depth -1
chunk encoding alert on chunks larger than 500000 bytes
non_strict URL parsing on
max_spaces 200

Profiles must be specified as the first server option and cannot be combined with any other options except:

• ports
• iis_unicode_map
• allow_proxy_use
• server_flow_depth
• client_flow_depth
• post_depth
• inspect_uri_only
• oversize_dir_length
• normalize_utf
• max_spaces
• extended_response_inspection
• inspect_gzip
• unlimited_decompress
• normalize_javascript
• max_javascript_whitespaces
• enable_xff
• http_methods
• log_uri
• log_hostname
• small_chunk_length
• decompress_swf
• decompress_pdf
• legacy_mode

These options must be specified after the profile option.

### 2.2.7.9 Example

    preprocessor http_inspect_server: \
server 1.1.1.1 profile all ports { 80 3128 }


ports portport

This is how the user configures which ports to decode on the HTTP server. However, HTTPS traffic is encrypted and cannot be decoded with HTTP Inspect. To ignore HTTPS traffic, use the SSL preprocessor.

iis_unicode_map map_filename codemap integer

The IIS Unicode map is generated by the program ms_unicode_generator.c. This program is located on the Snort.org web site at http://www.snort.org/dl/contrib/ directory. Executing this program generates a Unicode map for the system that it was run on. So, to get the specific Unicode mappings for an IIS web server, you run this program on that server and use that Unicode map in this configuration.

When using this option, the user needs to specify the file that contains the IIS Unicode map and also specify the Unicode map to use. For US servers, this is usually 1252. But the ms_unicode_generator program tells you which codemap to use for you server; it's the ANSI code page. You can select the correct code page by looking at the available code pages that the ms_unicode_generator outputs.

extended_response_inspection

This enables the extended HTTP response inspection. The default http response inspection does not inspect the various fields of a HTTP response. By turning this option the HTTP response will be thoroughly inspected. The different fields of a HTTP response such as status code, status message, headers, cookie (when enable_cookie is configured) and body are extracted and saved into buffers. Different rule options are provided to inspect these buffers.

This option must be enabled to make use of the decompress_swf or decompress_pdf options.

 Note:   When this option is turned on, if the HTTP response packet has a body then any content pattern matches ( without http modifiers ) will search the response body ((decompressed in case of gzip) and not the entire packet payload. To search for patterns in the header of the response, one should use the http modifiers with content such as http_header, http_stat_code, http_stat_msg and http_cookie.

Ex: Set-Cookie: mycookie \r\n

In this case, Set-Cookie: \r\n will be in the HTTP header buffer and the pattern


inspect_gzip

This option specifies the HTTP inspect module to uncompress the compressed data(gzip/deflate) in HTTP response. You should select the config option "extended_response_inspection" before configuring this option. Decompression is done across packets. So the decompression will end when either the 'compress_depth' or 'decompress_depth' is reached or when the compressed data ends. When the compressed data is spanned across multiple packets, the state of the last decompressed packet is used to decompressed the data of the next packet. But the decompressed data are individually inspected. (i.e. the decompressed data from different packets are not combined while inspecting). Also the amount of decompressed data that will be inspected depends on the 'server_flow_depth' configured.

Http Inspect generates a preprocessor alert with gid 120 and sid 6 when the decompression fails. When the decompression fails due to a CRC error encountered by zlib, HTTP Inspect will also provide the detection module with the data that was decompressed by zlib.

unlimited_decompress

This option enables the user to decompress unlimited gzip data (across multiple packets).Decompression will stop when the compressed data ends or when a out of sequence packet is received. To ensure unlimited decompression, user should set the 'compress_depth' and 'decompress_depth' to its maximum values in the default policy. The decompression in a single packet is still limited by the 'compress_depth' and 'decompress_depth'.

decompress_swf

This option will enable decompression of compressed SWF (Adobe Flash content) files encountered as the HTTP Response body in a GET transaction. The available decompression modes are 'deflate' and 'lzma'. A prerequisite is enabling extended_response_inspection (described above). When enabled, the preprocessor will examine the response body for the corresponding file signature. 'CWS' for Deflate/ZLIB compressed and 'ZWS' for LZMA compressed. Each decompression mode can be individually enabled. e.g. ... lzma or deflate or lzma deflate . The compressed content is decompressed 'in-place' with the content made available to the detection/rules 'file_data' option. If enabled and located, the compressed SWF file signature is converted to 'FWS' to indicate an uncompressed file.

The 'decompress_depth', 'compress_depth', and 'unlimited_decompress' are optionally used to place limits on the decompression process. The semantics for SWF files are similar to the gzip decompression process.

During the decompression process, the preprocessor may generate alert 120:12 if Deflate decompression fails or alert 120:13 if LZMA decompression fails.

 Note:   LZMA decompression is only available if Snort is built with the liblzma package present and functional. If the LZMA package is not present, then the lzma option will indicate a fatal parsing error. If the liblzma package IS present, but one desires to disable LZMA support, then the -disable-lzma option on configure will disable usage of the library.

decompress_pdf

This option will enable decompression of the compressed portions of PDF files encountered as the HTTP Response body in a GET transaction. A prerequisite is enabling extended_response_inspection (described above).

When enabled, the preprocessor will examine the response body for the ' PDF files are then parsed, locating PDF 'streams' with a single '/FlateDecode' filter. These streams are decompressed in-place, replacing the compressed content.

The 'decompress_depth', 'compress_depth', and 'unlimited_decompress' are optionally used to place limits on the decompression process. The semantics for PDF files are similar to the gzip decompression process.

During the file parsing/decompression process, the preprocessor may generate several alerts:

120:14 Deflate decompression failure
120:15 Located a 'stream' with an unsupported compression ('/Filter') algorithm
120:16 Located a 'stream' with unsupported cascaded '/FlateDecode' options, e.g.:
/Filter [ /FlateDecode /FlateDecode ]

120:17 PDF File parsing error

normalize_javascript This option enables the normalization of Javascript within the HTTP response body. You should select the config option extended_response_inspection before configuring this option. When this option is turned on, Http Inspect searches for a Javascript within the HTTP response body by searching for the script tags and starts normalizing it. When Http Inspect sees the script tag without a type, it is considered as a javascript. The obfuscated data within the javascript functions such as unescape, String.fromCharCode, decodeURI, decodeURIComponent will be normalized. The different encodings handled within the unescape/ decodeURI/decodeURIComponent are %XX, %uXXXX,
XX
and
uXXXXi
. Apart from these encodings, Http Inspect will also detect the consecutive whitespaces and normalize it to a single space. Http Inspect will also normalize the plus and concatenate the strings. The rule option file_data can be used to access this normalized buffer from the rule. A preprocessor alert with SID 9 and GID 120 is generated when the obfuscation levels within the Http Inspect is equal to or greater than 2.

Example:

HTTP/1.1 200 OK\r\n
Date: Wed, 29 Jul 2009 13:35:26 GMT\r\n
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch10 mod_ssl/2.2.3 OpenSSL/0.9.8c\r\n
Last-Modified: Sun, 20 Jan 2008 12:01:21 GMT\r\n
Accept-Ranges: bytes\r\n
Content-Length: 214\r\n
Keep-Alive: timeout=15, max=99\r\n
Connection: Keep-Alive\r\n
Content-Type: application/octet-stream\r\n\r\n
<html xmlns="http://www.w3.org/1999/xhtml">
<title>FIXME</title>
<body>
<script>document.write(unescape(unescape("%48%65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21")));
</script>
</body>
</html>


The above javascript will generate the preprocessor alert with SID 9 and GIDF 120 when normalize_javascript is turned on.

Http Inspect will also generate a preprocessor alert with GID 120 and SID 11 when there are more than one type of encodings within the escaped/encoded data.

For example:

unescape("%48\x65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21");
String.fromCharCode(0x48, 0x65, 0x6c, 0x6c, 111, 44, 32, 115, 110, 111, 114, 116, 32, 116, 101, 97, 109, 33)

\\end{verbatim}

The above obfuscation will generate the preprocessor alert with GID 120 and SID 11.

This option is turned off by default in HTTP Inspect.

\item \texttt{max\_javascript\_whitespaces $<$positive integer up to 65535$>$}
This option takes an integer as an argument.  The integer determines the maximum number
of consecutive whitespaces allowed within the Javascript obfuscated data in a HTTP
response body. The config option \texttt{normalize\_javascript} should be turned on before configuring
this config option. When the whitespaces in the javascript obfuscated data is equal to or more
than this value a preprocessor alert with GID 120 and SID 10 is generated. The default value for
this option is 200.  To enable, specify an integer argument to \texttt{max\_javascript\_spaces} of 1 to 65535.
Specifying a value of 0 is treated as disabling the alert.

\item \texttt{enable\_xff}

This option enables Snort to parse and log the original client IP present in the
X-Forwarded-For or True-Client-IP HTTP request headers along with the generated
events. The XFF/True-Client-IP Original client IP address is logged only with
unified2 output and is not logged with console (-A cmg) output.

If/When the \texttt{enable\_xff} option is present, the \texttt{xff\_headers} option specifies a set of custom 'xff'
two default (and always present) X-Forwarded-For and True-Client-IP headers.  The option
permits both the custom and default headers to be prioritized.  The headers/priority pairs
are specified as a list.  Lower numerical values imply a higher priority.  The headers do
not need to be specified in priority order.  Nor do the priorities need to be contiguous.
Priority values can range from 1 to 255.  The priority values and header names must be unique.
'content-length', etc.

A example of the \texttt{xff\_header} syntax is:
\begin{verbatim}
xff_headers { [ x-forwarded-highest-priority 1 ] [ x-forwarded-second-highest-priority 2 ] \
[ x-forwarded-lowest-priority-custom 3 ] }


The default X-Forwarded-For and True-Client-IP headers are always present. They may be explicitly specified in the xff_headers config in order to determine their priority. If not specified, they will be automatically added to the xff list as the lowest priority headers.

For example, let us say that we have the following (abbreviated) HTTP request header:

...
Host: www.snort.org
X-Forwarded-For: 192.168.1.1
X-Was-Originally-Forwarded-From: 10.1.1.1
...


With the default xff behavior (no xff_headers), the 'X-Forwarded-For' header would be used to provide a 192.168.1.1 Original Client IP address in the unified2 log. Custom headers are not parsed.

With:

xff_headers { [ x-was-originally-forwarded-from 1 ] [ x-another-forwarding-header 2 ] \
[ x-forwarded-for 3 ] }


The X-Was-Originally-Forwarded-From header is the highest priority present and its value of 10.1.1.1 will be logged as the Original Client IP in the unified2 log.

But with:

xff_headers { [ x-was-originally-forwarded-from 3 ] [ x-another-forwarding-header 2 ] \
[ x-forwarded-for 1 ] }


Now the X-Forwarded-For header is the highest priority and its value of 192.168.1.1 is logged.

 Note:   The original client IP from XFF/True-Client-IP in unified2 logs can be viewed using the tool u2spewfoo. This tool is present in the tools/u2spewfoo directory of snort source tree.

server_flow_depth integer

This specifies the amount of server response payload to inspect. When extended_response_inspection is turned on, it is applied to the HTTP response body (decompressed data when inspect_gzip is turned on) and not the HTTP headers. When extended_response_inspection is turned off the server_flow_depth is applied to the entire HTTP response (including headers). Unlike client_flow_depth this option is applied per TCP session. This option can be used to balance the needs of IDS performance and level of inspection of HTTP server response data. Snort rules are targeted at HTTP server response traffic and when used with a small flow_depth value may cause false negatives. Most of these rules target either the HTTP header, or the content that is likely to be in the first hundred or so bytes of non-header data. Headers are usually under 300 bytes long, but your mileage may vary. It is suggested to set the server_flow_depth to its maximum value.

This value can be set from -1 to 65535. A value of -1 causes Snort to ignore all server side traffic for ports defined in ports when extended_response_inspection is turned off. When the extended_response_inspection is turned on, value of -1 causes Snort to ignore the HTTP response body data and not the HTTP headers. Inversely, a value of 0 causes Snort to inspect all HTTP server payloads defined in "ports" (note that this will likely slow down IDS performance). Values above 0 tell Snort the number of bytes to inspect of the server response (excluding the HTTP headers when extended_response_inspection is turned on) in a given HTTP session. Only packets payloads starting with 'HTTP' will be considered as the first packet of a server response. If less than flow_depth bytes are in the payload of the HTTP response packets in a given session, the entire payload will be inspected. If more than flow_depth bytes are in the payload of the HTTP response packet in a session only flow_depth bytes of the payload will be inspected for that session. Rules that are meant to inspect data in the payload of the HTTP response packets in a session beyond 65535 bytes will be ineffective unless flow_depth is set to 0. The default value for server_flow_depth is 300. Note that the 65535 byte maximum flow_depth applies to stream reassembled packets as well. It is suggested to set the server_flow_depth to its maximum value.

 Note:   server_flow_depth is the same as the old flow_depth option, which will be deprecated in a future release.

client_flow_depth integer

This specifies the amount of raw client request payload to inspect. This value can be set from -1 to 1460. Unlike server_flow_depth this value is applied to the first packet of the HTTP request. It is not a session based flow depth. It has a default value of 300. It primarily eliminates Snort from inspecting larger HTTP Cookies that appear at the end of many client request Headers.

A value of -1 causes Snort to ignore all client side traffic for ports defined in "ports." Inversely, a value of 0 causes Snort to inspect all HTTP client side traffic defined in "ports" (note that this will likely slow down IDS performance). Values above 0 tell Snort the number of bytes to inspect in the first packet of the client request. If less than flow_depth bytes are in the TCP payload (HTTP request) of the first packet, the entire payload will be inspected. If more than flow_depth bytes are in the payload of the first packet only flow_depth bytes of the payload will be inspected. Rules that are meant to inspect data in the payload of the first packet of a client request beyond 1460 bytes will be ineffective unless flow_depth is set to 0. Note that the 1460 byte maximum flow_depth applies to stream reassembled packets as well. It is suggested to set the client_flow_depth to its maximum value.

post_depth integer

This specifies the amount of data to inspect in a client post message. The value can be set from -1 to 65495. The default value is -1. A value of -1 causes Snort to ignore all the data in the post message. Inversely, a value of 0 causes Snort to inspect all the client post message. This increases the performance by inspecting only specified bytes in the post message.

ascii yesno

The ascii decode option tells us whether to decode encoded ASCII chars, a.k.a %2f = /, %2e = ., etc. It is normal to see ASCII encoding usage in URLs, so it is recommended that you disable HTTP Inspect alerting for this option.

extended_ascii_uri

This option enables the support for extended ASCII codes in the HTTP request URI. This option is turned off by default and is not supported with any of the profiles.

utf_8 yesno

The utf-8 decode option tells HTTP Inspect to decode standard UTF-8 Unicode sequences that are in the URI. This abides by the Unicode standard and only uses % encoding. Apache uses this standard, so for any Apache servers, make sure you have this option turned on. As for alerting, you may be interested in knowing when you have a UTF-8 encoded URI, but this will be prone to false positives as legitimate web clients use this type of encoding. When utf_8 is enabled, ASCII decoding is also enabled to enforce correct functioning.

u_encode yesno

This option emulates the IIS %u encoding scheme. How the %u encoding scheme works is as follows: the encoding scheme is started by a %u followed by 4 characters, like %uxxxx. The xxxx is a hex-encoded value that correlates to an IIS Unicode codepoint. This value can most definitely be ASCII. An ASCII character is encoded like %u002f = /, %u002e = ., etc. If no iis_unicode_map is specified before or after this option, the default codemap is used.

You should alert on %u encodings, because we are not aware of any legitimate clients that use this encoding. So it is most likely someone trying to be covert.

bare_byte yesno

Bare byte encoding is an IIS trick that uses non-ASCII characters as valid values when decoding UTF-8 values. This is not in the HTTP standard, as all non-ASCII values have to be encoded with a %. Bare byte encoding allows the user to emulate an IIS server and interpret non-standard encodings correctly.

The alert on this decoding should be enabled, because there are no legitimate clients that encode UTF-8 this way since it is non-standard.

iis_unicode yesno

The iis_unicode option turns on the Unicode codepoint mapping. If there is no iis_unicode_map option specified with the server config, iis_unicode uses the default codemap. The iis_unicode option handles the mapping of non-ASCII codepoints that the IIS server accepts and decodes normal UTF-8 requests.

You should alert on the iis_unicode option, because it is seen mainly in attacks and evasion attempts. When iis_unicode is enabled, ASCII and UTF-8 decoding are also enabled to enforce correct decoding. To alert on UTF-8 decoding, you must enable also enable utf_8 yes.

double_decode yesno

The double_decode option is once again IIS-specific and emulates IIS functionality. How this works is that IIS does two passes through the request URI, doing decodes in each one. In the first pass, it seems that all types of iis encoding is done: utf-8 unicode, ASCII, bare byte, and %u. In the second pass, the following encodings are done: ASCII, bare byte, and %u. We leave out utf-8 because I think how this works is that the % encoded utf-8 is decoded to the Unicode byte in the first pass, and then UTF-8 is decoded in the second stage. Anyway, this is really complex and adds tons of different encodings for one character. When double_decode is enabled, so ASCII is also enabled to enforce correct decoding.

non_rfc_char bytebyte ...

This option lets users receive an alert if certain non-RFC chars are used in a request URI. For instance, a user may not want to see null bytes in the request URI and we can alert on that. Please use this option with care, because you could configure it to say, alert on all /' or something like that. It's flexible, so be careful.

multi_slash yesno

This option normalizes multiple slashes in a row, so something like: foo/////////bar'' get normalized to foo/bar.''

If you want an alert when multiple slashes are seen, then configure with a yes; otherwise, use no.

iis_backslash yesno

Normalizes backslashes to slashes. This is again an IIS emulation. So a request URI of /foobar'' gets normalized to /foo/bar.''

directory yesno

This option normalizes directory traversals and self-referential directories.

The directory:

    /foo/fake\_dir/../bar


gets normalized to:

    /foo/bar


The directory:

    /foo/./bar


gets normalized to:

    /foo/bar


If you want to configure an alert, specify yes, otherwise, specify no. This alert may give false positives, since some web sites refer to files using directory traversals.

apache_whitespace yesno

This option deals with the non-RFC standard of using tab for a space delimiter. Apache uses this, so if the emulated web server is Apache, enable this option. Alerts on this option may be interesting, but may also be false positive prone.

iis_delimiter yesno

This started out being IIS-specific, but Apache takes this non-standard delimiter was well. Since this is common, we always take this as standard since the most popular web servers accept it. But you can still get an alert on this option.

chunk_length non-zero positive integer

This option is an anomaly detector for abnormally large chunk sizes. This picks up the Apache chunk encoding exploits, and may also alert on HTTP tunneling that uses chunk encoding.

small_chunk_length { chunk size consecutive chunks }

This option is an evasion detector for consecutive small chunk sizes when either the client or server use Transfer-Encoding: chunked. chunk size specifies the maximum chunk size for which a chunk will be considered small. consecutive chunks specifies the number of consecutive small chunks = chunk size before an event will be generated. This option is turned off by default. Maximum values for each are 255 and a chunk size of 0 disables. Events generated are gid:119, sid:26 for client small chunks and gid:120, sid:7 for server small chunks.

Example:

small_chunk_length { 10 5 }

Meaning alert if we see 5 consecutive chunk sizes of 10 or less.

no_pipeline_req

This option turns HTTP pipeline decoding off, and is a performance enhancement if needed. By default, pipeline requests are inspected for attacks, but when this option is enabled, pipeline requests are not decoded and analyzed per HTTP protocol field. It is only inspected with the generic pattern matching.

non_strict

This option turns on non-strict URI parsing for the broken way in which Apache servers will decode a URI. Only use this option on servers that will accept URIs like this: "get /index.html alsjdfk alsj lj aj la jsj sn". The non_strict option assumes the URI is between the first and second space even if there is no valid HTTP identifier after the second space.

allow_proxy_use

By specifying this keyword, the user is allowing proxy use on this server. This means that no alert will be generated if the proxy_alert global keyword has been used. If the proxy_alert keyword is not enabled, then this option does nothing. The allow_proxy_use keyword is just a way to suppress unauthorized proxy use for an authorized server.

This option turns off all alerts that are generated by the HTTP Inspect preprocessor module. This has no effect on HTTP rules in the rule set. No argument is specified.

oversize_dir_length non-zero positive integer

This option takes a non-zero positive integer as an argument. The argument specifies the max char directory length for URL directory. If a url directory is larger than this argument size, an alert is generated. A good argument value is 300 characters. This should limit the alerts to IDS evasion type attacks, like whisker -i 4.

inspect_uri_only

This is a performance optimization. When enabled, only the URI portion of HTTP requests will be inspected for attacks. As this field usually contains 90-95% of the web attacks, you'll catch most of the attacks. So if you need extra performance, enable this optimization. It's important to note that if this option is used without any uricontent rules, then no inspection will take place. This is obvious since the URI is only inspected with uricontent rules, and if there are none available, then there is nothing to inspect.

For example, if we have the following rule set:

    alert tcp any any -> any 80 ( msg:"content"; content: "foo"; )


and the we inspect the following URI:

    get /foo.htm http/1.0\r\n\r\n


No alert will be generated when inspect_uri_only is enabled. The inspect_uri_only configuration turns off all forms of detection except uricontent inspection.

max_header_length positive integer up to 65535

This option takes an integer as an argument. The integer is the maximum length allowed for an HTTP client request header field. Requests that exceed this length will cause a "Long Header" alert. This alert is off by default. To enable, specify an integer argument to max_header_length of 1 to 65535. Specifying a value of 0 is treated as disabling the alert.

max_spaces positive integer up to 65535

This option takes an integer as an argument. The integer determines the maximum number of whitespaces allowed with HTTP client request line folding. Requests headers folded with whitespaces equal to or more than this value will cause a "Space Saturation" alert with SID 26 and GID 119. The default value for this option is 200. To enable, specify an integer argument to max_spaces of 1 to 65535. Specifying a value of 0 is treated as disabling the alert.

webroot yesno

This option generates an alert when a directory traversal traverses past the web server root directory. This generates much fewer false positives than the directory option, because it doesn't alert on directory traversals that stay within the web server directory structure. It only alerts when the directory traversals go past the web server root directory, which is associated with certain web attacks.

tab_uri_delimiter

This option turns on the use of the tab character (0x09) as a delimiter for a URI. Apache accepts tab as a delimiter; IIS does not. For IIS, a tab in the URI should be treated as any other character. Whether this option is on or not, a tab is treated as whitespace if a space character (0x20) precedes it. No argument is specified.

This option turns on normalization for HTTP Header Fields, not including Cookies (using the same configuration parameters as the URI normalization (i.e., multi-slash, directory, etc.). It is useful for normalizing Referrer URIs that may appear in the HTTP Header.

This option turns on normalization for HTTP Cookie Fields (using the same configuration parameters as the URI normalization (i.e., multi-slash, directory, etc.). It is useful for normalizing data in HTTP Cookies that may be encoded.

normalize_utf

This option turns on normalization of HTTP response bodies where the Content-Type header lists the character set as "utf-16le", "utf-16be", "utf-32le", or "utf-32be". HTTP Inspect will attempt to normalize these back into 8-bit encoding, generating an alert if the extra bytes are non-zero.

max_headers positive integer up to 1024

This option takes an integer as an argument. The integer is the maximum number of HTTP client request header fields. Requests that contain more HTTP Headers than this value will cause a "Max Header" alert. The alert is off by default. To enable, specify an integer argument to max_headers of 1 to 1024. Specifying a value of 0 is treated as disabling the alert.

http_methods This specifies additional HTTP Request Methods outside of those checked by default within the preprocessor (GET and POST). The list should be enclosed within braces and delimited by spaces, tabs, line feed or carriage return. The config option, braces and methods also needs to be separated by braces.

    http_methods { PUT CONNECT }


 Note:   Please note the maximum length for a method name is 256.

log_uri

This option enables HTTP Inspect preprocessor to parse the URI data from the HTTP request and log it along with all the generated events for that session. Stream reassembly needs to be turned on HTTP ports to enable the logging. If there are multiple HTTP requests in the session, the URI data of the most recent HTTP request during the alert will be logged. The maximum URI logged is 2048.

 Note:   Please note, this is logged only with the unified2 output and is not logged with console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

log_hostname

This option enables HTTP Inspect preprocessor to parse the hostname data from the "Host" header of the HTTP request and log it along with all the generated events for that session. Stream reassembly needs to be turned on HTTP ports to enable the logging. If there are multiple HTTP requests in the session, the Hostname data of the most recent HTTP request during the alert will be logged. In case of multiple "Host" headers within one HTTP request, a preprocessor alert with sid 24 is generated. The maximum hostname length logged is 256.

 Note:   Please note, this is logged only with the unified2 output and is not logged with console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

##########################################
# HTTP2 SUPPORT IS STILL EXPERIMENTAL!
# DO NOT USE IN PRODUCTION ENVIRONMENTS.
# Please send any issues to the Snort team
##########################################


legacy_mode By default, HTTP2 traffic is not supported. To enable it you need:

• Install nghttp library from https://nghttp2.org/
• If nghttp is not installed in default path, use with_libnghttp2_includes and with_libnghttp2_libraries to point to the correct path during configure'' step.
• Enable HTTP2 support in http_inspect configuration with legacy_mode no''

### 2.2.7.10 Examples

    preprocessor http_inspect_server: \
server 10.1.1.1 \
ports { 80 3128 8080 } \
server_flow_depth 0 \
ascii no \
double_decode yes \
non_rfc_char { 0x00 } \
chunk_length 500000 \
non_strict \

preprocessor http_inspect_server: \
server default \
ports  { 80 3128 }  \
non_strict \
non_rfc_char  { 0x00 }  \
server_flow_depth 300  \
apache_whitespace yes \
directory no \
iis_backslash no \
u_encode yes \
ascii no \
chunk_length 500000 \
bare_byte yes \
double_decode yes \
iis_unicode yes \
iis_delimiter yes \
multi_slash no

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


## 2.2.8 SMTP Preprocessor

The SMTP preprocessor is an SMTP decoder for user applications. Given a data buffer, SMTP will decode the buffer and find SMTP commands and responses. It will also mark the command, data header data body sections, and TLS data.

SMTP handles stateless and stateful processing. It saves state between individual packets. However maintaining correct state is dependent on the reassembly of the client side of the stream (i.e., a loss of coherent stream data results in a loss of state).

### 2.2.8.1 Configuration

SMTP has the usual configuration items, such as port and inspection_type. Also, SMTP command lines can be normalized to remove extraneous spaces. TLS-encrypted traffic can be ignored, which improves performance. In addition, regular mail data can be ignored for an additional performance boost. Since so few (none in the current snort rule set) exploits are against mail data, this is relatively safe to do and can improve the performance of data inspection.

The configuration options are described below:

37.
ports { <port> [<port>] ... }

This specifies on what ports to check for SMTP data. Typically, this will include 25 and possibly 465, for encrypted SMTP.

38.
inspection_type <stateful | stateless>

Indicate whether to operate in stateful or stateless mode.

39.
normalize <all | none | cmds>

This turns on normalization. Normalization checks for more than one space character after a command. Space characters are defined as space (ASCII 0x20) or tab (ASCII 0x09).

all checks all commands

none turns off normalization for all commands.

cmds just checks commands listed with the normalize_cmds parameter.

40.
ignore_data

Ignore data section of mail (except for mail headers) when processing rules.

41.
ignore_tls_data

Ignore TLS-encrypted data when processing rules.

42.
max_command_line_len <int>

Alert if an SMTP command line is longer than this value. Absence of this option or a "0" means never alert on command line length. RFC 2821 recommends 512 as a maximum command line length.

43.

Alert if an SMTP DATA header line is longer than this value. Absence of this option or a "0" means never alert on data header line length. RFC 2821 recommends 1024 as a maximum data header line length.

44.
max_response_line_len <int>

Alert if an SMTP response line is longer than this value. Absence of this option or a "0" means never alert on response line length. RFC 2821 recommends 512 as a maximum response line length.

45.
alt_max_command_line_len <int> { <cmd> [<cmd>] }

Overrides max_command_line_len for specific commands.

46.

Turn off all alerts for this preprocessor.

47.
invalid_cmds { <Space-delimited list of commands> }

Alert if this command is sent from client side. Default is an empty list.

48.
valid_cmds { <Space-delimited list of commands> }

List of valid commands. We do not alert on commands in this list. Default is an empty list, but preprocessor has this list hard-coded:

{ ATRN AUTH BDAT DATA DEBUG EHLO EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL NOOP QUIT RCPT RSET SAML SOML SEND ONEX QUEU STARTTLS TICK TIME TURN TURNME VERB VRFY X-EXPS X-LINK2STATE XADR XAUTH XCIR XEXCH50 XGEN XLICENSE XQUE XSTA XTRN XUSR }

49.
data_cmds { <Space-delimited list of commands> }

List of commands that initiate sending of data with an end of data delimiter the same as that of the DATA command per RFC 5321 - "<CRLF>.<CRLF>". Default is { DATA }.

50.
binary_data_cmds { <Space-delimited list of commands> }

List of commands that initiate sending of data and use a length value after the command to indicate the amount of data to be sent, similar to that of the BDAT command per RFC 3030. Default is { BDAT XEXCH50 }.

51.
auth_cmds { <Space-delimited list of commands> }

List of commands that initiate an authentication exchange between client and server. Default is { AUTH XAUTH X-EXPS }.

52.

Alert if we don't recognize command. Default is off.

53.
normalize_cmds { <Space-delimited list of commands> }

Normalize this list of commands Default is { RCPT VRFY EXPN }.

54.
xlink2state { enable | disable [drop] }

55.
print_cmds

List all commands understood by the preprocessor. This not normally printed out with the configuration because it can print so much data.

56.
disabled

Disables the SMTP preprocessor in a config. This is useful when specifying the decoding depths such as b64_decode_depth, qp_decode_depth, uu_decode_depth, bitenc_decode_depth or the memcap used for decoding max_mime_mem in default config without turning on the SMTP preprocessor.

57.
b64_decode_depth

This config option is used to turn off/on or set the base64 decoding depth used to decode the base64 encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the base64 decoding of MIME attachments. The value of 0 sets the decoding of base64 encoded MIME attachments to unlimited. A value other than 0 or -1 restricts the decoding of base64 MIME attachments, and applies per attachment. A SMTP preprocessor alert with sid 10 is generated (if enabled) when the decoding fails.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the base64 encoded MIME attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

This option replaces the deprecated options, enable_mime_decoding and max_mime_depth. It is recommended that user inputs a value that is a multiple of 4. When the value specified is not a multiple of 4, the SMTP preprocessor will round it up to the next multiple of 4.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

58.
qp_decode_depth

This config option is used to turn off/on or set the Quoted-Printable decoding depth used to decode the Quoted-Printable(QP) encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the QP decoding of MIME attachments. The value of 0 sets the decoding of QP encoded MIME attachments to unlimited. A value other than 0 or -1 restricts the decoding of QP MIME attachments, and applies per attachment. A SMTP preprocessor alert with sid 11 is generated (if enabled) when the decoding fails.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the QP encoded MIME attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

59.
bitenc_decode_depth

This config option is used to turn off/on or set the non-encoded MIME extraction depth used to extract the non-encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the extraction of these MIME attachments. The value of 0 sets the extraction of these MIME attachments to unlimited. A value other than 0 or -1 restricts the extraction of these MIME attachments, and applies per attachment.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the non-encoded MIME attachments/data across multiple packets are extracted too.

The extracted data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

60.
uu_decode_depth

This config option is used to turn off/on or set the Unix-to-Unix decoding depth used to decode the Unix-to-Unix(UU) encoded attachments. The value ranges from -1 to 65535. A value of -1 turns off the UU decoding of SMTP attachments. The value of 0 sets the decoding of UU encoded SMTP attachments to unlimited. A value other than 0 or -1 restricts the decoding of UU SMTP attachments, and applies per attachment. A SMTP preprocessor alert with sid 13 is generated (if enabled) when the decoding fails.

Multiple UU attachments/data in one packet are pipelined. When stateful inspection is turned on the UU encoded SMTP attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

61.
enable_mime_decoding

Enables Base64 decoding of Mime attachments/data. Multiple base64 encoded MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the base64 encoded MIME attachments/data across multiple packets are decoded too. The decoding of base64 encoded attachments/data ends when either the max_mime_depth or maximum MIME sessions (calculated using max_mime_depth and max_mime_mem) is reached or when the encoded data ends. The decoded data is available for detection using the rule option file_data. See rule option for more details.

This option is deprecated. Use the option b64_decode_depth to turn off or on the base64 decoding instead.

62.
max_mime_depth <int>

Specifies the maximum number of base64 encoded data to decode per SMTP attachment. The option take values ranging from 4 to 20480 bytes. The default value for this in snort in 1460 bytes.

It is recommended that user inputs a value that is a multiple of 4. When the value specified is not a multiple of 4, the SMTP preprocessor will round it up to the next multiple of 4.

This option is deprecated. Use the option b64_decode_depth to turn off or on the base64 decoding instead.

63.
max_mime_mem <int>

This option determines (in bytes) the maximum amount of memory the SMTP preprocessor will use for decoding base64 encoded/quoted-printable/non-encoded MIME attachments/data or Unix-to-Unix encoded attachments. This value can be set from 3276 bytes to 100MB.

This option along with the maximum of the decoding depths will determine the SMTP sessions that will be decoded at any given instant. The default value for this option is 838860.

Note: It is suggested to set this value such that the max smtp session calculated as follows is at least 1.

max smtp session = max_mime_mem /(2 * max of (b64_decode_depth, uu_decode_depth, qp_decode_depth or bitenc_decode_depth))

For example, if b64_decode_depth is 0 (indicates unlimited decoding) and qp_decode_depth is 100, then

max smtp session = max_mime_mem/2*65535 (max value for b64_decode_depth)

In case of multiple configs, the max_mime_mem of the non-default configs will be overwritten by the default config's value. Hence user needs to define it in the default config with the new keyword disabled (used to disable SMTP preprocessor in a config).

64.
log_mailfrom This option enables SMTP preprocessor to parse and log the sender's email address extracted from the "MAIL FROM" command along with all the generated events for that session. The maximum number of bytes logged for this option is 1024.

Please note, this is logged only with the unified2 output and is not logged with console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

65.
log_rcptto This option enables SMTP preprocessor to parse and log the recipient's email addresses extracted from the "RCPT TO" command along with all the generated events for that session. Multiple recipients are appended with commas. The maximum number of bytes logged for this option is 1024.

Please note, this is logged only with the unified2 output and is not logged with console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

66.
log_filename This option enables SMTP preprocessor to parse and log the MIME attachment filenames extracted from the Content-Disposition header within the MIME body along with all the generated events for that session. Multiple filenames are appended with commas. The maximum number of bytes logged for this option is 1024.

Please note, this is logged only with the unified2 output and is not logged with the console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

67.
log_email_hdrs This option enables SMTP preprocessor to parse and log the SMTP email headers extracted from SMTP data along with all generated events for that session. The number of bytes extracted and logged depends upon the email_hdrs_log_depth.

Please note, this is logged only with the unified2 output and is not logged with the console output (-A cmg). u2spewfoo can be used to read this data from the unified2.

68.
email_hdrs_log_depth <int> This option specifies the depth for logging email headers. The allowed range for this option is 0 - 20480. A value of 0 will disable email headers logging. The default value for this option is 1464.

Please note, in case of multiple policies, the value specified in the default policy is used and the values specified in the targeted policies are overwritten by the default value. This option must be configured in the default policy even if the SMTP configuration is disabled.

69.
memcap <int> This option determines in bytes the maximum amount of memory the SMTP preprocessor will use for logging of filename, MAIL FROM addresses, RCPT TO addresses and email headers. This value along with the buffer size used to log MAIL FROM, RCPT TO, filenames and email_hdrs_log_depth will determine the maximum SMTP sessions that will log the email headers at any given time. When this memcap is reached SMTP will stop logging the filename, MAIL FROM address, RCPT TO addresses and email headers until memory becomes available.

Max SMTP sessions logging email headers at any given time = memcap/(1024 + 1024 + 1024 + email_hdrs_log_depth)

The size 1024 is the maximum buffer size used for logging filename, RCPTTO and MAIL FROM addresses.

Default value for this option is 838860. The allowed range for this option is 3276 to 104857600. The value specified in the default config is used when this option is specified in multiple configs. This option must be configured in the default config even if the SMTP configuration is disabled.

Please note, in case of multiple policies, the value specified in the default policy is used and the values specified in the targeted policies are overwritten by the default value. This option must be configured in the default policy even if the SMTP configuration is disabled.

### 2.2.8.2 Example

    preprocessor SMTP: \
ports { 25 } \
inspection_type stateful \
normalize cmds \
normalize_cmds { EXPN VRFY RCPT } \
ignore_data \
ignore_tls_data \
max_command_line_len  512 \
max_response_line_len 512 \
alt_max_command_line_len 300 { RCPT } \
invalid_cmds { } \
valid_cmds { } \
print_cmds \
log_filename \
log_email_hdrs \
log_mailfrom \
log_rcptto \
email_hdrs_log_depth 2920 \
memcap 6000

preprocessor SMTP: \
b64_decode_depth 0\
max_mime_mem 4000 \
memcap 6000 \
email_hdrs_log_depth 2920 \
disabled


### 2.2.8.3 Default

    preprocessor SMTP: \
ports { 25 } \
inspection_type stateful \
normalize cmds \
normalize_cmds { EXPN VRFY RCPT } \
alt_max_command_line_len 260 { MAIL } \
alt_max_command_line_len 300 { RCPT } \
alt_max_command_line_len 500 { HELP HELO ETRN } \
alt_max_command_line_len 255 { EXPN VRFY }


### 2.2.8.4 Note

RCPT TO: and MAIL FROM: are SMTP commands. For the preprocessor configuration, they are referred to as RCPT and MAIL, respectively. Within the code, the preprocessor actually maps RCPT and MAIL to the correct command name.

## 2.2.9 POP Preprocessor

POP is an POP3 decoder for user applications. Given a data buffer, POP will decode the buffer and find POP3 commands and responses. It will also mark the command, data header data body sections and extract the POP3 attachments and decode it appropriately.

POP will handle stateful processing. It saves state between individual packets. However maintaining correct state is dependent on the reassembly of the server side of the stream (i.e., a loss of coherent stream data results in a loss of state).

Stream should be turned on for POP. Please ensure that the POP ports are added to the stream5 ports for proper reassembly.

The POP preprocessor uses GID 142 to register events.

### 2.2.9.1 Configuration

The configuration options are described below:

70.
ports { <port> [<port>] ... }

This specifies on what ports to check for POP data. Typically, this will include 110. Default ports if none are specified are 110 .

71.
disabled

Disables the POP preprocessor in a config. This is useful when specifying the decoding depths such as b64_decode_depth, qp_decode_depth, uu_decode_depth, bitenc_decode_depth or the memcap used for decoding memcap in default config without turning on the POP preprocessor.

72.
b64_decode_depth

This config option is used to turn off/on or set the base64 decoding depth used to decode the base64 encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the base64 decoding of MIME attachments. The value of 0 sets the decoding of base64 encoded MIME attachments to unlimited. A value other than 0 or -1 restricts the decoding of base64 MIME attachments, and applies per attachment. A POP preprocessor alert with sid 4 is generated (if enabled) when the decoding fails.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the base64 encoded MIME attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

It is recommended that user inputs a value that is a multiple of 4. When the value specified is not a multiple of 4, the POP preprocessor will round it up to the next multiple of 4.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

73.
qp_decode_depth

This config option is used to turn off/on or set the Quoted-Printable decoding depth used to decode the Quoted-Printable(QP) encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the QP decoding of MIME attachments. The value of 0 sets the decoding of QP encoded MIME attachments to unlimited. A value other than 0 or -1 restricts the decoding of QP MIME attachments, and applies per attachment. A POP preprocessor alert with sid 5 is generated (if enabled) when the decoding fails.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the QP encoded MIME attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

74.
bitenc_decode_depth

This config option is used to turn off/on or set the non-encoded MIME extraction depth used to extract the non-encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the extraction of these MIME attachments. The value of 0 sets the extraction of these MIME attachments to unlimited. A value other than 0 or -1 restricts the extraction of these MIME attachments, and applies per attachment.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the non-encoded MIME attachments/data across multiple packets are extracted too.

The extracted data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

75.
uu_decode_depth

This config option is used to turn off/on or set the Unix-to-Unix decoding depth used to decode the Unix-to-Unix(UU) encoded attachments. The value ranges from -1 to 65535. A value of -1 turns off the UU decoding of POP attachments. The value of 0 sets the decoding of UU encoded POP attachments to unlimited. A value other than 0 or -1 restricts the decoding of UU POP attachments, and applies per attachment. A POP preprocessor alert with sid 7 is generated (if enabled) when the decoding fails.

Multiple UU attachments/data in one packet are pipelined. When stateful inspection is turned on the UU encoded POP attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

76.
memcap <int>

This option determines (in bytes) the maximum amount of memory the POP preprocessor will use for decoding base64 encoded/quoted-printable/non-encoded MIME attachments/data or Unix-to-Unix encoded attachments. This value can be set from 3276 bytes to 100MB.

This option along with the maximum of the decoding depths will determine the POP sessions that will be decoded at any given instant. The default value for this option is 838860.

Note: It is suggested to set this value such that the max pop session calculated as follows is at least 1.

max pop session = memcap /(2 * max of (b64_decode_depth, uu_decode_depth, qp_decode_depth or bitenc_decode_depth))

For example, if b64_decode_depth is 0 (indicates unlimited decoding) and qp_decode_depth is 100, then

max pop session = memcap/2*65535 (max value for b64_decode_depth)

In case of multiple configs, the memcap of the non-default configs will be overwritten by the default config's value. Hence user needs to define it in the default config with the new keyword disabled (used to disable POP preprocessor in a config).

When the memcap for decoding (memcap) is exceeded the POP preprocessor alert with sid 3 is generated (when enabled).

### 2.2.9.2 Example

	preprocessor pop: \
ports { 110 } \
memcap 1310700 \
qp_decode_depth -1 \
b64_decode_depth 0 \
bitenc_decode_depth 100

preprocessor pop: \
memcap 1310700 \
qp_decode_depth 0 \
disabled


### 2.2.9.3 Default

	preprocessor pop: \
ports { 110 } \
b64_decode_depth 1460 \
qp_decode_depth 1460 \
bitenc_decode_depth 1460 \
uu_decode_depth 1460


## 2.2.10 IMAP Preprocessor

IMAP is an IMAP4 decoder for user applications. Given a data buffer, IMAP will decode the buffer and find IMAP4 commands and responses. It will also mark the command, data header data body sections and extract the IMAP4 attachments and decode it appropriately.

IMAP will handle stateful processing. It saves state between individual packets. However maintaining correct state is dependent on the reassembly of the server side of the stream (i.e., a loss of coherent stream data results in a loss of state).

Stream should be turned on for IMAP. Please ensure that the IMAP ports are added to the stream5 ports for proper reassembly.

The IMAP preprocessor uses GID 141 to register events.

### 2.2.10.1 Configuration

The configuration options are described below:

77.
ports { <port> [<port>] ... }

This specifies on what ports to check for IMAP data. Typically, this will include 143. Default ports if none are specified are 143 .

78.
disabled

Disables the IMAP preprocessor in a config. This is useful when specifying the decoding depths such as b64_decode_depth, qp_decode_depth, uu_decode_depth, bitenc_decode_depth or the memcap used for decoding memcap in default config without turning on the IMAP preprocessor.

79.
b64_decode_depth

This config option is used to turn off/on or set the base64 decoding depth used to decode the base64 encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the base64 decoding of MIME attachments. The value of 0 sets the decoding of base64 encoded MIME attachments to unlimited. A value other than 0 or -1 restricts the decoding of base64 MIME attachments, and applies per attachment. A IMAP preprocessor alert with sid 4 is generated (if enabled) when the decoding fails.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the base64 encoded MIME attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

It is recommended that user inputs a value that is a multiple of 4. When the value specified is not a multiple of 4, the IMAP preprocessor will round it up to the next multiple of 4.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

80.
qp_decode_depth

This config option is used to turn off/on or set the Quoted-Printable decoding depth used to decode the Quoted-Printable(QP) encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the QP decoding of MIME attachments. The value of 0 sets the decoding of QP encoded MIME attachments to unlimited. A value other than 0 or -1 restricts the decoding of QP MIME attachments, and applies per attachment. A IMAP preprocessor alert with sid 5 is generated (if enabled) when the decoding fails.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the QP encoded MIME attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

81.
bitenc_decode_depth

This config option is used to turn off/on or set the non-encoded MIME extraction depth used to extract the non-encoded MIME attachments. The value ranges from -1 to 65535. A value of -1 turns off the extraction of these MIME attachments. The value of 0 sets the extraction of these MIME attachments to unlimited. A value other than 0 or -1 restricts the extraction of these MIME attachments, and applies per attachment.

Multiple MIME attachments/data in one packet are pipelined. When stateful inspection is turned on the non-encoded MIME attachments/data across multiple packets are extracted too.

The extracted data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

82.
uu_decode_depth

This config option is used to turn off/on or set the Unix-to-Unix decoding depth used to decode the Unix-to-Unix(UU) encoded attachments. The value ranges from -1 to 65535. A value of -1 turns off the UU decoding of IMAP attachments. The value of 0 sets the decoding of UU encoded IMAP attachments to unlimited. A value other than 0 or -1 restricts the decoding of UU IMAP attachments, and applies per attachment. A IMAP preprocessor alert with sid 7 is generated (if enabled) when the decoding fails.

Multiple UU attachments/data in one packet are pipelined. When stateful inspection is turned on the UU encoded IMAP attachments/data across multiple packets are decoded too.

The decoded data is available for detection using the rule option file_data. See rule option for more details.

In case of multiple configs, the value specified in the non-default config cannot exceed the value specified in the default config.

83.
memcap <int>

This option determines (in bytes) the maximum amount of memory the IMAP preprocessor will use for decoding base64 encoded/quoted-printable/non-encoded MIME attachments/data or Unix-to-Unix encoded attachments. This value can be set from 3276 bytes to 100MB.

This option along with the maximum of the decoding depths will determine the IMAP sessions that will be decoded at any given instant. The default value for this option is 838860.

Note: It is suggested to set this value such that the max imap session calculated as follows is at least 1.

max imap session = memcap /(2 * max of (b64_decode_depth, uu_decode_depth, qp_decode_depth or bitenc_decode_depth))

For example, if b64_decode_depth is 0 (indicates unlimited decoding) and qp_decode_depth is 100, then

max imap session = memcap/2*65535 (max value for b64_decode_depth)

In case of multiple configs, the memcap of the non-default configs will be overwritten by the default config's value. Hence user needs to define it in the default config with the new keyword disabled (used to disable IMAP preprocessor in a config).

When the memcap for decoding (memcap) is exceeded the IMAP preprocessor alert with sid 3 is generated (when enabled).

### 2.2.10.2 Example

	preprocessor imap: \
ports { 110 } \
memcap 1310700 \
qp_decode_depth -1 \
b64_decode_depth 0 \
bitenc_decode_depth 100

preprocessor imap: \
memcap 1310700 \
qp_decode_depth 0 \
disabled


### 2.2.10.3 Default

	preprocessor imap: \
ports { 110 } \
b64_decode_depth 1460 \
qp_decode_depth 1460 \
bitenc_decode_depth 1460 \
uu_decode_depth 1460


## 2.2.11 FTP/Telnet Preprocessor

FTP/Telnet is an improvement to the Telnet decoder and provides stateful inspection capability for both FTP and Telnet data streams. FTP/Telnet will decode the stream, identifying FTP commands and responses and Telnet escape sequences and normalize the fields. FTP/Telnet works on both client requests and server responses.

FTP/Telnet has the capability to handle stateless processing, meaning it only looks for information on a packet-by-packet basis.

The default is to run FTP/Telnet in stateful inspection mode, meaning it looks for information and handles reassembled data correctly.

FTP/Telnet has a very rich'' user configuration, similar to that of HTTP Inspect (See ). Users can configure individual FTP servers and clients with a variety of options, which should allow the user to emulate any type of FTP server or FTP Client. Within FTP/Telnet, there are four areas of configuration: Global, Telnet, FTP Client, and FTP Server.

 Note:   Some configuration options have an argument of yes or no. This argument specifies whether the user wants the configuration option to generate a ftptelnet alert or not. The presence of the option indicates the option itself is on, while the yes/no argument applies to the alerting functionality associated with that option.

### 2.2.11.1 Global Configuration

The global configuration deals with configuration options that determine the global functioning of FTP/Telnet. The following example gives the generic global configuration format:

### 2.2.11.2 Format

    preprocessor ftp_telnet: \
global \
inspection_type stateful \
encrypted_traffic yes \
check_encrypted


You can only have a single global configuration, you'll get an error if you try otherwise. The FTP/Telnet global configuration must appear before the other three areas of configuration.

#### 2.2.11.2.1 Configuration

84.
inspection_type

This indicates whether to operate in stateful or stateless mode.

85.
encrypted_traffic yes|no

This option enables detection and alerting on encrypted Telnet and FTP command channels.

 Note:   When inspection_type is in stateless mode, checks for encrypted traffic will occur on every packet, whereas in stateful mode, a particular session will be noted as encrypted and not inspected any further.

86.
check_encrypted

Instructs the preprocessor to continue to check an encrypted session for a subsequent command to cease encryption.

### 2.2.11.3 Example Global Configuration

    preprocessor ftp_telnet: \
global inspection_type stateful encrypted_traffic no


### 2.2.11.4 Telnet Configuration

The telnet configuration deals with configuration options that determine the functioning of the Telnet portion of the preprocessor. The following example gives the generic telnet configuration format:

### 2.2.11.5 Format

    preprocessor ftp_telnet_protocol: \
telnet \
ports { 23 } \
normalize \
ayt_attack_thresh 6 \
detect_anomalies


There should only be a single telnet configuration, and subsequent instances will override previously set values.

#### 2.2.11.5.1 Configuration

87.
ports portport

This is how the user configures which ports to decode as telnet traffic. SSH tunnels cannot be decoded, so adding port 22 will only yield false positives. Typically port 23 will be included.

88.
normalize

This option tells the preprocessor to normalize the telnet traffic by eliminating the telnet escape sequences. It functions similarly to its predecessor, the telnet_decode preprocessor. Rules written with 'raw' content options will ignore the normalized buffer that is created when this option is in use.

89.
ayt_attack_thresh number

This option causes the preprocessor to alert when the number of consecutive telnet Are You There (AYT) commands reaches the number specified. It is only applicable when the mode is stateful.

90.
detect_anomalies

In order to support certain options, Telnet supports subnegotiation. Per the Telnet RFC, subnegotiation begins with SB (subnegotiation begin) and must end with an SE (subnegotiation end). However, certain implementations of Telnet servers will ignore the SB without a corresponding SE. This is anomalous behavior which could be an evasion case. Being that FTP uses the Telnet protocol on the control connection, it is also susceptible to this behavior. The detect_anomalies option enables alerting on Telnet SB without the corresponding SE.

### 2.2.11.6 Example Telnet Configuration

    preprocessor ftp_telnet_protocol: \
telnet ports { 23 } normalize ayt_attack_thresh 6


### 2.2.11.7 FTP Server Configuration

There are two types of FTP server configurations: default and by IP address.

#### 2.2.11.7.1 Default

This configuration supplies the default server configuration for any FTP server that is not individually configured. Most of your FTP servers will most likely end up using the default configuration.

### 2.2.11.8 Example Default FTP Server Configuration

    preprocessor ftp_telnet_protocol: \
ftp server default ports { 21 }


Refer to for the list of options set in default ftp server configuration.

#### 2.2.11.8.1 Configuration by IP Address

This format is very similar to default'', the only difference being that specific IPs can be configured.

### 2.2.11.9 Example IP specific FTP Server Configuration

    preprocessor _telnet_protocol: \
ftp server 10.1.1.1 ports { 21 } ftp_cmds { XPWD XCWD }


### 2.2.11.10 FTP Server Configuration Options

91.
ports portport

This is how the user configures which ports to decode as FTP command channel traffic. Typically port 21 will be included.

92.
print_cmds

During initialization, this option causes the preprocessor to print the configuration for each of the FTP commands for this server.

93.
ftp_cmds

The preprocessor is configured to alert when it sees an FTP command that is not allowed by the server.

This option specifies a list of additional commands allowed by this server, outside of the default FTP command set as specified in RFC 959. This may be used to allow the use of the 'X' commands identified in RFC 775, as well as any additional commands as needed.

For example:

    ftp_cmds { XPWD XCWD XCUP XMKD XRMD }


94.
def_max_param_len number

This specifies the default maximum allowed parameter length for an FTP command. It can be used as a basic buffer overflow detection.

95.
alt_max_param_len number

This specifies the maximum allowed parameter length for the specified FTP command(s). It can be used as a more specific buffer overflow detection. For example the USER command - usernames may be no longer than 16 bytes, so the appropriate configuration would be:

    alt_max_param_len 16 { USER }


96.
chk_str_fmt

This option causes a check for string format attacks in the specified commands.

97.
cmd_validity cmd fmt

This option specifies the valid format for parameters of a given command.

fmt must be enclosed in 's and may contain the following:

Value Description
int Parameter must be an integer
number Parameter must be an integer between 1 and 255
char chars Parameter must be a single character, one of chars
date datefmt Parameter follows format specified, where:

 n Number C Character optional format enclosed OR choice of options . + - literal

string Parameter is a string (effectively unrestricted)
host_port Parameter must be a host/port specified, per RFC 959
long_host_port Parameter must be a long host port specified, per RFC 1639
extended_host_port Parameter must be an extended host port specified, per RFC 2428
, One of choices enclosed within, separated by
, One of the choices enclosed within , optional value enclosed within

Examples of the cmd_validity option are shown below. These examples are the default checks, per RFC 959 and others performed by the preprocessor.

    cmd_validity MODE <char SBC>
cmd_validity STRU <char FRP>
cmd_validity ALLO < int [ char R int ] >
cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } >
cmd_validity PORT < host_port >


A cmd_validity line can be used to override these defaults and/or add a check for other commands.

    # This allows additional modes, including mode Z which allows for
# zip-style compression.
cmd_validity MODE < char ASBCZ >

# Allow for a date in the MDTM command.
cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string >


MDTM is an off case that is worth discussing. While not part of an established standard, certain FTP servers accept MDTM commands that set the modification time on a file. The most common among servers that do, accept a format using YYYYMMDDHHmmss[.uuu]. Some others accept a format using YYYYMMDDHHmmss[+|-]TZ format. The example above is for the first case (time format as specified in http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt)

To check validity for a server that uses the TZ format, use the following:

    cmd_validity MDTM < [ date nnnnnnnnnnnnnn[{+|-}n[n]] ] string >


98.
telnet_cmds yesno

This option turns on detection and alerting when telnet escape sequences are seen on the FTP command channel. Injection of telnet escape sequences could be used as an evasion attempt on an FTP command channel.

99.
ignore_telnet_erase_cmds yes|no

This option allows Snort to ignore telnet escape sequences for erase character (TNC EAC) and erase line (TNC EAL) when normalizing FTP command channel. Some FTP servers do not process those telnet escape sequences.

100.
data_chan

This option causes the rest of snort (rules, other preprocessors) to ignore FTP data channel connections. Using this option means that NO INSPECTION other than TCP state will be performed on FTP data transfers. It can be used to improve performance, especially with large file transfers from a trusted source. If your rule set includes virus-type rules, it is recommended that this option not be used.

Use of the "data_chan" option is deprecated in favor of the "ignore_data_chan" option. "data_chan" will be removed in a future release.

101.
ignore_data_chan yesno

This option causes the rest of Snort (rules, other preprocessors) to ignore FTP data channel connections. Setting this option to "yes" means that NO INSPECTION other than TCP state will be performed on FTP data transfers. It can be used to improve performance, especially with large file transfers from a trusted source. If your rule set includes virus-type rules, it is recommended that this option not be used.

### 2.2.11.11 FTP Server Base Configuration Options

The base FTP server configuration is as follows. Options specified in the configuration file will modify this set of options. FTP commands are added to the set of allowed commands. The other options will override those in the base configuration.

    def_max_param_len 100
ftp_cmds { USER PASS ACCT CWD CDUP SMNT
QUIT REIN TYPE STRU MODE RETR
STOR STOU APPE ALLO REST RNFR
RNTO ABOR DELE RMD MKD PWD LIST
NLST SITE SYST STAT HELP NOOP }
ftp_cmds { AUTH ADAT PROT PBSZ CONF ENC }
ftp_cmds { PORT PASV LPRT LPSV EPRT EPSV }
ftp_cmds { FEAT OPTS }
ftp_cmds { MDTM REST SIZE MLST MLSD }
alt_max_param_len 0 { CDUP QUIT REIN PASV STOU ABOR PWD SYST NOOP }
cmd_validity MODE < char SBC >
cmd_validity STRU < char FRPO [ string ] >
cmd_validity ALLO < int [ char R int ] >
cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } >
cmd_validity PORT < host_port >
cmd_validity LPRT < long_host_port >
cmd_validity EPRT < extd_host_port >
cmd_validity EPSV < [ { '1' | '2' | 'ALL' } ] >


### 2.2.11.12 FTP Client Configuration

Similar to the FTP Server configuration, the FTP client configurations has two types: default, and by IP address.

#### 2.2.11.12.1 Default

This configuration supplies the default client configuration for any FTP client that is not individually configured. Most of your FTP clients will most likely end up using the default configuration.

### 2.2.11.13 Example Default FTP Client Configuration

    preprocessor ftp_telnet_protocol: \
ftp client default bounce no max_resp_len 200


#### 2.2.11.13.1 Configuration by IP Address

This format is very similar to default'', the only difference being that specific IPs can be configured.

### 2.2.11.14 Example IP specific FTP Client Configuration

    preprocessor ftp_telnet_protocol: \
ftp client 10.1.1.1 bounce yes max_resp_len 500


### 2.2.11.15 FTP Client Configuration Options

102.
max_resp_len number

This specifies the maximum allowed response length to an FTP command accepted by the client. It can be used as a basic buffer overflow detection.

103.
bounce yes|no

This option turns on detection and alerting of FTP bounce attacks. An FTP bounce attack occurs when the FTP PORT command is issued and the specified host does not match the host of the client.

104.
bounce_to CIDR,[portportlow,porthi]

When the bounce option is turned on, this allows the PORT command to use the IP address (in CIDR format) and port (or inclusive port range) without generating an alert. It can be used to deal with proxied FTP connections where the FTP data channel is different from the client.

A few examples:

• Allow bounces to 192.162.1.1 port 20020 - i.e., the use of PORT 192,168,1,1,78,52.

    bounce_to { 192.168.1.1,20020 }


• Allow bounces to 192.162.1.1 ports 20020 through 20040 - i.e., the use of PORT 192,168,1,1,78,xx, where xx is 52 through 72 inclusive.

    bounce_to { 192.168.1.1,20020,20040 }


• Allow bounces to 192.162.1.1 port 20020 and 192.168.1.2 port 20030.

    bounce_to { 192.168.1.1,20020 192.168.1.2,20030 }


• Allows bounces to IPv6 address fe8::5 port 59340.

    bounce_to { fe8::5,59340 }


105.
telnet_cmds yes|no

This option turns on detection and alerting when telnet escape sequences are seen on the FTP command channel. Injection of telnet escape sequences could be used as an evasion attempt on an FTP command channel.

106.
ignore_telnet_erase_cmds yes|no

This option allows Snort to ignore telnet escape sequences for erase character (TNC EAC) and erase line (TNC EAL) when normalizing FTP command channel. Some FTP clients do not process those telnet escape sequences.

### 2.2.11.16 Examples/Default Configuration from snort.conf

    preprocessor ftp_telnet: \
global \
encrypted_traffic yes \
inspection_type stateful

preprocessor ftp_telnet_protocol:\
telnet \
normalize \
ayt_attack_thresh 200

# This is consistent with the FTP rules as of 18 Sept 2004.
# Set CWD to allow parameter length of 200
# MODE has an additional mode of Z (compressed)
# Check for string formats in USER & PASS commands
# Check MDTM commands that set modification time on the file.

preprocessor ftp_telnet_protocol: \
ftp server default \
def_max_param_len 100 \
alt_max_param_len 200 { CWD } \
cmd_validity MODE < char ASBCZ > \
cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \
chk_str_fmt { USER PASS RNFR RNTO SITE MKD } \
telnet_cmds yes \
ignore_data_chan yes

preprocessor ftp_telnet_protocol: \
ftp client default \
max_resp_len 256 \
bounce yes \
telnet_cmds yes


## 2.2.12 SSH

The SSH preprocessor detects the following exploits: Challenge-Response Buffer Overflow, CRC 32, Secure CRT, and the Protocol Mismatch exploit.

Both Challenge-Response Overflow and CRC 32 attacks occur after the key exchange, and are therefore encrypted. Both attacks involve sending a large payload (20kb+) to the server immediately after the authentication challenge. To detect the attacks, the SSH preprocessor counts the number of bytes transmitted to the server. If those bytes exceed a predefined limit within a predefined number of packets, an alert is generated. Since the Challenge-Response Overflow only effects SSHv2 and CRC 32 only effects SSHv1, the SSH version string exchange is used to distinguish the attacks.

The Secure CRT and protocol mismatch exploits are observable before the key exchange.

### 2.2.12.1 Configuration

By default, all alerts are disabled and the preprocessor checks traffic on port 22.

The available configuration options are described below.

107.
server_ports portport

This option specifies which ports the SSH preprocessor should inspect traffic to.

108.
max_encrypted_packets number

The number of stream reassembled encrypted packets that Snort will inspect before ignoring a given SSH session. The SSH vulnerabilities that Snort can detect all happen at the very beginning of an SSH session. Once max_encrypted_packets packets have been seen, Snort ignores the session to increase performance. The default is set to 25. This value can be set from 0 to 65535.

109.
max_client_bytes number

The number of unanswered bytes allowed to be transferred before alerting on Challenge-Response Overflow or CRC 32. This number must be hit before max_encrypted_packets packets are sent, or else Snort will ignore the traffic. The default is set to 19600. This value can be set from 0 to 65535.

110.
max_server_version_len number

The maximum number of bytes allowed in the SSH server version string before alerting on the Secure CRT server version string overflow. The default is set to 80. This value can be set from 0 to 255.

111.
autodetect

Attempt to automatically detect SSH.

112.
enable_respoverflow

Enables checking for the Challenge-Response Overflow exploit.

113.
enable_ssh1crc32

Enables checking for the CRC 32 exploit.

114.
enable_srvoverflow

Enables checking for the Secure CRT exploit.

115.
enable_protomismatch

Enables checking for the Protocol Mismatch exploit.

116.

Enable alerts for traffic flowing the wrong direction. For instance, if the presumed server generates client traffic, or if a client generates server traffic.

117.
enable_paysize

118.
enable_recognition

Enable alerts for non-SSH traffic on SSH ports.

The SSH preprocessor should work by default. After max_encrypted_packets is reached, the preprocessor will stop processing traffic for a given session. If Challenge-Response Overflow or CRC 32 false positive, try increasing the number of required client bytes with max_client_bytes.

### 2.2.12.2 Example Configuration from snort.conf

Looks for attacks on SSH server port 22. Alerts at 19600 unacknowledged bytes within 20 encrypted packets for the Challenge-Response Overflow/CRC32 exploits.

    preprocessor ssh: \
server_ports { 22 } \
max_client_bytes 19600 \
max_encrypted_packets 20 \
enable_respoverflow \
enable_ssh1crc32


## 2.2.13 DNS

The DNS preprocessor decodes DNS Responses and can detect the following exploits: DNS Client RData Overflow, Obsolete Record Types, and Experimental Record Types.

DNS looks at DNS Response traffic over UDP and TCP and it requires Stream preprocessor to be enabled for TCP decoding.

### 2.2.13.1 Configuration

By default, all alerts are disabled and the preprocessor checks traffic on port 53.

The available configuration options are described below.

119.
ports portport

This option specifies the source ports that the DNS preprocessor should inspect traffic.

120.
enable_obsolete_types

Alert on Obsolete (per RFC 1035) Record Types

121.
enable_experimental_types

Alert on Experimental (per RFC 1035) Record Types

122.
enable_rdata_overflow

Check for DNS Client RData TXT Overflow

The DNS preprocessor does nothing if none of the 3 vulnerabilities it checks for are enabled. It will not operate on TCP sessions picked up midstream, and it will cease operation on a session if it loses state because of missing data (dropped packets).

### 2.2.13.2 Examples/Default Configuration from snort.conf

Looks for traffic on DNS server port 53. Check for the DNS Client RData overflow vulnerability. Do not alert on obsolete or experimental RData record types.

    preprocessor dns: \
ports { 53 } \
enable_rdata_overflow


## 2.2.14 SSL/TLS

Encrypted traffic should be ignored by Snort for both performance reasons and to reduce false positives. The SSL Dynamic Preprocessor (SSLPP) decodes SSL and TLS traffic and optionally determines if and when Snort should stop inspection of it.

Typically, SSL is used over port 443 as HTTPS. By enabling the SSLPP to inspect port 443 and enabling the noinspect_encrypted option, only the SSL handshake of each connection will be inspected. Once the traffic is determined to be encrypted, no further inspection of the data on the connection is made.

By default, SSLPP looks for a handshake followed by encrypted traffic traveling to both sides. If one side responds with an indication that something has failed, such as the handshake, the session is not marked as encrypted. Verifying that faultless encrypted traffic is sent from both endpoints ensures two things: the last client-side handshake packet was not crafted to evade Snort, and that the traffic is legitimately encrypted.

In some cases, especially when packets may be missed, the only observed response from one endpoint will be TCP ACKs. Therefore, if a user knows that server-side encrypted data can be trusted to mark the session as encrypted, the user should use the 'trustservers' option, documented below.

### 2.2.14.1 Configuration

123.
ports portport

This option specifies which ports SSLPP will inspect traffic on.

By default, SSLPP watches the following ports:

• 443 HTTPS
• 465 SMTPS
• 563 NNTPS
• 636 LDAPS
• 989 FTPS
• 992 TelnetS
• 993 IMAPS
• 994 IRCS
• 995 POPS

124.
noinspect_encrypted

Disable inspection on traffic that is encrypted. Default is off.

125.
max_heartbeat_length

Maximum length of heartbeat record allowed. This config option is used to detect the heartbleed attacks. The allowed range is 0 to 65535. Setting the value to 0 turns off the heartbeat length checks. For heartbeat requests, if the payload size of the request record is greater than the max_heartbeat_length an alert with sid 3 and gid 137 is generated. For heartbeat responses, if the record size itself is greater than the max_heartbeat_length an alert with sid 4 and gid 137 is generated. Default is off.

126.
trustservers

Disables the requirement that application (encrypted) data must be observed on both sides of the session before a session is marked encrypted. Use this option for slightly better performance if you trust that your servers are not compromised. This requires the noinspect_encrypted option to be useful. Default is off.

### 2.2.14.2 Examples/Default Configuration from snort.conf

Enables the SSL preprocessor and tells it to disable inspection on encrypted traffic.

    preprocessor ssl: noinspect_encrypted


### 2.2.14.3 Rule Options

The following rule options are supported by enabling the ssl preprocessor:

    ssl_version
ssl_state


ssl_version

The ssl_version rule option tracks the version negotiated between the endpoints of the SSL encryption. The list of version identifiers are below, and more than one identifier can be specified, via a comma separated list. Lists of identifiers are OR'ed together.

The option will match if any one of the OR'ed versions are used in the SSL connection. To check for two or more SSL versions in use simultaneously, multiple ssl_version rule options should be used.

Syntax

   ssl_version: <version-list>

version-list = version | version , version-list
version      = ["!"] "sslv2" | "sslv3" | "tls1.0" | "tls1.1" | "tls1.2"


Examples

   ssl_version:sslv3;
ssl_version:tls1.0,tls1.1,tls1.2;
ssl_version:!sslv2;


ssl_state

The ssl_state rule option tracks the state of the SSL encryption during the process of hello and key exchange. The list of states are below. More than one state can be specified, via a comma separated list, and are OR'ed together.

The option will match if the connection is currently in any one of the OR'ed states. To ensure the connection has reached each of a set of states, multiple rules using the ssl_state rule option should be used.

Syntax

   ssl_state: <state-list>

state-list = state | state , state-list
state      = ["!"] "client_hello" | "server_hello" | "client_keyx" | "server_keyx" | "unknown"


Examples

   ssl_state:client_hello;
ssl_state:client_keyx,server_keyx;
ssl_state:!server_hello;


## 2.2.15 ARP Spoof Preprocessor

The ARP spoof preprocessor decodes ARP packets and detects ARP attacks, unicast ARP requests, and inconsistent Ethernet to IP mapping.

When no arguments are specified to arpspoof, the preprocessor inspects Ethernet addresses and the addresses in the ARP packets. When inconsistency occurs, an alert with GID 112 and SID 2 or 3 is generated.

When "-unicast" is specified as the argument of arpspoof, the preprocessor checks for unicast ARP requests. An alert with GID 112 and SID 1 will be generated if a unicast ARP request is detected.

Specify a pair of IP and hardware address as the argument to arpspoof_detect_host. The host with the IP address should be on the same layer 2 segment as Snort is. Specify one host IP MAC combo per line. The preprocessor will use this list when detecting ARP cache overwrite attacks. Alert SID 4 is used in this case.

### 2.2.15.1 Format

    preprocessor arpspoof[: -unicast]
preprocessor arpspoof_detect_host: ip mac


Option Description
mac The Ethernet address corresponding to the preceding IP.

### 2.2.15.2 Example Configuration

The first example configuration does neither unicast detection nor ARP mapping monitoring. The preprocessor merely looks for Ethernet address inconsistencies.

    preprocessor arpspoof


The next example configuration does not do unicast detection but monitors ARP mapping for hosts 192.168.40.1 and 192.168.40.2.

    preprocessor arpspoof
preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00
preprocessor arpspoof_detect_host: 192.168.40.2 f0:0f:00:f0:0f:01


The third example configuration has unicast detection enabled.

    preprocessor arpspoof: -unicast
preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00
preprocessor arpspoof_detect_host: 192.168.40.2 f0:0f:00:f0:0f:01


## 2.2.16 DCE/RPC 2 Preprocessor

The main purpose of the preprocessor is to perform SMB desegmentation and DCE/RPC defragmentation to avoid rule evasion using these techniques. SMB desegmentation is performed for the following commands that can be used to transport DCE/RPC requests and responses: Write, Write Block Raw, Write and Close, Write AndX, Transaction, Transaction Secondary, Read, Read Block Raw and Read AndX. The following transports are supported for DCE/RPC: SMB, TCP, UDP and RPC over HTTP v.1 proxy and server. New rule options have been implemented to improve performance, reduce false positives and reduce the count and complexity of DCE/RPC based rules.

### 2.2.16.1 Dependency Requirements

For proper functioning of the preprocessor:

• Stream session tracking must be enabled, i.e. stream5. The preprocessor requires a session tracker to keep its data.

• Stream reassembly must be performed for TCP sessions. If it is decided that a session is SMB or DCE/RPC, either through configured ports, servers or autodetecting, the dcerpc2 preprocessor will enable stream reassembly for that session if necessary.

• IP defragmentation should be enabled, i.e. the frag3 preprocessor should be enabled and configured.

### 2.2.16.2 Target Based

There are enough important differences between Windows and Samba versions that a target based approach has been implemented. Some important differences:

Named pipe instance tracking

A combination of valid login handle or UID, share handle or TID and file/named pipe handle or FID must be used to write data to a named pipe. The binding between these is dependent on OS/software version.

Samba 3.0.22 and earlier

Any valid UID and TID, along with a valid FID can be used to make a request, however, if the TID used in creating the FID is deleted (via a tree disconnect), the FID that was created using this TID becomes invalid, i.e. no more requests can be written to that named pipe instance.

Samba greater than 3.0.22

Any valid TID, along with a valid FID can be used to make a request. However, only the UID used in opening the named pipe can be used to make a request using the FID handle to the named pipe instance. If the TID used to create the FID is deleted (via a tree disconnect), the FID that was created using this TID becomes invalid, i.e. no more requests can be written to that named pipe instance. If the UID used to create the named pipe instance is deleted (via a Logoff AndX), since it is necessary in making a request to the named pipe, the FID becomes invalid.

Windows 2003
Windows XP
Windows Vista

These Windows versions require strict binding between the UID, TID and FID used to make a request to a named pipe instance. Both the UID and TID used to open the named pipe instance must be used when writing data to the same named pipe instance. Therefore, deleting either the UID or TID invalidates the FID.

Windows 2000

Windows 2000 is interesting in that the first request to a named pipe must use the same binding as that of the other Windows versions. However, requests after that follow the same binding as Samba 3.0.22 and earlier, i.e. no binding. It also follows Samba greater than 3.0.22 in that deleting the UID or TID used to create the named pipe instance also invalidates it.

Accepted SMB commands

Samba in particular does not recognize certain commands under an IPC$tree. Samba (all versions) Under an IPC$ tree, does not accept:
Open
Write And Close
Write Block Raw

Windows (all versions)
Accepts all of the above commands under an IPC$tree. AndX command chaining Windows is very strict in what command combinations it allows to be chained. Samba, on the other hand, is very lax and allows some nonsensical combinations, e.g. multiple logins and tree connects (only one place to return handles for these), login/logoff and tree connect/tree disconnect. Ultimately, we don't want to keep track of data that the server won't accept. An evasion possibility would be accepting a fragment in a request that the server won't accept that gets sandwiched between an exploit. Transaction tracking The differences between a Transaction request and using one of the Write* commands to write data to a named pipe are that (1) a Transaction performs the operations of a write and a read from the named pipe, whereas in using the Write* commands, the client has to explicitly send one of the Read* requests to tell the server to send the response and (2) a Transaction request is not written to the named pipe until all of the data is received (via potential Transaction Secondary requests) whereas with the Write* commands, data is written to the named pipe as it is received by the server. Multiple Transaction requests can be made simultaneously to the same named pipe. These requests can also be segmented with Transaction Secondary commands. What distinguishes them (when the same named pipe is being written to, i.e. having the same FID) are fields in the SMB header representing a process id (PID) and multiplex id (MID). The PID represents the process this request is a part of. An MID represents different sub-processes within a process (or under a PID). Segments for each "thread" are stored separately and written to the named pipe when all segments are received. It is necessary to track this so as not to munge these requests together (which would be a potential evasion opportunity). Windows (all versions) Uses a combination of PID and MID to define a "thread". Samba (all versions) Uses just the MID to define a "thread". Multiple Bind Requests A Bind request is the first request that must be made in a connection-oriented DCE/RPC session in order to specify the interface/interfaces that one wants to communicate with. Windows (all versions) For all of the Windows versions, only one Bind can ever be made on a session whether or not it succeeds or fails. Any binding after that must use the Alter Context request. If another Bind is made, all previous interface bindings are invalidated. Samba 3.0.20 and earlier Any amount of Bind requests can be made. Samba later than 3.0.20 Another Bind request can be made if the first failed and no interfaces were successfully bound to. If a Bind after a successful Bind is made, all previous interface bindings are invalidated. DCE/RPC Fragmented requests - Context ID Each fragment in a fragmented request carries the context id of the bound interface it wants to make the request to. Windows (all versions) The context id that is ultimately used for the request is contained in the first fragment. The context id field in any other fragment can contain any value. Samba (all versions) The context id that is ultimately used for the request is contained in the last fragment. The context id field in any other fragment can contain any value. DCE/RPC Fragmented requests - Operation number Each fragment in a fragmented request carries an operation number (opnum) which is more or less a handle to a function offered by the interface. Samba (all versions) Windows 2000 Windows 2003 Windows XP The opnum that is ultimately used for the request is contained in the last fragment. The opnum field in any other fragment can contain any value. Windows Vista The opnum that is ultimately used for the request is contained in the first fragment. The opnum field in any other fragment can contain any value. DCE/RPC Stub data byte order The byte order of the stub data is determined differently for Windows and Samba. Windows (all versions) The byte order of the stub data is that which was used in the Bind request. Samba (all versions) The byte order of the stub data is that which is used in the request carrying the stub data. ### 2.2.16.3 Configuration The dcerpc2 preprocessor has a global configuration and one or more server configurations. The global preprocessor configuration name is dcerpc2 and the server preprocessor configuration name is dcerpc2_server. Global Configuration  preprocessor dcerpc2  The global dcerpc2 configuration is required. Only one global dcerpc2 configuration can be specified. Option syntax  Option Argument Required Default memcap NO memcap 102400 disable_defrag NONE NO OFF max_frag_len NO OFF events NO OFF reassemble_threshold NO OFF disabled NONE NO OFF smb_fingerprint_policy NO OFF smb_legacy_mode NONE NO OFF  memcap = 1024-4194303 (kilobytes) max-frag-len = 1514-65535 events = pseudo-event | event | '[' event-list ']' pseudo-event = "none" | "all" event-list = event | event ',' event-list event = "memcap" | "smb" | "co" | "cl" re-thresh = 0-65535 fp-policy = "server" | "client" | "both"  Option explanations memcap Specifies the maximum amount of run-time memory that can be allocated. Run-time memory includes any memory allocated after configuration. Default is 100 MB. disabled Disables the preprocessor. By default this value is turned off. When the preprocessor is disabled only the memcap option is applied when specified with the configuration. disable_defrag Tells the preprocessor not to do DCE/RPC defragmentation. Default is to do defragmentation. max_frag_len Specifies the maximum fragment size that will be added to the defragmentation module. If a fragment is greater than this size, it is truncated before being added to the defragmentation module. The allowed range for this option is 1514 - 65535. events Specifies the classes of events to enable. (See Events section for an enumeration and explanation of events.) memcap Only one event. If the memcap is reached or exceeded, alert. smb Alert on events related to SMB processing. co Stands for connection-oriented DCE/RPC. Alert on events related to connection-oriented DCE/RPC processing. cl Stands for connectionless DCE/RPC. Alert on events related to connectionless DCE/RPC processing. reassemble_threshold Specifies a minimum number of bytes in the DCE/RPC desegmentation and defragmentation buffers before creating a reassembly packet to send to the detection engine. This option is useful in inline mode so as to potentially catch an exploit early before full defragmentation is done. A value of 0 supplied as an argument to this option will, in effect, disable this option. Default is disabled. smb_fingerprint_policy By default, SMBv1, SMBv2, and SMBv3 files are inspected. If legacy mode is configured, only SMBv1 file inspection is enabled. legacy_mode In the initial phase of an SMB session, the client needs to authenticate with a SessionSetupAndX. Both the request and response to this command contain OS and version information that can allow the preprocessor to dynamically set the policy for a session which allows for better protection against Windows and Samba specific evasions. Option examples  memcap 30000 max_frag_len 16840 events none events all events smb events co events [co] events [smb, co] events [memcap, smb, co, cl] reassemble_threshold 500 smb_fingerprint_policy both smb_fingerprint_policy client smb_legacy_mode  Configuration examples  preprocessor dcerpc2 preprocessor dcerpc2: memcap 500000 preprocessor dcerpc2: max_frag_len 16840, memcap 300000, events smb preprocessor dcerpc2: memcap 50000, events [memcap, smb, co, cl], max_frag_len 14440 preprocessor dcerpc2: disable_defrag, events [memcap, smb] preprocessor dcerpc2: reassemble_threshold 500 preprocessor dcerpc2: memcap 50000, events [memcap, smb, co, cl], max_frag_len 14440, smb_fingerprint_policy both  Default global configuration  preprocessor dcerpc2: memcap 102400  Server Configuration  preprocessor dcerpc2_server  The dcerpc2_server configuration is optional. A dcerpc2_server configuration must start with default or net options. The default and net options are mutually exclusive. At most one default configuration can be specified. If no default configuration is specified, default values will be used for the default configuration. Zero or more net configurations can be specified. For any dcerpc2_server configuration, if non-required options are not specified, the defaults will be used. When processing DCE/RPC traffic, the default configuration is used if no net configurations match. If a net configuration matches, it will override the default configuration. A net configuration matches if the packet's server IP address matches an IP address or net specified in the net configuration. The net option supports IPv6 addresses. Note that port and ip variables defined in snort.conf CANNOT be used. Option syntax  Option Argument Required Default default NONE YES NONE net YES NONE policy NO policy WinXP detect NO detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593] autodetect NO autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:] no_autodetect_http_proxy_ports NONE NO DISABLED (The preprocessor autodetects on all proxy ports by default) smb_invalid_shares NO NONE smb_max_chain NO smb_max_chain 3 smb_file_inspection NO smb_file_inspection off  net = ip | '[' ip-list ']' ip-list = ip | ip ',' ip-list ip = ip-addr | ip-addr '/' prefix | ip4-addr '/' netmask ip-addr = ip4-addr | ip6-addr ip4-addr = a valid IPv4 address ip6-addr = a valid IPv6 address (can be compressed) prefix = a valid CIDR netmask = a valid netmask policy = "Win2000" | "Win2003" | "WinXP" | "WinVista" | "Samba" | "Samba-3.0.22" | "Samba-3.0.20" detect = "none" | detect-opt | '[' detect-list ']' detect-list = detect-opt | detect-opt ',' detect-list detect-opt = transport | transport port-item | transport '[' port-list ']' transport = "smb" | "tcp" | "udp" | "rpc-over-http-proxy" | "rpc-over-http-server" port-list = port-item | port-item ',' port-list port-item = port | port-range port-range = ':' port | port ':' | port ':' port port = 0-65535 shares = share | '[' share-list ']' share-list = share | share ',' share-list share = word | '"' word '"' | '"' var-word '"' word = graphical ASCII characters except ',' '"' ']' '[' '$'
var-word     = graphical ASCII characters except ',' '"' ']' '['
max-chain    = 0-255
file-inspect = file-arg | '[' file-list ']'
file-arg     = "off" | "on" | "only"
file-list    = file-arg [ ',' "file-depth" <int64_t> ]


Because the Snort main parser treats '$' as the start of a variable and tries to expand it, shares with '$' must be enclosed quotes.

Option explanations

default

Specifies that this configuration is for the default server configuration.

net

Specifies that this configuration is an IP or net specific configuration. The configuration will only apply to the IP addresses and nets supplied as an argument.

policy

Specifies the target-based policy to use when processing. Default is "WinXP".

detect

Specifies the DCE/RPC transport and server ports that should be detected on for the transport. Defaults are ports 139 and 445 for SMB, 135 for TCP and UDP, 593 for RPC over HTTP server and 80 for RPC over HTTP proxy.

autodetect

Specifies the DCE/RPC transport and server ports that the preprocessor should attempt to autodetect on for the transport. The autodetect ports are only queried if no detect transport/ports match the packet. The order in which the preprocessor will attempt to autodetect will be - TCP/UDP, RPC over HTTP server, RPC over HTTP proxy and lastly SMB. Note that most dynamic DCE/RPC ports are above 1024 and ride directly over TCP or UDP. It would be very uncommon to see SMB on anything other than ports 139 and 445. Defaults are 1025-65535 for TCP, UDP and RPC over HTTP server.

no_autodetect_http_proxy_ports

By default, the preprocessor will always attempt to autodetect for ports specified in the detect configuration for rpc-over-http-proxy. This is because the proxy is likely a web server and the preprocessor should not look at all web traffic. This option is useful if the RPC over HTTP proxy configured with the detect option is only used to proxy DCE/RPC traffic. Default is to autodetect on RPC over HTTP proxy detect ports.

smb_invalid_shares

Specifies SMB shares that the preprocessor should alert on if an attempt is made to connect to them via a Tree Connect or Tree Connect AndX. Default is empty.

smb_max_chain

Specifies the maximum amount of AndX command chaining that is allowed before an alert is generated. Default maximum is 3 chained commands. A value of 0 disables this option. This value can be set from 0 to 255.

smb_file_inspection

Instructs the preprocessor to do inspection of normal SMB file transfers. This includes doing file type and signature through the file API as well as setting a pointer for the file_data rule option. Note that the file-depth option only applies to the maximum amount of file data for which it will set the pointer for the file_data rule option. For file type and signature it will use the value configured for the file API. If only is specified, the preprocessor will only do SMB file inspection, i.e. it will not do any DCE/RPC tracking or inspection. If on is specified with no arguments, the default file depth is 16384 bytes. An argument of -1 to file-depth disables setting the pointer for file_data, effectively disabling SMB file inspection in rules. An argument of 0 to file-depth means unlimited. Default is off, i.e. no SMB file inspection is done in the preprocessor. SMBv1, SMBv2, and SMBv3 are supported.

Option examples

    net 192.168.0.10
net 192.168.0.0/24
net [192.168.0.0/24]
net 192.168.0.0/255.255.255.0
net feab:45b3:ab92:8ac4:d322:007f:e5aa:7845
net feab:45b3:ab92:8ac4:d322:007f:e5aa:7845/128
net feab:45b3::/32
net [192.168.0.10, feab:45b3::/32]
net [192.168.0.0/24, feab:45b3:ab92:8ac4:d322:007f:e5aa:7845]
policy Win2000
policy Samba-3.0.22
detect none
detect smb
detect [smb]
detect smb 445
detect [smb 445]
detect smb [139,445]
detect [smb [139,445]]
detect [smb, tcp]
detect [smb 139, tcp [135,2103]]
detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server [593,6002:6004]]
autodetect none
autodetect tcp
autodetect [tcp]
autodetect tcp 2025:
autodetect [tcp 2025:]
autodetect tcp [2025:3001,3003:]
autodetect [tcp [2025:3001,3003:]]
autodetect [tcp, udp]
autodetect [tcp 2025:, udp 2025:]
autodetect [tcp 2025:, udp, rpc-over-http-server [1025:6001,6005:]]
smb_invalid_shares private
smb_invalid_shares "private"
smb_invalid_shares "C$" smb_invalid_shares [private, "C$"]
smb_invalid_shares ["private", "C$"] smb_max_chain 1 smb_file_inspection on smb_file_inspection off smb_file_inspection [ on, file-depth -1 ] smb_file_inspection [ on, file-depth 0 ] smb_file_inspection [ on, file-depth 4294967296 ] smb_file_inspection [ only, file-depth -1 ]  Configuration examples  preprocessor dcerpc2_server: \ default preprocessor dcerpc2_server: \ default, policy Win2000 preprocessor dcerpc2_server: \ default, policy Win2000, detect [smb, tcp], autodetect tcp 1025:, \ smb_invalid_shares ["C$", "D$", "ADMIN$"]

preprocessor dcerpc2_server: net 10.4.10.0/24, policy Win2000

preprocessor dcerpc2_server: \
net [10.4.10.0/24,feab:45b3::/126], policy WinVista, smb_max_chain 1

preprocessor dcerpc2_server: \
net [10.4.10.0/24,feab:45b3::/126], policy WinVista, \
detect [smb, tcp, rpc-over-http-proxy 8081],
autodetect [tcp, rpc-over-http-proxy [1025:6001,6005:]], \
smb_invalid_shares ["C$", "ADMIN$"], no_autodetect_http_proxy_ports

preprocessor dcerpc2_server: \
net [10.4.11.56,10.4.11.57], policy Samba, detect smb, autodetect none

preprocessor dcerpc2_server: default, policy WinXP, \
smb_file_inspection [ on, file-depth 0 ]


Default server configuration

    preprocessor dcerpc2_server: default, policy WinXP, \
detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
smb_max_chain 3, smb_file_inspection off


Complete dcerpc2 default configuration

    preprocessor dcerpc2: memcap 102400

preprocessor dcerpc2_server: \
default, policy WinXP, \
detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
smb_max_chain 3, smb_file_inspection off


### 2.2.16.4 Events

The preprocessor uses GID 133 to register events.

Memcap events

 SID Description 1 If the memory cap is reached and the preprocessor is configured to alert.

SMB events

Connection-oriented DCE/RPC events

Connectionless DCE/RPC events

 SID Description 40 The preprocessor will alert if the connectionless DCE/RPC major version is not equal to 4. 41 The preprocessor will alert if the connectionless DCE/RPC PDU type is not a valid PDU type. 42 The preprocessor will alert if the packet data length is less than the size of the connectionless header. 43 The preprocessor will alert if the sequence number uses in a request is the same or less than a previously used sequence number on the session. In testing, wrapping the sequence number space produces strange behavior from the server, so this should be considered anomalous behavior.

### 2.2.16.5 Rule Options

New rule options are supported by enabling the dcerpc2 preprocessor:

    dce_iface
dce_opnum
dce_stub_data


New modifiers to existing byte_test and byte_jump rule options:

    byte_test:dce
byte_jump:dce


dce_iface

For DCE/RPC based rules it has been necessary to set flow-bits based on a client bind to a service to avoid false positives. It is necessary for a client to bind to a service before being able to make a call to it. When a client sends a bind request to the server, it can, however, specify one or more service interfaces to bind to. Each interface is represented by a UUID. Each interface UUID is paired with a unique index (or context id) that future requests can use to reference the service that the client is making a call to. The server will respond with the interface UUIDs it accepts as valid and will allow the client to make requests to those services. When a client makes a request, it will specify the context id so the server knows what service the client is making a request to. Instead of using flow-bits, a rule can simply ask the preprocessor, using this rule option, whether or not the client has bound to a specific interface UUID and whether or not this client request is making a request to it. This can eliminate false positives where more than one service is bound to successfully since the preprocessor can correlate the bind UUID to the context id used in the request. A DCE/RPC request can specify whether numbers are represented as big endian or little endian. The representation of the interface UUID is different depending on the endianness specified in the DCE/RPC previously requiring two rules - one for big endian and one for little endian. The preprocessor eliminates the need for two rules by normalizing the UUID. An interface contains a version. Some versions of an interface may not be vulnerable to a certain exploit. Also, a DCE/RPC request can be broken up into 1 or more fragments. Flags (and a field in the connectionless header) are set in the DCE/RPC header to indicate whether the fragment is the first, a middle or the last fragment. Many checks for data in the DCE/RPC request are only relevant if the DCE/RPC request is a first fragment (or full request), since subsequent fragments will contain data deeper into the DCE/RPC request. A rule which is looking for data, say 5 bytes into the request (maybe it's a length field), will be looking at the wrong data on a fragment other than the first, since the beginning of subsequent fragments are already offset some length from the beginning of the request. This can be a source of false positives in fragmented DCE/RPC traffic. By default it is reasonable to only evaluate if the request is a first fragment (or full request). However, if the any_frag option is used to specify evaluating on all fragments.

Syntax

    dce_iface:<uuid>[, <operator><version>][, any_frag];

uuid       = hexlong '-' hexshort '-' hexshort '-' 2hexbyte '-' 6hexbyte
hexlong    = 4hexbyte
hexshort   = 2hexbyte
hexbyte    = 2HEXDIGIT
operator   = '<' | '>' | '=' | '!'
version    = 0-65535

Examples
    dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188;
dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, <2;
dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, any_frag;
dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, =1, any_frag;


This option is used to specify an interface UUID. Optional arguments are an interface version and operator to specify that the version be less than ('<'), greater than ('>'), equal to ('=') or not equal to ('!') the version specified. Also, by default the rule will only be evaluated for a first fragment (or full request, i.e. not a fragment) since most rules are written to start at the beginning of a request. The any_frag argument says to evaluate for middle and last fragments as well. This option requires tracking client Bind and Alter Context requests as well as server Bind Ack and Alter Context responses for connection-oriented DCE/RPC in the preprocessor. For each Bind and Alter Context request, the client specifies a list of interface UUIDs along with a handle (or context id) for each interface UUID that will be used during the DCE/RPC session to reference the interface. The server response indicates which interfaces it will allow the client to make requests to - it either accepts or rejects the client's wish to bind to a certain interface. This tracking is required so that when a request is processed, the context id used in the request can be correlated with the interface UUID it is a handle for.

hexlong and hexshort will be specified and interpreted to be in big endian order (this is usually the default way an interface UUID will be seen and represented). As an example, the following Messenger interface UUID as taken off the wire from a little endian Bind request:

    |f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc|


must be written as:

    5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc


The same UUID taken off the wire from a big endian Bind request:

    |5a 7b 91 f8 ff 00 11 d0 a9 b2 00 c0 4f b6 e6 fc|


must be written the same way:

    5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc


This option matches if the specified interface UUID matches the interface UUID (as referred to by the context id) of the DCE/RPC request and if supplied, the version operation is true. This option will not match if the fragment is not a first fragment (or full request) unless the any_frag option is supplied in which case only the interface UUID and version need match. Note that a defragmented DCE/RPC request will be considered a full request.

 Note:   Using this rule option will automatically insert fast pattern contents into the fast pattern matcher. For UDP rules, the interface UUID, in both big and little endian format will be inserted into the fast pattern matcher. For TCP rules, (1) if the rule option flow:to_server|from_client is used, 05 00 00 will be inserted into the fast pattern matcher, (2) if the rule option flow:from_server|to_client is used, 05 00 02 will be inserted into the fast pattern matcher and (3) if the flow isn't known, 05 00 will be inserted into the fast pattern matcher. Note that if the rule already has content rule options in it, the best (meaning longest) pattern will be used. If a content in the rule uses the fast_pattern rule option, it will unequivocally be used over the above mentioned patterns.

dce_opnum

The opnum represents a specific function call to an interface. After is has been determined that a client has bound to a specific interface and is making a request to it (see above - dce_iface) usually we want to know what function call it is making to that service. It is likely that an exploit lies in the particular DCE/RPC function call.

Syntax

    dce_opnum:<opnum-list>;

opnum-list   = opnum-item | opnum-item ',' opnum-list
opnum-item   = opnum | opnum-range
opnum-range  = opnum '-' opnum
opnum        = 0-65535

Examples
    dce_opnum:15;
dce_opnum:15-18;
dce_opnum:15, 18-20;
dce_opnum:15, 17, 20-22;


This option is used to specify an opnum (or operation number), opnum range or list containing either or both opnum and/or opnum-range. The opnum of a DCE/RPC request will be matched against the opnums specified with this option. This option matches if any one of the opnums specified match the opnum of the DCE/RPC request.

dce_stub_data

Since most netbios rules were doing protocol decoding only to get to the DCE/RPC stub data, i.e. the remote procedure call or function call data, this option will alleviate this need and place the cursor at the beginning of the DCE/RPC stub data. This reduces the number of rule option checks and the complexity of the rule.

This option takes no arguments.

Example

    dce_stub_data;


This option is used to place the cursor (used to walk the packet payload in rules processing) at the beginning of the DCE/RPC stub data, regardless of preceding rule options. There are no arguments to this option. This option matches if there is DCE/RPC stub data.

The cursor is moved to the beginning of the stub data. All ensuing rule options will be considered "sticky" to this buffer. The first rule option following dce_stub_data should use absolute location modifiers if it is position-dependent. Subsequent rule options should use a relative modifier if they are meant to be relative to a previous rule option match in the stub data buffer. Any rule option that does not specify a relative modifier will be evaluated from the start of the stub data buffer. To leave the stub data buffer and return to the main payload buffer, use the pkt_data rule option - see section for details).

byte_test and byte_jump with dce
A DCE/RPC request can specify whether numbers are represented in big or little endian. These rule options will take as a new argument dce and will work basically the same as the normal byte_test/byte_jump, but since the DCE/RPC preprocessor will know the endianness of the request, it will be able to do the correct conversion.

byte_test

Syntax
    byte_test:<convert>, [!]<operator>, <value>, <offset> [, relative], dce;

convert    = 1 | 2 | 4 (only with option "dce")
operator   = '<' | '=' | '>' | '<=' | '>=' | '&' | '^'
value      = 0 - 4294967295
offset     = -65535 to 65535


Examples

    byte_test:4, >, 35000, 0, relative, dce;
byte_test:2, !=, 2280, -10, relative, dce;


When using the dce argument to a byte_test, the following normal byte_test arguments will not be allowed: big, little, string, hex, dec and oct.

byte_jump

Syntax
    byte_jump:<convert>, <offset>[, relative][, multiplier <mult_value>] \

convert           = 1 | 2 | 4 (only with option "dce")
offset            = -65535 to 65535
mult_value        = 0 - 65535


Example

    byte_jump:4,-4,relative,align,multiplier 2,post_offset -4,dce;


When using the dce argument to a byte_jump, the following normal byte_jump arguments will not be allowed: big, little, string, hex, dec, oct and from_beginning.

Example of rule complexity reduction

The following two rules using the new rule options replace 64 (set and isset flowbit) rules that are necessary if the new rule options are not used:

    alert tcp $EXTERNAL_NET any ->$HOME_NET [135,139,445,593,1024:] \
(msg:"dns R_Dnssrv funcs2 overflow attempt"; flow:established,to_server; \
dce_iface:50abc2a4-574d-40b3-9d66-ee4fd5fba076; dce_opnum:0-11; dce_stub_data; \
pcre:"/^.{12}(\x00\x00\x00\x00|.{12})/s"; byte_jump:4,-4,relative,align,dce; \
byte_test:4,>,256,4,relative,dce; reference:bugtraq,23470; reference:cve,2007-1748; \

alert udp $EXTERNAL_NET any ->$HOME_NET [135,1024:] \
(msg:"dns R_Dnssrv funcs2 overflow attempt"; flow:established,to_server; \
dce_iface:50abc2a4-574d-40b3-9d66-ee4fd5fba076; dce_opnum:0-11; dce_stub_data; \
pcre:"/^.{12}(\x00\x00\x00\x00|.{12})/s"; byte_jump:4,-4,relative,align,dce; \
byte_test:4,>,256,4,relative,dce; reference:bugtraq,23470; reference:cve,2007-1748; \


## 2.2.17 Sensitive Data Preprocessor

The Sensitive Data preprocessor is a Snort module that performs detection and filtering of Personally Identifiable Information (PII). This information includes credit card numbers, U.S. Social Security numbers, and email addresses. A limited regular expression syntax is also included for defining your own PII.

### 2.2.17.1 Dependencies

The Stream preprocessor must be enabled for the Sensitive Data preprocessor to work.

### 2.2.17.2 Preprocessor Configuration

Sensitive Data configuration is split into two parts: the preprocessor config, and the rule options. The preprocessor config starts with:

preprocessor sensitive_data:


Option syntax

    alert_threshold     =  1 - 65535


Option explanations

The preprocessor will alert when any combination of PII are detected in a session. This option specifies how many need to be detected before alerting. This should be set higher than the highest individual count in your "sd_pattern" rules.

This option replaces all but the last 4 digits of a detected PII with "X"s. This is only done on credit card & Social Security numbers, where an organization's regulations may prevent them from seeing unencrypted numbers.

ssn_file
A Social Security number is broken up into 3 sections: Area (3 digits), Group (2 digits), and Serial (4 digits). On a monthly basis, the Social Security Administration publishes a list of which Group numbers are in use for each Area. These numbers can be updated in Snort by supplying a CSV file with the new maximum Group numbers to use. By default, Snort recognizes Social Security numbers issued up through November 2009.

Example preprocessor config

preprocessor sensitive_data: alert_threshold 25 \
ssn_file ssn_groups_Jan10.csv


### 2.2.17.3 Rule Options

Snort rules are used to specify which PII the preprocessor should look for. A new rule option is provided by the preprocessor:

sd_pattern


This rule option specifies what type of PII a rule should detect.

Syntax

    sd_pattern:<count>, <pattern>;

    count   = 1 - 255
pattern = any string


Option Explanations

count

This dictates how many times a PII pattern must be matched for an alert to be generated. The count is tracked across all packets in a session.

pattern

This is where the pattern of the PII gets specified. There are a few built-in patterns to choose from:

credit_card

The "credit_card" pattern matches 15- and 16-digit credit card numbers. These numbers may have spaces, dashes, or nothing in between groups. This covers Visa, Mastercard, Discover, and American Express. Credit card numbers matched this way have their check digits verified using the Luhn algorithm.

us_social

This pattern matches against 9-digit U.S. Social Security numbers. The SSNs are expected to have dashes between the Area, Group, and Serial sections.

SSNs have no check digits, but the preprocessor will check matches against the list of currently allocated group numbers.

us_social_nodashes

This pattern matches U.S. Social Security numbers without dashes separating the Area, Group, and Serial sections.

email

This pattern matches against email addresses.

If the pattern specified is not one of the above built-in patterns, then it is the definition of a custom PII pattern. Custom PII types are defined using a limited regex-style syntax. The following special characters and escape sequences are supported:

 \d matches any digit \D matches any non-digit \l matches any letter \L matches any non-letter \w matches any alphanumeric character \W matches any non-alphanumeric character {num} used to repeat a character or escape sequence "num" times. example: "{3}" matches 3 digits. ? makes the previous character or escape sequence optional. example: " ?" matches an optional space. This behaves in a greedy manner. \\ matches a backslash \{, \} matches { and } \? matches a question mark.

Other characters in the pattern will be matched literally.

 Note:   Unlike PCRE, \w in this rule option does NOT match underscores.

Examples
    sd_pattern: 2,us_social;

Alerts when 2 social security numbers (with dashes) appear in a session.

    sd_pattern: 5,(\d{3})\d{3}-\d{4};

Alerts on 5 U.S. phone numbers, following the format (123)456-7890

Whole rule example:

    alert tcp $HOME_NET$HIGH_PORTS -> $EXTERNAL_NET$SMTP_PORTS \
(msg:"Credit Card numbers sent over email"; gid:138; sid:1000; rev:1; \


Caveats
sd_pattern is not compatible with other rule options. Trying to use other rule options with sd_pattern will result in an error message.

Rules using sd_pattern must use GID 138.

## 2.2.18 Normalizer

When operating Snort in inline mode, it is helpful to normalize packets to help minimize the chances of evasion.

To enable the normalizer, use the following when configuring Snort:

    ./configure --enable-normalizer


The normalize preprocessor is activated via the conf as outlined below. There are also many new preprocessor and decoder rules to alert on or drop packets with "abnormal" encodings.

Note that in the following, fields are cleared only if they are non-zero. Also, normalizations will only be enabled if the selected DAQ supports packet replacement and is operating in inline mode.

If a policy is configured for inline_test or passive mode, any normalization statements in the policy config are ignored.

### 2.2.18.1 IP4 Normalizations

IP4 normalizations are enabled with:

    preprocessor normalize_ip4: [df], [rf], [tos], [trim]


Base normalizations enabled with "preprocessor normalize_ip4" include:

• TTL normalization if enabled (explained below).

• Clear the differentiated services field (formerly TOS).

• NOP all options octets.

Optional normalizations include:

• df don't fragment: clear this bit on incoming packets.

• rf reserved flag: clear this bit on incoming packets.

• tos type of service (differentiated services): clear this byte.

• trim truncate packets with excess payload to the datagram length specified in the IP header + the layer 2 header (e.g. ethernet), but don't truncate below minimum frame length. This is automatically disabled if the DAQ can't inject packets.

### 2.2.18.2 IP6 Normalizations

IP6 normalizations are enabled with:

    preprocessor normalize_ip6


Base normalizations enabled with "preprocessor normalize_ip6" include:

• Hop limit normalization if enabled (explained below).

• NOP all options octets in hop-by-hop and destination options extension headers.

### 2.2.18.3 ICMP4/6 Normalizations

ICMP4 and ICMP6 normalizations are enabled with:

    preprocessor normalize_icmp4
preprocessor normalize_icmp6


Base normalizations enabled with the above include:

• Clear the code field in echo requests and replies.

### 2.2.18.4 TCP Normalizations

TCP normalizations are enabled with:

    preprocessor normalize_tcp: \
[req_urg], [req_pay], [req_urp], \
[ips], [urp], [trim], \
[trim_syn], [trim_rst], \
[trim_win], [trim_mss], \
[ecn <ecn_type>], \
[opts [allow <allowed_opt>+]]

<ecn_type> ::= stream | packet

<allowed_opt> ::= \
sack | echo | partial_order | conn_count | alt_checksum | md5 | <num>

<sack> ::= { 4, 5 }
<echo> ::= { 6, 7 }
<partial_order> ::= { 9, 10 }
<conn_count> ::= { 11, 12, 13 }
<alt_checksum> ::= { 14, 15 }
<md5> ::= { 19 }
<num> ::= (3..255)


Normalizations include:

• block allow packet drops during TCP normalization.

• rsv clear the reserved bits in the TCP header.

• req_urg clear the urgent pointer if the urgent flag is not set.

• req_pay clear the urgent pointer and the urgent flag if there is no payload.

• req_urp clear the urgent flag if the urgent pointer is not set.

• ips ensure consistency in retransmitted data (also forces reassembly policy to "first"). Any segments that can't be properly reassembled will be dropped.

• trim_syn remove data on SYN.

• trim_rst remove any data from RST packet.

• trim_win trim data to window.

• trim_mss trim data to MSS.

• trim enable all of the above trim options.

• ecn packet

clear ECN flags on a per packet basis (regardless of negotiation).

• ecn stream

clear ECN flags if usage wasn't negotiated. Should also enable require_3whs.

• opts

NOP all option bytes other than maximum segment size, window scaling, timestamp, and any explicitly allowed with the allow keyword. You can allow options to pass by name or number.

• opts

if timestamp is present but invalid, or valid but not negotiated, NOP the timestamp octets.

• opts

if timestamp was negotiated but not present, block the packet.

• opts

clear TS ECR if ACK flag is not set.

• opts

MSS and window scale options are NOP'd if SYN flag is not set.

### 2.2.18.5 TTL Normalization

TTL normalization pertains to both IP4 TTL (time-to-live) and IP6 (hop limit) and is only performed if both the relevant base normalization is enabled (as described above) and the minimum and new TTL values are configured, as follows:

    config min_ttl: <min_ttl>
config new_ttl: <new_ttl>

<min_ttl> ::= (1..255)
<new_ttl> ::= (<min_ttl>+1..255)


If new_ttl min_ttl, then if a packet is received with a TTL min_ttl, the TTL will be set to new_ttl.

Note that this configuration item was deprecated in 2.8.6:

    preprocessor stream5_tcp: min_ttl <#>


By default min_ttl = 1 (TTL normalization is disabled). When TTL normalization is turned on the new_ttl is set to 5 by default.

## 2.2.19 SIP Preprocessor

Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP Preprocessor provides ways to tackle Common Vulnerabilities and Exposures (CVEs) related with SIP found over the past few years. It also makes detecting new attacks easier.

### 2.2.19.1 Dependency Requirements

For proper functioning of the preprocessor:

• Stream session tracking must be enabled, i.e. stream5. Both TCP and UDP must be enabled in stream5. The preprocessor requires a session tracker to keep its data. In addition, Stream API is able to provide correct support for ignoring audio/video data channel.

• IP defragmentation should be enabled, i.e. the frag3 preprocessor should be enabled and configured.

### 2.2.19.2 Configuration

The preprocessor configuration name is sip.
    preprocessor sip

Option syntax
 Option Argument Required Default disabled NONE NO OFF max_sessions NO max_sessions 10000 max_dialogs NO max_dialogs 4 ports NO ports { 5060 5061 } methods NO methods { invite cancel ack bye register options } max_uri_len NO max_uri_len 256 max_call_id_len NO max_call_id_len 256 max_requestName_len NO max_requestName_len 20 max_from_len NO max_from_len 256 max_to_len NO max_to_len 256 max_via_len NO max_via_len 1024 max_contact_len NO max_contact_len 256 max_content_len NO max_content_len 1024 ignore_call_channel NONE NO OFF
     max_sessions        = 1024-4194303
max_dialogs         = 1-4194303
methods             = "invite"|"cancel"|"ack"|"bye"|"register"| "options"\
|"refer" |"subscribe"|"update"|"join"|"info"|"message"\
|"notify"|"prack"
max_uri_len         = 0-65535
max_call_id_len     = 0-65535
max_requestName_len = 0-65535
max_from_len        = 0-65535
max_to_len          = 0-65535
max_via_len         = 0-65535
max_contact_len     = 0-65535
max_content_len     = 0-65535

Option explanations
disabled
SIP dynamic preprocessor can be enabled/disabled through configuration. By default this value is turned off. When the preprocessor is disabled, only the max_sessions option is applied when specified with the configuration.
max_sessions
This specifies the maximum number of sessions that can be allocated. Those sessions are stream sessions, so they are bounded by maximum number of stream sessions. Default is 10000.
max_dialogs
This specifies the maximum number of dialogs within one stream session. If exceeded, the oldest dialog will be dropped. Default is 4.
ports
This specifies on what ports to check for SIP messages. Typically, this will include 5060, 5061.
Syntax
    ports { <port> [<port>< ... >] }

Examples
    ports { 5060 5061 }

Note: there are spaces before and after {' and }'.
methods
This specifies on what methods to check for SIP messages: (1) invite, (2) cancel, (3) ack, (4) bye, (5) register, (6) options, (7) refer, (8) subscribe, (9) update (10) join (11) info (12) message (13) notify (14) prack. Note: those 14 methods are up to date list (Feb. 2011). New methods can be added to the list. Up to 32 methods supported.

Syntax
      methods { <method-list> }
method-list = method|method method-list
methods     = "invite"|"cancel"|"ack"|"bye"|"register"| "options"\
|"refer"|"subscribe"|"update"|"join"|"info"|"message"\
|"notify"|"prack"

Examples
   methods { invite cancel ack bye register options }
methods { invite cancel ack bye register options information }

Note: there are spaces before and after {' and }'.
max_uri_len
This specifies the maximum Request URI field size. If the Request URI field is greater than this size, an alert is generated. Default is set to 256. The allowed range for this option is 0 - 65535. 0'' means never alert.

max_call_id_len
This specifies the maximum Call-ID field size. If the Call-ID field is greater than this size, an alert is generated. Default is set to 256. The allowed range for this option is 0 - 65535. 0'' means never alert.

max_requestName_len
This specifies the maximum request name size that is part of the CSeq ID. If the request name is greater than this size, an alert is generated. Default is set to 20. The allowed range for this option is 0 - 65535. 0'' means never alert.

max_from_len
This specifies the maximum From field size. If the From field is greater than this size, an alert is generated. Default is set to 256. The allowed range for this option is 0 - 65535. 0'' means never alert.

max_to_len
This specifies the maximum To field size. If the To field is greater than this size, an alert is generated. Default is set to 256. The allowed range for this option is 0 - 65535. 0'' means never alert.

max_via_len
This specifies the maximum Via field size. If the Via field is greater than this size, an alert is generated. Default is set to 1024. The allowed range for this option is 0 - 65535. 0'' means never alert.
max_contact_len
This specifies the maximum Contact field size. If the Contact field is greater than this size, an alert is generated. Default is set to 256. The allowed range for this option is 0 - 65535. 0'' means never alert.
max_content_len
This specifies the maximum content length of the message body. If the content length is greater than this number, an alert is generated. Default is set to 1024. The allowed range for this option is 0 - 65535. 0'' means never alert.
ignore_call_channel
This enables the support for ignoring audio/video data channel (through Stream API). By default, this is disabled.

Option examples
     max_sessions 30000
disabled
ports { 5060 5061 }
methods { invite cancel ack bye register options }
methods { invite cancel ack bye register options information }
max_uri_len 1024
max_call_id_len 1024
max_requestName_len 10
max_from_len 1024
max_to_len 1024
max_via_len 1024
max_contact_len 1024
max_content_len 1024
max_content_len
ignore_call_channel


Configuration examples

     preprocessor sip
preprocessor sip: max_sessions 500000
preprocessor sip: max_contact_len 512, max_sessions 300000, methods { invite \
cancel ack bye register options } , ignore_call_channel
preprocessor sip: ports { 5060 49848 36780 10270 }, max_call_id_len 200, \
max_from_len 100, max_to_len 200, max_via_len 1000, \
max_requestName_len 50, max_uri_len 100, ignore_call_channel,\
max_content_len 1000
preprocessor sip: disabled
preprocessor sip: ignore_call_channel


Default configuration

     preprocessor sip


### 2.2.19.3 Events

The preprocessor uses GID 140 to register events.
 SID Description 1 If the memory cap is reached and the preprocessor is configured to alert, this alert will be created. 2 Request URI is required. When Request URI is empty, this alert will be created. 3 The Request URI is larger than the defined length in configuration. 4 When Call-ID is empty, this alert will be created. 5 The Call-ID is larger than the defined length in configuration. 6 The sequence e number value MUST be expressible as a 32-bit unsigned integer and MUST be less than . 7 The request name in the CSeq is larger than the defined length in configuration. 8 From field is empty. 9 From field is larger than the defined length in configuration. 10 To field is empty. 11 To field is larger than the defined length in configuration. 12 Via filed is empty. 13 Via filed is larger than the defined length in configuration. 14 Contact is empty, but it is required non-empty for the message. 15 The Contact is larger than the defined length in configuration. 16 The content length is larger than the defined length in configuration or is negative. 17 There are multiple requests in a single packet. Old SIP protocol supports multiple sip messages within one packet. 18 There are inconsistencies between Content-Length in SIP header and actual body data. 19 Request name is invalid in response. 20 Authenticated invite message received, but no challenge from server received. This is the case of InviteReplay billing attack. 21 Authenticated invite message received, but session information has been changed. This is different from re-INVITE, where the dialog has been established. and authenticated. This is can prevent FakeBusy billing attack. 22 Response status code is not a 3 digit number. 23 Content type header field is required if the message body is not empty. 24 SIP version other than 2.0, 1.0, and 1.1 is invalid 25 Mismatch in Method of request and the CSEQ header 26 The method is unknown 27 The number of dialogs in the stream session exceeds the maximal value.

### 2.2.19.4 Rule Options

New rule options are supported by enabling the sip preprocessor:
  sip_method
sip_stat_code
sip_body

Overload modifiers to existing pcre rule options:
P: Match SIP request or SIP response body, Similar to sip_body.
sip_method
The sip_method keyword is used to check for specific SIP request methods. The list of methods is: invite, cancel, ack, bye, register, options, refer, subscribe, update, join, info, message, notify, prack. More than one method can be specified, via a comma separated list, and are OR'ed together. It will be applied in fast pattern match if available. If the method used in this rule is not listed in the preprocessor configuration, it will be added to the preprocessor configuration for the associated policy.

Syntax

    sip_method:<method-list>;
method-list = method|method, method-list
method      = ["!"] "invite"|"cancel"|"ack"|"bye"|"register"| "options"\
|"refer"|"subscribe"|"update"|"join"|"info"|"message"\
|"notify"|"prack"
Note: if "!" is used, only one method is allowed in sip_method.

Examples
   sip_method:invite, cancel
sip_method:!invite

Note: If a user wants to use "and", they can use something like this:
sip_method:!invite; sip_method:!bye


sip_stat_code

The sip_stat_code is used to check the SIP response status code. This option matches if any one of the state codes specified matches the status codes of the SIP response.

Syntax

   sip_stat_code:<code _list> ;
code_list = state_code|state_code, code_list
code      = "100-999"|"1-9"

Note: 1,2,3,4,5,6... mean to check for "1xx", "2xx", '3xx', '4xx', '5xx', '6xx'... responses.

Examples

   sip_stat_code:200
sip_stat_code: 2
sip_stat_code: 200, 180


The sip_header keyword restricts the search to the extracted Header fields of a SIP message request or a response. This works similar to file_data.

Syntax

   sip_header;


Examples

   alert udp any any -> any 5060 (sip_header; content:"CSeq"; )


sip_body

The sip_body keyword places the cursor at the beginning of the Body fields of a SIP message. This works similar to file_data and dce_stub_data. The message body includes channel information using SDP protocol (Session Description Protocol).

Syntax

   sip_body;


Examples

   alert udp any any -> any 5060 (sip_body; content:"C=IN 0.0.0.0"; within 100;)

pcre
SIP overloads two options for pcre:
• H: Match SIP header for request or response , Similar to sip_header.
• P: Match SIP body for request or response , Similar to sip_body.
Examples
    alert udp any any -> any 5060 (pcre:"/INVITE/H"; sid:1000000;)
alert udp any any -> any 5060 (pcre:"/m=/P"; sid:2000000;)


## 2.2.20 Reputation Preprocessor

Reputation preprocessor provides basic IP blacklist/whitelist capabilities, to block/drop/pass traffic from IP addresses listed. In the past, we use standard Snort rules to implement Reputation-based IP blocking. This preprocessor will address the performance issue and make the IP reputation management easier. This preprocessor runs before other preprocessors.

### 2.2.20.1 Configuration

The preprocessor configuration name is reputation.

    preprocessor reputation

Option syntax
 Option Argument Required Default memcap NO memcap 500 scan_local NONE NO OFF blacklist NO NONE whitelist NO NONE priority [blacklist whitelist] NO priority whitelist nested_ip [inner outer both] NO nested_ip inner white [unblack trust] NO white unblack
     memcap        = 1-4095 Mbytes

Option explanations
memcap
Maximum total memory supported. It can be set up to 4095 Mbytes.

scan_local
Enable to inspect local address defined in RFC 1918:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

blacklist/whitelist
The IP lists are loaded from external files. It supports relative paths for inclusion and $variables for path. Multiple blacklists or whitelists are supported. Note: if the same IP is redefined later, it will overwrite the previous one. In other words, IP lists always favors the last file or entry processed. priority Specify either blacklist or whitelist has higher priority when source/destination is on blacklist while destination/source is on whitelist. By default, whitelist has higher priority. In other words, the packet will be passed when either source or destination is whitelisted. Note: this only defines priority when there is a decision conflict, during run-time. During initialization time, if the same IP address is defined in whitelist and blacklist, whoever the last one defined will be the final one. Priority does not work on this case. nested_ip Specify which IP address to be used when there is IP encapsulation. white Specify the meaning of whitelist. When white means unblack, it unblacks IPs that are in blacklists; when white means trust, the packet gets bypassed, without further detection by snort. You can only specify either unblack or trust. Note: when white means unblack, whitelist always has higher priority than blacklist. Configuration examples  preprocessor reputation:\ blacklist /etc/snort/default.blacklist, \ whitelist /etc/snort/default.whitelist preprocessor reputation: \ nested_ip both, \ blacklist /etc/snort/default.blacklist, \ whitelist /etc/snort/default.whitelist preprocessor reputation: \ memcap 4095, scan_local, nested_ip both, \ priority whitelist, \ blacklist /etc/snort/default.blacklist, \ whitelist /etc/snort/default.whitelist, white trust$REP_BLACK_FILE1 = ../dshield.list
$REP_BLACK_FILE2 = ../snort.org.list preprocessor reputation: \ blacklist$REP_BLACK_FILE1,\
blacklist $REP_BLACK_FILE2  IP List File Format Syntax The IP list file has 1 entry per line. The entry can be either IP entry or comment. IP Entry CIDR notation comments line break. Example:  172.16.42.32/32 172.33.42.32/16  Comment The comment start with # # comments Example  # This is a full line comment 172.33.42.32/16 # This is a in-line comment  IP List File Example  # This is a full line comment 172.16.42.32/32 # This is an inline comment, line with single CIDR block 172.33.42.32/16  Use case A user wants to protect his/her network from unwanted/unknown IPs, only allowing some trusted IPs. Here is the configuration:  preprocessor reputation: \ blacklist /etc/snort/default.blacklist whitelist /etc/snort/default.whitelist In file "default.blacklist" # These two entries will match all ipv4 addresses 1.0.0.0/1 128.0.0.0/1 In file "default.whitelist" 68.177.102.22 # sourcefire.com 74.125.93.104 # google.com  ### 2.2.20.2 Events Reputation preprocessor uses GID 136 to register events.  SID Description 1 Packet is blacklisted. 2 Packet is whitelisted. 3 Packet is inspected. ### 2.2.20.3 Shared memory support In order to minimize memory consumption when multiple Snort instances are running concurrently, we introduce the support of shared memory. After configured, all the snort instances share the same IP tables in shared memory. System requirement This feature is supported only in Linux. Build configuration A new option, -enable-shared-rep is introduced to ./configure command. This option enables the support for shared memory. Configuration shared_mem If the build supports shared memory, this configuration will enable shared memory. If this option isn't set, standard memory is used. This option must specify a path or directory where IP lists will be loaded in shared memory. One snort instance will create and maintain the shared IP lists. We use instance ID 1, specified in the snort -G option to be the master snort. All the other snort instances are clients (readers). Syntax  shared_mem: path  Examples  shared_mem /user/reputation/iplists  shared_refresh This option changes the period of checking new shared memory segment, in the unit of second. By default, the refresh rate is seconds. Syntax  shared_refresh <period> period = "1 - 4294967295"  Examples  shared_refresh 60  Steps to configure shared memory • When building Snort, add option -enable-shared-rep to ./configure For example:  ./configure --enable-gre --enable-sourcefire --enable-flexresp3 --enable-pthread --enable-linux-smp-stats --enable-targetbased --enable-shared-rep --enable-control-socket  • Put your IP list file into a directory, where snort has full access. For example:  /user/reputation/iplists  In order to separate whitelist with blacklist, you need to specify whitelist with .wlf extension and blacklist with .blf extension. • In snort config file, specify shared memory support with the path to IP files. For example:  shared_mem /user/reputation/iplists  If you want to change the period of checking new IP lists, add refresh period. For example:  shared_refresh 300  • Start shared memory master(writer) with -G 0 option. Note: only one master should be enabled. • Start shared memory clients (readers) with -G 1 or other IDs. Note: for one ID, only one snort instance should be enabled. • You will see the IP lists got loaded and shared across snort instances! Reload IP lists using control socket • Run snort using command line with option -cs-dir <path> or configure snort with:  config cs_dir:<path>  • (Optional) you can create a version file named IPRVersion.dat'' in the IP list directory. This file helps managing reloading IP lists, by specifying a version. When the version isn't changed, IP lists will not be reloaded if they are already in shared memory. The version number should be a 32 bit number. For example:  VERSION=1  • In the <snort root>/src/tools/control directory, you will find snort_control command if built with -enable-control-socket option. • Type the following command to reload IP lists. Before typing this command, make sure to update version file if you are using version file. The <path> is the same path in first step.  <snort root>/src/tools/control/snort_control <path> 1361  Using manifest file to manage loading (optional) Using manifest file, you can control the file loading sequence, action taken, and support zone based detection. You can create a manifest file named zone.info'' in the IP list directory. When Snort is signaled to load new lists, a manifest file is read first to determine which zones the IPs in each list are applicable to and what action to take per list (Block, White, Monitor). Files listed in manifest are loaded from top to bottom. You should put files that have higher priority first. In manifest file, you can put up to 255 files. Without manifest file, files will be loaded in alphabet order. Here's the format of the manifest file. Each line of the file has the following format:  <filename>, <list id>,<action>[, <zone>]+ <list id> ::= 32 bit integer <action> ::= "monitor"|"block"|"white" <zone> ::= [0-1051]  Using manifest file, you can specify a new action called monitor'', which indicates a packet needs to be inspected, but does not disable detection. This is different from block'' action, which disables further detection. This new action helps users evaluate their IP lists before applying it. An example manifest file:  #ipreputation manifest file white.wlf, 111 ,white, black1.blf, 1112, black, 3, 12 black2.blf, 1113, black, 3, 12 monitor.blf,2222, monitor, 0, 2, 8  ## 2.2.21 GTP Decoder and Preprocessor GTP (GPRS Tunneling Protocol) is used in core communication networks to establish a channel between GSNs (GPRS Serving Node). GTP decoding preprocessor provides ways to tackle intrusion attempts to those networks through GTP. It also makes detecting new attacks easier. Two components are developed: GTP decoder and GTP preprocessor. • GTP decoder extracts payload inside GTP PDU; • GTP preprocessor inspects all the signaling messages and provide keywords for further inspection When the decoder is enabled and configured, the decoder strips the GTP headers and parses the underlying IP/TCP/UDP encapsulated packets. Therefore all rules and detection work as if there was no GTP header. Example: Most GTP packets look like this IP -> UDP -> GTP -> IP -> TCP -> HTTP  If you had a standard HTTP rule: alert tcp any any -> any$HTTP_PORTS (msg:"Test HTTP"; flow:to_server,established;
content:"SOMETHINGEVIL"; http_uri;  .... sid:X; rev:Y;)

it would alert on the inner HTTP data that is encapsulated in GTP without any changes to the rule other than enabling and configuring the GTP decoder.

### 2.2.21.1 Dependency Requirements

For proper functioning of the preprocessor:

• Stream session tracking must be enabled, i.e. stream5. UDP must be enabled in stream5. The preprocessor requires a session tracker to keep its data.

• IP defragmentation should be enabled, i.e. the frag3 preprocessor should be enabled and configured.

### 2.2.21.2 GTP Data Channel Decoder Configuration

GTP decoder extracts payload from GTP PDU. The following configuration sets GTP decoding:
config enable_gtp

By default, GTP decoder uses port number (GTPv1) and (GTPv0). If users want to change those values, they can use portvar GTP_PORTS:

portvar GTP_PORTS [2152,3386]


### 2.2.21.3 GTP Control Channel Preprocessor Configuration

Different from GTP decoder, GTP preprocessor examines all signaling messages. The preprocessor configuration name is gtp.

preprocessor gtp

Option syntax
 Option Argument Required Default ports NO ports { 2123 3386 }
Option explanations
ports
This specifies on what ports to check for GTP messages. Typically, this will include 2123, 3386.
Syntax
    ports { <port> [<port>< ... >] }

Examples
    ports { 2123 3386 2152 }

Note: there are spaces before and after {' and }'.

Default configuration

     preprocessor gtp


### 2.2.21.4 GTP Decoder Events

 SID Description 297 Two or more GTP encapsulation layers present 298 GTP header length is invalid

### 2.2.21.5 GTP Preprocessor Events

 SID Description 1 Message length is invalid. 2 Information element length is invalid. 3 Information elements are out of order.

### 2.2.21.6 Rule Options

New rule options are supported by enabling the gtp preprocessor:
  gtp_type
gtp_info
gtp_version


gtp_type

The gtp_type keyword is used to check for specific GTP types. User can input message type value, an integer in [0, 255], or a string defined in the Table below. More than one type can be specified, via a comma separated list, and are OR'ed together. If the type used in a rule is not listed in the preprocessor configuration, an error will be thrown.

A message type can have different type value in different GTP versions. For example, sgsn_context_request has message type value in GTPv0 and GTPv1, but in GTPv2. gtp_type will match to a different value depending on the version number in the packet. In this example, evaluating a GTPv0 or GTPv1 packet will check whether the message type value is ; evaluating a GTPv2 packet will check whether the message type value is . When a message type is not defined in a version, any packet in that version will always return No match''.

If an integer is used to specify message type, every GTP packet is evaluated, no matter what version the packet is. If the message type matches the value in packet, it will return Match''.

Syntax

   gtp_type:<type-list>;
type-list = type|type, type-list
type      = "0-255"|
| "echo_request" | "echo_response" ...

Examples
   gtp_type:10, 11, echo_request;


GTP message types

gtp_info

The gtp_info keyword is used to check for specific GTP information element. This keyword restricts the search to the information element field. User can input information element value, an integer in , or a string defined in the Table below. If the information element used in this rule is not listed in the preprocessor configuration, an error will be thrown.

When there are several information elements with the same type in the message, this keyword restricts the search to the total consecutive buffer. Because the standard requires same types group together, this feature will be available for all valid messages. In the case of out of order information elements'', this keyword restricts the search to the last buffer.

Similar to message type, same information element might have different information element value in different GTP versions. For example, cause has value in GTPv0 and GTPv1, but in GTPv2. gtp_info will match to a different value depending on the version number in the packet. When an information element is not defined in a version, any packet in that version will always return No match''.

If an integer is used to specify information element type, every GTP packet is evaluated, no matter what version the packet is. If the message type matches the value in packet, it will return Match''.

Syntax

   gtp_info:<ie>;
ie      = "0-255"|
"rai" | "tmsi"...

Examples
   gtp_info: 16;
gtp_info: tmsi

GTP information elements
gtp_version
The gtp_version keyword is used to check for specific GTP version.
Because different GTP version defines different message types and information elements, this keyword should combine with gtp_type and gtp_info.

Syntax

   gtp_version:<version>;
version   = "0, 1, 2'

Examples
   gtp_version: 1;


## 2.2.22 Modbus Preprocessor

The Modbus preprocessor is a Snort module that decodes the Modbus protocol. It also provides rule options to access certain protocol fields. This allows a user to write rules for Modbus packets without decoding the protocol with a series of "content" and "byte_test" options.

Modbus is a protocol used in SCADA networks. If your network does not contain any Modbus-enabled devices, we recommend leaving this preprocessor turned off.

### 2.2.22.1 Dependency Requirements

For proper functioning of the preprocessor:

• Stream session tracking must be enabled, i.e. stream5. TCP must be enabled in stream5. The preprocessor requires a session tracker to keep its data.

• Protocol Aware Flushing (PAF) must be enabled.

• IP defragmentation should be enabled, i.e. the frag3 preprocessor should be enabled and configured.

### 2.2.22.2 Preprocessor Configuration

To get started, the Modbus preprocessor must be enabled. The preprocessor name is modbus.
preprocessor modbus

Option syntax
 Option Argument Required Default ports NO ports { 502 }
Option explanations
ports
This specifies on what ports to check for Modbus messages. Typically, this will include 502.
Syntax
    ports { <port> [<port>< ... >] }

Examples
    ports { 1237 3945 5067 }

Note: there are spaces before and after {' and }'.

Default configuration

    preprocessor modbus


### 2.2.22.3 Rule Options

The Modbus preprocessor adds 3 new rule options. These rule options match on various pieces of the Modbus headers:

    modbus_func
modbus_unit
modbus_data


The preprocessor must be enabled for these rule option to work.

modbus_func

This option matches against the Function Code inside of a Modbus header. The code may be a number (in decimal format), or a string from the list provided below.

Syntax

    modbus_func:<code>

code  = 0-255 |
"write_single_coil" |
"write_single_register" |
"diagnostics" |
"get_comm_event_counter" |
"get_comm_event_log" |
"write_multiple_coils" |
"write_multiple_registers" |
"report_slave_id" |
"write_file_record" |
"encapsulated_interface_transport"

Examples
    modbus_func:1;
modbus_func:write_multiple_coils;


modbus_unit

This option matches against the Unit ID field in a Modbus header.

Syntax

    modbus_unit:<unit>

unit = 0-255

Examples
    modbus_unit:1;


modbus_data

This rule option sets the cursor at the beginning of the Data field in a Modbus request/response.

Syntax

    modbus_data;


Examples

    modbus_data; content:"badstuff";


### 2.2.22.4 Preprocessor Events

The Modbus preprocessor uses GID 144 for its preprocessor events.
 SID Description 1 The length in the Modbus header does not match the length needed by the Modbus function code. Each Modbus function has an expected format for requests and responses. If the length of the message does not match the expected format, this alert is generated. 2 Modbus protocol ID is non-zero. The protocol ID field is used for multiplexing other protocols with Modbus. Since the preprocessor cannot handle these other protocols, this alert is generated instead. 3 Reserved Modbus function code in use.

## 2.2.23 DNP3 Preprocessor

The DNP3 preprocessor is a Snort module that decodes the DNP3 protocol. It also provides rule options to access certain protocol fields. This allows a user to write rules for DNP3 packets without decoding the protocol with a series of "content" and "byte_test" options.

DNP3 is a protocol used in SCADA networks. If your network does not contain any DNP3-enabled devices, we recommend leaving this preprocessor turned off.

### 2.2.23.1 Dependency Requirements

For proper functioning of the preprocessor:

• Stream session tracking must be enabled, i.e. stream5. TCP or UDP must be enabled in stream5. The preprocessor requires a session tracker to keep its data.

• Protocol Aware Flushing (PAF) must be enabled.

• IP defragmentation should be enabled, i.e. the frag3 preprocessor should be enabled and configured.

### 2.2.23.2 Preprocessor Configuration

To get started, the DNP3 preprocessor must be enabled. The preprocessor name is dnp3.
preprocessor dnp3

Option syntax
 Option Argument Required Default ports NO ports { 20000 } memcap
Option explanations
ports
This specifies on what ports to check for DNP3 messages. Typically, this will include 20000.
Syntax
    ports { <port> [<port>< ... >] }

Examples
    ports { 1237 3945 5067 }

Note: there are spaces before and after {' and }'.

memcap
This sets a maximum to the amount of memory allocated to the DNP3 preprocessor for session-tracking purposes. The argument is given in bytes. Each session requires about 4 KB to track, and the default is 256 kB. This gives the preprocessor the ability to track 63 DNP3 sessions simultaneously. Setting the memcap below 4144 bytes will cause a fatal error. When multiple configs are used, the memcap in the non-default configs will be overwritten by the memcap in the default config. If the default config isn't intended to inspect DNP3 traffic, use the "disabled" keyword.

check_crc
This option makes the preprocessor validate the checksums contained in DNP3 Link-Layer Frames. Frames with invalid checksums will be ignored. If the corresponding preprocessor rule is enabled, invalid checksums will generate alerts. The corresponding rule is GID 145, SID 1.

disabled
This option is used for loading the preprocessor without inspecting any DNP3 traffic. The disabled keyword is only useful when the DNP3 preprocessor is turned on in a separate policy.

Default configuration

    preprocessor dnp3


### 2.2.23.3 Rule Options

The DNP3 preprocessor adds 4 new rule options. These rule options match on various pieces of the DNP3 headers:

    dnp3_func
dnp3_obj
dnp3_ind
dnp3_data


The preprocessor must be enabled for these rule option to work.

dnp3_func

This option matches against the Function Code inside of a DNP3 Application-Layer request/response header. The code may be a number (in decimal format), or a string from the list provided below.

Syntax

    dnp3_func:<code>

code  = 0-255 |
"confirm" |
"write" |
"select" |
"operate" |
"direct_operate" |
"direct_operate_nr" |
"immed_freeze" |
"immed_freeze_nr" |
"freeze_clear" |
"freeze_clear_nr" |
"freeze_at_time" |
"freeze_at_time_nr" |
"cold_restart" |
"warm_restart" |
"initialize_data" |
"initialize_appl" |
"start_appl" |
"stop_appl" |
"save_config" |
"enable_unsolicited" |
"disable_unsolicited" |
"assign_class" |
"delay_measure" |
"record_current_time" |
"open_file" |
"close_file" |
"delete_file" |
"get_file_info" |
"authenticate_file" |
"abort_file" |
"activate_config" |
"authenticate_req" |
"authenticate_err" |
"response" |
"unsolicited_response" |
"authenticate_resp"

Examples
    dnp3_func:1;
dnp3_func:delete_file;


dnp3_ind

This option matches on the Internal Indicators flags present in a DNP3 Application Response Header. Much like the TCP flags rule option, providing multiple flags in one option will cause the rule to fire if ANY one of the flags is set. To alert on a combination of flags, use multiple rule options.

Syntax

    dnp3_ind:<flag>{,<flag>...]

flag =  "all_stations"
"class_1_events"
"class_2_events"
"class_3_events"
"need_time"
"local_control"
"defice_trouble"
"device_restart"
"no_func_code_support"
"object_unknown"
"parameter_error"
"event_buffer_overflow"
"config_corrupt"
"reserved_2"
"reserved_1"

Examples
    # Alert on reserved_1 OR reserved_2
dnp3_ind:reserved_1,reserved_2;

# Alert on class_1 AND class_2 AND class_3 events
dnp3_ind:class_1_events; dnp3_ind:class_2_events; dnp3_ind:class_3_events;


dnp3_obj

This option matches on DNP3 object headers present in a request or response.

Syntax

    dnp3_obj:<group>,<var>

group = 0 - 255
var   = 0 - 255

Examples
    # Alert on DNP3 "Date and Time" object
dnp3_obj:50,1;


dnp3_data

As Snort processes DNP3 packets, the DNP3 preprocessor collects Link-Layer Frames and reassembles them back into Application-Layer Fragments. This rule option sets the cursor to the beginning of an Application-Layer Fragment, so that other rule options can work on the reassembled data.

With the dnp3_data rule option, you can write rules based on the data within Fragments without splitting up the data and adding CRCs every 16 bytes.

Syntax

    dnp3_data;


Examples

    dnp3_data; content:"badstuff_longer_than_16chars";


### 2.2.23.4 Preprocessor Events

The DNP3 preprocessor uses GID 145 for its preprocessor events.
 SID Description 1 A Link-Layer Frame contained an invalid CRC. (Enable check_crc in the preprocessor config to get this alert.) 2 A DNP3 Link-Layer Frame was dropped, due to an invalid length. 3 A Transport-Layer Segment was dropped during reassembly. This happens when segments have invalid sequence numbers. 4 The DNP3 Reassembly buffer was cleared before a complete fragment could be reassembled. This happens when a segment carrying the "FIR" flag appears after some other segments have been queued. 5 A DNP3 Link-Layer Frame is larger than 260 bytes. 6 A DNP3 Link-Layer Frame uses an address that is reserved. 7 A DNP3 request or response uses a reserved function code.

## 2.2.24 AppId Preprocessor

With increasingly complex networks and growing network traffic, network administrators require application awareness in managing networks. An administrator may allow only applications that are business relevant, low bandwidth and/or deal with certain subject matter.

AppId preprocessor adds application level view to manage networks. It does this by adding the following features

• Network control: The preprocessor provides simplified single point application awareness by making a set of application identifiers (AppId) available to Snort Rule writers.

• Network usage awareness: the preprocessor outputs statistics to show network bandwidth used by each application seen on network. Administrators can monitor bandwidth usage and may decide to block applications that are wasteful.

• Custom applications: The preprocessor enables administrators to create their own application detectors to detect new applications. The detectors are written in Lua and interface with Snort using a well-defined C-Lua API.

### 2.2.24.1 Dependency Requirements

For proper functioning of the preprocessor:

• Stream session tracking must be enabled, i.e. stream5. TCP or UDP must be enabled in stream5. The preprocessor requires a session tracker to keep its data.

• Protocol Aware Flushing (PAF) must be enabled.

• IP defragmentation should be enabled, i.e. the frag3 preprocessor should be enabled and configured.

• HTTP preprocessor must be enabled and configured. The processor does not require any AppId specific configuration. The preprocessor provides parsed HTTP headers for application determination. Without HTTP preprocessor, AppId preprocessor will identify only non-HTTP applications.

• LuaJIT version 2.0.2 must be installed on host where snort is being compiled and run. Newer versions of LuaJIT are not tested for compatibility.

### 2.2.24.2 Preprocessor Configuration

AppId dynamic preprocessor can be enabled during build time. The following options must be included in ./configure:

-enable-open-appid

The configuration name is "appid":

The preprocessor name is appid.

preprocessor appid

Option syntax
 Option Argument Required Default app_detector_dir NO app_detector_dir { /usr/local/etc/appid } app_stats_filename NO NULL app_stats_period
Option explanations
app_detector_dir
specifies base path where Cisco provided detectors and application configuration files are installed by ODP (Open Detector Package) package. The package contains Lua detectors and some application metadata. Customer written detectors are stored in subdirectory "custom" under the same base path.
Syntax
    app_detector_dir <directory name>

Examples
    app_detector_dir /usr/local/cisco/apps


app_stats_filename
name of file. If this configuration is missing, application stats are disabled.
Syntax
    app_stats_filename <filename>

Examples
    app_stats_filename appStats.log


app_stats_period
bucket size in seconds. Default 5 minutes.
Syntax
    app_stats_period <time in seconds>

Examples
    app_stats_period 15


app_stats_rollover_size
file size which will cause file rollover. Default 20 MB.
Syntax
    app_stats_rollover_size <file size in bytes>

Examples
    app_stats_rollover_size 2000000


app_stats_rollover_time >
time since file creation which will cause rollover. Default 1 day.
Syntax
    app_stats_rollover_time <time in seconds>

Examples
    app_stats_rollover_time 3600


memcap >
upper bound for memory used by AppId internal structures. Default 32MB.
Syntax
    memcap <memory in bytes>

Examples
    memcap 100000000


dump_ports >
prints port only detectors and information on active detectors. Used for troubleshooting.
Syntax
    dump_ports <"yes"|"no">

Examples
    dump_ports "yes"


debug
Used in some old detectors for debugging.
Syntax
    debug

Examples
    debug


Default configuration

    preprocessor appid


### 2.2.24.3 Rule Options

The AppId preprocessor adds 1 new rule option as follows:

    appid


The preprocessor must be enabled for this rule option to work.

appid

The rule option allows users to customize rules to specific application in a simple manner. The option can take up to 10 application names separated by spaces, tabs, or commas. Application names in rules are the names you will see in last column in appMapping.data file. A rule is considered a match if one of the appId in a rule match an appId in a session.

For client side packets, payloadAppId in a session is matched with all AppIds in a rule. Thereafter miscAppId, clientAppId and serviceAppId are matched. Since Alert Events contain one AppId, only the first match is reported. If rule without appId option matches, then the most specific appId (in order of payload, misc, client, server) is reported.

The same logic is followed for server side packets with one exception. Order of matching is changed to make serviceAppId higher then clientAppId.

Syntax

    appid:<list of application names>

Examples
    appid: http;
appid: ftp, ftp-data;
appid: cnn.com, zappos;


### 2.2.24.4 Application Rule Events

A new event type is defined for logging application name in Snort Alerts in unified2 format only. These events contain only one application name. The Events can be enabled for unified2 output using 'appid_event_types keyword.

For example, the following configuration will log alert in my.alert file with application name.

    output alert\_unified2: filename my.alert, appid\_event\_types


u2spewfoo, u2openappid, u2streamer tools can be used to print alerts in new format. Each event will display additional application name at the end of the event.

Examples

#> u2spewfoo outputs the following event format
(Event)
sensor id: 0    event id: 6     event second: 1292962302        event microsecond: 227323
sig id: 18763   gen id: 1       revision: 4      classification: 0
priority: 0     ip source: 98.27.88.56  ip destination: 10.4.10.79
src port: 80    dest port: 54767        protocol: 6     impact\_flag: 0  blocked: 0
mpls label: 0   vland id: 0     policy id: 0    appid: zappos


### 2.2.24.5 Application Usage Statistics

AppId preprocessor prints application network usage periodically in snort log directory in unified2 format. File name, time interval for statistic and file rollover are controlled by appId preprocessor configuration. u2spewfoo, u2openappid, u2streamer tools can be used to print contents of these files. An example output from u2openappid tools is as follows:

    statTime="1292962290",appName="firefox",txBytes="9395",rxBytes="77021"
statTime="1292962290",appName="http",txBytes="28954",rxBytes="238000"
statTime="1292962290",appName="zappos",txBytes="26930",rxBytes="237072"


### 2.2.24.6 Open Detector Package (ODP) Installation

Application detectors from Snort team will be delivered in a separate package called Open Detector Package. ODP is a package that contains the following artifacts:
1. Application detectors in Lua language.

2. Port detectors, which are port only application detectors, in meta-data in YAML format.

3. appMapping.data file containing application metadata. This file should not be modified. The first column contains application identifier and second column contains application name. Other columns contain internal information.

4. Lua library files DetectorCommon.lua, flowTrackerModule.lua and hostServiceTrackerModule.lua
User can install ODP package in any directory of its choosing and configure this directory in app_detector_dir option in appId preprocessor configuration. Installing ODP will not modify any subdirectory named custom, where user-created detectors are located.

When installed, ODP will create following sub-directories:

    odp/port    //Cisco port-only detectors
odp/lua     //Cisco Lua detectors
odp/libs    //Cisco Lua modules


### 2.2.24.7 User Created Application Detectors

Users can create new applications by coding detectors in Lua language. Users can also copy Snort team provided detectors into custom subdirectory and customize the detector. A document will be posted on Snort Website with details on API usage.

Users must organize their Lua detectors and libraries by creating the following directory structure, under ODP installation directory.

    custom/port    //port-only detectors
custom/lua     //Lua detectors
custom/libs    //Lua modules
`