Red Hat Bugzilla – Bug 113918
default iptables firewall rules don't allow Network Servers smb:/// browsing
Last modified: 2007-11-30 17:10:35 EST
Description of problem:
The default stateful iptables rules created by s-c-securitylevel are
not sufficient to allow network clients based upon broadcast or
multicast protocols to work, such as smb:/// browsing in Nautilus. As
a result, the user has a bad experience with a secure system.
The best fix for this is to enhance the kernel netfilter/iptables
conntrack module to match state on broadcast/multicast-based
protocols, to be able to allow the reply to a broadcast/multicast
query back in.
I am filing this bug on s-c-securitylevel in the mean time in hopes of
a suitable workaround that may be used until then. The URL of this
bug points to a possible workaround using -m recent.
While it is probably not possible to make a workaround for every
protocol, it is important to at least fix the SMB case for now, since
it is such a user-visible feature which is expected to just work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start system-config-securitylevel
2. Enable Firewall
3. open Network Servers or type smb:/// ito Nautilus location bar
Browsing for SMB servers breaks. An SMB query is sent to the subnet
broadcast address, replie(s) come back, but they are dropped by
iptables. iptables sends an ICMP error message back to the server(s)
Client protocols, such as SMB browsing, should continue to work on a
secure system with the firewall enabled.
See also discussion on fedora-devel-list:
notting: Any opinions here?
It would be nice to fix the kernel in such a way - it would fix
printer browsing too.
Changing component to the kernel.
What would be involved in changing the kernel to support this ?
Is it a config option, a patch from netfilter patch-o-matic, or as of
yet non-existing code ?
I wrote a conntrack module for this:
I added ip_conntrack_netbios_ns.c to kernel-2.6.8-1.541, edited
/etc/sysconfig/iptables-config to add
IPTABLES_MODULES="ip_conntrack_netbios_ns" and it appears to work fine.
This is also bug 133478
Dave: What has to be done to get this moved forward? Is this assigned
to the wrong module?
still no sign of anything in the upstream kernel. Keep prodding the
netfilter guys until they take it.
If they won't take it, I'd like to know why. If theres something
fundamentally wrong with it, then its obviously not good enough for
the Fedora kernel either.
*** Bug 133478 has been marked as a duplicate of this bug. ***
The patch and some discussion about it is here:
Some people claimed i needed to re-issue the expectation as soon as it is
confirmed by the first packet, but whenever I tested that all I got was kernel
panics, so I was unable to make any progress.
I sort of hoped that someone who has more clue about netfilter than I would take
a serious look at this, as they could probably get this fixed in an hour or so.
This is an extremely embarrasing bug that we've had a big fat "warning you need
to disable the firewall to make the desktop work" item in our release notes for
the last three releases due to this.
jmorris: What would it take to get you to take a serious look at this? It should
be really easy for you, and fixing this bug would be very very nice for the desktop.
Someone added ip_conntrack_netbios_ns.ko to 2.6.14, and it is now built in
Rawhide. All we need to do now is to make sure we load this module when the
firewall is enabled.
Remember to get rid of: http://fedoraproject.org/wiki/Docs/Beats/Samba
when this is fixed.
Please try tomorrow's system-config-securitylevel package and let me know how it
works. Clicking on the Samba box should cause the ip_conntrack_netbios_ns
module to be loaded. I may still need to go in and remove previous code that
opens a variety of Samba-related ports for running a service. Thoughts on this?
clumens: No no no. That is wrong.
The ip_conntrack_netbios_ns should always be loaded (at least by default, but
its highly unlikely you'd want to disable it unless you're doing a totally
custom firewall). It really has no security disadvantages, since it only affects
replies to broadcasts sent from your computer.
The samba checkbox is for something completely different, namely if you are
running a samba server. If you really wanted a checkbox for this it would be
called something like "Working windows share integration in the desktop".
If it should always be loaded, that seems like a bug in iptables (the package
that provides /etc/sysconfig/iptables-config) or possibly in whichever package
would provide a program for browsing Samba shares.
I'm not sure what you mean? Should nautilus and konqueror load kernel modules?
That makes no sense at all (and is not possible, as it requires root access).
I guess it could be done in the iptables package, but I think it makes more
sense to have it in the package that sets up the default firewall. Without
s-c-sl there would be no firewall set up, right? And in that case you wouldn't
need to load the module. If you manually set up the firewall you might not want
the module (for some strange reason), but if you just enable the default
firewall it is guaranteed that you want this module. (If you don't use a smb
browser it won't affect security, but if you do it actually works.)
Okay, new version to try out.
clumens: I tested todays rawhide (s-c-s 1.6.9-1) and it seems to work. I.E.
after boot "smbtree -DN" shows me the workgroup i've set up on another samba
machine on the network.
When I remove the module line in /etc/sysconfig/iptables-config and reboot the
workgroup doesn't show up. Turning on debugging (-d 10) in smbtree shows clearly
that the problem is that the broadcast doesn't get a response, and loading the
module makes it work. So, the firewall problem has been fixed! YAY!
However, something else seems to have broken the smb support in Gnome, so
clicking on the "windows network" icon doesn't work. *sigh*
Alex, the GNOME bug you refer to is bug #168908 ? I'd like to track it.
No, that one is different. I can display smb:/// , I just don't get any
workspaces in it. smb://host/ works fine though. I haven't actually filed a bug
about it, just made a note here to figure out what it is (might be some local