Paranoid port-scan detection. [Re: spp_flood (the importance of port connection?)]

["Vinay A. Mahadik" <VAMahadik () lbl gov>]

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.

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,
Vinay.

[1] 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 
reconnaissance scans.

Chris Green wrote:

> "Vinay A. Mahadik" <VAMahadik () lbl gov> 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.
>
> Cheers,
> Chris

Attachment: Splice.zip
Description: