[Snort-devel] what about anti-rules and whatnot?
roesch at ...48...
Fri Apr 6 23:01:36 EDT 2001
Just a little point-by-point while we're still working with the Snort
> Regular expressions would work miracles in some cases, but ultimately we
> are going to need protocol inspection.
> land (source and destination ip address the same)
This is handled with the "sameip" plugin that was implemented by Phil
Wood about a month ago and is available in CVS.
> plaintext protocol exploit (binary data where plaintext 7bit expected)
It'd be trivial to write a "plaintext" plugin to check traffic from
protocols that we expect to be 7bit and make sure the high bit is never
> cgi exploits (identifying that a request is a cgi, not referer, etc)
It'd be relatively easy to set a pointer to the HTTP URI string when we
do decodes and normalization through the http_decode preprocessor. That
way we could have pattern matching on the URI payload only with a
keyword like "cgi_content". Once again, easy to implement if people
want to see it.
> decoding rpc (see sidestep, has relative offsets)
This is done in -current, we committed a RPC normalization plugin to CVS
2.5 weeks ago to catch exactly the evasion process that Sidestep uses.
> decoding dns (see sidestep, has relative offsets and pointers - guh!)
I'm not touching this one right now, but it'd be easy enough to
implement a DNS decoding and verification preprocessor.
> teardrop, nestea, etc (watching packet fragment states)
This is harder, although the defrag plugin could detect this sort of
stuff with a little work.
> deviance from rfcs (violations of state machine, helo->mail from->etc)
Blah, lots of state there. If someone wants to monitor mail explicitly
it'd be pretty simple to do a state machine that can track stuff like
that, protocol verifiers aren't too bad to code up. This is where a
target-based system would be best to give the IDS foreknowledge of the
applications it's monitoring.
More information about the Snort-devel