[Snort-users] The lack of a "client" and "server" definition in snort...
jed at ...2168...
Tue Jun 5 10:16:27 EDT 2001
What you might be alerting off is the actual HTML being sent from server:80
-> client:2301. Since snort doesn't do any real analysis of the HTTP
protocol, it doesn't understand that the '../icons/xxx.gif' is harmless, all
it sees is the verboten '../' in the content. You can avoid this by first
putting in a pass rule just before the rule in question:
pass tcp $EXTERNAL 80 -> $INTERNAL 2301 (Msg:" Pass ../ content from web
servers"; content: "../";)
And don't forget to run with -o.
Now if you actually have this vulnerability on your network (then fix it
dammit), some crafty attacker might attack with src port 80 with the hopes
that you have a pass rule like the one above.
hope this is some help,
On Tuesday 05 June 2001 02:03 am, you wrote:
> I see lots of false positives on vision18.conf from rules such as:
> alert TCP $EXTERNAL any -> $INTERNAL 2301 (msg:
> "IDS244/http-compaq-insight-dot-dot"; content: "../"; classtype:
> I get false positives off events such as a user downloading a HTML page
> that references "<IMG SRC='../icons/xxx.gif'>". The client request goes
> from $INTERNAL port 2301 to $EXTERNAL port 80 - hence the match.
> However, that wasn't the intent of the rule. From left to right it's saying
> that if an EXTERNAL CLIENT on any port makes a TCP connection to port 2301
> on an INTERNAL SERVER, then... Well, that's the way I read it :-)
> So, is such "stateful" matches possible? Is that what the stream2
> preprocessor will eventually be used for? At the moment I assume it "only"
> (trying not to offend anyone ;-) bundles lots of packets within a TCP
> session to make them appear as one really large packet WRT rule matches?
> I don't know if such "handedness" actually exists in the rules, but a
> combination of "handedness" plus stream2 recording which host-port pair
> instigated a session would probably do what I'm describing?
More information about the Snort-users