Detecting Stateless Attacks and Stream Reassembly

Problem

I have read about the Snort DoS, stateless-attack tools snot, and stick. How can I protect my sensor from this type of attack?

Solution

There are several options available to help defeat stateless-attack tools. Among these are two parts to the stream4 preprocessor: stream4 and stream4_reassemble.

The first is a simple command-line option for Snort: -z. This option forces Snort to alert only on streams that have established a full three-way handshake or that have shown some data in transit. This effectively blocks all the stick/snot/sneeze stateless attacks.

Snort -my -other -options -z

Stream4

Another option is to use the snort.conf file to tweak the stream4 preprocessor to be more effective on your network. Following are some examples of the types of attacks and traffic that the stream4 preprocessor can detect.

If you want stream4 to detect scans that are not full connection scans such as SYN, FIN/SYN, and other TCP-based scans, use the code in Example 4-1.

Example 4-1. Use stream4 to detect stealth scanning activity

"preprocessor stream4: detect_scans"

If you're trying to detect problems with a connection, such as bad or out-of-order sequence numbers, use Example 4-2 .

Example 4-2. Use stream4 to detect IP state problems, such as IP overlapping

"preprocessor stream4: detect_state_problems"

The stream4 preprocessor is useful in detecting possible evasion attempts through the code in Example 4-3. Note that if you're monitoring an asynchronous link or some high-speed networks, such as those used by some of the larger Internet Service Providers (ISP), detection is quite noisy. This is because asynchronous links see only part of a TCP connectioni.e., only the client side or the server side. If you are trying to use the evasion alarms, they will fire for just about every connection, as the link sees only, for example, a TCP ACK without the TCP SYN/ACK of a session.

Example 4-3. Don't alarm on high noise levels from possible evasion attacks

"preprocessor stream4:disable_evasion_alerts"

Another use of the stream4 preprocessor is to determine the amount of data transferred in a connection. This can be extremely helpful in cases of some of the more advanced exploits to determine either data loss or hostile code uploads. For more information, see later in the chapter. Example 4-4 shows how much traffic was sent and received. This is stored in session.log in your Snort log directory. To enable the session logging, use Example 4-5. The information is kept in the flat session.log text files to ease scripted searches through the file(s) with the help of the code in Example 4-6, which tells Snort to log the information one line at a time instead of multiple lines. However, if you are using Barnyard or some other log-unification system, and no logging or alerting from the stream4 preprocessor is wanted, simply enable Example 4-6 to prevent the preprocessor from outputting any data. Finally, like all the preprocessors, you can combine the options to be more effective on your network(s), such as in Example 4-7.

Example 4-4. Provide session information about your connections

"preprocessor stream4:keepstat"

Example 4-5. Format the stats information into single line entries

"preprocessor stream4:keepstat machine"

Example 4-6 makes searching through with tools like grep or custom scripts easier. Binary logging is used for binary installs. Baynard takes the steam4 logs in binary mode to increase speed.

Example 4-6. Format the stats information into binary entries

"preprocessor stream4: keepstats binary"

The following code affects only alarms from the preprocessor and not the signature engine. It should be invoked only while testing a preprocessor or some other part of the Snort engine(s).

"preprocessor stream4:noinspect"

Example 4-7 combines Example 4-4 through Example 4-6, which, depending on sensor placement and load, will be more effective for your network(s).

Example 4-7. Combine the options to be more effective for your network

"preprocessor stream4:disable_evasion_alerts,detect_scans,keepstats machine"

Stream4_reassemble

This part of the preprocessor determines how much of a session to reassemble for analysis. Depending on your unique requirements, you may want to enable/disable some of these options. Things such as network location, speed, and load of the sensor all should be considered when enabling these options. In Example 4-8, all alerts from the reassemble preprocessor have been disabled. This configuration might be found enabled on either highly loaded perimeter sensors or in testing environments where filtering of event data is used to test other portions of the Snort engine.

Example 4-8. Turn off all alerts from this preprocessor component

"preprocessor stream4_reassemble:noalert"

If you want to tax your sensor(s), try enabling full session reassembly on both the client and server sides of connections over the common ports, as in Example 4-9. The common or "default" ports used for the reassembly preprocessor are: 21/tcp, 23/tcp, 25/tcp, 53/tcp, 80/tcp, 143/tcp, 110/tcp, 111/tcp, 513/tcp, and 1433/tcp. However, for most events, the default configuration will reassemble client-side only over the "default" ports.

Example 4-9. Reassemble client and server sided events on common ports

"preprocessor stream4_reassemble:both,ports default"

If you're running common applications on nonstandard ports, the ports option might be helpful for assembling attacks against your applications. For example, you might want to change the ports option to reflect your NAT (network address translation) or PAT (port address translation) port ranges for those common applications. The ports option is a comma-separated list for your applications. The reassembly preprocessor can handle applications over these nonstandard ports with a simple snort.conf option, as in Example 4-10. Reassemble client side-only sessions for specific ports. The ports option will reassemble the port you provide within a bracket list. The preprocessor doesn't care what the application(s) running on the port(s) are being used for. However, it will still create the pseudopackets for the stream to hand back to the Snort rules engine for analysis.

