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 rules file is: 

    preprocessor <name>: <options>


2.2.1 Frag3

The frag3 preprocessor is a target-based IP defragmentation module for Snort. Frag3 is intended as a replacement for the frag2 defragmentation module and was designed with the following goals:

1.
Faster execution than frag2 with less complex data management.
2.
Target-based host modeling anti-evasion techniques.

The frag2 preprocessor used splay trees extensively for managing the data structures associated with defragmenting packets. Splay trees are excellent data structures to use when you have some assurance of locality of reference for the data that you are handling but in high speed, heavily fragmented environments the nature of the splay trees worked against the system and actually hindered performance. 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

Frag3 configuration is somewhat more complex than frag2. 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 Stream5

The Stream5 preprocessor is a target-based TCP reassembly module for Snort. It is capable of tracking sessions for both TCP and UDP. With Stream5, the rule 'flow' and 'flowbits' keywords are usable with TCP as well as UDP traffic.

2.2.2.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.2.2 Target-Based

Stream5, 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 Stream5 are the results of extensive research with many target operating systems.

2.2.2.3 Stream API

Stream5 fully supports the Stream API, other protocol normalizers/preprocessors to dynamically configure reassembly behavior as required by the application layer protocol, 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.

2.2.2.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.2.5 Stream5 Global Configuration

Global settings for the Stream5 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>], \
        [flush_on_alert], [show_rebuilt_packets], \
        [prune_log_max <bytes>], [disabled]

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 "256000", maximum is "1052672", minimum is "1".
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 "128000", maximum is "1052672", minimum is "1".
track_icmp <yes|no>

Track sessions for ICMP. The default is "yes".
max_icmp <num sessions>

Maximum simultaneous ICMP sessions tracked. The default is "64000", maximum is "1052672", minimum is "1".
disabled

Option to disble 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 is "0" (unlimited), maximum is not bounded, other than by the memcap.

2.2.2.6 Stream5 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: \
        [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>], \
        [ports <client|server|both> <all|number [number]*>], \
        [ignore_any_rules]

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 first 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 Stream5 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.
ports <client|server|both> <all|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".
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.

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.2.7 Stream5 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.2.8 Stream5 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.2.9 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.2.10 Alerts

Stream5 uses generator ID 129. It is capable of alerting on 8 (eight) anomalies, all of which relate to TCP anomalies. There are no anomalies detected relating to UDP or ICMP.

The list of SIDs is as follows:

  1. SYN on established session
  2. Data on SYN packet
  3. Data sent on stream not accepting data
  4. TCP Timestamp is outside of PAWS window
  5. Bad segment, overlap adjusted size less than/equal 0
  6. Window size (after scaling) larger than policy allows
  7. Limit on number of overlapping TCP packets reached
  8. Data after Reset packet

2.2.3 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.3.1 sfPortscan Configuration

Use of the Stream5 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:

3.
proto $<$protocol$>$

Available options:

4.
scan_type $<$scan_type$>$

Available options:

5.
sense_level $<$level$>$

Available options:

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

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

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

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

10.
include_midstream

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

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

12.
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.3.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.3.3 Example 

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

2.2.3.4 sfPortscan Alert Output

2.2.3.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 unified 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.3.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

13.
Event_id/Event_ref

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

14.
Priority Count

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

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

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

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

18.
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.3.5 Tuning sfPortscan

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

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

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

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

22.
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.4 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.4.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.5 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:

The following options can be used with the performance monitor:

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


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

The current version of HTTP Inspect only handles stateless processing. This means that HTTP Inspect looks for HTTP fields on a packet-by-packet basis, and will be fooled if packets are not reassembled. This works fine when there is another module handling the reassembly, but there are limitations in analyzing the protocol. Future versions will have a stateful processing mode which will hook into various reassembly modules.

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.6.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.6.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>] \
	disabled

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

2.2.6.2.1 Configuration

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

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

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

26.
compress_depth $<$integer$>$ This option specifies the maximum amount of packet payload to decompress. This value can be set from 1 to 20480. The default for this option is 1460.

27.
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 20480. The default for this option is 2920.

28.
max_gzip_mem

This option determines (in bytes) the maximum amount of memory the HTTP Inspect preprocessor will use for decompression. This value can be set from 3276 bytes to 100MB. This option along with compress_depth and decompress_depth determines the gzip sessions that will be decompressed at any given instant. The default value for this option is 838860.

Note:  

It is suggested to set this value such that the max gzip session calculated as follows is atleast 1.

max gzip session = max_gzip_mem /(decompress_depth + compress_depth)

29.
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 "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.6.3 Example Global Configuration 

    preprocessor http_inspect: \
        global iis_unicode_map unicode.map 1252

2.2.6.4 Server Configuration

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

2.2.6.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.6.5 Example Default Configuration 

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

2.2.6.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.6.6 Example IP Configuration 

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

