Detecting Port Scans and Talkative Hosts

How do I detect when hosts on my network(s) are performing port scans and host scans?

Solution

There are actually a couple of answers to that question. This is because Snort developers have gone through several iterations of port scan detectors. The most common is the portscan preprocessor, while the newest is the flow-portscan preprocessor. Finally, portscan2 was supposed to address some of the problems with the portscan preprocessor, such as detection of SYN floods as port scans instead of DoS attacks. All these preprocessors are still compiled into Snort by default, even as late as Version 2.2.0. However, the trend is toward the flow-portscan preprocessor, as this is the first preprocessor to use the flow engine for its data. This section gives some example configurations for all three. The most effort is on the flow-portscan preprocessor, as the other two are no longer part of the default snort.conf file.

Portscan

This is the oldest and most commonly used of the three preprocessors. However, if you are using ACID (Chapter 5), you might want to pull some port scan information into ACID with little changes. To enable this in your snort.conf file, simply enter this example into the file right below the flow preprocessor.

When enabled, this preprocessor detects when a source host other than the one in the HOME_NET variable starts more that four port connections within three seconds. When that happens, two events are written: one in the Snort alert file, and the other in the portscan.log file. The alert file notifies the analysts of a possible port scan against one of their resources.

One concern of this preprocessor was how to blanket ignore hosts such as your DNS servers that often appeared as portscan attackers. The solution came in the form of another component of the portscan preprocessor: portscan-ignorehosts. This component simply tells the portscan preprocessor to not alert on any traffic from the host(s) and/or network(s) in a given list. An example of that is as follows; more than one entry into this list is space separated.

This example filters out any port scans coming from either the DNS or web server.

Portscan2

As we mentioned, the portscan preprocessor had some limitations that another group of Snort developers tried to remedy with a rewrite and some added functionality. The portscan2 preprocessor relies on the old conversation tracking preprocessor and can't be enabled when the flow preprocessor is active. Following is an example of a typical conversation and portscan2 configuration.

# First Disable the flow preprocessor
# preprocessor flow: stats_interval 0 hash 2
#
# Enable the conversation preprocessor
preprocessor conversation: allowed_ip_protocols all, timeout 60,
max_conversations 50000
# the arguments are:
# allowed IP protocols, either a list of protocol numbers or word "all"
# timeout (seconds) before connections or conversations are rolled
# out of the preprocessor
#the max number of conversations that the preprocessor should see
# Enable the portscan2 preprocessor
preprocessor portscan2: scanners_max 256, targets_max 256,
target_limit 3, port_limit 10, timeout 60
# arguments are:
# the max number of scanning hosts to support at once
# the max number of target hosts to support at once
# the number of hosts a scanner must touch before a scan is triggered
# number of ports a scanner must touch before a scan is triggered
# the timeout period (seconds) before a scanners activity is rolled
# out of the preprocessor

From this logfile you can immediately determine several facts about this scan:

This is a TCP Syn scan, the ******S* is the snort flagging for Syn only packets.

The source port is going up and changing every connection, possibly from a tool such as nmap.

How many ports per hit our victim was taking from the "ports" tag.

Flow-portscan

This is the newest preprocessor to detect port scans. This preprocessor is the first to take advantage of the flow preprocessor data. While that is the case, this preprocessor remains one of the hardest preprocessors for people to configure and use.

# for a single IP cable/DSL connection detection config
# The would be useful for a network that doesn't server many or any services to
# the outside world.
#

Note that talkers are hosts that are active on your network such as your workstations for browsing the Web, file sharing, etc. Scanners are hosts that have started communicating with one of your hosts within the learning time of the host over a previously unused port.

preprocessor flow-portscan:
# the IP space to use for our allowed/learned network(s)
server-watchnet [10.0.4.0/24]
# The number of seconds to keep port information on your watchnet for example this
# will keep the ports in use on each host for a 1-minute interval before refreshing
server-learning-time 60
# the number of requests a port on a host in the watchnet must see before
# it's treated as a talker rather than a scanner
server-scanner-limit 50
# If you have hosts or networks that you want to ignore and not
# count into the learning time place here
# src-ignore-net [10.0.4.1/32]
# If you have destination networks or hosts that you want to ignore
# such as your DNS server or POP mail server place here
# dst-ignore-net [10.0.4.1/32]
# This sets how the alarms will be sent out. The default setting is
# display the alerts "once" per scan. However, in this case we are going
# to alarm every time the points go above the threshold.
alert-mode all
# The tells the preprocessor to send the alarm out in a text message
# mode as seen below. However, if you want there is "pktkludge" option
# that you can use as well to send to the snort logging system.
output-mode msg
# This turns on detection much like the stream4 preprocessor for invalid
# or odd tcp flows. Such as a SYN/FIN flagged flow.
tcp-penalties on

These settings log something like the following in the alert file. This correctly identifies the nmap hostin this case, 10.0.4.100. However, you don't see what ports it's been probing or the targets.

For monitoring a larger network, you might try the following configuration example:

preprocessor flow-portscan:
# Network to monitor
server-watchnet [192.168.1.0/24,192.168.2.0/24]
# Ignore traffic coming from the routers
#src-ignore-net [192.168.1.1/32,192.168.2.1/32]
# Ignore traffic going for the DNS servers
#dst-ignore-net [192.168.1.2/32,192.168.2.2/32]
# the number of requests to a single port such as 80/tcp that a hosts
# in the watchnet must recieve before the port is ignored for portscans
#server-ignore-limit 200
# Time (seconds) to keep there watchnet servers ports before resetting
server-learning-time 3600
# the number of requests a port on a host in the watchnet must see before
# it's treated as a talker rather than a scanner
server-scanner-limit 50
# sets the alert mode to alarm on every event over the threshold
alert-mode all
# Sends a text message to the alert file
output-mode msg
# alarm on odd flow tcp flag settings
tcp-penalties on
# Used for debugging to dump the contents of all of the flow-portscan
# 3 "tables" of data to the screen on snort exit. Set to 0 to disable.
Dumpall 1

Discussion

As you might have seen, the portscan preprocessor is still useful when detecting port scans from the flow preprocessor. This, combined with the fact that it's one of the simplest preprocessors to set up, makes it a viable preprocessor, especially if you are using a Snort frontend such as ACID (Chapter 5).

However, the portscan2 preprocessor takes quite a bit of memory and requires disabling and reenabling preprocessors. The worst of these is disabling the flow preprocessor. This causes problems even with the Snort rules engine, as quite a few of the new rules use the flow keyword in their detection patterns. The other concern about this preprocessor is the requirement of the conversation preprocessor, which flow was built to replace. The conversation preprocessor didn't handle state very well. However, one useful keyword that the conversation preprocessor had was alert_odd_protocols. The following conversation preprocessor configuration detects when protocols other than TCP, UDP, or ICMP are in use on your network.

Finally, with the new flow-portscan preprocessor, we used a small network and larger network configuration example that should at least get you started on detecting port scans on your network(s). However, the flow-portscan can be tweaked for your network. If you want data from the preprocessor's output, you can apply a patch to Snort to get more data back.