next up previous contents
Next: 2.3 Decoder and Preprocessor Up: 2. Configuring Snort Previous: 2.1 Includes   Contents

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

Engine Configuration

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

2.2.1.2.2 Advanced Configuration 

    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>], \
        [flush_on_alert], [show_rebuilt_packets], \
        [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.
flush_on_alert

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
min_session_lifetime <num millisecs>

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>], \
        [bind_to <ip_addr>], \
        [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
bind_to <ip_addr>

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:

These alerts are for one$\rightarrow$one 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:

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:

These are many$\rightarrow$one 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:

These alerts are for one$\rightarrow$many 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:

“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:

9.
scan_type $<$scan_type$>$

Available options:

10.
sense_level $<$level$>$

Available options:

11.
watch_ip $<$ip1$\vert$ip2/cidr[ [port$\vert$port2-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 $<$ip1$\vert$ip2/cidr[ [port$\vert$port2-port3]]$>$

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

13.
ignore_scanned $<$ip1$\vert$ip2/cidr[ [port$\vert$port2-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 sfPortscan Alert Output

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: \
        <ports> [ alert_fragments ] \
        [no_alert_multiple_requests] \
        [no_alert_large_fragments] \
        [no_alert_incomplete]


Option Description
alert_fragments

Alert on any fragmented RPC record.
no_alert_multiple_requests

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

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

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:

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:

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] \
        [proxy_alert] \
        [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.
proxy_alert

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

This option normalizes the text content with randomly encoded null bytes in 16LE,16BE,32LE and 32BE UTF encodings to UTF8 in the server response. It relies on file preprocessor to determine if the content is text. Hence file preprocessor should be enabled and configured with prepackaged file magics wihtout which this option is not effective.

Note:   This opton relies on file prepreprocessor to determine if content can safely be considered as text before normalizing. However, it is possible that non text file types unknown to file preprocessor may get normalized as this option treats file types unknown to file preprocessor as text. Such cases may result in false positives or false negatives in detection.

36.
fast_blocking

This option enables inspecting http data before the data is flushed. This enables early IPS rule evaluation so that the block rules will take into effect and the connection is blocked at the earliest instead of blocking later after flushing the data. This config will be effective only when inline normalisation is enabled.

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

38.
profile $<$all$\vert$apache$\vert$iis$\vert$iis5_0$\vert$iis4_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.

37-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
ASCII decoding on, alert off
multiple slash on, alert off
directory normalization on, alert off
apache whitespace on, alert off
double decoding on, alert on
%u decoding on, alert on
bare byte decoding on, alert on
iis unicode codepoints on, alert on
iis backslash on, alert off
iis delimiter on, alert off
webroot on, alert on
non_strict URL parsing on
tab_uri_delimiter is set
max_header_length 0, header length not checked
max_spaces 200
max_headers 0, number of headers not checked

37-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
ASCII decoding on, alert off
multiple slash on, alert off
directory normalization on, alert off
webroot on, alert on
apache whitespace on, alert on
utf_8 encoding on, alert off
non_strict url parsing on
tab_uri_delimiter is set
max_header_length 0, header length not checked
max_spaces 200
max_headers 0, number of headers not checked

37-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
ASCII decoding on, alert off
multiple slash on, alert off
directory normalization on, alert off
webroot on, alert on
double decoding on, alert on
%u decoding on, alert on
bare byte decoding on, alert on
iis unicode codepoints on, alert on
iis backslash on, alert off
iis delimiter on, alert on
apache whitespace on, alert on
non_strict URL parsing on
max_header_length 0, header length not checked
max_spaces 200
max_headers 0, number of headers not checked

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

37-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
ASCII decoding on, alert off
utf_8 encoding on, alert off
multiple slash on, alert off
directory normalization on, alert off
webroot on, alert on
iis backslash on, alert off
apache whitespace on, alert off
iis delimiter on, alert off
non_strict URL parsing on
max_header_length 0, header length not checked
max_spaces 200
max_headers 0, number of headers not checked

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
  • no_alerts
  • inspect_uri_only
  • oversize_dir_length
  • normalize_headers
  • normalize_cookies
  • normalize_utf
  • max_header_length
  • max_spaces
  • max_headers
  • extended_response_inspection
  • enable_cookie
  • 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 $\{ <$port$> [<$port$> <...>] \}$

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.

enable_cookie

This options turns on the cookie extraction from HTTP requests and HTTP response. By default the cookie inspection and extraction will be turned off. The cookie from the Cookie header line is extracted and stored in HTTP Cookie buffer for HTTP requests and cookie from the Set-Cookie is extracted and stored in HTTP Cookie buffer for HTTP responses. The Cookie: and Set-Cookie: header names itself along with leading spaces and the CRLF terminating the header line are stored in the HTTP header buffer and are not stored in the HTTP cookie buffer. 

Ex: Set-Cookie: mycookie \r\n

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

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 $\{ mode [mode] \}$

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 $\{ mode [mode] \}$

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:

Alert Description
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">
<head>
<title>FIXME</title>
</head>
<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.

\item \texttt{xff\_headers}

If/When the \texttt{enable\_xff} option is present, the \texttt{xff\_headers} option specifies a set of custom 'xff'
headers.  This option allows the definition of up to six custom headers in addition to the
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.
The header names must not collide with known http headers such as 'host', 'cookie',
'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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 $\{ <$byte$> [<$byte ...$>] \}$

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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

Normalizes backslashes to slashes. This is again an IIS emulation. So a request URI of “/foo$\backslash$bar” gets normalized to “/foo/bar.”

directory $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 $<$yes$\vert$no$>$

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 s$\backslash$n". 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.

no_alerts

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 $<$yes$\vert$no$>$

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.

normalize_headers

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.

normalize_cookies

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 $\{ cmd [cmd] \}$ 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. You can use "legacy_mode no" to enable HTTP2 support. If http legacy mode is configured, HTTP2 inspection is disabled.

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 \
        no_alerts

    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:

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

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

40.
inspection_type <stateful | stateless>

Indicate whether to operate in stateful or stateless mode.

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

42.
ignore_data

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

43.
ignore_tls_data

Ignore TLS-encrypted data when processing rules.

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

45.
max_header_line_len <int>

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.

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

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

Overrides max_command_line_len for specific commands.

48.
no_alerts

Turn off all alerts for this preprocessor.

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

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

50.
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 }

51.
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 }.

52.
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 }.

53.
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 }.

54.
alert_unknown_cmds

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

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

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

56.
xlink2state { enable | disable [drop] }

Enable/disable xlink2state alert. Drop if alerted. Default is enable.

57.
print_cmds

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

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

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

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

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

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

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

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

65.
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).

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

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

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

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

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

