[Snort-sigs] Problem with expn r-oot and expn de-code rules (sids 659 and 660)

dhenderson at ...87... dhenderson at ...87...
Wed Aug 29 13:02:46 EDT 2001

System Architecture x86
Operating System and version Linux 2.2.7
What rules (if any) you were using: expn r-oot and expn de-code (sid 
659, 660)
What command line switches you were using:-D -d -l /var/log/snort -c 
Any Snort error messages: None

The rules "expn r-oot" and "expn de-code" are causing me some problems. 
(I know they are not called that exactly, but I am referring to them in 
this way to avoid anybody reading this from having these rules 
triggered, simply from subscribing to this mailing list).

My problem: the rule names contain the content that triggers the rules.

Typically, reporting mechanisms use SMTP mail to send reports, which 
are formatted to include the rule name associated with the rule. This 
is having the following impact in my case:
1) Some network traffic is generated on port 25 including the content 
"expn r-oot" or "expn de-code", which triggers the rule (pretend the 
dashes are not there).
2) Some method generates a report, including the rule violation, and 
labels it as violating the "expn r-oot" or "expn de-code" rule (again, 
not including the dashes)
3) Some method mails the report to another host on the network using 
SMTP mail.
4) Some network traffic is generated on port 25 including the contnet 
"expn r-oot" or "expn de-code", which triggers the rule...

And so on, and so on...

I have locally fixed this problem by not using the provided rules, and 
creating our own local rules, naming them differently.

A better solution would be one of the following:

1) Enforcing the policy that a rule name cannot contain an expression 
that will match the rules "content".
2) In the specific case of these two rules, only match if the content 
is at the beginning of a line, allowing for possible whitespace. This 
will help prevent the case where people sending e-mail messages talking 
about the exploit (as I am doing) will not have to obfuscate the 
content. I believe the SMTP standard restricts use of the expn command 
to the beginning of a line, though I don't suspect this would prevent 
false positives in the case where the words are the first two lines 
somewhere in the body of a SMTP message.


David Henderson
FSC Internet Corp.
229 Yonge Street, Toronto, ON
(416) 921-4280 

More information about the Snort-sigs mailing list