Bug 133478 - default firewall rules break smb browsing
default firewall rules break smb browsing
Status: CLOSED DUPLICATE of bug 113918
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
high Severity medium
: ---
: ---
Assigned To: James Morris
Brian Brock
:
: 140763 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-09-24 07:04 EDT by Alexander Larsson
Modified: 2007-11-30 17:10 EST (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-23 10:17:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ip_conntrack_netbios_ns.c (1.83 KB, text/plain)
2004-10-16 05:14 EDT, Okke Timm
no flags Details
Makefile for ip_conntrack_netbios_ns.c (623 bytes, text/plain)
2004-10-16 05:15 EDT, Okke Timm
no flags Details

  None (edit)
Description Alexander Larsson 2004-09-24 07:04:58 EDT
I'm not sure what to file this against, but i'll start with
system-config-securitylevel.

The default firewall rule breaks smb browsing in gnome-vfs/nautilus.

I'm not sure what is to blame, gnome-vfs, samba, or the firewall
rules, but when you enable the firewall it breaks, and it works when
you disable it.
Comment 1 Colin Walters 2004-09-24 14:13:03 EDT
I'm not sure it's possible to make it work through the current
firewall, at least without the kernel firewall rules having very deep
knowledge about the SMB protocol.  Since I think we're keeping the
firewall on, I think we'll unfortunately have to punt this to FC4.

Dan Reed should know more about this, adding him to CC.
Comment 2 Colin Walters 2004-09-24 15:15:28 EDT
The firewall will definitely block the UDP port 137 and 139 incoming
which are necessary for passively getting service broadcasts from
other machines on the network.

Active service discovery is another question.  I'm not sure whether
the firewall state tracking understands it.
Comment 3 Bryan W Clark 2004-09-24 16:25:08 EDT
just noting this is somewhat simliar to bug 131745
Comment 4 Bill Nottingham 2004-09-24 19:15:26 EDT
Bug 58004 is the original version of this.
Comment 5 Alexander Larsson 2004-09-27 05:25:50 EDT
We can't just punt this and have a completely non-working samba UI on
the desktop. Windows interoperability was supposed to be important in
the release.
Comment 6 Alexander Larsson 2004-09-27 05:27:27 EDT
notting: Thats not really the same, is it? I read that as punching
hole for a samba server. This is about allowing the client to browse
for samba shares.
Comment 7 Alexander Larsson 2004-09-28 07:12:14 EDT
Bug 113918 seems very related though.
Comment 8 Alexander Larsson 2004-09-30 06:16:43 EDT
As i mentioned in bug 113918 i wrote a kernel module that fixes this:
http://www.redhat.com/archives/fedora-devel-list/2004-September/msg01178.html

I posted it both on upstream netfilter and fedora lists, but as yet
i've gotten no real responses about it. Hopefully upstream is
interested and we'll be able to get it into the kernel like that. But
this seems it will take some time.
Comment 9 Bryan W Clark 2004-10-08 17:14:02 EDT
Marking high priority, whatever that will do.  But this still doesn't
work by default and we really need to have this done.
Comment 10 Alexander Larsson 2004-10-11 03:18:40 EDT
Bryan: Its highly unlikely this will move at all. The kernel people
want it upstream before taking it, and upstream doesn't seem to care.
No replies to:
https://lists.netfilter.org/pipermail/netfilter-devel/2004-September/016986.html
Comment 11 Paul Nasrat 2004-10-11 04:37:07 EDT
Alex - I can put something like this in by default this round and get
a UI update later to allow selection:

-A -p udp --dport 137:139 -j ACCEPT 

Can someone confirm if that is sufficient and I'll add (and get added
to the release notes).
Comment 12 Alexander Larsson 2004-10-11 11:53:21 EDT
No. That is not sufficient.

The only stateless rule that works is to open all high port to udp
packets from port 137.
Comment 13 Alexander Larsson 2004-10-11 11:56:03 EDT
eh, that sounds confusing.
We'd need to allow udp packets from port 137 to any high port on the
local box.

The rule you posted is for running a smb server. Not for the client.

Comment 14 Bryan W Clark 2004-10-13 11:38:22 EDT
paul, did this get commited?
Comment 16 Okke Timm 2004-10-16 05:14:00 EDT
Created attachment 105322 [details]
ip_conntrack_netbios_ns.c
Comment 17 Okke Timm 2004-10-16 05:15:49 EDT
Created attachment 105323 [details]
Makefile for ip_conntrack_netbios_ns.c
Comment 18 Okke Timm 2004-10-16 05:34:02 EDT
I added the two files for convenience. Just for clarity: 
ip_conntrack_netbios_ns.c is written by Alexander Larsson. You can 
blame the Makefile to compile the module outside the kernel on me 
though. 
 
