Good morning everyone. I just wanted to say thanks for all the help. I
did discover the problem this morning and I should be hit with a
herring. I upgraded the IOS on the router with the issue to match the
other router and the problem was still there. So I tested and noticed
the following line in the logs, since I was on console it popped up
right in front of me.
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
What is this I thought? What is my ACL 166 doing this? I thought I
tested removing all access-lists from interfaces with the original
problem came up. Apparently not. Here is my ACL 166, the first line is
what was being matched. Apparently some how this connection is being
matched via NBAR for good old Code Red.
access-list 166 deny ip any any dscp 1 log
access-list 166 deny tcp any any eq sunrpc
access-list 166 deny tcp any any eq 135
access-list 166 deny tcp any any eq 137
access-list 166 deny tcp any any eq 138
access-list 166 deny tcp any any eq 139
access-list 166 deny tcp any any eq 445
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
access-list 166 deny udp any any eq 135
access-list 166 deny udp any any eq netbios-ns
access-list 166 deny udp any any eq netbios-dgm
access-list 166 deny udp any any eq netbios-ss
access-list 166 deny udp any any eq 445
access-list 166 deny icmp any any redirect
access-list 166 deny ip 127.0.0.0 0.255.255.255 any
access-list 166 deny ip 10.0.0.0 0.255.255.255 any
access-list 166 deny ip 172.16.0.0 0.15.255.255 any
access-list 166 deny ip 192.168.0.0 0.0.255.255 any
access-list 166 permit ip any any
class-map match-any http-hacks
match protocol http url "*default.ida*"
match protocol http url "*cmd.exe*"
match protocol http url "*root.exe*"
policy-map mark-inbound-http-hacks
class http-hacks
set ip dscp 1
I have always had this on my FE0/0 as an outbound ACL, well atleast
since Code Red came about: ip access-group 166 out.
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?
Thanks again everyone,
Mike
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
Hi John,
John Kristoff 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.
It's his NBAR config lower down that sets the dscp value:
class-map match-any http-hacks
match protocol http url "*default.ida*"
match protocol http url "*cmd.exe*"
match protocol http url "*root.exe*"
policy-map mark-inbound-http-hacks
class http-hacks
set ip dscp 1
So, there's probably two things that could happen here: One, NBAR is incorrectly identifying the SMTP traffic as code red, or two, the SMTP traffic is already marked with dscp 1. If you've using these values internally in your own network then they should be reset on all externally received traffic.
Sam
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
There is an elegant solution; administrators should set the evil bit
on any malicious packets seeking egress;
http://www.faqs.org/rfcs/rfc3514.html
Quoting:
0x0 If the bit is set to 0, the packet has no evil intent. Hosts,
network elements, etc., SHOULD assume that the packet is
harmless, and SHOULD NOT take any defensive measures. (We note
that this part of the spec is already implemented by many common
desktop operating systems.)
0x1 If the bit is set to 1, the packet has evil intent. Secure
systems SHOULD try to defend themselves against such packets.
Insecure systems MAY chose to crash, be penetrated, etc.
And now for something completely different...
- --
The whole point of the Internet is that different kinds of computers
can interoperate. Every time you see a web site that only supports
certain browsers or operating systems, they clearly don't get it.