[Snort-devel] Problem with expn r-oot and expn de-code rules (sids 659 and 660)
Donald.Smith at ...530...
Wed Aug 29 13:26:00 EDT 2001
-----BEGIN PGP SIGNED MESSAGE-----
comments in line.
Donald.Smith at ...530... IP Engineering Security
> -----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
> (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.
> David Henderson
> FSC Internet Corp.
> 229 Yonge Street, Toronto, ON
> (416) 921-4280
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8
-----END PGP SIGNATURE-----
More information about the Snort-devel