[Snort-users] Paranoid port-scan detection. [Re: spp_flood (the importance of port connection?)]
Vinay A. Mahadik
VAMahadik at ...6245...
Thu Aug 8 22:14:05 EDT 2002
(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.
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.
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!
Thanks a lot,
 We saw exactly two types of false positives - 1. FTP connects to
outside Active servers, or local Passive servers and 2. Reverse Ident
Auths from an external SMTP server to clients misconfigured to use it
for relaying. Horizontal scans were always malicious stealth slow
Chris Green wrote:
> "Vinay A. Mahadik" <VAMahadik at ...6245...> writes:
>>I think per (dip, dport) should be more effective. Are you only relying
>>on X/Y heuristics? That may not exist a decent X/Y rate threshold for
>>most networks without some sort of traffic conditioning. If you achieve
>>some stable incoming traffic distribution for a given (dport, dip)
>>combination, and place the threshold at a few standard deviations above
>>the average(?), a flood can still be achieved at rates slightly below
>>the known threshold rate for detection. Besides, a steady traffic rate
>>distribution typically doesn't exists (changes every hour, between days
>>etc). So, if you are looking for real time detection (else effects of
>>DoS will be felt and reported before your IDS), then you need to be
>>thinking 'anomaly detection' which is much more involved (and I don't
>>believe exists, without conditioning).
> If you are going to work on this, check out the stats portion of
> spp_conversation. Trying to figure out wether to make it a rule
> plugin to check ( which would be more natural ) or a preprocessor to
> check ( which would be more speedy ) is a hard call to make.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 79972 bytes
Desc: not available
More information about the Snort-users