netdev - Re: IP-less bridge as a martian source

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r65px6wf.fsf@tac.ki.iif.hu>
Date:	Thu, 06 Nov 2008 15:31:44 +0100
From:	Ferenc Wagner <wferi@...f.hu>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: IP-less bridge as a martian source

Jarek Poplawski <jarkao2@...il.com> writes:

> On Thu, Nov 06, 2008 at 01:00:05PM +0100, Ferenc Wagner wrote:
>> Jarek Poplawski <jarkao2@...il.com> writes:
>>
>>>> wferi@...1:~$ sudo cat /proc/net/vlan/vlan891 
>>>> [...]
>>>> EGRESSS priority Mappings: 
>>>
>>> Should be corrected: maybe you will send a patch? (Otherwise let me now.)
>> 
>> I sent one.  Hope it's OK.
>
> Looks OK to me.

Still I'm afraid it would break some users' scripts... ;)

>> My question is: why does the IP-less bridge pick up any packets?
>> Does the host-based addressing model require this, if the host has
>> any IP address at all (on some other interface)?
>
> Do you mean why it's routed at all?

Yes, probably that's what I mean.  I expected such packages to stay in
the link layer (http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png)
Hmm.  In my case the only possible way out is "Bridging Decision" in
the input phase.  That surely kicks in, as these packages are destined
to ff:ff:ff:ff:ff:ff...  Confirmed: after ebtables -A INPUT -j DROP
those "martian source" warnings don't appear anymore.

Btw what is that "Processing decision" right after Qdisc Deque(ue)?  A
check whether the destination MAC is ours?  I also wonder where
tcpdump attaches its probe on that picture...

> Probably it's something about bridge configs, like BRIDGE_EBT_BROUTE
> etc. You could try to analyze net/bridge/br_input.c/br_handle_frame()
> for cases when it returns skb (instead of NULL).

Thanks, that set me on track.  Although ebtable_broute was not loaded
originally, now ebtable_filter is.

>> I didn't mean separating the ports of the bridge, but separating the
>> host running the bridge from the traffic the bridge forwards.  It
>> should be able to forward all the strangest IP or non-IP traffic of
>> the world and stay totally unaffected.
>
> Yes, I missed your point. So I think this should be configurable.

Turns out it is, sort of, by ebtables.

But the directed broadcast pings (destined to the network broadcast
address) also have full-one destination MAC, and they weren't
logged...  Even though the host didn't know about those networks
either.  So part of the mistery remains.

> Are you sure they use something else then 0.0.0.0 as a source address
> with these 255.255.255.255 packets?

Yes, as my previous log summary shows, they usually carry the actual
source address.  DHCP is different in this respect.  Also, there are
different types of WoL, some masquerade as UDP, some do not.
-- 
Regards,
Feri.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html