Samba and Firestarter - the real story

dsmalley

Hi,

I've noticed several posts on the forums dealing with Samba problems when the Firestarter firewall is installed on an Ubuntu system. After playing with it for half a day, I think I know why. First, some basics:

Assume two or more PC's on a small network, behind a NAT router. At least one of them is running Ubuntu, the other one can be either another Ubuntu PC, or a Windows box. Both machines get their IP's dynamically using the DHCP service of the router.

In order resolve each other's hostnames on the local LAN, the Ubuntu machine(s) must be running winbind. This allows an Ubuntu system to send and receive netbios broadcasts for name resolution. The coreography of this transaction works like so:

The requesting machine sends a netbios broadcast from a pseudo-random port above 32767 to port 445. All other machines on the local LAN receive this broadcast, which is looking for hostame "whatever". The machine with hostname "whatever" (if it exists), responds to the requesting machine on the pseudo-random port used in the broadcast, sending its IP, and the requesting machine then has the IP for the requested name. This transaction works fine with an Ubuntu machine on either end assuming it is running the samba and windbind daemons, without Firestarter active.

When Firestarter is activated (which is really just a front-end for iptables), all ports are blocked, so this stops working. The first step to make it work again is to create an inbound rule for the Samba service which opens ports 137, 138, 139, and 445 for TCP and UDP packets. It is reasonable to specify the rule as applying all IP's on the local LAN, which would look something like this: 192.168.1.0/24. This means any machine with an IP having 192.168.1 as the first three numbers is allowed to access these ports; depnding on the configuration of the NAT/DHCP router, these numbers might be different. You do this rather than specifying full IP's, because they may change, since they're being assigned by the router's DHCP server. So far so good.

It turns out that the Ubuntu machine(s) will still have a problem, because the netbios broadcast requests from other machines will be blocked by default. You can unblock them by going to Preferences->Advanced Options, and unchecking "Block broadcasts from external network". But there will still be a problem:

When the Ubuntu machine(s) request a hostname, they will send the broadcast, the machine with the hostname (either a Windows or Ubuntu system) will respond on the pseudo-random port the requester used, and its response will be blocked as an unauthorized connection attempt on that port. This blocking can be seen in the Events tab of the Firestarter GUI, if it is running.

THIS SHOULD NOT HAPPEN. Why? Because iptables is what is called a "stateful" firewall. It has a rule which says that any packet on any port which is received as a response to an outgoing request will be accepted. This happens all the time when you use the internet. When you connect to a web site, the connection is actually from some port on your machine like 38000, to port 80 on the web site's server. The server sends your response on that port, not port 80. iptables allows this connection without an explicit rule for the port 38000 (for example), because it is recognized as a response to your original request.

So the problem here is that the response to the naming request is being dropped. You can't really fix this by adding explicit port rules, because the port number will change over time. If you use nmblookup now, you may see the blocked response in the Events tab as port 32768. You can add a rule for this port, but then 10 minutes later, you'll find the blocked response is now on port 32783. You could open all ports to the local LAN for ports above 32768, but at that point, you might as well forget about filtering by service (i.e., Samba) and use the "Allow connections from host" rules, and open all ports to all machines on the local LAN. This might not be such a problem, but it could be. For example, I run a development web server on my workstation, and I really don't want it accessed from any other machine, even those on my LAN. Of course, you can configure apache (the web server) to reject connections from anything other than localhost, but that is really a job better handled by the firewall.

So, I am not an iptables guru. I am wondering if it is possible to make iptables recognize requests/responses for netbios naming broadcasts? If not, can Samba be configured to use a specific port for the broadcast, which can then be opened explicitly for the response? And depending on what can be done at this low-level, is it then possible to make Firestarter add this as part of the Samba service? I don't seem to remember this problem with Samba on other distros, but it's been awhile since I used anything other than Ubuntu, so maybe they have this issue too, and I just don't remember it.

I should mention this is only a problem if you're trying to use hostnames for dynamically assigned IP's. Just adding the Samba service works fine if you want to access shares with raw IP addresses. But that's not very convenient when they are assigned with DHCP.