2.2.6.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.6.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.6.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.

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

29-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_headers 0, number of headers not checked

29-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_headers 0, number of headers not checked

29-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 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
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_headers 0, number of headers not checked

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

29-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 0
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_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
  • max_header_length
  • max_headers
  • extended_response_inspection
  • enable_cookie
  • inspect_gzip

These options must be specified after the profile option.

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

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.

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

Note:  

To enable compression of HTTP server response, Snort should be configured with the -enable-zlib flag.

server_flow_depth $<$integer$>$

This specifies the amount of server response payload to inspect. This option significantly increases IDS performance because we are ignoring a large part of the network traffic (HTTP server response payloads). A small percentage of Snort rules are targeted at this traffic and a small flow_depth value may cause false negatives in some of these rules. 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.

This value can be set from -1 to 2920. A value of -1 causes Snort to ignore all server side traffic for ports defined in ports. 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 in the first packet of the server response.It is suggested to set the 'server_flow_depth' to its maximum value or the 'decompress_depth' (if 'decompress_depth' is less than 2920) when 'inspect_gzip' is enabled.

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. It is similar to server_flow_depth (above), and 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.

post_depth $<$integer$>$

This specifies the amount of data to inspect in a client post message. The value can be set from 0 to 65495. The default value is 0. 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.

base36 $<$yes$\vert$no$>$

This is an option to decode base36 encoded chars. This option is based on info from:

http://www.yk.rim.or.jp/~shikap/patch/spp_http_decode.patch.

