The stream4 preprocessor

The stream4 preprocessor was built to help Snort get a better view of TCP sessions by providing stateful inspection and session reassembly. According to its original design, Snort is basically stateless. The stream4 preprocessor, when enabled, allows Snort to monitor thousands of concurrent sessions and has the added flexibility of activating state management for user-defined ports. By restricting the preprocessor to only a few ports, you can save a lot of processing power, which would normally be wasted on trying to keep track of potentially millions of sessions in a large-scale network.

Also, you can set stream4 to alert you when sniffed packets aren't part of any session at all. This event really only occurs when a hacker is trying to masquerade as one of the computers involved in a session or is trying to insert himself into the communications stream, often called a man-in-the-middle attack.

Stream4 also allows the construction of rules using the flow keyword that can identify the direction and state of the traffic. These rules are especially helpful in determining how sessions begin and end and whether an attack is inbound or outbound from your network, as well as giving some indication as to the nature of the session. (Chapter 8 shows rules building and testing, including many rules that rely on the stream4 preprocessor for a complete analysis.)

Configuring the stream4 preprocessor

To enable stream4, open your snort.conf file with a text editor and make sure that the following line is uncommented:

preprocessor stream4: detect_scans, keepstats machine

The stream4 preprocessor has several different options, which you include as a comma-separated list, as shown in the preceding example. The following options govern what you can configure the preprocessor to look for (including portscans and state problems):

I detect_scans: The detect_scans option (which is normally set to Off if it's not included on the configuration file) instructs the stream4 preprocessor to alert when a portscan is attempting to avoid detection by using stealth techniques. Because the regular way TCP/IP traffic works involves a three-step handshake, which many types of stealth portscanners intentionally fail, they're snooped out by using this stream4 parameter.

I detect_state_problems: The detect_state_problems option (which defaults to Off if not explicitly set) instructs the stream4 preprocessor to analyze how the state of a flow of TCP packets is kept. This feature is intended to catch faults or failures if the state mechanism of a TCP session is somehow altered by a peer. Given how noisy this parameter can be, we don't recommend it unless you intend on doing some heavy in-depth analysis. Although good at detecting packets that are malformed, many implementations of TCP/IP have small variations that trip this sensor.

I disable_evasion_alerts: The disable_evasion_alerts option is an advanced setting that detects special cases where an attacker tries to fool an IDS detection engine into ignoring a packet, but the packet gets to the target.

We recommend leaving this option off (which is the default). It can generate many false positives and eat lots of processing power.

I ttl_limit: TTL means Time To Live and is a common term used when talking about packet transmissions over a network. A TTL setting can help keep tabs on how much time a packet flow takes to reach its destination. Sometimes an attacker tries to evade detection or masquerade as being somewhere else by twiddling the TTL settings with a session. You can use the ttl_limit option to alert you to a big variation in the TTL setting across a stream of traffic. This parameter is hard to tune properly, but it's a safe bet to use 10 as a starting point as the maximum TTL.

i keepstats: The keepstats parameter accumulates a set of statistical data on the connection tracking and session state analysis, which can be logged with either the machine keyword (which actually is a text file) or the "binary" keyword, which tools such as Barnyard can read.

i noinspect: To curb excessive processing on a busy Snort installation, the noinspect switch can restrict the stateful inspection to only those ports listed with the stream4_reassemble preprocessor.

i timeout: The timeout parameter sets an idle time after which stream4 stops monitoring a particular session. Basically, if Snort doesn't see a packet as part of an active session in its table within the time specified by the timeout switch, then that session is flushed from memory. Because this option defaults to 30 seconds without even specifying it, Snort's normal behavior is to only perform stateful analysis of traffic that has been active within a 30-second window.

i log_flushed_streams: The stream4 preprocessor works by building a session block from the little packets that comprise the entire stream. Using this method, the preprocessor can look for anomalous behavior and perform rule testing. This session block, which is kind of like a gigantic packet, can be flushed to disk for troubleshooting and further analysis. The log_flushed_streams parameter to stream4, if used, instructs the preprocessor to drop the session block in the logs when it triggers an alert.

Our advice is to experiment with the preceding options, see what works well for you, stick with it for a time, and then go back and tune as attack trends change.

Stream4 and session reassembly

Somewhat similar to session tracking (see the preceding section), Snort's stream4 preprocessor also supports full session reassembly. By keeping a window of packets that comprise a session in memory, Snort can alert you to attacks that span multiple packets.

TCP connections can have data fragmented across a group of packets, while UDP transmissions are required to contain all the data in a single packet. Many applications that use TCP for their transfer medium are interactive in nature and often have lots of fragmentation. SSH and telnet session are notorious for splitting data in this way.

By reassembling packets, Snort's analysis and detection engines can catch the sneakiest of attacks. For example, say that you wanted notification when someone transmits a sequence of characters containing /etc/passwd (the location of the users and groups on a Unix operating system) over a telnet session. Telnet sends a separate packet for each keystroke. So, in essence, what you'd have is thousands of little packets, with one character in each, which is horrible for a rule-matching system like Snort. Reassembly globs all of those individual packets into a giant packet to which the rules engine can analyze.

Session reassembly is set up in much the same way as the stream4 preprocessor (which we discussed in the preceding section). By adding the following line to your snort.conf configuration file, you can enable the reassembly features.

preprocessor stream4_reassemble: both ports 21 23 80 110

The following options are available in the stream4_reassemble preprocessor:

I clientonly, serveronly, both: The first parameters given to stream4_reassemble identify which sides of the connection to conduct reassembly on.

• Clientonly refers to traffic inbound to what you've defined as

$HOME_NET in your snort.conf file.

• serveronly refers to traffic outbound.

• Both means reassembly of everything.

I ports: The ports parameter directs Snort's stream4 preprocessor to restrict its reassembly activity to just the ports identified with this switch.

• By using the default keyword, Snort performs reassembly on ports 21 23 25 53 80 110 111 143 and 513.

• The keyword all performs reassembly on all ports, which we don't recommend (except for short periods of testing).

I noalerts: The noalerts parameter tells stream4 not to report on strange or problematic issues encountered during reassembly. For example, traffic manually inserted into a stream or modified packets is detected and logged, and stream4_reassemble generates an alert, unless this option has been indicated.

The preceding example of stream4_reassemble usage should be enough for most people. If you either use other protocols where you want reassembly to occur or run telnet, FTP, HTTP, or POP on nonstandard ports, change the ports listing to the appropriate application ports for your configuration.

Was this article helpful?

0 0

Post a comment