Copyright © 2005
| Revision History | |
|---|---|
| Revision 0.1 | 2005-11-11 |
| Initial version. | |
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.
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.1that 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 servicenmbd(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.
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.
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
--------- ---- -------
...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>
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.