71.
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_header_line_len   1024 \
        max_response_line_len 512 \
        no_alerts \
        alt_max_command_line_len 300 { RCPT } \
        invalid_cmds { } \
        valid_cmds { } \
        xlink2state { disable } \
	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:

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

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

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

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

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

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

78.
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:

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

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

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

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

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

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

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

86.
inspection_type

This indicates whether to operate in stateful or stateless mode.

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

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

89.
ports $\{ <$port$> [<$port$> <...>] \}$

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.

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

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

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

93.
ports $\{ <$port$> [<$port$> <...>] \}$

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

94.
print_cmds

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

95.
ftp_cmds $\{ cmd [cmd] \}$

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 }

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

97.
alt_max_param_len $<$number$>$ $\{ cmd [cmd] \}$

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 }

98.
chk_str_fmt $\{ cmd [cmd] \}$

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

99.
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
$\vert$ 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
$\{\}$, $\vert$ One of choices enclosed within, separated by $\vert$
$\{\}$, $[]$ 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 >

100.
telnet_cmds $<$yes$\vert$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.

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

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

103.
ignore_data_chan $<$yes$\vert$no$>$

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

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

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

106.
bounce_to $<$ CIDR,[port$\vert$portlow,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:

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

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

109.
server_ports $\{ <$port$> [<$port$> <...>] \}$

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

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

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

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

113.
autodetect

Attempt to automatically detect SSH.

114.
enable_respoverflow

Enables checking for the Challenge-Response Overflow exploit.

115.
enable_ssh1crc32

Enables checking for the CRC 32 exploit.

116.
enable_srvoverflow

Enables checking for the Secure CRT exploit.

117.
enable_protomismatch

Enables checking for the Protocol Mismatch exploit.

118.
enable_badmsgdir

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

119.
enable_paysize

Enables alerts for invalid payload sizes.

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

121.
ports $\{ <$port$> [<$port$> <...>] \}$

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

122.
enable_obsolete_types

Alert on Obsolete (per RFC 1035) Record Types

123.
enable_experimental_types

Alert on Experimental (per RFC 1035) Record Types

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

125.
ports $\{ <$port$> [<$port$> <...>] \}$

This option specifies which ports SSLPP will inspect traffic on.

By default, SSLPP watches the following ports:

126.
noinspect_encrypted

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

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

128.
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
ip IP address.
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:

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
 Read
 Read Block Raw
 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 <memcap> NO memcap 102400
disable_defrag NONE NO OFF
max_frag_len <max-frag-len> NO OFF
events <events> NO OFF
reassemble_threshold <re-thresh> NO OFF
disabled NONE NO OFF
smb_fingerprint_policy <fp-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 <net> YES NONE
policy <policy> NO policy WinXP
detect <detect> NO detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593]
autodetect <detect> 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 <shares> NO NONE
smb_max_chain <max-chain> NO smb_max_chain 3
smb_file_inspection <file-inspect> 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
 