Dave

dsmalley

Answered my own question.

In /etc/firestarter/inbound/setup, there are two lines which look like this:

Code:

# Allow response traffic
$IPT -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

These set up the general rule for allowing responses to be forwarded. Changing them to:

Code:

# Allow response traffic
$IPT -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INBOUND -p udp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

(adding state NEW for udp) lets through the response to a netbios name request broadcast. The status NEW is required, because for a broadcast, no connection is established (a broadcast does not go to any specific machine, nor does it require a response in order to "succeed" (at the IP level). It does, however, mean it is a response to an outgoung request. It is not the same as state INVALID, which would correspond to an "unsolicited" incoming packet, which would effectively mean anything goes.

So, I can now have netbios name resolution while still using service based rules in Firestarter. Linux is wonderful, you know.

Dave

cuz

Hi,

I'm totally new to Linux (after a couple of failed Gentoo installation efforts). Over the last couple of days I've been making active use of this forum to configure Samba and Firestarter and to get them to play together. I was tearing my hair out and about to accept less than best. But this post, Dave, was the solution. It was clear and explicit about why the change should be made. And best of all, it worked! (My clue as to why something like this must be the case was that in the Events tab of Firestarter, each attempt to survey the surrounding Windows network would generate several sun-rpc portmap connections blocked in random ports above 32000.

So I registered to say, "Thanks for letting me move forward with my life," and to add (for other complete newbies) that the permissions for the /etc/firestarter/inbound folder and the setup file must be changed to writable before editing (and then, of course, changed back).

Thanks again (and thanks to all the efforts of other I've used to begin my now inevitable shift away from Windows).

cuz

dsmalley

Hi cuz,

Glad it helped you out. Since nobody responded to this post, I started wondering if my system(s) were somehow possessed and I was the only one having this problem

Actually, I have changed my inbound/setup file slightly from what I indicated above. I left the first two lines as installed and instead added a third one below it:

Code:

# Allow response traffic
$IPT -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow response to netbios name broadcasts from the local network.
$IPT -A INBOUND -s $NET -p udp -m state --state NEW -j ACCEPT

"$NET" is defined in the script which calls this one as the local subnet (your IP with a mask of 255.255.255.0), so this only allows NEW connections from machines on the same subnet, which is usually the case for small LAN's behind a NAT router.

Incidentally, I've found that even with these changes, Nautilus is quite unreliable for browsing a Windows network. What is so frustrating about it is it works (or fails) intermittently. However, I've found that whenever it fails (indicating the workgroup is empty, or that some share is inaccessible), I can ALWAYS get the correct behaviour from findsmb (list machines and workgroups), smbtree (list shared resources), smbclient (connect and access files), or smbmount (mount a samba folder in the local filesystem) from the command line. For that matter, doing CTRL-L in Nautilus and manually entering the smb path usually works too, but that implies you already know the resource you want.

Dave

cuz

Thanks for the update.

For what it is, I haven't experienced any unreliability. Slower response than Konqueror, yes, but unreliability, no. Based on another post (somewhere), I changed my smb.conf file's [global] section to include 'os level = 10' so that my XP machine, which is still the center of the network and has a default os level of 16 would win the election for browse master. Perhaps that could be contributing? I can't really say since I've made many changes along the way, but my feeling is that the connections were more unreliable prior to that change.

Best,
cuz

dsmalley

I forgot to mention one other useful thing: when winbind is installed, it's always nice to add "wins" to the hosts: line in /etc/nsswitch.conf.

Code:

hosts:          files dns mdns wins

This will allow ordinary TCP/IP programs to resolve hostnames with netbios, so you can, for instance, do "ping <hostname>" instead of "ping 192.168.1.xxx". Of course, ping isn't all that wonderful, but it's a lot easer to do "ftp hostname" or "ssh hostname" or browse to "http://hostname" than using raw IP's for the local machines (assuming of course they are running the given service and the forewall on the target machine allows access to the right ports).

Dave

gwi · 05:24 AM

And what if I have a Linux host in a LAN with Internet connection (interface eth0, subnet 192.168.11), running VMWare server with virtual host-only network (interface vmnet1, subnet 192.168.25)?

I want Samba shares to be reachable from the VMWare machines on the host-only network, but not from the LAN (with its Internet connection).

I added Samba (SMB) with ports 137-139 445 and IP 192.168.25.0/24 to the allowed services for incoming traffic. But I still can't access the share from the VMWare machines (which run Windows 2000 and XP). When I disable the firewall, I can access the share.

(I am a total iptables newbee

)

akudewan

dsmalley: Wow. I can't thank you enough. Samba is working just fine, and I can browse the machines on my network with ease (using konqueror).

This thread deserves to be pinned/sticky. You should really post this as a Howto in the Howto forum. I'm sure it will help lots of people

B7may

I have the same problem and changed the setup file the same. Now from the machine that has firestarter installed, I can access my main network. (In other words, I have a larger network and connected to that is the machine with Firestarter that controls a smaller network.) But any machine that is connected to the network controlled by firestarter cannot get to the main network. I am lost as to what i should do. Any ideas?

scrooge_74

Quote:

Originally Posted by akudewan

dsmalley: Wow. I can't thank you enough. Samba is working just fine, and I can browse the machines on my network with ease (using konqueror).

This thread deserves to be pinned/sticky. You should really post this as a Howto in the Howto forum. I'm sure it will help lots of people

NOW I CAN HAVE MY LIVE BACK!!! This really needs to be pinned, lots of people with the same problem.

June 6th, 2006	#1
dsmalley 5 Cups of Ubuntu Join Date: Apr 2006 Beans: 8	Samba and Firestarter - the real story Hi, I've noticed several posts on the forums dealing with Samba problems when the Firestarter firewall is installed on an Ubuntu system. After playing with it for half a day, I think I know why. First, some basics: Assume two or more PC's on a small network, behind a NAT router. At least one of them is running Ubuntu, the other one can be either another Ubuntu PC, or a Windows box. Both machines get their IP's dynamically using the DHCP service of the router. In order resolve each other's hostnames on the local LAN, the Ubuntu machine(s) must be running winbind. This allows an Ubuntu system to send and receive netbios broadcasts for name resolution. The coreography of this transaction works like so: The requesting machine sends a netbios broadcast from a pseudo-random port above 32767 to port 445. All other machines on the local LAN receive this broadcast, which is looking for hostame "whatever". The machine with hostname "whatever" (if it exists), responds to the requesting machine on the pseudo-random port used in the broadcast, sending its IP, and the requesting machine then has the IP for the requested name. This transaction works fine with an Ubuntu machine on either end assuming it is running the samba and windbind daemons, without Firestarter active. When Firestarter is activated (which is really just a front-end for iptables), all ports are blocked, so this stops working. The first step to make it work again is to create an inbound rule for the Samba service which opens ports 137, 138, 139, and 445 for TCP and UDP packets. It is reasonable to specify the rule as applying all IP's on the local LAN, which would look something like this: 192.168.1.0/24. This means any machine with an IP having 192.168.1 as the first three numbers is allowed to access these ports; depnding on the configuration of the NAT/DHCP router, these numbers might be different. You do this rather than specifying full IP's, because they may change, since they're being assigned by the router's DHCP server. So far so good. It turns out that the Ubuntu machine(s) will still have a problem, because the netbios broadcast requests from other machines will be blocked by default. You can unblock them by going to Preferences->Advanced Options, and unchecking "Block broadcasts from external network". But there will still be a problem: When the Ubuntu machine(s) request a hostname, they will send the broadcast, the machine with the hostname (either a Windows or Ubuntu system) will respond on the pseudo-random port the requester used, and its response will be blocked as an unauthorized connection attempt on that port. This blocking can be seen in the Events tab of the Firestarter GUI, if it is running. THIS SHOULD NOT HAPPEN. Why? Because iptables is what is called a "stateful" firewall. It has a rule which says that any packet on any port which is received as a response to an outgoing request will be accepted. This happens all the time when you use the internet. When you connect to a web site, the connection is actually from some port on your machine like 38000, to port 80 on the web site's server. The server sends your response on that port, not port 80. iptables allows this connection without an explicit rule for the port 38000 (for example), because it is recognized as a response to your original request. So the problem here is that the response to the naming request is being dropped. You can't really fix this by adding explicit port rules, because the port number will change over time. If you use nmblookup now, you may see the blocked response in the Events tab as port 32768. You can add a rule for this port, but then 10 minutes later, you'll find the blocked response is now on port 32783. You could open all ports to the local LAN for ports above 32768, but at that point, you might as well forget about filtering by service (i.e., Samba) and use the "Allow connections from host" rules, and open all ports to all machines on the local LAN. This might not be such a problem, but it could be. For example, I run a development web server on my workstation, and I really don't want it accessed from any other machine, even those on my LAN. Of course, you can configure apache (the web server) to reject connections from anything other than localhost, but that is really a job better handled by the firewall. So, I am not an iptables guru. I am wondering if it is possible to make iptables recognize requests/responses for netbios naming broadcasts? If not, can Samba be configured to use a specific port for the broadcast, which can then be opened explicitly for the response? And depending on what can be done at this low-level, is it then possible to make Firestarter add this as part of the Samba service? I don't seem to remember this problem with Samba on other distros, but it's been awhile since I used anything other than Ubuntu, so maybe they have this issue too, and I just don't remember it. I should mention this is only a problem if you're trying to use hostnames for dynamically assigned IP's. Just adding the Samba service works fine if you want to access shares with raw IP addresses. But that's not very convenient when they are assigned with DHCP. Dave

June 6th, 2006	#2
dsmalley 5 Cups of Ubuntu Join Date: Apr 2006 Beans: 8	Re: Samba and Firestarter - the real story Answered my own question. In /etc/firestarter/inbound/setup, there are two lines which look like this: Code: # Allow response traffic $IPT -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A INBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT These set up the general rule for allowing responses to be forwarded. Changing them to: Code: # Allow response traffic $IPT -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A INBOUND -p udp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT (adding state NEW for udp) lets through the response to a netbios name request broadcast. The status NEW is required, because for a broadcast, no connection is established (a broadcast does not go to any specific machine, nor does it require a response in order to "succeed" (at the IP level). It does, however, mean it is a response to an outgoung request. It is not the same as state INVALID, which would correspond to an "unsolicited" incoming packet, which would effectively mean anything goes. So, I can now have netbios name resolution while still using service based rules in Firestarter. Linux is wonderful, you know. Dave

June 7th, 2006	#3
cuz First Cup of Ubuntu Join Date: Jun 2006 Beans: 10 Kubuntu 6.06	Re: Samba and Firestarter - the real story Hi, I'm totally new to Linux (after a couple of failed Gentoo installation efforts). Over the last couple of days I've been making active use of this forum to configure Samba and Firestarter and to get them to play together. I was tearing my hair out and about to accept less than best. But this post, Dave, was the solution. It was clear and explicit about why the change should be made. And best of all, it worked! (My clue as to why something like this must be the case was that in the Events tab of Firestarter, each attempt to survey the surrounding Windows network would generate several sun-rpc portmap connections blocked in random ports above 32000. So I registered to say, "Thanks for letting me move forward with my life," and to add (for other complete newbies) that the permissions for the /etc/firestarter/inbound folder and the setup file must be changed to writable before editing (and then, of course, changed back). Thanks again (and thanks to all the efforts of other I've used to begin my now inevitable shift away from Windows). cuz

June 8th, 2006	#4
dsmalley 5 Cups of Ubuntu Join Date: Apr 2006 Beans: 8	Re: Samba and Firestarter - the real story Hi cuz, Glad it helped you out. Since nobody responded to this post, I started wondering if my system(s) were somehow possessed and I was the only one having this problem Actually, I have changed my inbound/setup file slightly from what I indicated above. I left the first two lines as installed and instead added a third one below it: Code: # Allow response traffic $IPT -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A INBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT # Allow response to netbios name broadcasts from the local network. $IPT -A INBOUND -s $NET -p udp -m state --state NEW -j ACCEPT "$NET" is defined in the script which calls this one as the local subnet (your IP with a mask of 255.255.255.0), so this only allows NEW connections from machines on the same subnet, which is usually the case for small LAN's behind a NAT router. Incidentally, I've found that even with these changes, Nautilus is quite unreliable for browsing a Windows network. What is so frustrating about it is it works (or fails) intermittently. However, I've found that whenever it fails (indicating the workgroup is empty, or that some share is inaccessible), I can ALWAYS get the correct behaviour from findsmb (list machines and workgroups), smbtree (list shared resources), smbclient (connect and access files), or smbmount (mount a samba folder in the local filesystem) from the command line. For that matter, doing CTRL-L in Nautilus and manually entering the smb path usually works too, but that implies you already know the resource you want. Dave

June 9th, 2006	#5
cuz First Cup of Ubuntu Join Date: Jun 2006 Beans: 10 Kubuntu 6.06	Re: Samba and Firestarter - the real story Thanks for the update. For what it is, I haven't experienced any unreliability. Slower response than Konqueror, yes, but unreliability, no. Based on another post (somewhere), I changed my smb.conf file's [global] section to include 'os level = 10' so that my XP machine, which is still the center of the network and has a default os level of 16 would win the election for browse master. Perhaps that could be contributing? I can't really say since I've made many changes along the way, but my feeling is that the connections were more unreliable prior to that change. Best, cuz

June 10th, 2006	#6
dsmalley 5 Cups of Ubuntu Join Date: Apr 2006 Beans: 8	Re: Samba and Firestarter - the real story I forgot to mention one other useful thing: when winbind is installed, it's always nice to add "wins" to the hosts: line in /etc/nsswitch.conf. Code: hosts: files dns mdns wins This will allow ordinary TCP/IP programs to resolve hostnames with netbios, so you can, for instance, do "ping <hostname>" instead of "ping 192.168.1.xxx". Of course, ping isn't all that wonderful, but it's a lot easer to do "ftp hostname" or "ssh hostname" or browse to "http://hostname" than using raw IP's for the local machines (assuming of course they are running the given service and the forewall on the target machine allows access to the right ports). Dave

June 20th, 2006	#7
gwi A Carafe of Ubuntu Join Date: Feb 2006 Location: EU Beans: 104 Ubuntu 9.10 Karmic Koala	Re: Samba and Firestarter - the real story And what if I have a Linux host in a LAN with Internet connection (interface eth0, subnet 192.168.11), running VMWare server with virtual host-only network (interface vmnet1, subnet 192.168.25)? I want Samba shares to be reachable from the VMWare machines on the host-only network, but not from the LAN (with its Internet connection). I added Samba (SMB) with ports 137-139 445 and IP 192.168.25.0/24 to the allowed services for incoming traffic. But I still can't access the share from the VMWare machines (which run Windows 2000 and XP). When I disable the firewall, I can access the share. (I am a total iptables newbee ) Last edited by gwi; June 20th, 2006 at 05:24 AM..

June 22nd, 2006	#8
akudewan Quad Shot of Ubuntu Join Date: Aug 2005 Location: India Beans: 399 Ubuntu 9.04 Jaunty Jackalope	Re: Samba and Firestarter - the real story dsmalley: Wow. I can't thank you enough. Samba is working just fine, and I can browse the machines on my network with ease (using konqueror). This thread deserves to be pinned/sticky. You should really post this as a Howto in the Howto forum. I'm sure it will help lots of people __________________ Registered Linux user: #389188 http://akshaydewan.110mb.com/

June 27th, 2006	#9
B7may 5 Cups of Ubuntu Join Date: Feb 2006 Beans: 20	Re: Samba and Firestarter - the real story I have the same problem and changed the setup file the same. Now from the machine that has firestarter installed, I can access my main network. (In other words, I have a larger network and connected to that is the machine with Firestarter that controls a smaller network.) But any machine that is connected to the network controlled by firestarter cannot get to the main network. I am lost as to what i should do. Any ideas?

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode