Page MenuHomeVyOS Platform

source-validation will be configured at different locations and could lead to massiv confusion
Open, Requires assessmentPublic

Description

hi.

after working on T2059 I had took a deeper look into it confused how source-validation is set . In the moment there are two different way's to configure source-validation:

  1. vyatta-cfg-firewall (/opt/vyatta/share/vyatta-cfg/templates/firewall/source-validation/node.def)
  2. vyatta-cfg-quagga: (/opt/vyatta/share/vyatta-cfg/templates/interfaces/*/node.tag/ip/source-validation/node.def)

In vyatta-cfg-firewall all Interfaces and the all interfacces is configured.
In vyatta-cfg-quagga it's only configured at interface level

The default behavior is unconfigured.

sysctl.txt from the kernel documentation say's:

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.

	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.

Especially:

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

looks like that the current system makes it very confused. Then there is also:

net.ipv4.conf.default.rp_filter:

conf/default/*: Change the interface-specific default settings.
conf/all/*: Change all the interface-specific settings.

I thing we should discuss how we can handle this better and more understandable for the users.

Details

Difficulty level
Unknown (require assessment)
Version
1.2.4
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Config syntax change (migratable)

Event Timeline

rherold created this task.Feb 21 2020, 9:37 AM
rherold created this object in space S1 VyOS Public.
pasik added a subscriber: pasik.Mar 30 2020, 7:10 AM
marekm added a subscriber: marekm.EditedOct 14 2020, 6:59 PM

Just my thoughts - there are situations where rp_filter is not sufficient, and it was not clear to me how to do this cleanly with the zone firewall, so I ended up hacking a few iptables commands in rc.local instead.

Consider a multihomed BGP setup, like the one I have here, where asymmetric routing is possible so rp_filter not useful. I want to filter out incoming traffic with spoofed source IP addresses that appear to come from inside my network, but actually arrive on a subset of interfaces that connect to the upstreams. Set of prefixes to match is easily configured by a few "set firewall group network-group $group network $prefix" lines which translate to an IP set, but I haven't figured out the easy VyOS CLI equivalent of:
iptables -t raw -I PREROUTING -i $iface -m set --match-set $group src -j DROP

I only care about incoming interfaces (one such rule for each upstream interface over which BGP runs), no matter where the traffic goes to (outgoing via another interface, or destined to the local router itself). I've recently learned that improving Source Address Validation on the Internet is the subject or at least two experiments mentioned below, it should be made easy to set up.

https://imaal.byu.edu
http://drakkardnsv4.com

Both seem to work in a similar way - send a DNS request with spoofed source address asking about a domain they control, and see if they get a request from a vulnerable DNS resolver.

As a side note, I was hoping ipset would support checking against a list of network interfaces (similar to MikroTik interface lists) - but that's not supported yet. That would allow a single rule to match ingress traffic from a subset of interfaces connected to upstreams (like 3 separate VLANs for 4 separate BGP sessions with the IXP I use). So, for now each iptables rule matches just one interface.