SID Description
2 An invalid NetBIOS Session Service type was specified in the header. Valid types are: Message, Request (only from client), Positive Response (only from server), Negative Response (only from server), Retarget Response (only from server) and Keep Alive.
3 An SMB message type was specified in the header. Either a request was made by the server or a response was given by the client.
4 The SMB id does not equal \xffSMB or \xfeSMB.
5 The word count of the command header is invalid. SMB commands have pretty specific word counts and if the preprocessor sees a command with a word count that doesn't jive with that command, the preprocessor will alert.
6 Some commands require a minimum number of bytes after the command header. If a command requires this and the byte count is less than the minimum required byte count for that command, the preprocessor will alert.
7 Some commands, especially the commands from the SMB Core implementation require a data format field that specifies the kind of data that will be coming next. Some commands require a specific format for the data. The preprocessor will alert if the format is not that which is expected for that command.
8 Many SMB commands have a field containing an offset from the beginning of the SMB header to where the data the command is carrying starts. If this offset puts us before data that has already been processed or after the end of payload, the preprocessor will alert.
9 Some SMB commands, such as Transaction, have a field containing the total amount of data to be transmitted. If this field is zero, the preprocessor will alert.
10 The preprocessor will alert if the NetBIOS Session Service length field contains a value less than the size of an SMB header.
11 The preprocessor will alert if the remaining NetBIOS packet length is less than the size of the SMB command header to be decoded.
12 The preprocessor will alert if the remaining NetBIOS packet length is less than the size of the SMB command byte count specified in the command header.
13 The preprocessor will alert if the remaining NetBIOS packet length is less than the size of the SMB command data size specified in the command header.
14 The preprocessor will alert if the total data count specified in the SMB command header is less than the data size specified in the SMB command header. (Total data count must always be greater than or equal to current data size.)
15 The preprocessor will alert if the total amount of data sent in a transaction is greater than the total data count specified in the SMB command header.
16 The preprocessor will alert if the byte count specified in the SMB command header is less than the data size specified in the SMB command. (The byte count must always be greater than or equal to the data size.)
17 Some of the Core Protocol commands (from the initial SMB implementation) require that the byte count be some value greater than the data size exactly. The preprocessor will alert if the byte count minus a predetermined amount based on the SMB command is not equal to the data size.
18 For the Tree Connect command (and not the Tree Connect AndX command), the preprocessor has to queue the requests up and wait for a server response to determine whether or not an IPC share was successfully connected to (which is what the preprocessor is interested in). Unlike the Tree Connect AndX response, there is no indication in the Tree Connect response as to whether the share is IPC or not. There should be under normal circumstances no more than a few pending tree connects at a time and the preprocessor will alert if this number is excessive.
19 After a client is done writing data using the Write* commands, it issues a Read* command to the server to tell it to send a response to the data it has written. In this case the preprocessor is concerned with the server response. The Read* request contains the file id associated with a named pipe instance that the preprocessor will ultimately send the data to. The server response, however, does not contain this file id, so it need to be queued with the request and dequeued with the response. If multiple Read* requests are sent to the server, they are responded to in the order they were sent. There should be under normal circumstances no more than a few pending Read* requests at a time and the preprocessor will alert if this number is excessive.
20 The preprocessor will alert if the number of chained commands in a single request is greater than or equal to the configured amount (default is 3).
21 With AndX command chaining it is possible to chain multiple Session Setup AndX commands within the same request. There is, however, only one place in the SMB header to return a login handle (or Uid). Windows does not allow this behavior, however Samba does. This is anomalous behavior and the preprocessor will alert if it happens.
22 With AndX command chaining it is possible to chain multiple Tree Connect AndX commands within the same request. There is, however, only one place in the SMB header to return a tree handle (or Tid). Windows does not allow this behavior, however Samba does. This is anomalous behavior and the preprocessor will alert if it happens.
23 When a Session Setup AndX request is sent to the server, the server responds (if the client successfully authenticates) which a user id or login handle. This is used by the client in subsequent requests to indicate that it has authenticated. A Logoff AndX request is sent by the client to indicate it wants to end the session and invalidate the login handle. With commands that are chained after a Session Setup AndX request, the login handle returned by the server is used for the subsequent chained commands. The combination of a Session Setup AndX command with a chained Logoff AndX command, essentially logins in and logs off in the same request and is anomalous behavior. The preprocessor will alert if it sees this.
24 A Tree Connect AndX command is used to connect to a share. The Tree Disconnect command is used to disconnect from that share. The combination of a Tree Connect AndX command with a chained Tree Disconnect command, essentially connects to a share and disconnects from the same share in the same request and is anomalous behavior. The preprocessor will alert if it sees this.
25 An Open AndX or Nt Create AndX command is used to open/create a file or named pipe. (The preprocessor is only interested in named pipes as this is where DCE/RPC requests are written to.) The Close command is used to close that file or named pipe. The combination of a Open AndX or Nt Create AndX command with a chained Close command, essentially opens and closes the named pipe in the same request and is anomalous behavior. The preprocessor will alert if it sees this.
26 The preprocessor will alert if it sees any of the invalid SMB shares configured. It looks for a Tree Connect or Tree Connect AndX to the share.
48 The preprocessor will alert if a data count for a Core dialect write command is zero.
49 For some of the Core dialect commands such as Write and Read, there are two data count fields, one in the main command header and one in the data format section. If these aren't the same, the preprocessor will alert.
50 In the initial negotiation phase of an SMB session, the server in a Negotiate response and the client in a SessionSetupAndX request will advertise the maximum number of outstanding requests supported. The preprocessor will alert if the lesser of the two is exceeded.
51 When a client sends a request it uses a value called the MID (multiplex id) to match a response, which the server is supposed to echo, to a request. If there are multiple outstanding requests with the same MID, the preprocessor will alert.
52 In the Negotiate request a client gives a list of SMB dialects it supports, normally in order from least desirable to most desirable and the server responds with the index of the dialect to be used on the SMB session. Anything less than "NT LM 0.12" would be very odd these days (even Windows 98 supports it) and the preprocessor will alert if the client doesn't offer it as a supported dialect or the server chooses a lesser dialect.
53 There are a number of commands that are considered deprecated and/or obsolete by Microsoft (see MS-CIFS and MS-SMB). If the preprocessor detects the use of a deprecated/obsolete command used it will alert.
54 There are some commands that can be used that can be considered unusual in the context they are used. These include some of the transaction commands such as: SMB_COM_TRANSACTION / TRANS_READ_NMPIPE SMB_COM_TRANSACTION / TRANS_WRITE_NMPIPE SMB_COM_TRANSACTION2 / TRANS2_OPEN2 SMB_COM_NT_TRANSACT / NT_TRANSACT_CREATE The preprocessor will alert if it detects unusual use of a command.
55 Transaction commands have a setup count field that indicates the number of 16bit words in the transaction setup. The preprocessor will alert if the setup count is invalid for the transaction command / sub command.
56 There can be only one Negotiate transaction per session and it is the first thing a client and server do to determine the SMB dialect each supports. The preprocessor will alert if the client attempts multiple dialect negotiations.
57 Malware will often set a file's attributes to ReadOnly/Hidden/System if it is successful in installing itself as a Windows service or is able to write an autorun.inf file since it doesn't want the user to see the file and the default folder options in Windows is not to display Hidden files. The preprocessor will alert if it detects a client attempt to set a file's attributes to ReadOnly/Hidden/System.
58 File offset provided is greater than file size specified. This is applied to read / write requests for file.
59 Nextcommand specified in SMBv2 or SMBv3 header is beyond payload boundary.

