Samba Security

Samba Security

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:

• LAN Manager (”LM”, “LAN MAN”) (least secure, most compatible). Generated by splitting the password into two 7-character uppercase strings, and then converting each to a 56-bit DES key which both then encrypt the string”KGS!@#$%” (minus quotes) and concatenating the results.
• NT LAN Manager Version 2 (”NTLMv2″) (most secure and least compatible).

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 Windows 9x/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. Note that this only addresses the password issues on the server, not anything stored locally on the clients.

lanman auth = no
lm announce = no
min protocol = NT1

TCP/IP Filtering

First off, don’t run Samba on an unsecured, publicly-accessible Internet connection. It’s just asking for trouble. We can, of course, lock it down a bit:

# Allow these IP Addresses to connect
hosts allow = 192.168.0.0/16 127.0.0.1

# Anything else not allowed is, by default, rejected
hosts deny = ALL

# If your machine has more than one Internet address, you can restrict
# the subnets which Samba will listen to.
interfaces = 192.168.0.0/24 127.0.0.1
bind interfaces only = Yes

As an additional layer of security,ou can also filter out (or in, depending on your philosophy) traffic using iptables with something like:

# Allow access to Samba from a particular subnet
iptables -A INPUT -p icmp -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p udp -s 192.168.0.0/16 –dport 137:138 -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.0.0/16 -m multiport –dports 139,445 -j ACCEPT

# Log all unauthorized access attempts...
iptables -A INPUT -p udp –dport 137:138 -m limit -j LOG
iptables -A INPUT -p tcp -m multiport –dports 139,445 -m limit -j LOG

# ...and then reject the unauthorized access attempts
iptables -A INPUT -p udp –dport 137:138 -j REJECT –reject-with icmp-port-unreachable
iptables -A INPUT -p tcp -m multiport –dports 139,445 -j REJECT –reject-with tcp-reset

SSL Encryption

For better or worse, SSL support has gone the way of the dodo and has been removed from Samba as of version 3. 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. The actual post that talks about the demise of SSL Encryption (May 2002) states:

This message is a warning: –with-ssl will die.

Ok, thats enough with the dramatics, but the general consensus amoungst the samba team is that –with-ssl really isn’t a particulary smart idea, and it is better implemented by external tools. So what is –with-ssl exactly? And why kill it? –with-ssl allows Samba to tunnel SMB inside an SSL connection. Unfortunately there are only 2 clients: smbclient and sharity. Windows clients simply don’t know how to use SSL. So why kill it? It might be useful to somebody? While some small minority of users might find it handy, it confuses many more including a surprising number of our distributors. Users actually using this functionality will find that they can achieve almost the same effect by creative use of ’stunnel’ both as an inetd wrapper as as a ‘LIBSMB_PROG’ program. Finally, it is intrusive and ugly, with large #ifdef sections in what should be simple code.

SSH Encryption

Why anyone would want to do this given the latency issues of running SMB/CIFS services over a WAN is somewhat beyond my comprehension. 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 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 This is c:/windows/system32/drivers/etc/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.