September 26, 2012 at 12:16uRPF (anti-spoofing protection of data plane)
Good afternoon, respected community.
In preparation for the SECURE exam (642-637), I would like to talk about uRPF (Unicast Reverse Path Forwarding) technology.
This technology is an antispoofing tool at the third level of the OSI model, and is used as one of the technologies for protecting the data plane. More precisely, it allows you to combat the falsification of the IP address of the sender in packets that come to the router interfaces. After all, an attacker can use the IP address stolen from another network in the sent packets, or an incorrect IP address from the ranges allotted for specific use, for example 127.0.0.0/8.
When implementing comprehensive anti-spoofing protection, it is recommended to use:
Now more about uRPF technology. By enabling uRPF on the interface, it will automatically check the IP address of the packet sender with the data from the CEF FIB. It follows that the use of CEF is mandatory. In this case, we rely on the fact that the RIB and, accordingly, the FIB contain only the correct routing information.
There are two types of uRPF: loose and strict.
If a packet arrives at the interface with Loose uRPF configured, then it will check if there is an entry in the FIB about such a network, of which the sender's IP address is a member. If there is no such record, the packet will be deleted, otherwise the packet will be redirected in accordance with the FIB.
If the packet arrives at the interface with configured strict uRPF, then the sender's IP address will be checked again, and if the interface to which the packet arrived does not match the entry in the FIB (for example, such a sender is behind another interface), the packet will be deleted. Otherwise, it will be redirected according to the entry in the FIB.
Configuration example, general information about the topology:
First you need to make sure that CEF is enabled, or enable it using the ip cef command .
Primary configuration:
“ ip verify unicast source reachable-via rx allow-default allow-self-ping ”, the main part of the command “ ip verify unicast source reachable-via rx"Includes strict uRPF on the routed port, that is, now the packet arriving at Fa0 / 0 will be checked, if the network that owns the sender's IP address really is in the FIB and it is really accessible through the interface to which the packet arrived, then it will be redirected, otherwise it will be deleted. The allow-default argument specifies that a default route is available through this interface. This means that packets entering this interface can have any sender IP address except for those networks that are accessible via FIB through other interfaces. Allow-self-ping argument"Allows ping this interface from the same router. And the last argument may be the ACL number which allows the “permit” rules to make an exception for some addresses and / or log blocked packets.
The “ ip verify unicast source reachable-via any ” command enables loose mode on the uRPF interface. In this mode, any packet whose sender network information is in the FIB will be skipped. In this mode, the argument “ allow-default ” is not used, since it will allow forwarding of any packets through the interface.
Example of logging packets blocked by uRPF technology using ACLs:
uRPF and asymmetric routing
Since in real topologies the routes on the routers are not symmetrical, that is, a specific router, sending a packet to a specific network through a specific port (based on FIB), can receive a response packet through a completely different interface. In this situation, strict uRPF will block such packets.
There are two ways to solve this problem. Firstly, you can use loose uRPF, and secondly, using the same ACL that we used for logging, you can use it to exclude checking certain ranges of IP addresses in strict uRPF (of course, only for those ranges that include asymmetric routes).
Example of setting up uRPF notifications: uRPF notifications
can be sent via snmp protocol. " Ip verify drop-rate compute windowseconds ”determines the period during which the uRPF drop rate is calculated, that is, only after this period of time we will know the drop rate.
“ Ip verify drop-rate compute interval seconds” defines the time interval between the uRPF drop rate calculation processes.
The " ip verify drop-rate notify hold-down seconds" command determines the minimum time between sending uRPF drop rate notifications.
" Ip verify unicast notification threshold packets-per-second" defines the threshold value of packets per second which determines when to send a notification about exceeding drop rate.
" Snmp trap ip verify drop-rate"- the last command forces the router to send notifications when the drop rate is exceeded by snmp protocol and not only to the syslog subsystem.
If you want to see the statistics of dropped packets on an interface, you can use the show ip interface iface_name command: I
also want to emphasize that ISR routers support both uRPF and uRPF notifications starting with IOS 12.4 (20) T.
In preparation for the SECURE exam (642-637), I would like to talk about uRPF (Unicast Reverse Path Forwarding) technology.
This technology is an antispoofing tool at the third level of the OSI model, and is used as one of the technologies for protecting the data plane. More precisely, it allows you to combat the falsification of the IP address of the sender in packets that come to the router interfaces. After all, an attacker can use the IP address stolen from another network in the sent packets, or an incorrect IP address from the ranges allotted for specific use, for example 127.0.0.0/8.
When implementing comprehensive anti-spoofing protection, it is recommended to use:
- IP Source Guard - this technology allows sending packets only from the IP address that was issued to the device connected to the switch port via DHCP.
- It is also recommended to disable the ability to route from the source on devices using the “no ip source-route” command
- At access and distribution levels, use ACLs that will filter spoofed packets.
- URPF is recommended for use at access and distribution levels.
Now more about uRPF technology. By enabling uRPF on the interface, it will automatically check the IP address of the packet sender with the data from the CEF FIB. It follows that the use of CEF is mandatory. In this case, we rely on the fact that the RIB and, accordingly, the FIB contain only the correct routing information.
There are two types of uRPF: loose and strict.
If a packet arrives at the interface with Loose uRPF configured, then it will check if there is an entry in the FIB about such a network, of which the sender's IP address is a member. If there is no such record, the packet will be deleted, otherwise the packet will be redirected in accordance with the FIB.
If the packet arrives at the interface with configured strict uRPF, then the sender's IP address will be checked again, and if the interface to which the packet arrived does not match the entry in the FIB (for example, such a sender is behind another interface), the packet will be deleted. Otherwise, it will be redirected according to the entry in the FIB.
Configuration example, general information about the topology:
First you need to make sure that CEF is enabled, or enable it using the ip cef command .
Primary configuration:
“ ip verify unicast source reachable-via rx allow-default allow-self-ping ”, the main part of the command “ ip verify unicast source reachable-via rx"Includes strict uRPF on the routed port, that is, now the packet arriving at Fa0 / 0 will be checked, if the network that owns the sender's IP address really is in the FIB and it is really accessible through the interface to which the packet arrived, then it will be redirected, otherwise it will be deleted. The allow-default argument specifies that a default route is available through this interface. This means that packets entering this interface can have any sender IP address except for those networks that are accessible via FIB through other interfaces. Allow-self-ping argument"Allows ping this interface from the same router. And the last argument may be the ACL number which allows the “permit” rules to make an exception for some addresses and / or log blocked packets.
The “ ip verify unicast source reachable-via any ” command enables loose mode on the uRPF interface. In this mode, any packet whose sender network information is in the FIB will be skipped. In this mode, the argument “ allow-default ” is not used, since it will allow forwarding of any packets through the interface.
Example of logging packets blocked by uRPF technology using ACLs:
uRPF and asymmetric routing
Since in real topologies the routes on the routers are not symmetrical, that is, a specific router, sending a packet to a specific network through a specific port (based on FIB), can receive a response packet through a completely different interface. In this situation, strict uRPF will block such packets.
There are two ways to solve this problem. Firstly, you can use loose uRPF, and secondly, using the same ACL that we used for logging, you can use it to exclude checking certain ranges of IP addresses in strict uRPF (of course, only for those ranges that include asymmetric routes).
Example of setting up uRPF notifications: uRPF notifications
can be sent via snmp protocol. " Ip verify drop-rate compute windowseconds ”determines the period during which the uRPF drop rate is calculated, that is, only after this period of time we will know the drop rate.
“ Ip verify drop-rate compute interval seconds” defines the time interval between the uRPF drop rate calculation processes.
The " ip verify drop-rate notify hold-down seconds" command determines the minimum time between sending uRPF drop rate notifications.
" Ip verify unicast notification threshold packets-per-second" defines the threshold value of packets per second which determines when to send a notification about exceeding drop rate.
" Snmp trap ip verify drop-rate"- the last command forces the router to send notifications when the drop rate is exceeded by snmp protocol and not only to the syslog subsystem.
If you want to see the statistics of dropped packets on an interface, you can use the show ip interface iface_name command: I
also want to emphasize that ISR routers support both uRPF and uRPF notifications starting with IOS 12.4 (20) T.