Comment 22 Alexander Larsson 2004-10-19 04:47:50 EDT
In the hope of getting some form of response i re-posted this to the
netfilter list:
https://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017159.html
Comment 23 Paul Nasrat 2004-11-11 16:48:53 EST
Looks like there was some feedback this time - Alex did you get any
take further upstream?
Comment 24 Bill 2004-11-27 22:51:43 EST
I'm new to Linux. I have Fedora Core 2 installed.  I wanted to use 
samba on my small in-house network.  I wanted to access my printer 
connected to a Windows PC from my Linux box.  (The reverse will not 
happen.)  My email is jeff12@fastpitchcentral.com .

After reading this page it seems to indicate samba doesn't work even 
on Fedora Core 3.  So I guess I'll give up at this point.  Does 
anyone know when I'll be able to even get the rpm to work, much less 
hoping for the graphical Add/Remove Programs to work on samba?

I have no idea how anyone expects Linux to fly unless it can be 
cooperative on a Windows network without requiring a $150,000 Linux 
Nerd.
Comment 25 Havoc Pennington 2004-11-28 01:01:31 EST
It will work if you run System Settings -> Security Level and 
set the firewall to disabled.
Comment 26 Ron Hawkins 2004-11-28 09:47:39 EST
I have a hack which is at least a partial solution to this problem.

 (1) disable Block broadcast traffic in Firestarter
     Preferences -> Firewall -> Advanced options
 (2) Add the following line to the file
     /etc/firestarter/user-post

$IPT -A INPUT -i $INIF -j ACCEPT

You can then browse the samba share using Konqueror smb:/

Ron Hawkins
Lansoftemail@yahoo.com.au
Comment 27 Ron Hawkins 2004-11-28 11:41:41 EST
Arghh - my apologies - I take it all back
my last post refers to a fix for Firestarter,
While you needed a fix for system-config-securitylevel

Opening these ports to the Internet is dangerous,
Just opening these ports to the internal network should work.
Comment 28 Paul Nasrat 2004-11-29 17:31:28 EST
*** Bug 140763 has been marked as a duplicate of this bug. ***
Comment 29 Alexander Larsson 2004-11-30 04:43:32 EST
pnasrat:
I think the latest version is in:
https://lists.netfilter.org/pipermail/netfilter-devel/2004-October/017261.html
It seemed to work in some tests i did. 

I haven't done any more work on this since then. It would be nice if
we could get one of our network people to look at this, such as
jmorris. He could help getting this stuff upstream which seems to be
necessary for inclusion.
Comment 30 Greg 2004-12-08 10:50:16 EST
OK. I have turned off the firewall completely. In Gnome browsing
samba/windows shares doesn't work at ALL...

KDE I can get the browsing to work, once Lisa is activated, but I like
the visual appearance of Gnome. 

What must I do to get browsing shares to work in Gnome?

Thanks,
G
Comment 31 Havoc Pennington 2004-12-08 23:59:40 EST
For questions on how to get things working, you should use a support
channel such as a mailing list (or Red Hat support if using a
purchased product). https://bugzilla.redhat.com/bugzilla/ has a note
on why this is important - in short to keep bugzilla usable for
developer task tracking.

If in the course of figuring out your problem you discover a software
bug and can characterize it in enough detail for a developer to
investigate, please file a separate bugzilla report for each such bug
with the details of your setup and configuration. If you aren't sure
how to characterize a problem, forums such as the lists can help with
that as well.
Comment 32 Greg 2004-12-09 17:19:11 EST
I have the iptables rutned off. I have the firewall turned off based
on a previous comment above. 

Gnome browsing shares on either windows or linux machines (samba
shares) does NOT work. KDE broswing (provide lisa is activated) works
but I prefer the look of Gnome (better fonts easier on the eyes)

Please advise as to how to fix this...

Thank you,
~G
Comment 33 Paul Nasrat 2004-12-09 17:30:28 EST
Greg please file a new bug for your issues - this one is specifically
aimed at dealing with transparent browsing firewall rules.
Comment 34 Danielle 2005-01-03 21:31:00 EST
Easy this one, I have used browsing samba shares in all fedora 
releases, its just a pain theres no tick boxes for these ports.

In the security level window accessed through menu system settings, 
enable firewall add the following to the enable other ports bit,

