[Snort-users] Tuning sfPortscan

Gentoo-Wally gentoowally at ...11827...
Thu Mar 16 12:02:02 EST 2006


Since we're talking about sfportscan...

is the proper syntax of the proto option for specifying protocols other than
"all"...

proto { tcp,icmp } ...
proto { tcp icmp } ...

or should you have to preprocessors...

 proto { tcp } ...
 proto { icmp } ...

Thx,
Wally



On 3/15/06, Rob.Ward at ...11329... <Rob.Ward at ...11329...> wrote:
>
> 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-----
> >
>
>
>
>
> -------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20060316/de05c0b9/attachment.html>


More information about the Snort-users mailing list