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

Chris Green cmg at ...402...
Fri Aug 9 05:28:03 EDT 2002

"Vinay A. Mahadik" <VAMahadik at ...1463...> 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

> 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 at ...402...>
This is my signature. There are many like it but this one is mine.

More information about the Snort-devel mailing list