Router / Protocol Problem
jtk at ultradns.net
Thu Sep 7 12:24:37 UTC 2006
On Thu, 7 Sep 2006 07:27:16 -0400
"Mike Walter" <mwalter at 3z.net> wrote:
> Sep 7 06:50:20.697 EST: %SEC-6-IPACCESSLOGP: list 166 denied tcp
> 126.96.36.199(25) -> 188.8.131.52(2421), 4 packets
I'm not very familiar with NBAR or how to use it for CodeRed, but this
> 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
> 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.
More information about the NANOG