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


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

More information about the Snort-devel mailing list