Differences between current version and predecessor to the previous major change of ReversePathFiltering.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| 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 @@
-(Paraphrased from
the excellent [Linux Advanced Routing
and Traffic Control HOWTO|http://www
.lartc
.org]):
+Reverse Path Filtering
(RPF) is a technology that is used on InternetProtocol routers to try and prevent source address spoofing, which is often used for DenialOfService attacks. RPF works by checking
the source IP of each packet received on an interface against the routing table. If the best route for the source IP address does not use the same interface that the packet was received on the packet is dropped. There are some situations where this feature will obviously not be the desired behaviour
and will need to be disabled
. In general if you are not multi-homed then enabling RPF on your router will not be a problem
.
-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.
+----
+!Example
+Assume
a router with
the following
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
10.4
../24, you don't expect a packet from 202
.49
.46
.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
.
+<?plugin OldStyleTable
+|Dest|Mask|Interface
+|
10.
..|255
.
.
.|eth0
+|192
.168
..|255.255..|eth1
+|default|*|eth0
+?>
-Lots
of people will want to turn this feature off
, so
the [Kernel] hackers have made it easy. There are files in /proc where you can tell the kernel to do this
for you
. 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
.
+A packet arriving at eth0 with a source IP address
of 10.10.10.2 would not be dropped
, as
the best route
for 10
.10.10.2
is out eth0
.
-If a
packet arrived on your Linux router on eth1 claiming to come from the
eth0 subnet, it
would be dropped. Similarly
, if
a packet came from the eth0 subnet, claiming to be from somewhere outside your firewall, it would be dropped also
.
+A
packet arriving at
eth0 with a source IP address of 192.168.40.2
would be dropped as the best route for 192
.168.40.2 is out eth1
, a different interface to what the
packet was received on
.
+----
-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).
+!! Controlling RPF
in Linux
-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.
+In linux RPF is controlled by
the rp_filter kernel option found in /proc/sys/net/ipv4/conf/*/rp_filter. Setting this option to 1 enables reverse path filtering
on the specified
interface, while setting it to 0 disables it
. conf/all/rp_filter must be set
to 1 for filtering to work on
any interface.
+
+See ip-sysctl.txt
in the Documentation
directory of
the kernel source for more information
-This is implemented by the "if_feature rp_filter" option in PerrysFirewallingScript.
----
-This feature also exists
on Cisco routers that support CiscoExpressForwarding.%%%
+!! Controlling RPF
on Cisco Routers
-To enable Reverse Path Forwarding
.%%%
+To use RPF your router must support CiscoExpressForwarding
.%%%
+To enable Reverse Path Forwarding.%%%
+<verbatim>
Router#
Router#configure terminal
Router(config)#int <<interface-type>> <<Interface-num>>
Router(config-if)#ip verify unicast reverse-path
Router(config-if)#end
+</verbatim>
To verify the RPF is working%%%
''Look closely at the last three lines''%%%
-
+<verbatim>
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__
+</verbatim>
+See http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7d4.html for more details.
-----
-João from Brazil writes:
+!!Configuring RPF on Juniper Routers
-Hi
-nice article, but what you wrote here:
+To enable Reverse Path Forwarding
-''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.''
+<verbatim>
+ [[edit]
+
routing-options {
-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
+ forwarding-table {
-tcp/ip is not ping
-pong, somebody sends a packet and gets an answer perhaps, but never the packet comes back
+ unicast
-reverse-path (active-paths | feasible-paths);
-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.
+ }
+</verbatim>
-I guess that makes us InNeedOfRefactor
. Aristotle, what do you know? ;)
+See http://www.juniper.net/techpubs/software/junos/junos63/swconfig63-routing/html/routing-generic-config11.html for more details
.
----
CategoryNetworking
