BCP38 on public-facing Ubuntu servers

Stephen Satchell list at satchell.net
Wed Jun 9 04:50:10 UTC 2021


On 6/8/21 2:38 PM, Fran via NANOG wrote:
> Hey,
> 
> to my knowledge there is no IPv6 equivalent for 
> net.ipv4.conf.all.rp_filter.
> 
> Therefore I use netfilter to do the RP filtering for both address families.
> 
> ip(6)tables -t raw -I PREROUTING -m rpfilter --invert -j DROP
> 
> Using the raw tables less resources are used, but you could also choose 
> other tables.
> Details abour rpfilter can be found here [1].
> 
> This can also be achieved using nftables [2].

I've been in discussions on how to filter packets with bad source 
addresses on several mailing lists, including this one.  For the last 
few weeks, I've been search for all the information I can find for how 
Linux implements rp_filter...which appears to have some holes.

Looking at /proc/sys/net/ipv6, there is no knob for rp_filter, so if 
your system is IPv6 enabled you have to use the built-in firewall.

For IPv4, I found kernel documentation, but it doesn't tell the whole 
story.  For that, I had to comb the kernel sources to find out all the 
details of rp_filter.  I've prepared a RFC letter of what I think I 
found, to be sent to the kernel developers.  Here is the text of what 
I'll be sending, with any constructive criticism I get from here:

Letter begins:

After looking at the source that appears to implement rp_filter
     linux/net/ipv4/fib_frontend.c
I believe that I now understand the tests rp_filter performs to
validate the source address when net.ipv4.conf.*.rp_filter is
set to one or two for a given interface.

Does the new paragraph I have written accurately reflect what
happens?  If so, then I find out how to submit a patch to add the
clarification to the kernel document.

Description of rp_filter from
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
--------------------------------------------------------------------
rp_filter - INTEGER
	0 - No source validation.
	1 - Strict mode as defined in RFC3704 Strict Reverse Path
	    Each incoming packet is tested against the FIB and if the
	    interface is not the best reverse path the packet check will
	    fail. By default failed packets are discarded.
	2 - Loose mode as defined in RFC3704 Loose Reverse Path
	    Each incoming packet's source address is also tested against
	    the FIB and if the source address is not reachable via any
	    interface the packet check will fail.

	[*new text here]
	
	Current recommended practice in RFC3704 is to enable strict mode
	to prevent IP spoofing from DDos attacks. If using asymmetric
	routing or other complicated routing, then loose mode is
	recommended.

	The max value from conf/{all,interface}/rp_filter is used
	when doing source validation on the {interface}.

	Default value is 0. Note that some distributions enable it
	in startup scripts.
--------------------------------------------------------------------

Recommended addition where marked with "[*new text here]":
     rp_filter will examine the source address of an incoming IP
     packet by performing an FIB lookup.  In loose mode (value 2),
     the packet is rejected if the source address is neither
     UNICAST nor LOCAL nor IPSEC.  For strict mode (value 1) the
     interface indicated by the FIB entry must also match the
     interface on which the packet arrived.


More information about the NANOG mailing list