Snort mailing list archives
Re: RE: Network Behaviour Anomoly Detection
From: pieter claassen <pieter () countersnipe com>
Date: Sat, 26 Jun 2004 14:02:43 +0100
As a first cut I can think of the following anomalous events that might be interesting: 1. Changes in spread of connections from source/to destination to services over a specific time period. (i.e. there are new requests which makes your environment look differently from what it was) 2. Changes in volume from source/to destination going to services over a specific time period. (i.e. resource abuse or successful compromise) How would the logic be implemented? Can this be done through the existing rule syntax? sample rules: alert tcp any any -> $WEBSERVERS any (msg:"Somebody is probing our servers" ; anomaly:"ports > 20/min" ) - A match would indicate a quantitative increase in connections to more than 20/min to a webserver alert tcp any any -> $WEBSERVERS any (msg:"Sudden increase in consumption"; anomaly:"volume > 20%/min" ) - A match would indicate a qualitative increase in volume of traffic being requested from a service alert tcp any any <> any any (msg:"Client is making a whole lot of new connections and getting loads of data back"; anomaly:"volume_per_con > 20%/min AND ports > 20%/min" ) - A match would indicate that a client is originating new connections and getting data back Isn't the first option just the portscan preprocessor in a different from? Is there another way to "program" the preprocessor in this case? Pieter On Thu, 2004-06-24 at 20:25, Martin Roesch wrote:
Hi Mike,Anyone interested in starting up an opensource project to build something like this?FYI, Snort's stream4 module (and the new spp_flow) module is capable of logging the stats you mention for any flow that is observed, specifically start/stop time, src/dst IPs and ports, number of packets and number of bytes transferred, as well as IDS event stats and any other flags you care to hang off of them. For example, along with the flow record you could record the number of IDS events that fired for a given flow as well as any anomalies that were detected on that flow (e.g. fragmentation/tcp protocol anomalies, etc). Snort's got 50% of what you want already, you could implement the anomaly detection as a preprocessor if you were so inclined...
------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ 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
Current thread:
- Network Behaviour Anomoly Detection crayola (Jun 23)
- Re: Network Behaviour Anomoly Detection Jon Baer (Jun 23)
- RE: Network Behaviour Anomoly Detection Michael Cunningham (Jun 23)
- RE: RE: Network Behaviour Anomoly Detection Jerry Shenk (Jun 24)
- Re: RE: Network Behaviour Anomoly Detection security (Jun 24)
- Re: RE: Network Behaviour Anomoly Detection Martin Roesch (Jun 24)
- Re: RE: Network Behaviour Anomoly Detection pieter claassen (Jun 26)
- Re: RE: Network Behaviour Anomoly Detection security (Jun 30)
- RE: Network Behaviour Anomoly Detection Michael Cunningham (Jun 23)
- Re: Network Behaviour Anomoly Detection Jon Baer (Jun 23)
- <Possible follow-ups>
- RE: RE: Network Behaviour Anomoly Detection hugh_fraser (Jun 30)