|Newer page:||version 9||Last edited on Wednesday, February 28, 2007 5:45:39 pm||by GerwinVanDeSteeg|
|Older page:||version 6||Last edited on Tuesday, June 1, 2004 9:52:03 pm||by CraigBox||Revert|
@@ -1,33 +1,45 @@
the excellent [Linux Advanced Routing
and Traffic Control HOWTO|http://www
+ ( the and . .
Reverse patch filtering (often abbreviated rp_filter) is
a feature in the [Linux] networking system that checks incoming packets against
the routing table , and if the source of a packet (the destination for it's reply) would not go out the interface that the packet came in on, it will be dropped.
+ a the routing table
By default, a router routes everything - even packets which 'obviously' don't belong on your network. For example, if you have an internal interface of
.. /24, you don't expect a packet from 202
. 2 to come in on that interface
. If it did, your reply would be routed out your default gateway, and it could well be the beginnings of a networking exploit
+ 10. .. . . .
+ . .
of people will want to turn this feature off
the [Kernel] hackers have made it easy. There are files in /proc where you can tell the kernel to do this
. The method
is called "Reverse Path Filtering". Basically, if the reply to this packet wouldn't go
out the interface this packet came in, then this is a bogus packet and should be ignored
+ of , the for . is out .
packet arrived on your Linux router on eth1 claiming to come from the
eth0 subnet, it
would be dropped. Similarly
a packet came from the eth0 subnet, claiming to be from somewhere outside your firewall, it would be dropped also
+ packet eth0 would be dropped . , a packet .
The above is full reverse path filtering. The default is to only filter based on IPs that are on directly connected networks. This is because the full filtering breaks
in the case of asymmetric routing (where packets come in one way and go out another, like satellite traffic, or if you have dynamic (bgp, ospf, rip) routes in your network. The data comes down through the satellite dish and replies go back through normal land-lines).
If this exception applies to you (and you'll probably know if it does) you can simply turn off
the rp_filter on the interface where the satellite data comes in
. If you want
to see if
any packets are being dropped, the log_martians file
in the same
directory will tell
the kernel to log them to your syslog.
+ the rp_filter on the interface . to any
+ in the directory the kernel
This is implemented by the "if_feature rp_filter" option in PerrysFirewallingScript.
This feature also exists
on Cisco routers that support CiscoExpressForwarding.%%%
+ on Cisco
enable Reverse Path Forwarding
Router(config)#int <<interface-type>> <<Interface-num>>
Router(config-if)#ip verify unicast reverse-path
To verify the RPF is working%%%
''Look closely at the last three lines''%%%
Router#show ip interface
<<Interface-type>> <<interface-num>> is up, line protocol is up
Internet address is xxx.xxx.xxx.xxx/xx
Broadcast address is xxx.xxx.xxx.xxx
@@ -36,26 +48,30 @@
BGP Policy Mapping is disabled
__IP verify source reachable-via RX, allow default__
__4 verification drops__
__0 suppressed verification drops__
João from Brazil writes:
nice article, but what you wrote here:
''Reverse patch filtering (often abbreviated rp_filter) is a feature in the Linux networking system that checks incoming packets against the
routing table, and if the source of a packet (the destination for it's reply) would not go out the interface that the packet came in on, it will be dropped.''
is not entirely correct. Important is that in tcp/ip a packet does not come in and then goes out ... it may go through a firewall but this is not touched by rpf
tcp/ip is not ping
- pong, somebody sends a packet and gets an answer perhaps, but never the packet comes back
in fact rpf do only check if the origin of the packet is routable from this interface and if not it discard it, so it handles mostly issues with faked IPs in fact
rpf do not know who asked for this packet, means it do not care who send the initial requisition, this would be handled by dynamic fw rules.
I guess that makes us InNeedOfRefactor
. Aristotle, what do you know? ;)