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