<div> </div>
<div>Since we're talking about sfportscan...</div>
<div> </div>
<div>is the proper syntax of the proto option for specifying protocols other than "all"...</div>
<div> </div>
<div>proto { tcp,icmp } ...</div>
<div>proto { tcp icmp } ...</div>
<div> </div>
<div>or should you have to preprocessors...</div>
<div> </div>
<div>
<div>proto { tcp } ...</div></div>
<div>
<div>proto { icmp } ...</div>
<div> </div>
<div>Thx,</div>
<div>Wally</div><br><br> </div>
<div><span class="gmail_quote">On 3/15/06, <b class="gmail_sendername"><a href="mailto:Rob.Ward@...11329...">Rob.Ward@...11329...</a></b> <<a href="mailto:Rob.Ward@...11329...">Rob.Ward@...11329...</a>
> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I appreciate that Eric, hence the question about how to tune sfPortscan to best<br>effect however. Over a million portscan alerts a day isn't particularly useful
<br>and rendered my implementation useless by the time I came into work on Monday.<br><br>I already had the sensitivity level set to low and watch_ip configured. What I<br>wanted to know is if the configuration of watch_ip and ignore_scanners overlaps
<br>will I still get alerts on scans to watch_ip?<br><br>Would supression be another option, if so how do I go about this?<br><br>Quoting Eric Hines <<a href="mailto:eric.hines@...8860...">eric.hines@...8860...
</a>>:<br><br>> -----BEGIN PGP SIGNED MESSAGE-----<br>> Hash: SHA1<br>><br>> You guys really should be using the preprocessor's tuning options built<br>> in to sfportscan rather than disabling things. Check out the
<br>> ignore_scanners and ignore_scanned directives, play with the sensitivity<br>> level, etc..<br>><br>> Turning things off entirely because of false positives is a really bad<br>> practice..<br>><br>>
<br>> (Excerpt below from Snort manual)<br>><br>> - ------- snip ------------<br>><br>> <a href="http://2.1.7.4">2.1.7.4</a> Tuning sfPortscan<br>><br>> The most important aspect in detecting portscans is tuning the detection
<br>> engine for your network(s). Here are some tuning tips:<br>><br>> 16.<br>>     Use the watch_ip, ignore_scanners, and ignore_scanned options.<br>><br>>     It's important to correctly set these options. The watch_ip option
<br>> is easy to understand. The analyst should set this option to the list of<br>> Cidr blocks and IPs that they want to watch. If no watch_ip is defined,<br>> sfPortscan will watch all network traffic.<br>><br>
>     The ignore_scanners and ignore_scanned options come into play in<br>> weeding out legitimate hosts that are very active on your network. Some<br>> of the most common examples are NAT IPs, DNS cache servers, syslog
<br>> servers, and nfs servers. sfPortscan may not generate false positives<br>> for these types of hosts, but be aware when first tuning sfPortscan for<br>> these IPs. Depending on the type of alert that the host generates, the
<br>> analyst will know which to ignore it as. If the host is generating<br>> portsweep events, then add it to the ignore_scanners option. If the host<br>> is generating portscan alerts (and is the host that is being scanned),
<br>> add it to the ignore_scanned option.<br>><br>> 17.<br>>     Filtered scan alerts are much more prone to false positives.<br>><br>>     When determining false positives, the alert type is very important.
<br>> Most of the false positives that sfPortscan may generate are of the<br>> filtered scan alert type. So be much more suspicious of filtered<br>> portscans. Many times this just indicates that a host was very active
<br>> during the time period in question. If the host continually generates<br>> these types of alerts, add it to the ignore_scanners list or use a lower<br>> sensitivity level.<br>><br>> 18.<br>>     Make use of the Priority Count, Connection Count, IP Count, Port
<br>> Count, IP range, and Port range to determine false positives.<br>><br>>     The portscan alert details are vital in determining the scope of a<br>> portscan and also the confidence of the portscan. In the future, we hope
<br>> to automate much of this analysis in assigning a scope level and<br>> confidence level, but for now the user must manually do this. The<br>> easiest way to determine false positives is through simple ratio<br>
> estimations. The following is a list of ratios to estimate and the<br>> associated values that indicate a legimite scan and not a false positive.<br>><br>>     Connection Count / IP Count: This ratio indicates an estimated
<br>> average of connections per IP. For portscans, this ratio should be high,<br>> the higher the better. For portsweeps, this ratio should be low.<br>><br>>     Port Count / IP Count: This ratio indicates an estimated average of
<br>> ports connected to per IP. For portscans, this ratio should be high and<br>> indicates that the scanned host's ports were connected to by fewer IPs.<br>> For portsweeps, this ratio should be low, indicating that the scanning
<br>> host connected to few ports but on many hosts.<br>><br>>     Connection Count / Port Count: This ratio indicates an estimated<br>> average of connections per port. For portscans, this ratio should be<br>
> low. This indicates that each connection was to a different port. For<br>> portsweeps, this ratio should be high. This indicates that there were<br>> many connections to the same port.<br>><br>>     The reason that Priority Count is not included, is because the
<br>> priority count is included in the connection count and the above<br>> comparisons take that into consideration. The Priority Count play an<br>> important role in tuning because the higher the priority count the more
<br>> likely it is a real portscan or portsweep (unless the host is firewalled).<br>><br>> 19.<br>>     If all else fails, lower the sensitivity level.<br>><br>>     If none of these other tuning techniques work or the analyst doesn't
<br>> have the time for tuning, lower the sensitivity level. You get the best<br>> protection the higher the sensitivity level, but it's also important<br>> that the portscan detection engine generates alerts that the analyst
<br>> will find informative. The low sensitivity level only generates alerts<br>> based on error responses. These responses indicate a portscan and the<br>> alerts generated by the low sensitivity level are highly accurate and
<br>> require the least tuning. The low sensitivity level does not catch<br>> filtered scans, since these are more prone to false positives.<br>><br>><br>><br>><br>><br>><br>><br>><br>> Best Regards,
<br>><br>> Eric Hines, GCIA, CISSP<br>> CEO, President<br>> Applied Watch Technologies, LLC<br>><br>><br>> - ---------------------------------------------<br>><br>> Eric Hines, GCIA, CISSP<br>> CEO, President
<br>> Applied Watch Technologies, LLC<br>> 1095 Pingree Road<br>> Suite 213<br>> Crystal Lake, IL 60014<br>> Toll Free: (877) 262-7593 ext:327<br>> Direct: (847) 854-2725 ext:327<br>> Fax: (847) 854-5106
<br>> Web: <a href="http://www.appliedwatch.com">http://www.appliedwatch.com</a><br>> Email: <a href="mailto:eric.hines@...8860...">eric.hines@...8860...</a><br>><br>> - --------------------------------------------
<br>><br>> "Enterprise Open Source Security Management"<br>><br>><br>> Alex Gottschalk wrote:<br>> > Rob Ward wrote:<br>> ><br>> >><br>> >> What I'd like to do, rather than disable the preprocessor, is see only
<br>> >> alerts for scans to hosts on our network.<br>> ><br>> ><br>> > I'm having almost exactly the same issue, and would be very interested<br>> > to know if anyone has worked out a good solution to this.  For the time
<br>> > being, I've disabled the portsweep scan, since that seem to create the<br>> > greatest number of useless alerts,<br>> ><br>> > Solutions would be what Rob said above, or to be able to filter by port
<br>> > (as in, ignore "portsweeps" to EXTERNAL_NET on ports 80 and 443).<br>> ><br>> > Alex<br>> ><br>> > #include <std-disclaimer.h><br>> ><br>> > /-------------------------------------------------\
<br>> > | Alex Gottschalk <<a href="mailto:agottschalk@...13728.....">agottschalk@...13723...</a>>      |<br>> > | IT Manager/Sysadmin, LetsTalk, Inc.             |<br>> > \-------------------------------------------------/
<br>> ><br>> ><br>> > -------------------------------------------------------<br>> > This SF.Net email is sponsored by xPML, a groundbreaking scripting language<br>> > that extends applications into web and mobile media. Attend the live
<br>> > webcast<br>> > and join the prime developer group breaking into this new coding territory!<br>> > <a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
</a><br>> > _______________________________________________<br>> > Snort-users mailing list<br>> > <a href="mailto:Snort-users@...3204...ts.sourceforge.net">Snort-users@lists.sourceforge.net</a><br>> > Go to this URL to change user options or unsubscribe:
<br>> > <a href="https://lists.sourceforge.net/lists/listinfo/snort-users">https://lists.sourceforge.net/lists/listinfo/snort-users</a><br>> > Snort-users list archive:<br>> > <a href="http://www.geocrawler.com/redir-sf.php3?list=snort-users">
http://www.geocrawler.com/redir-sf.php3?list=snort-users</a><br>> -----BEGIN PGP SIGNATURE-----<br>> Version: GnuPG v1.4.2 (GNU/Linux)<br>> Comment: Using GnuPG with Thunderbird - <a href="http://enigmail.mozdev.org">
http://enigmail.mozdev.org</a><br>><br>> iD8DBQFEGF6ebOqF2QHgUK0RAlhyAJ9Wk5zfVnjjndD31f6xq4S9wtdjzACeNbB7<br>> 6VFQDKeYrBDmcGZFSVXnS/w=<br>> =E+wI<br>> -----END PGP SIGNATURE-----<br>><br><br><br><br><br>
-------------------------------------------------------<br>This SF.Net email is sponsored by xPML, a groundbreaking scripting language<br>that extends applications into web and mobile media. Attend the live webcast<br>and join the prime developer group breaking into this new coding territory!
<br><a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642</a><br>_______________________________________________
<br>Snort-users mailing list<br><a href="mailto:Snort-users@...4137...orge.net">Snort-users@lists.sourceforge.net</a><br>Go to this URL to change user options or unsubscribe:<br><a href="https://lists.sourceforge.net/lists/listinfo/snort-users">
https://lists.sourceforge.net/lists/listinfo/snort-users</a><br>Snort-users list archive:<br><a href="http://www.geocrawler.com/redir-sf.php3?list=snort-users">http://www.geocrawler.com/redir-sf.php3?list=snort-users</a><br>
</blockquote></div><br>