Connection-oriented DCE/RPC events
 

SID Description
27 The preprocessor will alert if the connection-oriented DCE/RPC major version contained in the header is not equal to 5.
28 The preprocessor will alert if the connection-oriented DCE/RPC minor version contained in the header is not equal to 0.
29 The preprocessor will alert if the connection-oriented DCE/RPC PDU type contained in the header is not a valid PDU type.
30 The preprocessor will alert if the fragment length defined in the header is less than the size of the header.
31 The preprocessor will alert if the remaining fragment length is less than the remaining packet size.
32 The preprocessor will alert if in a Bind or Alter Context request, there are no context items specified.
33 The preprocessor will alert if in a Bind or Alter Context request, there are no transfer syntaxes to go with the requested interface.
34 The preprocessor will alert if a non-last fragment is less than the size of the negotiated maximum fragment length. Most evasion techniques try to fragment the data as much as possible and usually each fragment comes well below the negotiated transmit size.
35 The preprocessor will alert if a fragment is larger than the maximum negotiated fragment length.
36 The byte order of the request data is determined by the Bind in connection-oriented DCE/RPC for Windows. It is anomalous behavior to attempt to change the byte order mid-session.
37 The call id for a set of fragments in a fragmented request should stay the same (it is incremented for each complete request). The preprocessor will alert if it changes in a fragment mid-request.
38 The operation number specifies which function the request is calling on the bound interface. If a request is fragmented, this number should stay the same for all fragments. The preprocessor will alert if the opnum changes in a fragment mid-request.
39 The context id is a handle to a interface that was bound to. If a request if fragmented, this number should stay the same for all fragments. The preprocessor will alert if the context id changes in a fragment mid-request.

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, $\vert$05 00 00$\vert$ will be inserted into the fast pattern matcher, (2) if the rule option flow:from_server|to_client is used, $\vert$05 00 02$\vert$ will be inserted into the fast pattern matcher and (3) if the flow isn't known, $\vert$05 00$\vert$ 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>] \
        [, align][, post_offset <adjustment_value>], dce;

    convert           = 1 | 2 | 4 (only with option "dce")
    offset            = -65535 to 65535
    mult_value        = 0 - 65535
    adjustment_value  = -65535 to 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; \
        classtype:attempted-admin; sid:1000068;)

    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; \
        classtype:attempted-admin; sid:1000069;)


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
 