If %u encoding is enabled, this option will not work. You have to use the base36 option with the utf_8 option. Don't use the %u option, because base36 won't work. When base36 is enabled, ASCII encoding is also enabled to enforce correct behavior.

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.

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.

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 (ie, 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 (ie, multi-slash, directory, etc.). It is useful for normalizing data in HTTP Cookies that may be encoded.

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.

2.2.6.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.7 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 (ie, a loss of coherent stream data results in a loss of state).

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

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

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

32.
inspection_type <stateful | stateless>

Indicate whether to operate in stateful or stateless mode.

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

34.
ignore_data

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

35.
ignore_tls_data

Ignore TLS-encrypted data when processing rules.

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

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

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

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

Overrides max_command_line_len for specific commands.

40.
no_alerts

Turn off all alerts for this preprocessor.

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

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

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

43.
alert_unknown_cmds

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

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

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

45.
xlink2state { enable | disable [drop] }

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

46.
print_cmds

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

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

2.2.7.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.7.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.8 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.8.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.8.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.8.2.1 Configuration

47.
inspection_type

This indicates whether to operate in stateful or stateless mode.

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

49.
check_encrypted

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

2.2.8.3 Example Global Configuration 

    preprocessor ftp_telnet: \
        global inspection_type stateful encrypted_traffic no

2.2.8.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.8.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.8.5.1 Configuration

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

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

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

53.
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.8.6 Example Telnet Configuration 

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

2.2.8.7 FTP Server Configuration

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

2.2.8.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.8.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.8.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.8.9 Example IP specific FTP Server Configuration 

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

2.2.8.10 FTP Server Configuration Options

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

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

55.
print_cmds

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

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

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

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

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

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

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

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

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

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

64.
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.8.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.8.12 FTP Client Configuration

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

2.2.8.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.8.13 Example Default FTP Client Configuration 

    preprocessor ftp_telnet_protocol: \
        ftp client default bounce no max_resp_len 200

2.2.8.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.8.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.8.15 FTP Client Configuration Options

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

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

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

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

69.
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.8.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.9 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.9.1 Configuration

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

The available configuration options are described below.

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

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

71.
max_encrypted_packets $<$ number $>$

The number of 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.

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

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

74.
autodetect

Attempt to automatically detect SSH.

75.
enable_respoverflow

Enables checking for the Challenge-Response Overflow exploit.

76.
enable_ssh1crc32

Enables checking for the CRC 32 exploit.

77.
enable_srvoverflow

Enables checking for the Secure CRT exploit.

78.
enable_protomismatch

Enables checking for the Protocol Mismatch exploit.

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

80.
enable_paysize

Enables alerts for invalid payload sizes.

81.
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.9.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.10 DCE/RPC

Note:   The dcerpc preprocessor is now considered deprecated and will be removed in a future release. Please use the dcerpc2 preprocessor in its place. See section [*] of this manual and README.dcerpc2 for documentation.

The dcerpc preprocessor detects and decodes SMB and DCE/RPC traffic. It is primarily interested in DCE/RPC requests, and only decodes SMB to get to the potential DCE/RPC requests carried by SMB.

Currently, the preprocessor only handles desegmentation (at SMB and TCP layers) and defragmentation of DCE/RPC. Snort rules can be evaded by using both types of fragmentation. With the preprocessor enabled, the rules are given reassembled DCE/RPC data to examine.

At the SMB layer, only segmentation using WriteAndX is currently reassembled. Other methods will be handled in future versions of the preprocessor.

Autodetection of SMB is done by looking for "\xFFSMB" at the start of the SMB data, as well as checking the NetBIOS header (which is always present for SMB) for the type "Session Message".

Autodetection of DCE/RPC is not as reliable. Currently, two bytes are checked in the packet. Assuming that the data is a DCE/RPC header, one byte is checked for DCE/RPC version 5 and another for a DCE/RPC PDU type of Request. If both match, the preprocessor proceeds with the assumption that it is looking at DCE/RPC data. If subsequent checks are nonsensical, it ends processing.

2.2.10.1 Configuration

The preprocessor has several optional configuration options. They are described below:

2.2.10.2 Configuration Examples

In addition to defaults, autodetect SMB and DCE/RPC sessions on non-configured ports. Don't do desegmentation on SMB writes. Truncate DCE/RPC fragment if greater than 4000 bytes. 

    preprocessor dcerpc: \
        autodetect \
        disable_smb_frag \
        max_frag_size 4000

In addition to defaults, don't do DCE/RPC defragmentation. Set memory cap for desegmentation/defragmentation to 50,000 kilobytes. (Since no DCE/RPC defragmentation will be done the memory cap will only apply to desegmentation.) 

    preprocessor dcerpc: \
        disable_dcerpc_frag \
        memcap 50000

In addition to the defaults, detect on DCE/RPC (or TCP) ports 135 and 2103 (overrides default). Set memory cap for desegmentation/defragmentation to 200,000 kilobytes. Create a reassembly packet every time through the preprocessor if there is data in the desegmentation/defragmentation buffers. 

    preprocessor dcerpc: \
        ports dcerpc { 135 2103 } \
        memcap 200000 \
        reassemble_increment 1

2.2.10.3 Default Configuration

If no options are given to the preprocessor, the default configuration will look like: 

    preprocessor dcerpc: \
        ports smb { 139 445 } \
        ports dcerpc { 135 } \
        max_frag_size 3000 \
        memcap 100000 \
        reassemble_increment 0

2.2.10.4 Preprocessor Events

There is currently only one alert, which is triggered when the preprocessor has reached the memcap limit for memory allocation. The alert is gid 130, sid 1.

2.2.10.5 Note

At the current time, there is not much to do with the dcerpc preprocessor other than turn it on and let it reassemble fragmented DCE/RPC packets.


2.2.11 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.11.1 Configuration

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

The available configuration options are described below.

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

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

83.
enable_obsolete_types

Alert on Obsolete (per RFC 1035) Record Types

84.
enable_experimental_types

Alert on Experimental (per RFC 1035) Record Types

85.
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.11.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.12 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.12.1 Configuration

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

This option specifies which ports SSLPP will inspect traffic on.

By default, SSLPP watches the following ports:

87.
noinspect_encrypted

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

88.
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.12.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.12.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 SSL versions in use simultaneously, multiple ssl_version rule options should be used.

The rule option does not support negation.

Syntax 

   ssl_version: <ssl-version-list>

   ssl-version-list = ssl-version | ssl-version , ssl-version-list
   ssl-version = sslv2 | sslv3 | tls1.0 | tls1.1 | tls1.2

Example 

   ssl_version: sslv3

   ssl_version: tls1.0 | tls1.1 | tls1.2

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'e together.

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

The rule option does not support negation.

Syntax 

   ssl_state: <ssl-state-list>

   ssl-state-list = ssl-state | ssl-state , ssl-state-list
   ssl-state = client_hello | server_hello | client_keyx | server_keyx | unknown

Example 

   ssl_state: client_hello

   ssl_state: client_keyx | server_keyx


2.2.13 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.13.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.13.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.14 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.14.1 Dependency Requirements

For proper functioning of the preprocessor:

2.2.14.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".

Multliple 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.14.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 

    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

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 defragmention module. If a fragment is greater than this size, it is truncated before being added to the defragmentation module. Default is not set.

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.

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

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

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 

    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

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.

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

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

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

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

2.2.14.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. Note that since the preprocessor does not yet support SMB2, id of \xfeSMB is turned away before an eventable point is reached.
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.

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

    <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 

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

byte_test and byte_jump
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 
    <convert> ',' [ '!' ] <operator> ',' <value> [ ',' <offset> [ ',' "relative" ]] \
        ',' "dce"

    convert    = 1 | 2 | 4
    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 
    <convert> ',' <offset> [ ',' "relative" ] [ ',' "multiplier" <mult-value> ] \
        [ ',' "align" ] [ ',' "post_offet" <adjustment-value> ] ',' "dce"

    convert           = 1 | 2 | 4
    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})/sR"; 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})/sR"; 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.15 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.15.1 Dependencies

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

2.2.15.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 - 4294067295

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

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