Original: http://www.samba.org/~tpot/articles/multiple-interfaces.html
Multiple Network Interfaces with Samba
Abstract
Server and workstation machines that are running Samba often have multiple network interfaces. Sometimes it may not be prudent to allow Samba to be accessed over all network interfaces. This article describes the smb.conf
parameters used to restrict Samba to only use particular network interfaces, and how to test this is actually working using some Unix command line tools.
A Multi-Homed Server
Let's assume that we have a server with two network interfaces. Say that one interface, eth0
connects to the company network 10.0.0.0/8
, and eth1
connects to 192.168.1.0/24
, a small private network within the company. For one reason or another, we want shares exported by Samba to be available on the private network eth1
, but not visible to the rest of the organisation via eth0
. The machine in question is may be a firewall, gateway or plays some other sensitive role. In other configurations, you might want to avoid SMB connections over your PPP or wireless connection, for performance reasons.
The relevant smb.conf
parameters here are both global parameters. They are interfaces
and bind interfaces only
. From the manual page for smb.conf
, we find the following documentation:
This option allows you to override the default network interfaces list that Samba will use for browsing, name registration and other NBT traffic. By default Samba will query the kernel for the list of all active interfaces and use any interfaces except 127.0.0.1 that are broadcast capable.
This global parameter allows the Samba admin to limit what interfaces on a machine will serve SMB requests. It affects file service smbd(8)
and name service nmbd(8)
in a slightly different ways.
(The two parameters kind of overlap a bit, I think. I don't see why it should be necessary to specify bind interfaces only
if you have already specified something for the interfaces
parameter. One implies the other).
Anyway, if you read the rest of the documentation for these parameters you will discover the gory details about the operation of these two parameters. Some of these details are important, and we'll touch on them later on.
Configuration changes
OK let's set some appropriate values for interfaces
and bind interfaces only
to the smb.conf
for our server described above.
[global]
interfaces = eth1 lo
bind interfaces only = yes
Don't forget to restart Samba after making these changes. Sending smbd and nmbd a SIGHUP isn't sufficient in this case.
Testing SMB Connections
Now since preventing access on particular network interfaces may be a security sensitive configuration, it might be a good idea to test that the configuration changes we have made have had some effect and are working as expected. From the smb.conf
documentation, we know that the bind interfaces only
parameter causes smbd
to restrict which network a TCP port 139 or port 445 connection comes in on, and nmbd
to ignore name registration and query requests originating on unspecified interfaces.
Let's start with TCP connections to smbd. Under Unix, it's quite easy to check on which network address a process is listening on by using the netstat command. Here's the relevant output of netstat
for our example system:
# netstat -tapn | grep smbd
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 24040/smbd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 24040/smbd
Note: if you are running Samba 2.2 you won't see an entry for port 445. It's supported in Samba 3.0 and higher only.
After making the required changes to smb.conf
we rerun the netstat
command and get some slightly different output:
# netstat -tapn | grep smbd
tcp 0 0 192.168.1.1:139 0.0.0.0:* LISTEN 26182/smbd
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 26182/smbd
tcp 0 0 192.168.1.1:445 0.0.0.0:* LISTEN 26182/smbd
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN 26182/smbd
Notice that there is no entry for the “all interfaces” address, 0.0.0.0
, but rather a specific line for each entry in the interfaces
parameter. This tells us that Samba is only listening on the interfaces we have told it to, and not every one.
If you're still not convinced, you can use smbclient
, telnet
or any program that can make a TCP connection to port 139 or 445 (let's assume that our server has an IP address of 10.1.1.1
on eth0
and 192.168.1.1
on eth1
:
$ smbclient -L //10.1.1.1 -U%
Error connecting to 10.1.1.1 (Connection refused)
Connection to 10.1.1.1 failed
$ smbclient -L //192.168.1.1 -U%
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 3.0.20b-Debian]
Sharename Type Comment
--------- ---- -------
...
Testing Name Lookups
Now, the other half of the problem is to prevent NetBIOS packets (basically name lookups) from occuring on eth0
. Let's look at the output of netstat
before fiddling with Samba's configuration:
# netstat -apn | grep nmbd
udp 0 0 10.1.1.1:137 0.0.0.0:* 26245/nmbd
udp 0 0 192.168.1.1:137 0.0.0.0:* 26245/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 26245/nmbd
udp 0 0 10.1.1.1:138 0.0.0.0:* 26245/nmbd
udp 0 0 192.168.1.1:138 0.0.0.0:* 26245/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 26245/nmbd
This output tells us that nmbd
is listening on both eth0
and eth1
interfaces on the server. Probably due to the way Samba uses the Unix UDP networking API, there is not just a single wildcard entry for listening to all interfaces, but rather one entry for each interface, plus an entry that can receive broadcast datagrams.
After applying the changes to smb.conf
and restarting, netstat
says:
# netstat -apn | grep nmbd
udp 0 0 192.168.1.1:137 0.0.0.0:* 26270/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 26270/nmbd
udp 0 0 192.168.1.1:138 0.0.0.0:* 26270/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 26270/nmbd
Notice that we have now lost the entry for eth0
and are only listening on eth1
as well as the broadcast entry.
We can use the nmblookup
program that comes with Samba to further test that name lookups are not being processed on the eth0
interface. The '-B' option can be used to specify the broadcast address to use and thus which network interface the lookup request appears to come from.
Before we change the smb.conf
file:
$ nmblookup -B 10.255.255.255 server
querying server on 10.255.255.255
10.1.1.1 server<00>
$ nmblookup -B 192.168.1.255 server
querying server on 192.168.1.255
192.168.1.1 server<00>
Afterwards we can see that our server doesn't respond to NetBIOS name requests on the eth0
interface:
$ nmblookup -B 10.255.255.255 server
querying server on 10.255.255.255
name_query failed to find name server
$ nmblookup -B 192.168.1.255 server
querying server on 192.168.1.255
192.168.1.1 server<00>
Other Tricks
The interfaces parameter understands a couple of different ways of specifying network interfaces. You may like to use the IP and mask format way of specifying a network. Instead of of specifying eth1
you can say either 10.1.1.1/8
(bit length format) or 10.1.1.1/255.0.0.0
(netmask format). This may be more readable than just using the interface name.