| The Unofficial Samba HOWTO | ||
|---|---|---|
| Prev | Next | |
"It turned out that the worm exploited three or four different holes in the system. From this, and the fact that we were able to capture and examine some of the source code, we realized that we were dealing with someone very sharp, probably not someone here on campus." --Dr. Richard LeBlanc, associate professor of ICS, in George Tech's campus newspaper after the Internet worm
Microsoft Windows does not store or transmit passwords in clear text. Instead, it uses a hash of the user's password for authentication. A hash is essentially an algorithm where a piece of data (the password) is transformed by a mathematical formula (the hashing algorithm). Microsoft Windows implements three of these algorithms:
Although Windows NT & higher don't use the first algorithm (LM) anymore, for backwards compatibility they locally store these insecure password hashes in addition to the secure version. It's worth noting that since both the LMHash and the NTLM Hash are stored, the weaker of the two hashes becomes the weakest link. Therefore, the weakest link becomes the most optimal password (as anything stronger will be reduced in strength). Even the most complex password is therefore reduced to the effectiveness offered by a simple 7-digit single-case password.As a result, if your network does not include any Windows95/98/ME machines, you are strongly recommended to disable LM authentication on the Samba server and increase the minimum protocol by using the following global configuration in your smb.conf file:
lanman auth = no
lm announce = no
min protocol =
NT1
Note that this only addresses the password issues on the server, not anything stored locally on the clients.
If you run your samba server on a machine that has a valid IP address to the Internet, or an an untrusted LAN, you'll probably want to limit who can connect to your Samba shares.
Assuming your server runs on 192.168.0.1, your netmask is 255.255.255.0 and you wish to deny access to a host in your network on 192.168.0.8, your smb.conf file should look like:
[global]
hosts allow = 192.168.0.0/24 127.0.0.1 EXCEPT 192.168.0.8/32
hosts deny = ALL
If you're unclear as to why this is, or are confused by the '/24' bit, you should spend some time reading up on subnet masks. A nifty network calculator that lets you get your hands dirty is available at http://www.telusplanet.net/public/sparkman/netcalc.htm.
It's also useful to limit the interfaces on which Samba will run, if you have a multi-homed (more than one IP address)server. A common mistake is to set the interfaces line to the specific IP address of the box, when it is actually the IPsubnet that your interface is on that you want to use. Assuming your server runs on 192.168.0.1 and your netmask is255.255.255.0, your smb.conf file should look like:
[global]
interfaces = 192.168.0.0/255.255.255.0 127.0.0.1
bind interfaces only = Yes
Regardless of the security measures you incorporate into your Samba design, you should never run SMB services across an untrusted network (e.g., the Internet). The SMB/CIFS protocol is vulnerable to many attacks. Ports 135/UDP, 135/TCP, 137/uid,138/UDP, 139/TCP and 445/TCP should never be exposed to untrusted networks.
To prevent the administrative user from logging in, use:
invalid users = root @wheel
To prevent unreadable files (per Linux permissions) from being displayed, use:
hide unreadable = yes
To prevent browsing by default, use:
browseable = no
To prevent access to suspicious files (e.g., those that tend to become infected by virus'), use the following. The last bit prevents access to files with a CLSID in the file extension.
veto files =
/*.exe/*.dll/*.pif/*.com/*.vbs/*.{*}/
To hide (but not prevent access to) files, you can use:
hide files = /example.txt/*.ico/
To filter traffic to your Samba server using iptables(8), you could try something like:
SERVER="192.168.0.1" # Server IP Address
NETMASK="255.255.0.0" # Server Netmask
NETWORK="192.168.0.0" # Local area network
BROADCAST="192.168.255.255" # Local area network Broadcast Address
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -p udp -s ${NETWORK}/${NETMASK} -d ${SERVER}/32 -m multiport --dports 137,138 -j ACCEPT
iptables -A INPUT -p tcp -s ${NETWORK}/${NETMASK} -d ${SERVER}/32 -m multiport --dports 139,445 -j ACCEPT
iptables -A INPUT -p udp -s ${NETWORK}/${NETMASK} -d ${BROADCAST}/32 --dport 137 -j ACCEPT
iptables -A INPUT -p udp -d ${SERVER}/32 -m multiport --dports 137,138 -j DROP
iptables -A INPUT -p tcp -d ${SERVER}/32 -m multiport --dports 139,445 -j DROP
iptables -A OUTPUT -s ${SERVER}/32 -d ${NETWORK}/32 -m state --state ESTABLISHED,RELATED -j ACCEPT
Additionally, ICMP type 3 code 4 (Fragmentation Needed) should never be blocked. Otherwise, your server/client will be unable to negotiate a valid MTU window size. A good rule of thumb is to avoid blocking ICMP traffic while tuning your Samba server.
One method of encrypting SMB traffic over a network is to "tunnel" SMB through SSH using a method known as port forwarding. This is a frequently asked question by system administrators wishing to secure remote SMB traffic.While this is possible, it does have some serious drawbacks which we will touch on as well.It's important to be aware that running SMB by itself without SSH over a 56k dial-up line is still terribly slow to the point of frustration. If you don't have a high speed link or at least a lot of patience, you probably don't even want to deal with tunneling over SSH.The other unfortunate bit of news is that due to a design limitation in the GUI API of Windows 9x/ME, you'll only be able to perform your tunneled work in a MS-DOS window. Once you step outside of this and attempt to interact with your remote server via the GUI, you'll find 30-60 second periods where the computer will pause/hang, after which it will complain that the path is invalid or unavailable. One possible explanation is the 16/32-bit nature of this type of Windows OS, however there has yet to be a confirmation of this by either Microsoft or the Samba team. Those using the 32-bit Windows 2000/XP systems will not have this limitation whatsoever.That being said, the good news is that tunneling SMB through SSH is indeed possible. Name services, or anything relying on UDP, can't be forwarded via SSH due to a limitation in how SSH forwards ports (TCP only).So, we'll focus on port forwarding only TCP/port 139. Since UDP tunneling is not available under SSH, your first step involves adjusting the lack of WINS/broadcast name resolution.
Windows provides two different files, HOSTS and LMHOSTS. The former is for Hostname-to-IP Address resolution (similar to DNS), and the latter is for NetBIOS-name-to-IP Address resolution (similar to WINS). LMHOSTS originally stood for "LAN Manager". These files are provided as a "backup" in the case that DNS or WINS are not available. Since NetBIOS name resolution only works via UDP, which can't be tunneled via SSH, the first step is to edit the LMHOSTS file:
REM Under WinNT/2k/XP, this is c:\windows\system32\drivers\etc\LMHOSTS REM Under Win9x/ME, this is c:\windows\LMHOSTS 127.0.0.1 FAKENAME #PRE
Where FAKENAME is a bogus NetBIOS name that you will use to refer to your Samba server. The #PRE statement tells Windows that this name should be cached into memory, otherwise it won't always be read. The LMHOSTS file will not be processed by Windows until you reboot or you issue the following command, which forces a reload of the NetBIOS name cache (note the uppercase-R):
NBTSTAT -R
Configure your client's SSH program to forward port 139/TCP on the localhost to port 139/TCP on the server, and then connect via SSH. Once done, open up a Command Prompt and issue these commands:
NET VIEW \\127.0.0.1 NET VIEW \\FAKENAME
Viola! Both commands work, and you can confirm the encryption with a packet filter. Possible error messages you might see include:
For better or worse, SSL support has been removed from Samba as of version 3.0. The general consensus among the Samba team was that an SSL-enabled Samba could be better implemented by external tools. Add to that a batch of unmaintained and (mostly) unused code led to the final decision of the removal of SSL from Samba.
| Prev | Home | Next |
| Troubleshooting | Epilogue |