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

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

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


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