-----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