FW: Re: Is there a line of defense against Distributed Reflective attacks?

Sun Jan 19 06:24:50 UTC 2003

Everyone probably knows... But if not -- just a reminder that you can 
also add access-list number after 'ip verify unicast reverse-path' to 
allow any hosts you think that should be able to get allowed through the 
filter :-) It's convenient when you are doing some mobileIP+vpn stuff in 
which some type of setup breaks when there is egress filtering.

Multihomed customers should use uRPF at their Ethernet/local interface 
as egress filter... Using uRPF as ingress filter at ISP connections 
(such as Serial3/0, Pos2/0, whatever connects to your ISP's) when you 
are doing BGP can be quite a nightmare.. :-D So I guess they would have 
to use plain-old manual access-list at their ISP-connection interfaces 
for ingress filtering.

i.e..

!
int Gig2/0
 des backbone connection, egress
 ip add 192.0.2.21 255.255.255.252
 ip ver unicas reverse-path 180
!
int Pos3/0
 des OC-3 from XXX ISP, ingress
 ip add 199.99.99.99 255.255.255.252
 ip access 101 i
!
!
acc 101 remark plain-old regular ingress filter for multihomed networks
acc 101 den ip $my_network an
acc 101 den ip 10.0.0.0 0.255.255.255 an
acc 101 den ip 172.16.0.0 0.15.255.255 an
acc 101 den ip 192.168.0.0 0.0.255.255 an
acc 101 per ip an an
acc 180 remark exceptions to egress filtering
acc 180 per ip host 199.59.9.110 an
!
!

-hc

Chris Adams wrote:

>Once upon a time, John Kristoff <jtk at aharp.is-net.depaul.edu> said:
>  
>
>>It might be nice if all router vendors were able to associate the
>>interface configured address(es)/nets as a variable for ingress
>>filters.  So for in the Cisco world, a simple example would be:
>>
>>  interface Serial0
>>    ip address 192.0.2.1 255.255.255.128
>>    ip access-group 100 in
>>  !
>>  interface Serial1
>>    ip address 192.0.2.129 255.255.255.128
>>    ip access-group 100 in
>>  !
>>  access-list 100 permit ip $interface-routes any
>>  access-list 100 deny ip any any
>>    
>>
>
>How is this different than "ip verify unicast reverse-path" (modulo CEF
>problems and bugs, which of course NEVER happen :-) )?
>
>Multihomed customers are more interesting, but if all the single homed
>customers had uRPF (or $VENDOR's equivalent) enabled it would cut down
>on a significant amount of the spoofed traffic.
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20030119/3ddfd066/attachment.html>