11.11 uRPF (protecting against spoofing)

JoeMJoeM ✭✭✭

Hey Everyone,

I have looked at a  past thread, but I am not really clear about what the final verdict is for this solution -- on R4's F0/0 interface.

Why does the SG Solution say to use "loose-mode" for f0/0 ?   As others have already commented, this completely defeats the first requirement of the exercise, as it will now accept internal addresses.

SG: "Ensure that R4 does not accept packets with IP addresses of the internal subnets on its connection to the ISP."

After searching through the forum on this task , I found another thread that helped me understand the use of the optional ACL.   So now, my question is, wouldn't the optional ACL ensure that we filter out "internal subnets".  Maybe something like the following:

! this ACL is ONLY for F0/0 to the ISP, while using "Strict Mode".

ip access-list extended 150

        10 deny ip 150.1.0.0   0.0.255.255  any log

        15 deny ip 155.1.0.0   0.0.255.255  any log

        20 permit ip any any log

This way we are fulfilling the primary requirement (above), as well as the logging. 

I hope someone can clear this up for me.  I am reaching the point that I need to stop just skipping over exercises like this.   

Any help is much appreciated.  Thanks.

Comments

  • peetypeety ✭✭✭

    I don't possess the WB or SG you reference, so I can't speak to the specifics.

    However, assuming the internal routes are in 150.1.0.0/16 and 155.1.0.0/16, I think your suggested solution would be correct as long as you kept the uRPF feature in strict mode.  However, "in the real world" this would be a painful implementation, as the logs would go crazy, and so would the CPU.  :)

  • JoeMJoeM ✭✭✭

    Thanks for the quick response Peety.  I just want to stop skipping over some of these exercises that do not seem correct.

    Below are couple of other requirements.

    *Log all packets with spoofed sources.

    *There is another connection to the same ISP in the network, so account for possible asymmetric routing issues on R4.

    I think the logs will only go crazy if there is not a Default-Route out F0/0 to cover all Internet addresses (during the uRPF check).   A default route would keep the uRPF from checking the ACL (I think). As I understand it, the ACL is ony double-checked (and logged) if there is a "violation" of the uRPF.

    Also, for this exercise, all of the internal interfaces are set to strict mode in the SG (with ACL logs).

     

  • In my perspective none of the solutions will accomplish what is required.

    My solution would be to use strict mode in case both the ISP links are being used at the same time (load-sharing traffic) which is not the case.

    Therefore, we are only left with loose mode and creating static routes pointing to null0, which works fine if a DOS or DDOS is launched from a non-directly attached network of R4.

    ip route 150.1.x.x y.y.y.y null0

    ip route 155.1.x.x y.y.y.y null0

    where y.y.y.y is IGP learned mask

    HTH

    Good luck!

  • peetypeety ✭✭✭

    qqabdal, your solution doesn't fix the problem.  IP routing is "longest match wins", so /16 null routes plus (longer than /16 null routes) means you aren't null routing the whole /16, only that which isn't covered by a more-specific route.

    In this case, we want to ensure R4 accepts packets from non-internal routes, even in the face of asymmetric routing, and logs anything that's spoofed.  In this example, "spoofed" essentially means "any packets from our address blocks".  Strict mode uRPF normally dumps any traffic for which the CEF FIB doesn't send replies out the same interface that the packet in question came in.  Loose mode uRPF normally dumps any traffic for which the CEF FIB cannot reply.  Therefore, to achieve blocking of spoofed packets, strict mode is essential, as the internal routes will "punch holes" in the CEF FIB allowing spoofed packets to come in (the exception ACL is only invoked if uRPF would have dropped the packet).  With strict mode as the correct mode choice, we need to still allow outside traffic in.  I think the answer is therefore strict mode with an exception ACL that looks like:

    access-list 181 deny ip 150.1.0.0 0.0.255.255 any log

    access-list 181 deny ip 155.1.0.0 0.0.255.255 any log

    access-list 181 permit ip any any

    This is slightly different than what we've seen previously: it drops the logging on the final permit statement, thereby only logging the spoofed traffic.

    In the real world (in other words, this isn't applicable to your exam studies), loose mode is the right choice on the outside, as it allows us to reject traffic from unrouted sources.  When you overlay a "Real-Time Black Hole" over this, and inject null routes for attackers, you can effectively squish attacks at the entire perimeter in seconds.  If you assume (which translates to "hope") that every network uses strict mode on their customer-facing ports, you don't have to worry about spoofing (much); it's the attacks that are a problem.  I've seen consulting clients who cooked up a tool to peruse their Netflow reports, pick off any flows >1kp/min, and null-route them automatically (at which point CEF drops all traffic TO them, while uRPF drops all traffic FROM them).  With a little tweaking of that threshold to suit, it's probably a pretty good simple tool.

  • JoeMJoeM ✭✭✭

    Hi qqabdal,  thanks for the reply.

    I didn't really understand the first couple of sentences.  Why would we only be left with loose mode and static routes to null0?   Why wouldn't the solution I provided work?    Sorry if I am being slow on this.

    We are suppose to protect against spoofed addresses.  I do not think that the IP ROUTEs /16 to null0 would do anything, as we already have more specific internal routes provided by the IGP.

    Can you explain to me again, why you think strict mode  would  not work on the external interface?     The ISP connections are not on the same router, but there is another ISP connection on the network. 

      Thanks again for your help.

  • qqabdal, your solution doesn't fix the problem.  IP routing is "longest match wins", so /16 null routes plus (longer than /16 null routes) means you aren't null routing the whole /16, only that which isn't covered by a more-specific route

    Peety, great catch, I accidently typed in the /16, but I was referring to host static routes for the destinations, like ip route 150.1.1.1 255.255.255.255, I was going to replace the 0 with x's or routes with exact mask length as your IGP routes.

    I do agree with you that this is unmanageable and would be an administrative nightmare on a real world implementation. I will fix my original post to reflect what I meant to say.

  • Hi qqabdal,  thanks for the reply.

    I didn't really understand the first couple of sentences.  Why would we only be left with loose mode and static routes to null0?   Why wouldn't the solution I provided work?    Sorry if I am being slow on this.

    We are suppose to protect against spoofed addresses.  I do not think that the IP ROUTEs to null0 would do anything, as we already have more specific internal routes provided by the IGP.

    Can you explain to me again, why you think strict mode  would  not work on the external interface?     The ISP connections are not on the same router, but there is another ISP connection on the network. 

      Thanks again for your help.

    Hi JoeM,

    Sorry for not being very clear, I knew it would cause more confusion than clarifying the issue.

    Strict mode would work, but this would break if there is some sort of asymmetrical traffic between the two ISP links, if you have a temporary routing issue that leads to asymmetric traffic (traffic inbound to your CE comes via ISP1, but your best route out is via ISP2) it would cause your RPF check to fail and thus the packets would be dropped.

    The thing with the static routes pointing to null0 is that loose mode checks if there is a route in the RIB, however, if that route points to the Null0 interface, the RPF check fails and the packet is dropped, so if you create static routes  pointing to Null0 that have the same mask length as your IGP learned routes and you have loose mode configured the RPF check will fail and the packets will be dropped. 

    Due to the sheer amount of routers you have to touch to make this happen in real world implemenations we make use of Remotely Triggered Black Hole Filtering (RTBH) to blackhole a specific address that we have identified as the source of a DOS or DDOS. But this is not within the CCIE R&S scope.

    HTH

    Good luck!

     

  • JoeMJoeM ✭✭✭

    Well guys, I guess I do understand this enough to move on.  I have never used a router as a firewall before, so all of this is new to me.

    Peety, one more clarification please, regarding what you and qqabal are saying about real-world design.

    You say that loose mode is the correct solution for the external facing interface (in the real world).   This still does not make since to me, because I do not see how it is unmanageable -- unless we are talking about a huge network and then the ACL might be unmanageble.    Is this what you mean?

    In the SG, it talks about the added feature of being able to use a default-route with the uRPF.  This means that the ACL would never be used, unless there was a violation.      AHHH lightbulb     If we used a default-route for Internet routes, than the ACL would be the same in the SG. DENY and log violations.

     

     

  • peetypeety ✭✭✭

    In the real world, there's an assumption that customer-facing interfaces have strict-mode uRPF.  If that's semi-true, we're now discussing what uRPF to use on Internet-facing interfaces, and we're assuming that "our network" is multi-homed in some fashion.  Because of the multi-homing, loose mode starts to become the obvious choice.

    When I wear my ISP hat, I'm not worried about someone spoofing as my customer - if they are, it's small potatoes.  I'm worried about two things: people spoofing from unrouted space (i.e. a router with a full BGP table but no default route would be unable to reach said address, as it's reserved etc.) and people DOSing my customer.  The DOS attack is the biggest concern, as it's most likely so big that my customer's port is massively swamped, and it's also possible that the DOS is big enough to swamp MY upstream-facing ports (i.e. where the attack is coming in).

    If there's an attack, and I've done my uRPF and RTBH homework ahead of time (which means uRPF strict with allow-self-ping on customer ports, uRPF loose with allow-self-ping and allow-default on upstream ports, RTBH set up on 1 or 2 "trigger routers" in different corners of the network), I have two options to deflect the attack:

    Using a trigger router, null-route the victim IP address.  This does take the customer's IP address/subnet "off the air", but means that the attack packets go into the bit-bucket (because they're routed to Null) at every perimeter interface.  In my eyes, this is "plain vanilla recursive routing": I go to the trigger router and add 'ip route a.b.c.d 255.255.255.255 tag 123 null0'.  When I redistribute any static with 'tag 123' into BGP, I use a route-map to set the next-hop to 192.0.2.1 (chosen from the updated version of RFC 1918, I think it's 5734 but don't quote me, where 192.0.2.0/24 is reserved as it's used as a test network in some books).  On EVERY router, 192.0.2.0/24 is static-routed to Null0.  So, as every router learns this route for a.b.c.d, it gets routed to Null0 recursively ("route 192.0.2.1 to null0, route a.b.c.d to 192.0.2.1, therefore route a.b.c.d to null0).

    Using a trigger router, null-route the attacker IP address.  This means that "my network" can no longer reach the attacker (which is a good thing in my book), but more importantly, because the attacker's address is null-routed, uRPF (either mode) will reject any packets FROM the attacker since they are routed to null0 (through the same recursive process mentioned above).

    If someone spoofs as my customer, they can't do much, since TCP probably can't complete a connection (I'm assuming the attacker hasn't hijacked the BGP ROUTE for my customer), so whatever they do is probably restricted to UDP or ICMP.  However, if someone DOSes my customer, it's likely felt instantly, so protecting/reacting against this is far more important than protecting against spoofing.

    Circling back to the top regarding mode choice, both strict and loose mode support this RTBH behavior.  Therefore, loose mode is appropriate for upstream interfaces, since asymmetric routing is quite likely.  I normally use allow-self-ping every time I use uRPF, and I normally also use allow-default on upstream loose interfaces (not on any loose interfaces towards multi-homed customers; they're expected to announce routes to me for anything they might send).

    Does any of that babble help clarify real-world usage?

    For what it's worth, I usually have an inbound ACL on customer ports that blocks any protocols the customer shouldn't be sending us (PIM, OSPF, EIGRP). I usually have an inbound ACL on upstream ports blocking the same protocols, along with an explicit anti-spoof protection against my infrastructure subnets (so nobody can spoof as one of my routers).

  • JoeMJoeM ✭✭✭

    That was good. I am marking it as a favorite post, so I remember to come back and read it again.  It will be interesting to read after I finish up a couple of these workbooks.

     

    Thanks guys for the help with this. Much appreciated.

  • Hi Joe

     

    Sorry for dragging up an old post but hopefully it helps.  I agree the SG does not really cover the fact that spoofed packet from BB3 could be coming into f0/0.  The "loose" mode means we will accept them if we have a route out any interface which we will because we learn our IGP routes on the serials or VLAN146.

     

    I approached this be putting a normal ACL on the interface itself blocking 150.1.0.0/16 and 155.1.0.0/16 which allows loose mode to work i.e. if we actually prefer to get to AS54 via R6 we still let packets from AS54 come in via F0/0 which is the interntion of loose mode but the ip access-group prevents the spoofing of inside addresses.

     

    Another item of interest is suppressed verfication drops - these appear to be drops that would of occurred but did not so they are not actual drops.  This happens becuase of a) loose mode or b) an acl was used to bypass the drop i.e. a permit

     

    You can use debug ip cef drops rpf as verification and show ip interface <x>:

     

    CEF-Drop: Packet from 150.1.6.6 via Serial0/1/0 -- via-rx ; drop due to rx interface mismatch (strict mode)


    CEF-Drop: Packet from 150.1.6.6 via Serial0/1/0 -- via-rx ; was going to drop then....

    CEF-Drop-Suppress: Packet from 150.1.6.6 via Serial0/1/0 -- ACL check ; drop “suppressed” means the packet was sent, due to ‘ACL check’


    CEF-Drop: Packet from 150.1.1.1 via FastEthernet0/0 -- via-rx ; was going to drop then.....

    CEF-Drop-Suppress: Packet from 150.1.1.1 via FastEthernet0/0 -- ip verify check (via-any)

     

    ; drop “suppressed” means the packet was sent dues to “via-any” or loose mode


    I stuck a 150.1.1.1 loopback on BB3 for the last test, the first two I had a 150.1.6.6 address on SW2


    Nick
Sign In or Register to comment.