nanog mailing list archives

Re: Router / Protocol Problem


From: John Kristoff <jtk () ultradns net>
Date: Thu, 7 Sep 2006 07:24:37 -0500


On Thu, 7 Sep 2006 07:27:16 -0400
"Mike Walter" <mwalter () 3z net> wrote:

Sep  7 06:50:20.697 EST: %SEC-6-IPACCESSLOGP: list 166 denied tcp
69.50.222.8(25) -> 69.4.74.14(2421), 4 packets
[...]
I'm not very familiar with NBAR or how to use it for CodeRed, but this
first rule:

access-list 166 deny   ip any any dscp 1 log

Seems dubious.  So I'm not not sure what sets the codepoint to 000001
by default, but apparently CodeRed does?  Nevertheless, this seems like
a very weak basis for determining whether something is malicious.

access-list 166 deny   tcp any any eq 5554
access-list 166 deny   tcp any any eq 9996
access-list 166 deny   tcp any any eq 1025
access-list 166 deny   udp any any eq 1434

You may realize this, but I bet some of the rules above I bet are
matching on the occasional legitimate packets.  Particular the last
four rules above.  In fact, I bet the rule that matches on TCP
destination port 1025 probably has a lot of falsepositives.

I'm not sure what you're trying to do with some of them, but if it
is to stop some sort of worm, presumably you know that it will also
stop applications that happen to choose those source ports.  Windows
hosts and apps will probably match the 1025 rule fairly frequently,
UDP and NTP will match the UDP rule occasionally and various things
will the others more or less frequently depending on what traverses
your net.

Now I have two questions.  Is that not a good idea to have this on
FE0/0 out?  Second, why the heck would a smtp connection be matched
via my http-hacks class-map?

You don't show the interface config, but my guess is that the SMTP-
looking packet may have originally had a codepoint of 1 and didn't
really have anything to do with your policy-map.

John


Current thread: