Hello Networkers,
Today, I am going to discuss a security methodology uRPF (Unicast Reverse Path Forwarding), which is very useful in preventing DDoS attacks sourced from your internal network.
When a routing device receives a packet, by default it checks destination address in the IP header, then lookup into own routing/forwarding table for next hop address and exit interface for this destination. In this process, device doesn’t look into the source field of IP header. Which may open a flaw for an intruder or compromised systems to perform DDoS attack.
DoS and DDoS
DoS or Denial of Service attack is a way to impact serviceability of a Server by overloading it with a huge amount of requests. For example, if a DNS server which can handle 1000 DNS queries per second. A bad machine generating more than 1000 DNS queries/second will overload DNS server. At this time, all legitimate DNS requests from other hosts will be denied, causing Denial of (DNS) Service in network.
DDoS or Distributed Denial of Service also does the same thing, however, now, attackers may be different machines, attacking all together to impact the serviceability of same Server. Now, even 15-20 machines sending less than 100 DNS requests/second will cause DDoS attack. In terms of impact, DDoS is more powerful and hard to prevent.
Considering same example, we observed that a healthy system even in peak usage generates less than 100 queries per second. So, we can apply restriction of 100 DNS requests/second per source IP on server gateway (or at closest firewall). This restriction can help to prevent DoS attack. However, it will not help in case of a DDoS attack.
Usually, Servers are provisioned to serve much greater services than during peak usage. But some infected machine may generate much more traffic than expected. To make the situation worse, these machines may spoof traffic with different source IP addresses. So, it will look like traffic is coming from different hosts, causing DDoS.
In picture below compromized machine M1 is spoofing source address of N1 and N2 and attacking Server host.
In DDoS attack, targeted volume of attack is summed by multiple hosts (or different spoofed addresses). So, it appears as legitimate traffic and becomes harder to detect and prevent.
Spoofing has few other ways to harm your network. Another way is by performing a passive attack. Attacker can generate traffic from a compromised machine by spoofing source IP of the target machine and send request to one or multiple destination hosts. Destination Server will return response to target (which was masked in spoof packet). DNS-Zone-transfer attack and NTP attacks are executed by spoofing many machines.
In picture below compromized machines M1 is attacking target S1 by spoofing S1's source address and generating request to nodes N1 and N2.
Compromised machines involved in attack remains hidden. After you know about the attack, your logs will point to source IP of machine, which was masked in spoof packets.
In these attacks, not necessarily, you be the victim, but hackers may use your network to attack some other organizations. This may not only degrade the reputation of your origination but, may also lead to legal actions.
Spoof Prevention:
Now when we understood potential harms about Spoofing, Let’s talk about how to mitigate it. Spoofing can be effectively prevented at origin only. Traffic, the farther travels away from the source, gets harder to identify its legitimacy. So, it’s always better to implement any-spoofing close the each network subnets.
Unicast Reverse Path Forwarding (uRPF) is method to enable capability in network devices to do source lookup while doing packet forwarding. An interface with URPF, when receives a packet, along with destination IP, device inspects its source IP also. Same way, how device does lookup for egress interface associated to destination IP, it resolves ingress interface associated to source IP. If packet is received on resolved ingress interface, it is routed further through egress interface, else, packet dropped.
Implementing URPF
uRPF may be applied in different ways, based on network topology and how routes are learned.
Strict Mode
Strict mode lookup for source subnet and resolve active ingress interface. If packet is received on any other interface, its discarded.
Best and most effective use of strict mode is to apply it on a Lan interfaces or an interface which act as single point of ingress/egress to subnet.
On a Cisco device, command at interface to be used
Interface gi0/0
ip verify unicast source reachable-via rx
On a Juniper Device, command at interface to be used
set interfaces ge-0/0/0 unit 0 family inet rpf-check
Loose Mode
In case of Loose mode, router will lookup for Source IP, and it will process it if specific subnet matching source IP is in routing/forwarding table (it will not strictly check the ingress interface). However, if a routing entry is missing for source IP, it will be discarded.
Loose Mode can be used when you have redundant interfaces for a subnet or if you expect asymmetric paths in the network.
On a Cisco device, command at the interface to be used
interface gi0/0
ip verify unicast source reachable-via any
While on Juniper Devices, command at the interface to be used
set interfaces ge-0/0/0 unit 0 family inet rpf-check mode loose
uRPF with Default Route
Interfaces pointing to default route may not be ideal to apply uRPF, Because, it will either match all possible routes and permit all traffic or will discard all unknown sourced traffic.
However, on a Cisco device, there may be a reason to do so. Enabling uRPF on a Cisco device enables option to lookup for blocked routes. If you have blocked a subnet (Cisco- next hop Null 0, Juniper- next hop discard/reject), router will perform uRPF lookup and if source IP matches discarded route, it will discard packet.
Cisco command,
ip verify unicast source reachable-via {rx | any} allow-default
Juniper don’t recommend enabling uRPF on an interface pointing to default route. Instead, suggest to use the following command to discard traffic source matching route next-hop discard.
set forwarding-options rpf-loose-mode-discard family inet
above command doesn’t need to be applied at interface specific and can be used even when you are not enabling uRPF on any interface of the device.
JunOS also gives option for all traffic which fail uRPF check to imply an action. This action can be permit, discard, log, or any instruction permissible in a firewall filter. This is very useful when dealing with special traffic (eg. DHCP or Multicast traffic).
set interfaces ge-0/0/0 unit 0 family inet rpf-check fail-filter rpf-special-case-dhcp
set interfaces ge-0/0/0 unit 0 family inet rpf-check mode loose fail-filter rpf-special-case-dhcp
Firewall filter in this example (rpf-special-case-dhcp) can be used to permit DHCP traffic. Note that by default Juniper will discard DHCP traffic due to its IP field info (Source IP: 0.0.0.0, Destination IP: 255.255.255.255).
set firewall filter rpf-special-case-dhcp term allow-dhcp from source-address 0.0.0.0/32
set firewall filter rpf-special-case-dhcp term allow-dhcp from destination-address 255.255.255.255/32
set firewall filter rpf-special-case-dhcp term allow-dhcp then count rpf-dhcp-traffic
set firewall filter rpf-special-case-dhcp term allow-dhcp then accept
set firewall filter rpf-special-case-dhcp term default then log
set firewall filter rpf-special-case-dhcp term default then reject
In Juniper devices, globally, it can be configured to match exact interface (default) or to consider feasible paths also while doing uRPF check.
set routing-options forwarding-table unicast-reverse-path active-paths
set routing-options forwarding-table unicast-reverse-path feasible-paths
Validating URPF
uRPF related validations can be done using following commands,
Cisco commands,
show cef interface Gi0/0
show ip interface Gi0/0
show ip traffic
Juniper commands,
show interfaces ge-0/0/0.0 extensive | match RPF
show firewall
URPF should be always done after proper analysis of the network. Validate all different kind of traffic and routes in the table. Implement uRPF closest to user segment and avoid to at wan where it has less effect.
Please Share your views and comments.
