North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: hc
  • Date: Sun Jan 19 01:27:06 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 <[email protected]> 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.