Aug 13 18:35:58 permitted icmp 205.139.170.70 -> 192.41.177.255 (8/0), 9999 packets Aug 13 18:35:58 permitted icmp 193.132.24.178 -> 192.41.177.255 (8/0), 8819 packets Aug 13 18:36:38 permitted icmp 128.83.42.2 -> 192.41.177.255 (8/0), 225 packets Aug 13 18:39:59 permitted icmp 134.115.226.26 -> 192.41.177.255 (8/0), 9051 packets Aug 13 18:39:59 permitted icmp 194.128.134.47 -> 192.41.177.255 (8/0), 9327 packets Aug 13 18:43:59 permitted icmp 149.112.125.54 -> 192.41.177.255 (8/0), 8722 packets [ some others snipped out ] Now if only Cisco's let you obtain a "src_hardware_addr" :( Lyndon Levesley Xara Networks -- Penis Envy is a total Phallusy.
On Wed, Aug 13, 1997 at 06:46:55PM +0100, Lyndon Levesley said:
[...]
Aug 13 18:43:59 permitted icmp 149.112.125.54 -> 192.41.177.255 (8/0), 8722 packets
8/0 is 'echo request', according to trusty old /usr/include/net_inet/ip_icmp.h (Solaris 2.5.1)
[ some others snipped out ]
Now if only Cisco's let you obtain a "src_hardware_addr" :(
doesn't the 'log-input' keyword log the input interface? at the end of the access-list rule. or, copy the access-list to another access-list number, and use different access-list numbers on different interfaces. (if you don't need the input interface at all, but the source host, then some type of packet sniffing is the only way to go.. sorry I can't help..) And here's something that I wrote up, it's an idea to stop the flood... " Policy routing is fast switched in the right IOS revs (I think starting at 11.2(6)F). Your config would look something like this: ! access-list 101 permit icmp any any echo-reply ! route-map KILLICMP permit 10 match ip-address 101 set interface Null0 ! ! interface hssi 5/1/0 ip policy route-map KILLICMP ip route-cache policy ! " Since denying on an ACL is process switched, and kills your router, the goal is to make your router fast-switch the packet to /dev/null... aka Null0. Thanks to Barry Raveendran Greene <bgreene@cisco.com> for this one. I don't know for sure if it works, as I haven't had a chance to try it, but if it does, let me know...
Now if only Cisco's let you obtain a "src_hardware_addr" :(
doesn't the 'log-input' keyword log the input interface? at the end of the access-list rule.
The I/P i/f is FDDI to MAE-East - we know this. The question is which router on MAE-East it comes from. A trace to the source doesn't help as we don't know the source address isn't faked. It would be nice if using logging access lists you could show the MAC address the packet came from. Alex Bligh Xara Networks
On Wed, 13 Aug 1997 14:00:00 -0500, ed@texas.net writes:
Policy routing is fast switched in the right IOS revs (I think starting at 11.2(6)F). Your config would look something like this:
Since denying on an ACL is process switched, and kills your router, the goal is to make your router fast-switch the packet to /dev/null... aka Null0.
I'm not from a Cisco background, so forgive me, but.. What a strange way to configure a router. You have to configure it in a non-intuitive way because the intuitive way will blow up the router? I guess we should be thankful that IOS lets us get around hardware limitations of the box, but someone should really teach Cisco a concept called "SMP". Just an observation.. -Jon
A 7513 with an RSP2 (100Mhz MIPS R4700) can process switch around 3500 packets/sec, by my unofficial testing. People at cisco may respond negatively to my post, but I'll refer them to two cases I opened with TAC, neither of which were able to raise the ceiling on how many packets can be process switched. Cisco configuration is aimed towards fast-switching as many packets as possible. The same box can probably fast switch a couple of hundered thousand packets/sec or more (I have no idea, I just know it's a lot) but if you force the box to process switch, YOU WILL KILL IT. It will start dropping bgp sessions, etc etc, and you're toast. One way to force a cisco to process switch is by sending it packets that match an ACL deny.... and this latest round of 'smurfing' will send tens of thousands of packets/sec through your router.. so access-list filtering is worse than useless, it is destructive, when combating DoS attacks. hence the idea of using policy-routing to filter the smurf-attacks. realize here that doubling (or tripling, or quadrupling) the CPU power of the cisco will not help. Upgrading from an rsp2 to an rsp4 would buy you about 3 times 3.5Kpps, say around 10Kpps, process switched. That's still hardly enough to save you when you're being smurfed. Ed -- On Wed, Aug 13, 1997 at 02:27:43PM -0500, Jon Green said:
I'm not from a Cisco background, so forgive me, but.. What a strange way to configure a router. You have to configure it in a non-intuitive way because the intuitive way will blow up the router? I guess we should be thankful that IOS lets us get around hardware limitations of the box, but someone should really teach Cisco a concept called "SMP". Just an observation..
-Jon
On Wed, 13 Aug 1997 14:40:05 -0500, ed@texas.net writes:
realize here that doubling (or tripling, or quadrupling) the CPU power of the cisco will not help. Upgrading from an rsp2 to an rsp4 would buy you about 3 times 3.5Kpps, say around 10Kpps, process switched. That's still hardly enough to save you when you're being smurfed.
That's my point. The answer is to get rid of the concept of an RSP completely. A box with a central CPU is never going to scale as well as a distributed processor design no matter how many MHz you throw at it. There ARE vendors that have such designs (and have had such designs for about the past 5 years or so..) While admittedly I (strongly) dislike Cisco, it is in the best interest of the entire Internet to see them build a better box. With 80% of the routers in the Internet being Cisco, these types of DoS attacks make me a bit nervous about our future when the infrastructure is built on what is IMHO a non-scalable architecture. -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
participants (4)
-
Alex.Bligh -
Edward Henigin -
Jon Green -
Lyndon Levesley