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

[Chris Green <cmg () sourcefire com>]

"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