[Snort-sigs] L3Retriever false positives

Nigel Houghton nigel at ...435...
Tue Jan 25 04:16:03 EST 2005

On  0, Javier Fernandez-Sanguino <jfernandez at ...2106...> allegedly wrote:
> I believe the L3Retriever information should be enhanced as shown below.
> --------------------------------------------------------------------------
> Rule:  alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP 
> L3retriever Ping"; icode:0; itype:8; 
> reference:arachnids,311; classtype:attempted-recon; sid:466; rev:4;)
> --
> Sid:  	 1:466
> --
> False positives:
> [add] Windows 2000 and Windows XP systems are also known to 
> occasionally send similar ICMP echo requests with this content when 
> communicating with their domain controller or other Windows systems 
> when trying to mount remote shares or doing network discovery.
> --------------------------------------------------------------------------
> This has been brought up a number of times in the list:
> Message-ID: <C038832A1A43884582CACB4B95217DC2011838EE at ...2548...>
> Message-ID: 
> <3D89EF6753768740AE4A1DD594736C0701A80E at ...2587...>
> Message-Id: <s0fbae32.096 at ...2651...>
> Message-ID: <20040716125316.34288.qmail at ...2644...>
> ¿Any reason why it's not included yet? I understand that this is 
> sometimes seen because HOME_NET and EXTERNAL_NET are not properly 
> defined, but for IDS monitoring internal sensors for worm activities 
> you really want to have EXTERNAL_NET = HOME_NET so you can detect 
> attacks between internal users.
> The funny thing is I noticed this while reviewing somebody's Kerio 
> Firewall logs which includes this signatures as a "medium priority 
> intrusion" (that's probably been fixed in Kerio, he was using an old 
> version). Googling I've found people discussing this signature at
> http://forums.speedguide.net/archive/index.php/t-160456.html
> and
> http://www.wilderssecurity.com/showthread.php?s=640949ba590225f0f8f60cad22bcfe8a&p=147781#post147781
> :-)
> Regards
> Javier

The docs for each of the rules are written for the rule as shipped and
usually assume that the user has correctly configured the appropriate
variables in snort.conf for a snort IDS being used in the standard
behind-the-firewall manner. It is important that the false positive section
should not create possible cases of false negatives, this is why we do
not normally include false positive information like this for
"non-standard" configurations.

That said, some installations as you mentioned, could potentially set
variables like $EXTERNAL_NET and $HOME_NET to be the same. (There are
other things you could do with variables but that is off-topic for this
thread) In these situations, you must expect to have a higher incidence of
false positives and the snort installation needs considerably more
tuning than normal. If you are in this situation, you more than likely
have more of an idea about what is going on and more time to deal with
internal host to internal host traffic.

On a final note, it is a good thing that the mailing list archives are 
searchable and easily found, as you have demonstrated, a little work
searching the web can reveal some useful information :)

    Nigel Houghton      Research Engineer       Sourcefire Inc.
                  Vulnerability Research Team

 Stewie: You know, I rather like this God fellow. Very theatrical, 
         you know. Pestilence here, a plague there. Omnipotence 
				 ...gotta get me some of that.

More information about the Snort-sigs mailing list