uRPF (anti-spoofing protection data plane)
Good afternoon, dear community.
In preparation for the SECURE exam (642-637), I would like to talk about the technology of uRPF (Unicast Reverse Path Forwarding).
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 deal with the fake IP address of the sender in the packets that come to the interfaces of the router. After all, an attacker may use an IP address that is “stolen from another network” in the sent packets, or an incorrect IP address from the ranges allocated for specific use, for example, 127.0.0.0/8.
')
When introducing integrated anti-spoofing protection, it is recommended to use:
Now in more detail about the uRPF technology. By enabling uRPF on the interface, it will automatically verify the IP address of the sender of the packet with the data from the CEF FIB. It follows that the use of CEF is mandatory. At the same time, we rely on the fact that RIB and FIB contain only correct routing information.
There are two types of uRPF: loose and strict.
If the packet arrives on the interface with the configured Loose uRPF, then a check will be made whether there is an entry in the FIB about such a network whose member is the IP address of the sender of the packet. If there is no such record, the packet will be deleted, otherwise the packet will be redirected in accordance with the FIB.
If a packet arrives on an interface with strict uRPF configured, then the sender's IP address will be checked again, and if the interface on which the packet came did not match the entry in the FIB (for example, the sender is actually behind another interface), then the packet will be deleted. Otherwise, it will be redirected according to the entry in the FIB.
Configuration example, general topology information:
First you need to make sure that CEF is turned on, or you can 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, the packet that came to Fa0 / 0 will now be it is checked if the network which owns the IP address of the sender really is in the FIB and it is really available through the interface to which the packet came, 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 the packets entering this interface can have any IP address of the sender except those networks that are accessible via FIB through other interfaces. The argument “ allow-self-ping ” allows to ping this interface from the same router. And the final argument may be the ACL number which the “permit” rules will allow to make an exception for some addresses and / or to log blocked packets.
The “ ip verify unicast source reachable-via any ” command enables the uRPF interface to have a loose mode. In this mode, any packet whose sender’s network information is in the FIB will be skipped. In this mode, the “ allow-default ” argument is not used, since it will allow forwarding any packets through the interface.
An example of logging packets blocked by uRPF using ACLs:
uRPF and asymmetric routing
Since in real topologies routes on routers are not symmetrical, that is, a specific router sending a packet to a specific network through a specific port (based on the FIB) can receive a reply packet through a completely different interface. In this situation, strict uRPF will block such packages.
This problem can be solved in two ways. Firstly, you can use loose uRPF, secondly, using the same ACL that we used for logging, you can use it to exclude checking certain IP address ranges in strict uRPF (of course, only for those ranges that include asymmetric routes).
An example of setting up uRPF notifications:
URPF notifications can be sent using snmp protocol. “ Ip verify drop-rate compute window seconds” defines the period during which the uRPF drop rate is calculated, ie only after this time period has elapsed, we will know the drop rate.
“ Ip verify drop-rate compute interval seconds” defines the time interval between the processes of calculating the uRPF drop rate.
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” specifies the threshold value of packets per second that determines when to send a notification about exceeding drop rates.
“ Snmp trap ip verify drop-rate ” —the last command forces the router to send notifications when the drop rate is exceeded via the snmp protocol and not just to the syslog subsystem.
If you want to see the statistics of dropped packets on the interface, you can use the " show ip interface iface_name" command:
I would also like to emphasize that ISR routers support both uRPF and uRPF notifications since IOS 12.4 (20) T.
In preparation for the SECURE exam (642-637), I would like to talk about the technology of uRPF (Unicast Reverse Path Forwarding).
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 deal with the fake IP address of the sender in the packets that come to the interfaces of the router. After all, an attacker may use an IP address that is “stolen from another network” in the sent packets, or an incorrect IP address from the ranges allocated for specific use, for example, 127.0.0.0/8.
')
When introducing integrated 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 routing from the source on devices using the “no ip source-route” command.
- At the access and distribution levels use ACLs that will filter spoofed packets.
- The uRPF technology is recommended for use at access and distribution levels.
Now in more detail about the uRPF technology. By enabling uRPF on the interface, it will automatically verify the IP address of the sender of the packet with the data from the CEF FIB. It follows that the use of CEF is mandatory. At the same time, we rely on the fact that RIB and FIB contain only correct routing information.
There are two types of uRPF: loose and strict.
If the packet arrives on the interface with the configured Loose uRPF, then a check will be made whether there is an entry in the FIB about such a network whose member is the IP address of the sender of the packet. If there is no such record, the packet will be deleted, otherwise the packet will be redirected in accordance with the FIB.
If a packet arrives on an interface with strict uRPF configured, then the sender's IP address will be checked again, and if the interface on which the packet came did not match the entry in the FIB (for example, the sender is actually behind another interface), then the packet will be deleted. Otherwise, it will be redirected according to the entry in the FIB.
Configuration example, general topology information:
First you need to make sure that CEF is turned on, or you can 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, the packet that came to Fa0 / 0 will now be it is checked if the network which owns the IP address of the sender really is in the FIB and it is really available through the interface to which the packet came, 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 the packets entering this interface can have any IP address of the sender except those networks that are accessible via FIB through other interfaces. The argument “ allow-self-ping ” allows to ping this interface from the same router. And the final argument may be the ACL number which the “permit” rules will allow to make an exception for some addresses and / or to log blocked packets.
The “ ip verify unicast source reachable-via any ” command enables the uRPF interface to have a loose mode. In this mode, any packet whose sender’s network information is in the FIB will be skipped. In this mode, the “ allow-default ” argument is not used, since it will allow forwarding any packets through the interface.
An example of logging packets blocked by uRPF using ACLs:
uRPF and asymmetric routing
Since in real topologies routes on routers are not symmetrical, that is, a specific router sending a packet to a specific network through a specific port (based on the FIB) can receive a reply packet through a completely different interface. In this situation, strict uRPF will block such packages.
This problem can be solved in two ways. Firstly, you can use loose uRPF, secondly, using the same ACL that we used for logging, you can use it to exclude checking certain IP address ranges in strict uRPF (of course, only for those ranges that include asymmetric routes).
An example of setting up uRPF notifications:
URPF notifications can be sent using snmp protocol. “ Ip verify drop-rate compute window seconds” defines the period during which the uRPF drop rate is calculated, ie only after this time period has elapsed, we will know the drop rate.
“ Ip verify drop-rate compute interval seconds” defines the time interval between the processes of calculating the uRPF drop rate.
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” specifies the threshold value of packets per second that determines when to send a notification about exceeding drop rates.
“ Snmp trap ip verify drop-rate ” —the last command forces the router to send notifications when the drop rate is exceeded via the snmp protocol and not just to the syslog subsystem.
If you want to see the statistics of dropped packets on the interface, you can use the " show ip interface iface_name" command:
I would also like to emphasize that ISR routers support both uRPF and uRPF notifications since IOS 12.4 (20) T.
Source: https://habr.com/ru/post/152287/
All Articles