3 ms·

Anyone know if the MASQUERADE support in Linux iptables is affected by this? Or how I could tell?

lathiat 2y ago
I would have assumed linux conntrack to do more rigorous "tcp window checking" as an assumption, however the article also notes they received a positive response from OpenWRT who implemented a mitigation, so I am curious to see the details of that mitigation.
- taneliv 2y ago
  As user zootboy above comments, OpenWRT removed a patch from their kernels that introduced a "no window checking" option for TCP processing,[1] which I suppose was enabled by default. [1] https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce1782eb2dea9dff9a029171 https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...
  - xxpor 2y ago
    Note that this means that conntrack's window tracking has to be perfectly in sync with both endpoints (assuming TCP invalids are dropped). Given endpoints tend to be updated more often than middleboxes, this isn't a great assumption to make.
zootboy 2y ago
Well, of the three mitigations suggested in the article: 1 - Random NAT port allocation Seems like the answer is "not by default." According to iptables(8), SNAT defaults to using the pre-translated ports whenever possible, so it's up to the connecting client (victim's TCP stack) to randomly select source ports. There is a "--to-ports" option that lets you limit the usable source ports, but it's not mentioned how the ports are selected in that case. 2 - Reverse Path Validation I'm not really sure how this helps in the described situation. If the attacker and the victim are on the same wifi access point, then both of their traffic will be sourced from the same network interface, so even strict RFC 3704 validation will pass for spoofed packets from the attacker. But for completeness, you can turn that on by setting a sysctl (rp_filter = 1). 3 - TCP window checking I _believe_ that the vanilla linux kernel does check this by default, as the mentioned adjustments to OpenWRT seem to be removing a non-standard option to disable the TCP window checking https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce1782eb2dea9dff9a029171 https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...
- aidenn0 2y ago
  For those looking for rp_filter it is net.ipv4.conf.all.rp_filter (or replace "all" with a device name to turn it on for just one device).
- fanf2 2y ago
  The attack uses packets sent from the WiFi side to the WAN IP address, which is what reverse path filtering prevents.
  - zootboy 2y ago
    Ah, yes, that's the detail I missed for why #2 is relevant. So the answer to #2 is "not by default, but easy to enable." Though other comment threads here have discussed the potential for this to impact NAT hole punching.
Joel_Mckay 2y ago
In general there are usually rules that prevent cross-forwarding traffic, and thus traffic over wifi is isolated from each client (unless you need to share a home NAS/printer this should remain enabled.) Most if not all modern routers have this feature, and also the ability to turn off the dumpster-fire that is UPnP and flaky port-trigger mods. Additionally, some add packet marking rules, which is often also used to enforce fair bandwidth sharing. Yet note this can be a nonstandard controversial gray-area. One could also use a private cert based VPN + Kerberos with firewall client pre-set rules on any un-trusted/open access points. YMMV, =3

I would have assumed linux conntrack to do more rigorous "tcp window checking" as an assumption, however the article also notes they received a positive response from OpenWRT who implemented a mitigation, so I am curious to see the details of that mitigation.

taneliv 2y ago
As user zootboy above comments, OpenWRT removed a patch from their kernels that introduced a "no window checking" option for TCP processing,[1] which I suppose was enabled by default. [1] https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce1782eb2dea9dff9a029171 https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...
- xxpor 2y ago
  Note that this means that conntrack's window tracking has to be perfectly in sync with both endpoints (assuming TCP invalids are dropped). Given endpoints tend to be updated more often than middleboxes, this isn't a great assumption to make.

zootboy 2y ago

Well, of the three mitigations suggested in the article: 1 - Random NAT port allocation Seems like the answer is "not by default." According to iptables(8), SNAT defaults to using the pre-translated ports whenever possible, so it's up to the connecting client (victim's TCP stack) to randomly select source ports. There is a "--to-ports" option that lets you limit the usable source ports, but it's not mentioned how the ports are selected in that case. 2 - Reverse Path Validation I'm not really sure how this helps in the described situation. If the attacker and the victim are on the same wifi access point, then both of their traffic will be sourced from the same network interface, so even strict RFC 3704 validation will pass for spoofed packets from the attacker. But for completeness, you can turn that on by setting a sysctl (rp_filter = 1). 3 - TCP window checking I _believe_ that the vanilla linux kernel does check this by default, as the mentioned adjustments to OpenWRT seem to be removing a non-standard option to disable the TCP window checking https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce1782eb2dea9dff9a029171 https://github.com/openwrt/openwrt/commit/75e78bcaab847557ce...

aidenn0 2y ago
For those looking for rp_filter it is net.ipv4.conf.all.rp_filter (or replace "all" with a device name to turn it on for just one device).
fanf2 2y ago
The attack uses packets sent from the WiFi side to the WAN IP address, which is what reverse path filtering prevents.
- zootboy 2y ago
  Ah, yes, that's the detail I missed for why #2 is relevant. So the answer to #2 is "not by default, but easy to enable." Though other comment threads here have discussed the potential for this to impact NAT hole punching.

Joel_Mckay 2y ago

In general there are usually rules that prevent cross-forwarding traffic, and thus traffic over wifi is isolated from each client (unless you need to share a home NAS/printer this should remain enabled.) Most if not all modern routers have this feature, and also the ability to turn off the dumpster-fire that is UPnP and flaky port-trigger mods. Additionally, some add packet marking rules, which is often also used to enforce fair bandwidth sharing. Yet note this can be a nonstandard controversial gray-area. One could also use a private cert based VPN + Kerberos with firewall client pre-set rules on any un-trusted/open access points. YMMV, =3