RE: Router / Protocol Problem
At 07:27 AM 07-09-06 -0400, Mike Walter wrote: Best moved to cisco-nsp. -Hank Nussbacher http://www.interall.co.il
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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Rodney Dunn Sent: Wednesday, September 06, 2006 8:45 PM To: Christopher L. Morrow Cc: Rodney Dunn; Mike Walter; Hank Nussbacher; Justin M. Streiner; nanog@merit.edu Subject: Re: Router / Protocol Problem
Then that proves it's not a local router problem then. :)
On Wed, Sep 06, 2006 at 07:49:26PM +0000, Christopher L. Morrow wrote:
On Wed, 6 Sep 2006, Rodney Dunn wrote:
Get a sniffer trace. Packets on the wire prove what's going on.
provided the packets get back to him, it seems his problem is traffic getting back to him :( so probably no packets will be on the wire (none in question atleast)...
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Apparently some how this connection is being
matched via NBAR for good old Code Red.
Best moved to cisco-nsp.
What!? Network operator discovers that measures taken to mitigate an old network security measure, long past their sell-by date, are now causing random grief. Seems to me like bang on topic for NANOG. What other such temporary mitigating measures are still in place long after the danger has passed. Note, that Code RED was a both an application vulnerability and a network DDoS. Even though there are likely still many hosts running the vulnerable application, the number is not sufficient to cause another massive DDoD and measures taken to protect against this particular peculiar DDoS, really don't have a good technical reason to remain in place. This is probably also another instance of the well-known ops problem: We know how to get stuff deployed but we can't undeploy stuff because we are too busy deploying other stuff. --Michael Dillon
Michael.Dillon@btradianz.com writes:
Network operator discovers that measures taken to mitigate an old network security measure, long past their sell-by date, are now causing random grief. Seems to me like bang on topic for NANOG.
Agreed. Rare that people do haircuts on router configs; they're tedious and can not be delegated to an intern or someone else who doesn't have historical context. I just cut a config by half by removing unused ACLs, and even that is fairly painful.
What other such temporary mitigating measures are still in place long after the danger has passed. (?)
It's been almost nine and a half years and was a short-lived problem, but I'll betcha that an announcement from AS 7007 will have reachability problems to a measurable fraction of the Internet. That would make a kind of cool experiment. Vinny, you listening? ---Rob
Yeah. Don't want any operational stuff here. Need to get back to who's got a free 300-baud dialup in Antwerp. Hank Nussbacher wrote:
At 07:27 AM 07-09-06 -0400, Mike Walter wrote:
Best moved to cisco-nsp.
-Hank Nussbacher http://www.interall.co.il
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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Rodney Dunn Sent: Wednesday, September 06, 2006 8:45 PM To: Christopher L. Morrow Cc: Rodney Dunn; Mike Walter; Hank Nussbacher; Justin M. Streiner; nanog@merit.edu Subject: Re: Router / Protocol Problem
Then that proves it's not a local router problem then. :)
On Wed, Sep 06, 2006 at 07:49:26PM +0000, Christopher L. Morrow wrote:
On Wed, 6 Sep 2006, Rodney Dunn wrote:
Get a sniffer trace. Packets on the wire prove what's going on.
provided the packets get back to him, it seems his problem is traffic getting back to him :( so probably no packets will be on the wire (none in question atleast)...
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
-- Requiescas in pace o email Ex turpi causa non oritur actio http://members.cox.net/larrysheldon/
participants (4)
-
Hank Nussbacher -
Laurence F. Sheldon, Jr. -
Michael.Dillonļ¼ btradianz.com -
Robert E.Seastrom