#21738: firewall: Leaking of non-NATed packets to the WAN interface
-----------------------+------------------------
Reporter: anonymous | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: packages | Version: Trunk
Keywords: |
-----------------------+------------------------
The default OpenWrt firewall rules masquerade traffic. This requires
conntracking and a valid state of connections. But it leaks un-NATed (aka.
only routed) packets to the wan interface when TCP packets not belonging
to a conntrack connection are received on the br-lan interface. Missing is
a rule like:
{{{
iptables -t filter -I delegate_forward 1 -m conntrack --ctstate INVALID -j
reject
}}}
How to reproduce:
1. connect a client to br-lan of the AP (for example via ethernet)
2. start wireshark on the client
3. run "nc google.de 80" on the client
4. wait until connection was established (look at the wireshark output)
5. stop nc process on the client via ctrl+c
6. export in wireshark (only!!!!) the FIN packet from your client to the
google server as replay_fin.pcapng
7. check that the connection is no longer in the conntrack database of the
AP
{{{
cat /proc/net/nf_conntrack|grep port=80
}}}
8. start tcpdump on the wan interface of the AP (I use in this example
192.168.1.1 as the IP of the wan interface eth1 from the standard
configuration)
{{{
tcpdump -ni eth1 "outbound and net 192.168.1.0/24"
}}}
9. start a tcpreplay on your client over the interface which connects to
the AP
{{{
while true; do tcpreplay -i eth0 replay_fin.pcapng; done
}}}
10. Look at the output of tcpdump to see the routed (but not NATed)
packets with the invalid source IP addresses. This looks something like
{{{
13:12:31.830988 IP 192.168.1.159.35949 > 92.226.2.49.80: Flags [F.],
seq 1053871330, ack 3323244445, win 229, options [nop,nop,TS val
4294941813 ecr 658853739], length 0
13:12:33.476070 IP 192.168.1.159.35949 > 92.226.2.49.80: Flags [F.],
seq 0, ack 1, win 229, options [nop,nop,TS val 4294941813 ecr 658853739],
length 0
13:12:35.012624 IP 192.168.1.159.35949 > 92.226.2.49.80: Flags [F.],
seq 0, ack 1, win 229, options [nop,nop,TS val 4294941813 ecr 658853739],
length 0
13:12:36.191517 IP 192.168.1.159.35949 > 92.226.2.49.80: Flags [F.],
seq 0, ack 1, win 229, options [nop,nop,TS val 4294941813 ecr 658853739],
length 0
}}}
You can now try the mentioned iptables rule. But please be aware that some
versions of OpenWrt have a broken patch called
617-netfilter_skip_filter_sysctl.patch which has to be deactivated first
to make this rule work:
{{{
sysctl -w net.netfilter.nf_conntrack_skip_filter=0
}}}
The behavior that packets with INVALID ctstate are just accepted and not
NATed is documented in the kernel in nf_nat_l3proto_ipv4.c nf_nat_ipv4_fn:
{{{
ct = nf_ct_get(skb, &ctinfo);
/* Can't track? It's not due to stress, or conntrack would
* have dropped it. Hence it's the user's responsibilty to
* packet filter it out, or implement conntrack/NAT for that
* protocol. 8) --RR
*/
if (!ct)
return NF_ACCEPT;
/* Don't try to NAT if this packet is not conntracked */
if (nf_ct_is_untracked(ct))
return NF_ACCEPT;
}}}
and in nf_conntrack_core.c nf_conntrack_in
{{{
ct = resolve_normal_ct(net, tmpl, skb, dataoff, pf, protonum,
l3proto, l4proto, &set_reply, &ctinfo);
if (!ct) {
/* Not valid part of a connection */
NF_CT_STAT_INC_ATOMIC(net, invalid);
ret = NF_ACCEPT;
goto out;
}
if (IS_ERR(ct)) {
/* Too stressed to deal. */
NF_CT_STAT_INC_ATOMIC(net, drop);
ret = NF_DROP;
goto out;
}
}}}
You should check the counters of this rule after a normal work day to see
that this really happens quite often even without the involvement of
tcpreplay
{{{
iptables -t filter -L delegate_forward -vnx
}}}
--
Ticket URL: <https://dev.openwrt.org/ticket/21738>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
