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

Smith, Donald Donald.Smith at ...530...
Wed Aug 29 13:26:00 EDT 2001

Hash: SHA1

comments in line.

Donald.Smith at ...530... IP Engineering Security
303-226-9939/0688 Office/Fax
720-320-1537 cell

> -----Original Message-----
> From: dhenderson at ...639...
> [mailto:dhenderson at ...639...] Sent: Wednesday, August 29,
> 2001 11:03 AM
> To: roesch at ...16...; snort-sigs at lists.sourceforge.net
> Cc: snort-devel at lists.sourceforge.net
> Subject: [Snort-devel] Problem with expn r-oot and expn de-code
> rules (sids 659 and 660)
> 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  /usr/local/lib/snort/rules/snort.conf"
> 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".
That makes the most sense because if your doing alerts via (smb,
smtp, ...) and you alert on content
and your watching your own alerts you could get in an alert loop.
This could be used to 
dos your sensor/alert communication path.
> 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  
Depending on what you consider whitespace this could be very hard.
a^hb^hc^hexpn root doesn't contain white space 
doesn't start at the begining of the line and would work with many
email servers. There are preprocessors that
handle unicode and I suspect this would take care of 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.
> Thanks,
> David Henderson
> FSC Internet Corp.
> 229 Yonge Street, Toronto, ON
> (416) 921-4280 
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/snort-devel

Version: PGP Personal Privacy 6.5.8


More information about the Snort-devel mailing list