-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13.08.2009 01:39, Matthias Buecher / Germany wrote:
> 
> Matthias "Maddes" Bücher
> http://www.maddes.net/
> Home: Earth / Germany / Ruhr-Area
> 
> On 12.08.2009 21:13, Matthias Buecher / Germany wrote:
>> On 12.08.2009 14:56, Matthias Buecher / Germany wrote:
>>> On 12.08.2009 10:50, Ferenc Wagner wrote:
>>>> Matthias Buecher / Germany <m...@maddes.net> writes:
>>>>> When compiling a kernel prepared for all packages, then bridge
>>>>> firewalling is enabled inside the kernel.
>>>> Rather, I think you get the "problem" when you start the firewall.
>>>>> This leads to "unexpected" behaviour for newbies and normal users: they
>>>>> can not access other devices on the LAN.
>>>> Well, I'd expect a firewall to filter traffic, actually.  It's more
>>>> alarming that a couple of packets can slip through, as the Trac ticket
>>>> #5640 shows.
>>>>> Therefore disable bridge firewalling in sysctl.conf to avoid newbiw
>>>>> problems.
>>>> I'm not sure that less security by default is a good idea.  Especially
>>>> via changing a long time Linux default.  If you don't want a firewall,
>>>> why install and start it?
>>> I agree that in general "less security by default" is not a good idea,
>>> but in this special case it makes sense.
>>> * bridge firewalling is not on by default (see [1]). it just gets
>>> activated when compiling the OpenWrt kernel from trunk with all packages.
>>> * the kernel mostly is compiled from trunk with all packages (seems also
>>> true for the official snapshot), to be prepared for future uses (e.g.
>>> kmod-tun for VPN) and to be able to use the official OpenWrt package
>>> repository.
>>>   if a kernel is used that wasn't compiled with all packages, then this
>>> causes errors/crashes with several packages from the OpenWrt repository
>>> (see #5341 for OpenVPN).
>>> * bridge firewalling is an additional kernel firewall for bridges. when
>>> disabled, this doesn't mean that iptables is not working.
>>> * the typical bridge in OpenWrt is the LAN switch of a router. so it's
>>> mainly an additional security for interal threads, not external threads.
>>> * the typical default behaviour of a router/switch is: allow all LAN
>>> traffic and all outgoing WAN traffic, block all incoming WAN traffic.
> 
>>> The other "but" is the user side:
>>> * Although I have some Linux experience and work as a programmer it took
>>> me over 3 mandays to find the solution. A normal user will be totally lost.
>>> * Someone who wants "bridge firewalling" will find it within some
>>> minutes as he knows what he is looking for.
> 
>>> So in my eyes "bridge firewalling" is an extra security option for
>>> experts, that have/want to protect the LAN ports against each others.
>>> Therefore I would add these settings to the trunk, just like the already
>>> existing more "insecure" settings (e.g. "net.ipv4.ip_forward=1" for VPN).
> 
>>> About the slip-through packets:
>>> This only happens when starting the kernel, the bridge firewalling (not
>>> iptables) seems to be enabled after the network.
>>> So for some seconds some packets may not be "bridge firewalled" on startup.
> 
>>> [1] Linux bridge firewalling:
>>> http://www.linuxfoundation.org/en/Net:Bridge#Kernel_Configuration
>> Another solution would be to compile it as a separate module (BRIDGE=m).
>> Then the user can decide if he want to install it or not.
> 
> The bridge firewalling is caused by CONFIG_BRIDGE_NETFILTER=y (bool),
> which is enabled by kmod-ebtables. As it is bool it can not be
> outsourced into an installable module.
> 
> So I think my initial patch is still a good and reasonable solution.
> 

Maybe the word "disable" is misleading.

It is still enabled inside the kernel's netfilter, and can be turned on
by editing /etc/sysctl.conf
So it's not gone with my patch, it's just turned off.

Maddes

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqD2lwACgkQUXXT+9wZdbURrwCgqBzlylv9AZcv/oVhGY7x5AFG
6M0AoKqcSgVmKlvmq5zm7dPMgJxMZAia
=S1AD
-----END PGP SIGNATURE-----
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to