Option Argument Required Default
alert_threshold <number> NO alert_threshold 25
mask_output NONE NO OFF
ssn_file <filename> NO OFF 

    alert_threshold     =  1 - 65535

Option explanations
 alert_threshold
 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.

 mask_output
 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 \
                             mask_output \
                             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; \
    sd_pattern:4,credit_card; metadata:service smtp;)

 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:

Optional normalizations include:

2.2.18.2 IP6 Normalizations

IP6 normalizations are enabled with: 

    preprocessor normalize_ip6

Base normalizations enabled with "preprocessor normalize_ip6" include:

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:

2.2.18.4 TCP Normalizations

TCP normalizations are enabled with: 

    preprocessor normalize_tcp: \
        [block], [rsv], [pad], \
        [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:

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:

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 <max_sessions> NO max_sessions 10000
max_dialogs <max_dialogs> NO max_dialogs 4
ports <ports> NO ports { 5060 5061 }
methods <methods> NO methods { invite cancel ack bye register options }
max_uri_len <max_uri_len> NO max_uri_len 256
max_call_id_len <max_call_id_len> NO max_call_id_len 256
max_requestName_len <max_requestName_len> NO max_requestName_len 20
max_from_len <max_from_len> NO max_from_len 256
max_to_len <max_to_len> NO max_to_len 256
max_via_len <max_via_len> NO max_via_len 1024
max_contact_len <max_contact_len> NO max_contact_len 256
max_content_len <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 $2^{31}$.
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_header
  sip_body
Overload modifiers to existing pcre rule options:
 H: Match SIP request or SIP response header, Similar to sip_header.
 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

sip_header
 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 <memcap> NO memcap 500
scan_local NONE NO OFF
blacklist <list file name> NO NONE
whitelist <list file name> 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 $60$ 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.

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:

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 $2152$ (GTPv1) and $3386$ (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 <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 $50$ in GTPv0 and GTPv1, but $130$ 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 $50$; evaluating a GTPv2 packet will check whether the message type value is $130$. 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
Type GTPv0 GTPv1 GTPv2
0 N/A N/A N/A
1 echo_request echo_request echo_request
2 echo_response echo_response echo_response
3 version_not_supported version_not_supported version_not_supported
4 node_alive_request node_alive_request N/A
5 node_alive_response node_alive_response N/A
6 redirection_request redirection_request N/A
7 redirection_response redirection_response N/A
16 create_pdp_context_request create_pdp_context_request N/A
17 create_pdp_context_response create_pdp_context_response N/A
18 update_pdp_context_request update_pdp_context_request N/A
19 update_pdp_context_response update_pdp_context_response N/A
20 delete_pdp_context_request delete_pdp_context_request N/A
21 delete_pdp_context_response delete_pdp_context_response N/A
22 create_aa_pdp_context_request init_pdp_context_activation_request N/A
23 create_aa_pdp_context_response init_pdp_context_activation_response N/A
24 delete_aa_pdp_context_request N/A N/A
25 delete_aa_pdp_context_response N/A N/A
26 error_indication error_indication N/A
27 pdu_notification_request pdu_notification_request N/A
28 pdu_notification_response pdu_notification_response N/A
29 pdu_notification_reject_request pdu_notification_reject_request N/A
30 pdu_notification_reject_response pdu_notification_reject_response N/A
31 N/A supported_ext_header_notification N/A
32 send_routing_info_request send_routing_info_request create_session_request
33 send_routing_info_response send_routing_info_response create_session_response
34 failure_report_request failure_report_request modify_bearer_request
35 failure_report_response failure_report_response modify_bearer_response
36 note_ms_present_request note_ms_present_request delete_session_request
37 note_ms_present_response note_ms_present_response delete_session_response
38 N/A N/A change_notification_request
39 N/A N/A change_notification_response
48 identification_request identification_request N/A
49 identification_response identification_response N/A
50 sgsn_context_request sgsn_context_request N/A
51 sgsn_context_response sgsn_context_response N/A
52 sgsn_context_ack sgsn_context_ack N/A
53 N/A forward_relocation_request N/A
54 N/A forward_relocation_response N/A
55 N/A forward_relocation_complete N/A
56 N/A relocation_cancel_request N/A
57 N/A relocation_cancel_response N/A
58 N/A forward_srns_contex N/A
59 N/A forward_relocation_complete_ack N/A
60 N/A forward_srns_contex_ack N/A
64 N/A N/A modify_bearer_command
65 N/A N/A modify_bearer_failure_indication
66 N/A N/A delete_bearer_command
67 N/A N/A delete_bearer_failure_indication
68 N/A N/A bearer_resource_command
69 N/A N/A bearer_resource_failure_indication
70 N/A ran_info_relay downlink_failure_indication
71 N/A N/A trace_session_activation
72 N/A N/A trace_session_deactivation
73 N/A N/A stop_paging_indication
95 N/A N/A create_bearer_request
96 N/A mbms_notification_request create_bearer_response
97 N/A mbms_notification_response update_bearer_request
98 N/A mbms_notification_reject_request update_bearer_response
99 N/A mbms_notification_reject_response delete_bearer_request
100 N/A create_mbms_context_request delete_bearer_response
101 N/A create_mbms_context_response delete_pdn_request
102 N/A update_mbms_context_request delete_pdn_response
103 N/A update_mbms_context_response N/A
104 N/A delete_mbms_context_request N/A
105 N/A delete_mbms_context_response N/A
112 N/A mbms_register_request N/A
113 N/A mbms_register_response N/A
114 N/A mbms_deregister_request N/A
115 N/A mbms_deregister_response N/A
116 N/A mbms_session_start_request N/A
117 N/A mbms_session_start_response N/A
118 N/A mbms_session_stop_request N/A
119 N/A mbms_session_stop_response N/A
120 N/A mbms_session_update_request N/A
121 N/A mbms_session_update_response N/A
128 N/A ms_info_change_request identification_request
129 N/A ms_info_change_response identification_response
130 N/A N/A sgsn_context_request
131 N/A N/A sgsn_context_response
132 N/A N/A sgsn_context_ack
133 N/A N/A forward_relocation_request
134 N/A N/A forward_relocation_response
135 N/A N/A forward_relocation_complete
136 N/A N/A forward_relocation_complete_ack
137 N/A N/A forward_access
138 N/A N/A forward_access_ack
139 N/A N/A relocation_cancel_request
140 N/A N/A relocation_cancel_response
141 N/A N/A configuration_transfer_tunnel
149 N/A N/A detach
150 N/A N/A detach_ack
151 N/A N/A cs_paging
152 N/A N/A ran_info_relay
153 N/A N/A alert_mme
154 N/A N/A alert_mme_ack
155 N/A N/A ue_activity
156 N/A N/A ue_activity_ack
160 N/A N/A create_forward_tunnel_request
161 N/A N/A create_forward_tunnel_response
162 N/A N/A suspend
163 N/A N/A suspend_ack
164 N/A N/A resume
165 N/A N/A resume_ack
166 N/A N/A create_indirect_forward_tunnel_request
167 N/A N/A create_indirect_forward_tunnel_response
168 N/A N/A delete_indirect_forward_tunnel_request
169 N/A N/A delete_indirect_forward_tunnel_response
170 N/A N/A release_access_bearer_request
171 N/A N/A release_access_bearer_response
176 N/A N/A downlink_data
177 N/A N/A downlink_data_ack
178 N/A N/A N/A
179 N/A N/A pgw_restart
199 N/A N/A pgw_restart_ack
200 N/A N/A update_pdn_request
201 N/A N/A update_pdn_response
211 N/A N/A modify_access_bearer_request
212 N/A N/A modify_access_bearer_response
231 N/A N/A mbms_session_start_request
232 N/A N/A mbms_session_start_response
233 N/A N/A mbms_session_update_request
234 N/A N/A mbms_session_update_response
235 N/A N/A mbms_session_stop_request
236 N/A N/A mbms_session_stop_response
240 data_record_transfer_request data_record_transfer_request N/A
241 data_record_transfer_response data_record_transfer_response N/A
254 N/A end_marker N/A
255 pdu pdu N/A

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 $[0, 255]$, 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 $1$ in GTPv0 and GTPv1, but $2$ 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
Type GTPv0 GTPv1 GTPv2
0 N/A N/A N/A
1 cause cause imsi
2 imsi imsi cause
3 rai rai recovery
4 tlli tlli N/A
5 p_tmsi p_tmsi N/A
6 qos N/A N/A
7 N/A N/A N/A
8 recording_required recording_required N/A
9 authentication authentication N/A
10 N/A N/A N/A
11 map_cause map_cause N/A
12 p_tmsi_sig p_tmsi_sig N/A
13 ms_validated ms_validated N/A
14 recovery recovery N/A
15 selection_mode selection_mode N/A
16 flow_label_data_1 teid_1 N/A
17 flow_label_signalling teid_control N/A
18 flow_label_data_2 teid_2 N/A
19 ms_unreachable teardown_ind N/A
20 N/A nsapi N/A
21 N/A ranap N/A
22 N/A rab_context N/A
23 N/A radio_priority_sms N/A
24 N/A radio_priority N/A
25 N/A packet_flow_id N/A
26 N/A charging_char N/A
27 N/A trace_ref N/A
28 N/A trace_type N/A
29 N/A ms_unreachable N/A
71 N/A N/A apn
72 N/A N/A ambr
73 N/A N/A ebi
74 N/A N/A ip_addr
75 N/A N/A mei
76 N/A N/A msisdn
77 N/A N/A indication
78 N/A N/A pco
79 N/A N/A paa
80 N/A N/A bearer_qos
81 N/A N/A flow_qos
82 N/A N/A rat_type
83 N/A N/A serving_network
84 N/A N/A bearer_tft
85 N/A N/A tad
86 N/A N/A uli
87 N/A N/A f_teid
88 N/A N/A tmsi
89 N/A N/A cn_id
90 N/A N/A s103pdf
91 N/A N/A s1udf
92 N/A N/A delay_value
93 N/A N/A bearer_context
94 N/A N/A charging_id
95 N/A N/A charging_char
96 N/A N/A trace_info
97 N/A N/A bearer_flag
98 N/A N/A N/A
99 N/A N/A pdn_type
100 N/A N/A pti
101 N/A N/A drx_parameter
102 N/A N/A N/A
103 N/A N/A gsm_key_tri
104 N/A N/A umts_key_cipher_quin
105 N/A N/A gsm_key_cipher_quin
106 N/A N/A umts_key_quin
107 N/A N/A eps_quad
108 N/A N/A umts_key_quad_quin
109 N/A N/A pdn_connection
110 N/A N/A pdn_number
111 N/A N/A p_tmsi
112 N/A N/A p_tmsi_sig
113 N/A N/A hop_counter
114 N/A N/A ue_time_zone
115 N/A N/A trace_ref
116 N/A N/A complete_request_msg
117 N/A N/A guti
118 N/A N/A f_container
119 N/A N/A f_cause
120 N/A N/A plmn_id
121 N/A N/A target_id
122 N/A N/A N/A
123 N/A N/A packet_flow_id
124 N/A N/A rab_contex
125 N/A N/A src_rnc_pdcp
126 N/A N/A udp_src_port
127 charge_id charge_id apn_restriction
128 end_user_address end_user_address selection_mode
129 mm_context mm_context src_id
130 pdp_context pdp_context N/A
131 apn apn change_report_action
132 protocol_config protocol_config fq_csid
133 gsn gsn channel
134 msisdn msisdn emlpp_pri
135 N/A qos node_type
136 N/A authentication_qu fqdn
137 N/A tft ti
138 N/A target_id mbms_session_duration
139 N/A utran_trans mbms_service_area
140 N/A rab_setup mbms_session_id
141 N/A ext_header mbms_flow_id
142 N/A trigger_id mbms_ip_multicast
143 N/A omc_id mbms_distribution_ack
144 N/A ran_trans rfsp_index
145 N/A pdp_context_pri uci
146 N/A addi_rab_setup csg_info
147 N/A sgsn_number csg_id
148 N/A common_flag cmi
149 N/A apn_restriction service_indicator
150 N/A radio_priority_lcs detach_type
151 N/A rat_type ldn
152 N/A user_loc_info node_feature
153 N/A ms_time_zone mbms_time_to_transfer
154 N/A imei_sv throttling
155 N/A camel arp
156 N/A mbms_ue_context epc_timer
157 N/A tmp_mobile_group_id signalling_priority_indication
158 N/A rim_routing_addr tmgi
159 N/A mbms_config mm_srvcc
160 N/A mbms_service_area flags_srvcc
161 N/A src_rnc_pdcp mmbr
162 N/A addi_trace_info N/A
163 N/A hop_counter N/A
164 N/A plmn_id N/A
165 N/A mbms_session_id N/A
166 N/A mbms_2g3g_indicator N/A
167 N/A enhanced_nsapi N/A
168 N/A mbms_session_duration N/A
169 N/A addi_mbms_trace_info N/A
170 N/A mbms_session_repetition_num N/A
171 N/A mbms_time_to_data N/A
173 N/A bss N/A
174 N/A cell_id N/A
175 N/A pdu_num N/A
176 N/A N/A N/A
177 N/A mbms_bearer_capab N/A
178 N/A rim_routing_disc N/A
179 N/A list_pfc N/A
180 N/A ps_xid N/A
181 N/A ms_info_change_report N/A
182 N/A direct_tunnel_flags N/A
183 N/A correlation_id N/A
184 N/A bearer_control_mode N/A
185 N/A mbms_flow_id N/A
186 N/A mbms_ip_multicast N/A
187 N/A mbms_distribution_ack N/A
188 N/A reliable_inter_rat_handover N/A
189 N/A rfsp_index N/A
190 N/A fqdn N/A
191 N/A evolved_allocation1 N/A
192 N/A evolved_allocation2 N/A
193 N/A extended_flags N/A
194 N/A uci N/A
195 N/A csg_info N/A
196 N/A csg_id N/A
197 N/A cmi N/A
198 N/A apn_ambr N/A
199 N/A ue_network N/A
200 N/A ue_ambr N/A
201 N/A apn_ambr_nsapi N/A
202 N/A ggsn_backoff_timer N/A
203 N/A signalling_priority_indication N/A
204 N/A signalling_priority_indication_nsapi N/A
205 N/A high_bitrate N/A
206 N/A max_mbr N/A
250 N/A N/A N/A
N/A N/A N/A
251 charging_gateway_addr charging_gateway_addr N/A
255 private_extension private_extension private_extension
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:

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 <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 |
            "read_coils" |
            "read_discrete_inputs" |
            "read_holding_registers" |
            "read_input_registers" |
            "write_single_coil" |
            "write_single_register" |
            "read_exception_status" |
            "diagnostics" |
            "get_comm_event_counter" |
            "get_comm_event_log" |
            "write_multiple_coils" |
            "write_multiple_registers" |
            "report_slave_id" |
            "read_file_record" |
            "write_file_record" |
            "mask_write_register" |
            "read_write_multiple_registers" |
            "read_fifo_queue" |
            "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:

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 <ports> NO ports { 20000 }
memcap <number NO memcap 262144
check_crc NONE NO OFF
disabled NONE NO OFF
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" |
            "read" |
            "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"
            "already_executing"
            "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

2.2.24.1 Dependency Requirements

For proper functioning of the preprocessor:

2.2.24.2 Preprocessor Configuration

AppId dynamic preprocessor is enabled by default(from snort-2.9.12). The preprocessor can be disabled during build time by including the following option in ./configure:

-disable-open-appid

The configuration name is "appid":

The preprocessor name is appid. 

preprocessor appid
Option syntax
 
Option Argument Required Default
app_detector_dir <directory> NO app_detector_dir { /usr/local/etc/appid }
app_stats_filename <filename> NO NULL
app_stats_period <time in seconds> NO 300 seconds
app_stats_rollover_size <disk size in bytes> NO 20 MB
app_stats_rollover_time <time in seconds> NO 1 day
memcap <memory limit bytes> NO 256 MB
debug <"yes"> NO disabled
dump_ports No NO disabled
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="google\_analytic",txBytes="2024",rxBytes="928"
    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

next up previous contents
Next: 2.3 Decoder and Preprocessor Up: 2. Configuring Snort Previous: 2.1 Includes   Contents