Re: [PATCH nf] netfilter REJECT: Fix destination MAC in RST packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 9 Mar 2021, Pablo Neira Ayuso wrote:
On Mon, Mar 08, 2021 at 09:21:20AM -0700, Marc Aurèle La France wrote:
On Mon, 8 Mar 2021, Pablo Neira Ayuso wrote:
On Sun, Mar 07, 2021 at 06:16:34PM -0700, Marc Aurèle La France wrote:

In the non-bridge case, the REJECT target code assumes the REJECTed
packets were originally emitted by the local host, but that's not
necessarily true when the local host is the default route of a subnet
it is on, resulting in RST packets being sent out with an incorrect
destination MAC.  Address this by refactoring the handling of bridged
packets which deals with a similar issue.  Modulo patch fuzz, the
following applies to v5 and later kernels.

The code this patch updates is related to BRIDGE_NETFILTER. Your patch
description refers to the non-bridge case. What are you trying to
achieve?

Via DHCP, my subnet's default route is a Linux system so that it can monitor
all outbound traffic.  By doing so, for example, I have determined that my
Android phone connects to Facebook despite the fact that I have no such app
installed.  I want to know, and control, what other behind-the-scenes
(under-handed) traffic devices on my subnet generate.

dev_queue_xmit() path should not be exercised from the prerouting
chain, packets generated from the IP later must follow the
ip_local_out() path.

Well, I can tell you dev_queue_xmit() does in fact work in prerouting
chains, as it must for the bridging case.  The only potential problem I've
found so far is that the RST packet doesn't go through any netfilter hooks.

That's the issue, Netfilter rejects code from the IP layer, so the
packets follows the ip_local_out() path.

... which sets an incorrect destination MAC. Also, in this case, netfilter doesn't reject any such thing. It doesn't even "see" the RST packet dev_queue_xmit() sends out. That's OK as there is no further need to process such a packet. At least, the device whose connection request is being denied doesn't hang anymore...

You could use ingress to reject through dev_queue_xmit() / neigh_xmit().

I'm sticking to my guns. I'm a firm believer in the KISS principle, part of a dying breed to be sure.

Marc.

[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux