[Snort-devel] Connection tracking in rules and tracking of 'related' connections
mjohnston at ...1001...
Wed Jan 23 06:51:06 EST 2002
I noticed that there's a 'stateless' rule option:
"Used in conjunction with the Stream4 preprocessor, the stateless
keyword allows rules to match regardless of the state of the connection
the packet is associated with."
What about options for 'new', 'established' in addition to 'stateless'?
For example, a packet with a SYN flag set qualifies as new, a packet
that's part of a connection that stream 4 is following qualifies as
Also, are there any plans to have stream4 watch for related connections
(necessary for the related states described above)? A cool rule to pass
ftp data transfers using that would be:
pass $users any -> any any (state: new, established; related_to: ftp
The related_to rule option that I have in mind is "protocol source
destination" where source and destination are valid snort address
strings. My uneducated idea for implementation would be that stream4 (or
5 :) would generate a hash... think...
hash['tcp/udp/icmp_sIP:sPort_dIP:dPort'] = 'protocol source destination'
When a new packet came in, it would be as simple as looking for the
packet's source/destination ip/port combo in the hash, and seeing what
the connection relates to.
Here's my concept for a rule layout (to give you an idea of why I'm
interested in this):
alert on signatures for attacks
(include established flag to avoid stuff like snot)
pass traffic that is expected
(or even alert on it for auditing purposes)
($users any -> any 80 (state: new, established;))
($users any -> dnsServer 53 (state: new, established;))
($users any -> dnsServer 21 (state: new, established;))
(alert any any -> any any (state: new,established; related_to: ftp
alert on traffic that is not expected
This would turn snort into a human managed anomaly detection engine that
would not rely on statistical analysis and would encourage auditing by
More information about the Snort-devel