I appreciate that Eric, hence the question about how to tune sfPortscan to
best
effect however. Over a million portscan alerts a day isn't particularly
useful
and rendered my implementation useless by the time I came into work on
Monday.
I already had the sensitivity level set to low and watch_ip configured.
What I
wanted to know is if the configuration of watch_ip and ignore_scanners
overlaps
will I still get alerts on scans to watch_ip?
Would supression be another option, if so how do I go about this?
Quoting Eric Hines <eric.hines@appliedwatch.com>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You guys really should be using the preprocessor's tuning options built
in to sfportscan rather than disabling things. Check out the
ignore_scanners and ignore_scanned directives, play with the sensitivity
level, etc..
Turning things off entirely because of false positives is a really bad
practice..
(Excerpt below from Snort manual)
- ------- snip ------------
2.1.7.4 Tuning sfPortscan
The most important aspect in detecting portscans is tuning the detection
engine for your network(s). Here are some tuning tips:
16.
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.
17.
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.
18.
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).
19.
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 generates 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.
Best Regards,
Eric Hines, GCIA, CISSP
CEO, President
Applied Watch Technologies, LLC
- ---------------------------------------------
Eric Hines, GCIA, CISSP
CEO, President
Applied Watch Technologies, LLC
1095 Pingree Road
Suite 213
Crystal Lake, IL 60014
Toll Free: (877) 262-7593 ext:327
Direct: (847) 854-2725 ext:327
Fax: (847) 854-5106
Web: http://www.appliedwatch.com
Email: eric.hines@appliedwatch.com
- --------------------------------------------
"Enterprise Open Source Security Management"
Alex Gottschalk wrote:
Rob Ward wrote:
What I'd like to do, rather than disable the preprocessor, is see
only
alerts for scans to hosts on our network.
I'm having almost exactly the same issue, and would be very interested
to know if anyone has worked out a good solution to this. For the
time
being, I've disabled the portsweep scan, since that seem to create the
greatest number of useless alerts,
Solutions would be what Rob said above, or to be able to filter by
port
(as in, ignore "portsweeps" to EXTERNAL_NET on ports 80 and 443).
Alex
#include <std-disclaimer.h>
/-------------------------------------------------\
| Alex Gottschalk <agottschalk@letstalk.com> |
| IT Manager/Sysadmin, LetsTalk, Inc. |
\-------------------------------------------------/
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEGF6ebOqF2QHgUK0RAlhyAJ9Wk5zfVnjjndD31f6xq4S9wtdjzACeNbB7
6VFQDKeYrBDmcGZFSVXnS/w=
=E+wI
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Snort-users mailing list
Snort-users@lists.sourceforge.net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users
