Recycled from this list below. Also, newer code being tested now will deny
based on RPF lookup, so the deny ACL will not be as extensive/pervasive.
Make sure you run a version of code that fast-switches deny ACLs...
Here's some things to do (others please jump in an help with suggestions):
1. As Ravi just posted, use the "log-input" feature on the extended ACLs to
find out which Interface the DoS packets are coming from.
>Ravi Chandra wrote:
>
>The is a additional option to the extended access-list that will allow
>logging input interface and mac address information.. The keyword is
>log-input and it was added in 011.002(002.002) 11.2(02.02)F
>11.2(02.02)P 11.1(08)CA.
When you do this, make sure you've got enough buffers set on the logging
function and/or stream the logging data off to an UNIX logging server for
analysis.
2. Check the Interface that has this coming in. Here are some commands that
a lot of ISPs/NSPs put on their Interfaces by default:
no ip redirects
no ip directed-broadcast
no ip proxy-arp
3. Now you will come to the point where your customer may wish to block
these attacks. To do this, you will need to put an extended ACL with a
"deny" statement. The "deny" ACL option is currently process switched. So
the CPU shoots up. This is one of the problems different people are working
on right now (see 4).
BTW - If you are trying to block a DoS attack by ICMP packets, add the
following:
no ip unreachables
Otherwise, you will be sending ICMP unreachables back from the "deny" ACL
to invalid source addresses.
4. Attached is one hack that is being worked on to minimize the CPU impact
when you place a deny ACL in the path of a DoS attack. Craig just tested it
in his lab and has pushed it out to the customer he's working with to see
how far it will scale.
Ravi Chandra is working on a "real" solution for this process switched
problem.
Barry
Craig A. Huegen wrote:
>
>Tony Li sent a message to NANOG which refreshed my memory about
>fast-switching packets into the bit bucket, so I set up the lab config
>again.
>
>The following configuration sent the packets to the bit bucket in the fast
>path (17% CPU on 12% interrupts for 7 Mbits of ICMP's @ 3500 pps):
>
>(Note that you can substitute another LAN interface as the target--this
>box only has one LAN interface that's active and I would have had to drive
>to Cisco to put a hub on it--if you have a free ethernet port, shove just
>a hub onto it and use it as the target and "ip route-cache same-interface"
>won't be needed).
>
>interface FastEthernet1/0
> ip address 171.68.183.124 255.255.255.192
> ip route-cache same-interface
> ip route-cache policy
> ip policy route-map killicmp
>!
>access-list 110 permit icmp any host 171.70.200.33 echo
>access-list 110 permit icmp any host 171.70.200.33 echo-reply
>!
>arp 171.68.183.69 2222.2222.2222 ARPA
>!
>route-map killicmp permit 10
> match ip address 110
> set ip next-hop 171.68.183.69
>!
>route-map killicmp permit 20
>end
>
>171.70.200.33 was the host I smurfed.
>
>Any questions, mail me. I'll be happy to answer them.
>
>
At 09:39 AM 3/16/98 -0500, you wrote:
>I've kept hearing about a UDP smurf floating around and I'd like to put up
>a firewall to prevent it. Can anyone give me any insight on how this is
>done? I don't understand enough about UDP, broadcasts or enough about
>access-lists to create an effective one. Can anyone give me some
>pointers?
>
>--
>Regards,
>
>Jason A. Lixfeld jlixfeld@idirect.ca
>System Administrator [L5] jlixfeld@torontointernetxchange.net
>
>---------------------------------------------------------------------
>TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company"
>Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs"
>5415 Dundas Street West | http://www.torontointernetxchange.net
>Suite 301, Toronto Ontario | (416) 236-5806 ext 18 (T)
>M9B-1B5 CANADA | (416) 236-5804 (F)
>---------------------------------------------------------------------
>
>
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:15 EDT