Snort mailing list archives
Re: Tuning sfPortscan
From: Eric Hines <eric.hines () appliedwatch com>
Date: Wed, 15 Mar 2006 12:36:15 -0600
-----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
Current thread:
- Tuning sfPortscan Rob Ward (Mar 13)
- Re: Tuning sfPortscan Alex Gottschalk (Mar 15)
- Re: Tuning sfPortscan Eric Hines (Mar 15)
- Re: Tuning sfPortscan Alex Gottschalk (Mar 15)
- Re: Tuning sfPortscan Rob . Ward (Mar 15)
- Re: Tuning sfPortscan Gentoo-Wally (Mar 16)
- Re: Tuning sfPortscan Eric Hines (Mar 15)
- Re: Tuning sfPortscan Alex Gottschalk (Mar 15)