Snort mailing list archives
Re: Paranoid port-scan detection. [Re: spp_flood (the importance of port connection?)]
From: Chris Green <cmg () sourcefire com>
Date: Fri, 09 Aug 2002 08:21:33 -0400
"Vinay A. Mahadik" <VAMahadik () lbl gov> writes:
Hi Chris, (Not exactly related to flood detection, but still..) Attached is a Port*scan* preprocessor patch for Snort 1.8.6 that enables detection of slow (stealth) portscans.
That's really a problem ( and spade too ) designed for a post processing phase. Haven't had a chance to look yet but it seems that this kinda stuff should be done based off recorded conversation statistics.
Basically, this is a sort of 'proof of concept' patch that shows how slow scans can be detected by measuring the rate of anomalous/rare port (dip, dport) connects from any scanning sources. Spade generates anomaly scores for any connection attempt (SYN) based on the rarity of its (dip, dport) pair for our network. Typically, the Portscan preprocessor works independently of Spade by measuring the rate at which SYNs arrive at any/* (dip, dport) ports. So if the threshold rate were 4 SYNs in 3 seconds (default), any scan that makes 4 SYNs in 5 seconds would be missed and successful. What this patch does is to allow Spade to 'mark' *anomalous* packets (rare port connects) for Portscan detection. The latter then monitors such sources for much longer (hardcoded to be 1000 times longer than for fastscan detection) before expiring the connections/state. Further, all detected stealth (XMAS etc) and fast scan sources are removed from the slow scan sources' list to keep state to a minimum. With this extremely small subset of incoming packets (SYNs that are going to ports where they have no business of going, and which are not fast scans or stealth XMAS-like ones), Snort is able to detect slow scans without 'hog'ging :) the system.
How does it handle 1000 spoofed src syns? Does it just keeping adding nodes? How about 10000k ( I think you see where I'm going with this ). Portscan2 was done to help try make that a bit better ( the port representations need a bit of work ).
Long story short, if Spade works for your network given that it is 'stationary' enough (few DHCP crawlers that provide *services* and other such screwups etc), this will find all slow scanners. The hardcoded slow scan watch period makes a slow scan of 100 ports require 5 days. I had decent performance and stability, although I had all rules and unrelated preprocessors turned off. It was a class B with roughly 600 hosts and quite a few servers. Please, pretty please let me know of problems/experiences/annoyances/etc with this approach/concept/implementation. A Readme is included too!
It's neat research but I don't think doing this type of stuff in the interrupt driven snort process is the right place. Let me mull over this for a bit more. -- Chris Green <cmg () sourcefire com> This is my signature. There are many like it but this one is mine. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ 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:
- Re: snort-flood detection preprocessor Grudge Mason (Aug 05)
- Re: Re: [Snort-users] snort-flood detection preprocessor Chris Green (Aug 06)
- spp_flood (the importance of port connection?) Cearns Angela (Aug 08)
- Message not available
- Message not available
- Paranoid port-scan detection. [Re: spp_flood (the importance of port connection?)] Vinay A. Mahadik (Aug 08)
- Re: Paranoid port-scan detection. [Re: spp_flood (the importance of port connection?)] Chris Green (Aug 09)
- Re: [Snort-devel] Re: Paranoid port-scan detection. Vinay A. Mahadik (Aug 09)
- spp_flood (the importance of port connection?) Cearns Angela (Aug 08)
- Re: Re: [Snort-users] snort-flood detection preprocessor Chris Green (Aug 06)