|
|
|
|
Next: RPC Decode
Up: sfPortscan
Previous: Log File Output
Contents
Tuning sfPortscan
The most important aspect in detecting portscans is tuning the detection engine
for your network(s). Here are some tuning tips:
- 18.
- 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.
- 19.
- 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.
- 20.
- 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 legimite 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).
- 21.
- 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.
Next: RPC Decode
Up: sfPortscan
Previous: Log File Output
Contents
Steven Sturges
2008-04-01
|
|
|