[Snort-devel] Re: Paranoid port-scan detection.

Vinay A. Mahadik VAMahadik at ...1463...
Fri Aug 9 13:40:07 EDT 2002


Chris Green wrote:
> 
> 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.
> 

Quite right. Spade, Portscan(2), and their derivatives would work best
over a save file with a minimum of (time, sip, dip, dport, flags) info.
Such logs could be rotated over a few days/weeks depending on network
throughput and storage available.
Another idea is to run a parallel instance of Snort with only these
turned on.

> 
> 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 ).
> 

Spoofed scans or distributed scans would make Splice (let me call it
that) bloat and hang/crash. I don't want to shove my idea down snorters'
throats, but let me put up a little bit of a defense (let me know if
they suck/rock! :) ) -

1. For keeping state for detection in general, instead of hardcoding a
fixed time for that, we could use an exponentially decreasing
distribution of some sort ranging from 10 seconds to 4 hours lets say
(that is a scanner source that is inactive of this long is expired and
lost). So typically we would use an expiry time of near 10s, but with a
low but non-zero chance, one of near 4 hours! The point is to make it
near impossible to be certain that your scan was stealth. We are
generating FUD (of detection) in the minds of malicious organized
stealth/slow scanners.

2. We keep a memcap on the amount of memory used by Splice, such that if
that memcap is reached, we would have just *too many* anomalously
connecting sources in the past 4 hours (say) to be anything but a scan.
That is a detect in itself, isn't it Chris? Spade provides methods that
allow you to adaptively increase the threshold of anomaly detection if
your network's 'entropy' has increased naturally. Thus you have a good
control over the size of rare-port scanning-sources list. I have watched
Spade generate alerts for days, and for non-spoofed scans, I for one
never saw it fill up a 4 hour window with false positives.

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

Thanks Chris; I know what you mean. However, a good choice of axioms can
make this anomaly detection pretty effective imho. Please let me know
about all these (the idea, the limitations, the defense).

Thanks,
Vinay.

--
Vinay A. Mahadik
Summer Intern
Computer Protection Program
Lawrence Berkeley National Laboratory
(510) 495 2618




More information about the Snort-devel mailing list