137:udp, 137:tcp, 139:udp, 139:tcp, 445:udp, 445:tcp

this allows me to browse my samba shares with the firewall enabled, 
using win98 win2k and winXP and fedora.

windoze type sharing still uses netbios over tcp and uses the above 
ports, sometimes port 138 needs to be opened too.  You should get all 
yor shares with this including the printers.

Hope this is of help 

Cheers

Danielle.

Comment 35 Oded Rimon 2005-04-22 09:14:40 EDT
But isn't this dangerous? Doesn't this open a door in your computer for hackers
to come through?

Please explain all the risks in doing this.
Thanks,
O.R.


(In reply to comment #34)
> In the security level window accessed through menu system settings, 
> enable firewall add the following to the enable other ports bit,
> 
> 137:udp, 137:tcp, 139:udp, 139:tcp, 445:udp, 445:tcp
> 
> this allows me to browse my samba shares with the firewall enabled, 
> using win98 win2k and winXP and fedora.
Comment 36 Havoc Pennington 2005-04-23 17:53:06 EDT
The more open your firewall, the more possible security issues, but also the
more useful your computer.
Comment 38 Chris Lumens 2005-06-09 10:51:13 EDT
Updated s-c-securitylevel in rawhide to include an option for enabling browsing
of Samba networks based on documentation provided by Jay Fenalson.  It's my
understanding that some work will still need to be done on the kernel for the
serving side of this bug, however.
Comment 39 Mike MacCana 2005-06-13 22:16:19 EDT
Could the release notes be chnaged to talk about enabling just those ports, just
on local interfaces, to use SMB, rather than disabling the entire firewall?
Comment 40 Alexander Larsson 2005-06-14 04:30:07 EDT
clumens: Exactly what ports did you enable to get samba browsing to work?

I ask, because the only stateless rule that could work is for all udp packets
from port 137 to any high port to go through the firewall. And this is a very
dangerous rule to add, since it essentially disables the firewall for udp.

The real solution is to get the right kernel people to review the netfilter
module I wrote and get it into the fc kernel.
Comment 41 Chris Lumens 2005-06-15 10:38:22 EDT
I only enabled ports to allow browsing Samba shares on other machines, not to
enable sharing your own stuff out through your firewall.  My modifications were
based on the following:

10:47 <hack> Page 215 of /usr/share/doc/samba-3.0.15/docs/Samba-HOWTO-collection.pdf
10:47 <hack> section 16.3.4 says
10:47 <hack> 16.3.4 Using a Firewall
10:47 <hack> Many people use a firewall to deny access to services they do not
want exposed outside their
10:47 <hack> network. This can be a good idea, although I recommend using it in
conjunction with the
10:47 <hack> above methods so you are protected even if your firewall is not
active for some reason.
10:47 <hack> If you are setting up a firewall, you need to know what TCP and UDP
ports to allow and
10:47 <hack> block. Samba uses the following:
10:47 <hack>  UDP/137 - used by nmbd
10:47 <hack>  UDP/138 - used by nmbd
10:47 <hack>  TCP/139 - used by smbd
10:47 <hack>  TCP/445 - used by smbd
10:47 <hack> The last one is important as many older firewall setups may not be
aware of it, given that
10:47 <hack> this port was only added to the protocol in recent years.
10:47 <hack> These are for incoming connections.
Comment 42 Alexander Larsson 2005-06-17 04:59:58 EDT
That is a firewall rule for the samba server. But this bug is about smb browsing.

Let me take an example. I'm using Nautilus to browse the smb neigbourhood, and
I'm not using wins or anything like that. What happens then is that nautilus
sends a broadcast udp message to port 137. To do this nautilus has to open a
socket, which then gets allocated a high port, say it gets port 14525. The
various smb machines on the network respond to this broadcast by sending a reply
from to the broadcast. This reply is an UDP packet with source port 137 and
destination port 14525. These packets will be filtered out by the firewall, even
with the firewall rules you listed above. 

Since the high port the application gets is dynamic the only way to make a
static firewall rule handle this is to allow UDP packets from port 137 to any
port. This is clearly bad.

The alternative is a statefull firewall that keeps track of the broadcast to
port 137 and allows the replies to go throught the firewall. The iptables module
I wrote does this. However, no kernel developers seem to have any interest in it.
Comment 43 Danielle 2005-07-21 23:41:12 EDT
Ok further to my post above here is an eplanation of how smb works:

If the client has NetBT enabled, it will always try to connect to the server at
both port 139 and 445 simultaneously. If there is a response from port 445, it
sends a RST to port 139, and continues it's SMB session to port 445 only. If
there is no response from port 445, it will continue it's SMB session to port
139 only, if it gets a response from there. If there is no response from either
of the ports, the session will fail completely.

If the client has NetBT disabled, it will always try to connect to the server at
port 445 only. If the server answers on port 445, the session will be
established and continue on that port. If it doesn't answer, the session will
fail completely. This is the case if the server for example runs Windows NT 4.0.

If the server has NetBT enabled, it listens on UDP ports 137, 138, and on TCP
ports 139
, 445. If it has NetBT disabled, it listens on TCP port 445 only.

Opening up these ports is a risk yes but you always have to way up the pro's and
con's.  Set any network firewall to block these ports from leaving the local
network and the information will not get out.(In reply to comment #0)
> I'm not sure what to file this against, but i'll start with
> system-config-securitylevel.
> 
> The default firewall rule breaks smb browsing in gnome-vfs/nautilus.
> 
> I'm not sure what is to blame, gnome-vfs, samba, or the firewall
> rules, but when you enable the firewall it breaks, and it works when
> you disable it.

(In reply to comment #34)
> Easy this one, I have used browsing samba shares in all fedora 
> releases, its just a pain theres no tick boxes for these ports.
> 
> In the security level window accessed through menu system settings, 
> enable firewall add the following to the enable other ports bit,
> 
> 137:udp, 137:tcp, 139:udp, 139:tcp, 445:udp, 445:tcp
> 
> this allows me to browse my samba shares with the firewall enabled, 
> using win98 win2k and winXP and fedora.
> 
> windoze type sharing still uses netbios over tcp and uses the above 
> ports, sometimes port 138 needs to be opened too.  You should get all 
> yor shares with this including the printers.
> 
> Hope this is of help 
> 
> Cheers
> 
> Danielle.
> 
> 

Comment 44 Mark McLoughlin 2005-08-23 06:17:16 EDT
There are two separate issues getting confused here:

  1) In order to allow clients to browse samba shares on a given samba
     server, you need to open certain ports in the firewall. 

     system-config-securitylevel allows you to do this. No issue here.

  2) In order for a client to be able to browse samba shares, it needs
     to be able to receive UDP packets on port 137 that are sent by
     servers in response to a broadcast query.

     This isn't something you should need to switch on explicitly, clients
     should be able to browse for Samba shares without changing any 
     configuration.

     So, Alex has written a ip_conntrack module which allows UDP packets
     on port 137 so long as they are actually in response to a query
     initiated by the client.


There's nothing to be done in system-config-securitylevel, I don't think. This
should probably be just marked as a dup of bug #113918
Comment 45 Marius Andreiana 2005-08-23 10:17:09 EDT
Agreeing with Mark, marking as duplicate. Will add bug #113918 to FC5 target, as
this is a target too.

*** This bug has been marked as a duplicate of 113918 ***
Comment 46 Mark McLoughlin 2005-09-02 05:25:01 EDT
(In reply to comment #44)

>   2) In order for a client to be able to browse samba shares, it needs
>      to be able to receive UDP packets on port 137 that are sent by
>      servers in response to a broadcast query.
> 
>      This isn't something you should need to switch on explicitly, clients
>      should be able to browse for Samba shares without changing any 
>      configuration.
> 
>      So, Alex has written a ip_conntrack module which allows UDP packets
>      on port 137 so long as they are actually in response to a query
>      initiated by the client.

I was totally wrong about this bit - the replies don't come in on UDP port 137,
but on a random high numbered port. Alex's ip_conntrack tracks outgoing packets
on UDP port 137 and allows replies to them on high numbered ports within a timeout.

So, without Alex's module, you can't get SMB browsing to work on the client just
by opening UDP 137 - you need to totally disable the firewall.
Comment 47 yhoo_gary 2005-11-17 03:52:58 EST
I have the Firewall disabled, and sharing doesn't work under FC4.  However, if 
I su to root and run smbd -D manually, it works great.  If I restart with 
service smb restart, it's broken again.  Also, if I just try to launch it 
directly (hack /etc/init.d/samba) and then exit 0 immediately.
Comment 48 Richard Chen 2005-11-17 23:17:49 EST
firewall settings does not matter for me. The command

server# smbclient //<server_ip>/<share_name> -U <user_name>

will fail if you start up samba like this:

# /etc/init.d/smb start

But it will work if you start it like this

# sh /etc/init.d/smb start

It would be nice to know why such a huge difference.

Note You need to log in before you can comment on or make changes to this bug.