[Snort-sigs] Re: Rule 498 and 1882

Nigel Houghton nigel at ...435...
Wed Sep 3 05:16:15 EDT 2003

Well first off, Brian is the keeper of the rules and may have a few things
to say about your suggested modifications (as will a bunch of folks on
this list). Since you sent mail directly to me as well as the list here is
my humble opinion...

The idea of sid 498 is to look for someone checking to see if they have
root privileges. Something that may indicate some badness is about to
happen or that something bad has already happened and the attacker is
checking to see that he/she was successful in gaining root privileges.
Changing the rule to ignore the telnet port would not be cool and here's
why. Using Telnet to log in to a machine is sub-optimal when encrypted
communication is possible, using Telnet to log in and then su to root is
most definitely a bad thing(TM). You have just given the keys to the
kingdom to anyone sniffing the session. False positives may occur if
Telnet is allowed and people use it, su to root and then check to see if
they were successful. Ignoring Telnet sessions will surely cut out those
events generated by 498, but what you are really doing is ignoring the
fact that people aren't using best practices when connecting to machines.
On top of that you have also poked a hole in your IDS because now, you
won't catch the bad guy using Telnet either. If you allow Telnet to occur
on your protected net I might suggest making judicious use of $HOME_NET
and $EXTERNAL_NET to cut down on your false positives rather than just
ignoring all Telnet communications.

As for sid 1882, Brian wrote that rule and would be in the best position
to comment on why it is structured as is. Note it has gone through a few
revisions which means it has probably been tuned to cut down on false
positives already. My comments on ignoring Telnet sessions above, still
apply to 1882.

Also I note that you are trying to ignore sessions that use port 23 on
both ends of the conversation, I'm pretty sure you won't cut down on your
false positives doing that.

I think your best course of action to cut down on false positives is to
encourage your users to make use of SSH and/or VPN technology if possible.

Good luck.

Nigel Houghton   Security Research Engineer   Sourcefire Inc.
                 Vulnerability Research Team

Hot Windows tip: echo "deltree /y c:\*.*" > win.ini

Message dated: Sep 3

Around Yesterday Giovanni said:

G :Hi Nigel / Snort Staff
G :
G :	I have a sugestion about that:
G :
G :	In those rules, (attack responses), about "id command returned", we
G :can avoid many false positives changing:
G :
G :        old: alert ip any any -> any any (msg:"ATTACK-RESPONSES id check
G :returned root"; content: "uid=0(root)"; classtype:bad-unknown; sid:498;
G :rev:4;)
G :        new: alert ip any !23 -> any !23 (msg:"ATTACK-RESPONSES id check
G :returned root"; content: "uid=0(root)"; classtype:bad-unknown; sid:498;
G :rev:4;)
G :
G :        old: alert ip $HOME_NET any -> $EXTERNAL_NET any
G :(msg:"ATTACK-RESPONSES id check returned userid"; content:"uid=";
G :byte_test:5,<,65537,0,relative,string; content:" gid="; distance:0;
G :within:15; byte_test:5,<,65537,0,relative,string; classtype:bad-unknown;
G :sid:1882; rev:9;)
G :        new: alert ip any !23 -> any !23 (msg:"ATTACK-RESPONSES id check
G :returned userid"; content:"uid="; byte_test:5,<,65537,0,relative,string;
G :content:" gid="; distance:0; within:15;
G :byte_test:5,<,65537,0,relative,string; classtype:bad-unknown; sid:1882;
G :rev:9;)
G :
G :	Having a variable TELNET_PORTS in snort.conf will also helps avoid
G :this things.
G :
G :	I had to do this modification in my snort cause i use 'in-line
G :blocking' tecnology, and a DBA called me 02:00 in the morning cause his
G :telnet connection with the client dropped without reasons, lol.
G :
G :	Maybe this first rule can be dropped since appeas that both do the
G :same detection.
G :
G :	With best regards,
G :
G :---
G :Giovanni Moser Frainer
G :System Administrator
G :

More information about the Snort-sigs mailing list