Example 4-10. Reassemble client side-only sessions for specific ports

"preprocessor stream4_reassemble:clientonly,ports [2121,27,25,53,8080,1443]"

All the options in Example 4-10. can be combined for more effectiveness on your networks; for example, on a RAS or VPN sensor, you might want to monitor all ports and both sides of connections, as in the Example 4-11.

Example 4-11. Combining the options in Example 4-10. Reassemble client side-only sessions for specific ports to be more effective for your network(s)

"preprocessor stream4_reassemble: both, ports all"

However, note that as you're now attempting to put together sessions from encrypted traffic, you won't be able to determine any session information. The only reason to capture ports such as 443/tcp (HTTPS) or 22/tcp (ssh) is to use the session information to take an educated guess on the amount of data transferred. For example, if you have an SSH session that has 2 GB of packet data, there is a good chance that you might have a problem with exfiltration of data.

Discussion

For the first part of the stream4 preprocessor, stream4, we might want to adjust a couple of options for our network. All options are comma-delimited values and can be combined to be more effective.

In Example 4-1, we used the detect_scans keyword. This option allows Snort to alert on several types of stealth scans, such as those used by Nmap, to try to hide from other detection tools. This option is disabled by default in the snort.conf file.

In Example 4-2, we used the detect_state_problems keyword. This option allows us to trigger lots of alarms for events such as data sent in a SYN flagged TCP packet with window and ACK numbers out of sequence. Be very careful using this option, as on a core network, it can cause a flood of alarms due to poorly written IP stack implementations. This option is disabled by default in the snort.conf file.

In Example 4-3, we used the disable_evasion_alerts keyword. This option disables alerts on "possible" IDS evasion packets, such as IP overlapping or TCP RST flooding. This option is enabled by default to help cut down on the noise from a new Snort implementation.

In Example 4-4, we used a very useful keyword, keepstats. This keyword has two subkeywords that may be useful to an IDS team. This option takes the data passing through the stream4 preprocessor and creates a log of that information in the file session.log. This file is automatically created and placed in your Snort log directory. This log contains information to help determine if a file was transferred during an exploit by showing the size of the connection. For example, the following is a copy out of a session.log file and the data available to search on:

[*] Session => Start: 08/24/04-10:35:57 End Time: 08/24/04-10:36:22 [Server IP: 10.0.4.45 port: 21 pkts: 14 bytes: 3339] [Client IP: 10.0.4.2 port: 2147 pkts: 13 bytes: 112]

For example, in this session log, we can determine the amount of data transferred and by whom as well as the time and duration.

This connection was pretty much just banners; check maybe an attempted and failed login. Not enough to actually push out too much. As well, this connection had the server sending out only 14 packets and the client in the connection sent only 13. So this is pretty much only enough for the banner and possibly the login prompt of an FTP connection. In Example 4-5 and Example 4-6, we used the subkeywords machine and binary. The machine keyword causes the stream4 preprocessor to output each session onto a single line instead of multiple lines. This will make sorting and gathering data out of the session.log file much easier.

The binary keyword causes the stream4 preprocessor to output in the machine-readable unified format. This can then be read by something like Barnyard for detailed postprocessing of the data.

In Example 4-6, we used the keyword noinspect. This option would be used if, for example, you weren't getting any useful information back from the stream4 preprocessor or wanted to temporarily disable it.

In Example 4-7, we demonstrated combining several options to be more effective on our network. In our example, we turned off the noise evasion alarms while enabling detection of stealth scans. Finally, we also turned on session logging, writing to a new file session.log, formatted with each new entry as a single line. Using this example, we have new alarms to show to the analysts as well as a record of the size and duration of each connection.

Lastly, the min_ttl, ttl_limit, and log_flushed_streams keywords should almost never be adjusted. If you would like to learn about them, check out the Snort documentation that comes with the source code snort_manual.pdf in the doc subdirectory.

stream4_reassemble

This component takes packets and reassembles them into server-side, client-side, or both-sided connections. Snort's default configuration reassembles client-sided connections on only a short list of ports common applications.

Example 4-8 enabled the noalert keyword to prevent triggers of an event on either client-side or server-side evasion and insertion attacks. This option should be disabled only during testing, or if you are using a nonregenerative tap for your IDS sensor.

Example 4-9 enabled the stream4_reassemble preprocessor to reassemble and find alarms for both client- and server-sided connections over the default ports. Those ports are 21, 23, 25, 53, 80, 110, 111, 143, 513, and 1433, which apply for both TCP and UDP ports.

Example 4-10 reassembled client side-only sessions for specific ports demonstrated a way to specify new ports to use. This could be helpful when running common applications on nonstandard ports, such as using a proxy for all network traffic. The ports option is a comma-separated list for your applications.

Finally, Example 4-11 combined the options to increase effectiveness, albeit a slight hit on your Snort sensor's performance. This might be an effective solution a slower or less-used connection, such as on a RAS or VPN sensor where you might want to monitor all ports and both sides of connections for clarity.

See Also

Recipe 5.9

Argus web site (http://www.qosient.com/argus)

Recipe 7.2