[Snort-users] Tuning sfPortscan

Rob.Ward at ...11329... Rob.Ward at ...11329...
Wed Mar 15 12:14:05 EST 2006


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 at ...8860...>:

> -----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 at ...8860...
>
> - --------------------------------------------
>
> "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 at ...13723...>      |
> > | 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 at 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-----
>






More information about the Snort-users mailing list