| Intro | Install | Configure | Troubleshoot | Optimize | PDC | Security |
David Lechnyr <david@lechnyr.com>
Fri, 9 May 2003 12:49:09 -0700
"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.
Samba stores its passwords in /usr/local/samba/private/smbpasswd.
Every account listed in smbpasswd must exist in the system's /etc/passwd file.
Permissions should be as follows:
# chown -R root.root /usr/local/samba/private # chmod 700 /usr/local/samba/private # chmod 600 /usr/local/samba/private/smbpasswd
The layout of smbpasswd, one account entry per line, is:
Username:UID:LMHash:NTLMHash:AccountFlags:LastChangeTime:
/etc/passwd./etc/passwd.So, an example might look like:
davidrl:100:A2808FB34C870C0FAAD3B435B51404EE:0BEC2704FE052C6264637F06494E5EF9:[UX ]:LCT-3EBBF3FA:
It's worth noting that since both the LMHash and the NTLMHash are stored (for legacy support), the weaker of the two hashes (LMHash) becomes the weakest link. The LMHash is initially 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. 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 (Cavet Emptor -- "Let the Buyer Beware").
According to SANS:
Although most current Windows environments have no need for LAN Manager (LM) support,
Microsoft locally stores legacy LM password hashes (also known as LANMAN hashes) by default
on Windows NT, 2000 and XP systems. Since LM uses a much weaker encryption scheme than more
current Microsoft approaches (NTLM and NTLMv2), LM passwords can be broken in a very short
period of time. Even passwords that otherwise would be considered "strong" can be cracked by
brute-force in under a week on current hardware.
The weakness of LM hashes derives from the following:
* Passwords are truncated to 14 characters.
* Passwords are padded with spaces to become 14 characters.
* Passwords are converted to all upper case characters.
* Passwords are split into two seven character pieces.
This hashing process means that an attacker needs only to complete the trivial task of cracking
two seven-character, upper-case passwords to gain authenticated access to your system. Since the
complexity of cracking hashes increases geometrically with the length of the hash, each seven-
character string is at least an order of magnitude simpler to attack by brute-force than would
a combined fourteen-character string. Since all strings are exactly seven characters (including
spaces) and entirely upper-case, a dictionary-style attack is also simplified. The LM hashing
method therefore completely undermines good password policies.
In addition to the risk posed by having legacy LM hashes stored in the SAM, the LAN Manager
authentication process is often by default enabled on clients and accepted by servers. As a
result, Windows machines capable of utilizing stronger hash algorithms instead send weak LM
hashes across the network, making Windows authentication vulnerable to eavesdropping by packet
sniffing, and therefore easing the efforts of an attacker to obtain and crack user passwords.
As a result, if your network does not include any Windows 95/98/ME or earlier clients, you are strongly recommended to disable Lan Manager authentication on the server and increase the minimum protocol (see below). Note that this only addresses the password issues on the server, not the clients.
[global] lanman auth = no min protocol = NT1 lm announce = no
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:
hosts allow = 192.168.0.0/255.255.255.0 127.0.0.1 EXCEPT 192.168.0.8 hosts deny = ALL
It's also useful to limit the interfaces on which Samba will run, if you have a multihomed (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 IP subnet that your interface is on that you want to use. Assuming your server runs on 192.168.0.1 and your netmask is 255.255.255.0, your smb.conf file should look like:
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/upd, 138/udp, 139/tcp and 445/tcp should never be exposed to untrusted networks.
These are simple smb.conf configuration settings that make Samba a little more transparent to the watching eye.
# Encrypt all passwords stored in /usr/local/samba/private/smbpasswd
encrypt passwords = yes
# Prevent the administrative user from logging in
invalid users = root @wheel
# Files that have their Linux permissions set to prevent access shouldn't even appear
hide unreadable = yes
# Prevent browsing by default
browseable = no
# Don't allow access to any of the following files.
# Useful for preventing the spread of virus infections on your server
# should a Windows-connected client become infected.
# The last match bit prevents accessing files with a CLSID in its file extension
veto files = /*.exe/*.dll/*.com/*.vbs/*.{*}/
# You could uncomment the next line to use a more restrictive set of
# unallowed file extensions (see Microsoft KB 290497)
# veto files = /*.scr/*.scf/*.sct/*.pif/*.exe/*.bas/*.bat/*.com/*.ade/*.adp/*.asp/*.asx/*.chm/*.cmd/*.cpl/*.crt/*.hta/*.hlp/*.inf/*.ins/*.isp/*.js/*.jse/*.lnk/*.mda/*.mde/*.mdt/*.mdw/*.mdz/*.msc/*.msi/*.msp/*.mst/*.ops/*.pcd/*.prf/*.reg/*/shb/*.shs/*.url/*.vb/*.vbs/*.vbe/*.wsc/*.wsf/*.wsh/*.{*}/lost+found/
# Hide the following files; the client can still choose to alter their view settings to show hidden files.
hide files = /example.txt/*.ico/
NBT (NetBIOS-over-TCP): This method of communication relies on three specific services: NetBIOS Name Service (port 137/udp), NetBIOS Datagram Service (port 138/udp), and NetBIOS Session Service (port 139/tcp). If you're using Windows 95/98/ME or Windows NT, this is the only method available to you.
Direct Hosted: This is the new Microsoft marketing term used to describe a new method of file/printer sharing which uses only port 445/tcp. Currently, only Windows 2000 and Windows XP support this new method. It is "NetBIOS-less" in that all name resolution is done via DNS (which removes the dependence on WINS). By default, Windows 2000/XP will attempt to use both NBT and Direct Hosted; whichever method receives a response first is the one that will be used. With Direct Hosted traffic, a four-byte header precedes all SMB traffic. The first byte of this header is always 0x00, and the next three bytes are the length of the remaining data.
Samba does have the ability to accept connections on port 445, but it does not listen on this port when started with the -D option. Instead, it must be started from inetd (without the -D flag) and inetd must be configured to accept smb connections on port 445. Please be aware that this is a very new and untested feature, so your mileage may vary.
Assuming your server has an IP address of 192.168.0.1, a netmask of 255.255.255.0 (aka "/24"), and is using the Traditional NetBIOS method, your iptables bit might look like:
iptables -A INPUT -p udp -s 192.168.0.0/24 -d 192.168.0.1/32 -m multiport --dports 135,137,138 -j ACCEPT iptables -A INPUT -p tcp -s 192.168.0.0/24 -d 192.168.0.1/32 -m multiport --dports 135,139,445 -j ACCEPT iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT [... insert the rest of your rules here ...] iptables -A INPUT -j DROP iptables -A OUTPUT -j DROP
As a sidenote, if you're running a 2.4.x Linux kernel and you're still using ipchains(8), you should consider upgrading to iptables which is considered a stateful firewall and a lot easier to configure. If you have an old ipchains or ipfwadm based firewall, you should be able to apply the same logical layout of the above script and adapt it to your needs.
A NULL session connection is an unauthenticated connection to an NT/W2000 machine. Gaining NULL session access to an NT\W2000 system is the number one method for hackers to enumerating information about an NT\W2000 machine.
From a NULL session hackers can call APIs and use Remote Procedure calls to enumerate information. These techniques can, and will provide information on passwords, groups, services, users and even active processors. NULL session access can also even be used for escalating privileges and perform DoS attacks.
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 dialup 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 tunnelled 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 MS-DOS window 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.
For better or worse, SSL support is being deprecated in Samba 3.0. This is mainly due to the lack of implementation of Windows support for SMB/SSL. While the code still exists in the 2.2.x branch, it hasn't been updated for some time. Those interested in the specifics can review the following posting to samba-technical:
From: vorlon@netexpress.net (Steve Langasek)
Subject: Re: Impending Removal of --with-ssl
Date: Fri, 3 May 2002 15:51:55 +0000 (UTC)
On Fri, May 03, 2002 at 07:56:43AM -0700, abartlet@samba.org wrote:
> 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 implmented 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 sombody?
> While some small minority of users might find it handy, it
> confuses many more including a supprising number of our
> distributors. Users actually using this functionality will
> find that they can achive 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. If sombody can come up
> with both reasons to keep this code, and time to maintain it,
> then I would like to hear it.
Though I don't object to --with-ssl's presence if someone is willing to maintain it, there are a variety of reasons why Debian has never enabled this option, and probably never will. Having gotten past the obstacle of US export law, it's now been pointed out[1] that the GPL does not permit us as a distributor to ship GPLed binaries linked against OpenSSL together with the OpenSSL libraries themselves; unless all copyright holders in Samba are willing to grant an explicit exemption for linking with OpenSSL, Debian is not willing to expose itself or its mirror operators to the legal risk.
Assuming everyone was ok with the legal minutiae, we would still have to decide if SSL was really worth enabling. I've always been lukewarm about this option, because setting up an SSL tunnel on the Unix side has always been the /easy/ part: it's configuring all of your Windows clients (of varying flavors) to use SSL for SMB connections that takes doing. So the savings of having SSL support compiled into Samba are minimal, but the potential headaches are numerous. I'd almost say you'd be doing users a favor by removing this option.
Steve Langasek
postmodern programmer
[1] http://lists.debian.org/debian-devel/2002/debian-devel-200203/msg01569
The following information is written by Andrew Tridgell, the leader of the Samba Team, on additional ways to protect an unpatched pre-2.2.8 Samba server. It's also a good overview of some basic Samba security techniques as well:
This is a note on how to provide your Samba server some protection against the recently discovered remote security hole if you are unable to upgrade to the fixed version immediately. Even if you do upgrade you might like to think about the suggestions in this note to provide you with additional levels of protection.
Using host based protection
In many installations of Samba the greatest threat comes for outside your immediate network. By default Samba will accept connections from any host, which means that if you run an insecure version of Samba on a host that is directly connected to the Internet you can be especially vulnerable.
One of the simplest fixes in this case is to use the 'hosts allow' and 'hosts deny' options in the Samba smb.conf configuration file to only allow access to your server from a specific range of hosts. An example might be:
hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
hosts deny = 0.0.0.0/0The above will only allow SMB connections from 'localhost' (your own computer) and from the two private networks 192.168.2 and 192.168.3. All other connections will be refused connections as soon as the client sends its first packet. The refusal will be marked as a 'not listening on
called name' error.Using interface protection
By default Samba will accept connections on any network interface that it finds on your system. That means if you have a ISDN line or a PPP connection to the Internet then Samba will accept connections on those links. This may not be what you want.
You can change this behavior using options like the following:
interfaces = eth* lo
bind interfaces only = yesthat tells Samba to only listen for connections on interfaces with a name starting with 'eth' such as eth0, eth1, plus on the loopback interface called 'lo'. The name you will need to use depends on what OS you are using. In the above I used the common name for ethernet adapters on Linux.
If you use the above and someone tries to make a SMB connection to your host over a PPP interface called 'ppp0', they will get a TCP connection refused reply. In that case no Samba code is run at all as the operating system has been told not to pass connections from that interface to any process.
Using a firewall
Many people use a firewall to deny access to services that they don't want exposed outside their network. This can be a very good idea, although I would recommend using it in conjunction with the above methods so that you are protected even if your firewall is not active for some reason.
If you are setting up a firewall then you need to know what TCP and UDP ports to allow and block. Samba uses the following:
UDP/137 - used by nmbd
UDP/138 - used by nmbd
TCP/139 - used by smbd
TCP/445 - used by smbdThe last one is important as many older firewall setups may not be aware of it, given that this port was only added to the protocol in recent years.
Using a IPC$ share deny
If the above methods are not suitable, then you could also place a more specific deny on the IPC$ share that is used in the recently discovered security hole. This allows you to offer access to other shares while denying access to IPC$ from potentially untrustworthy hosts.
To do that you could use:
[ipc$]
hosts allow = 192.168.115.0/24 127.0.0.1
hosts deny = 0.0.0.0/0this would tell Samba that IPC$ connections are not allowed from anywhere but the two listed places (localhost and a local subnet). Connections to other shares would still be allowed. As the IPC$ share is the only share that is always accessible anonymously this provides some level of protection against attackers that do not know a username/password for your host.
If you use this method then clients will be given a 'access denied' reply when they try to access the IPC$ share. That means that those clients will not be able to browse shares, and may also be unable to access some other resources. I don't recommend this method unless you cannot use one of the other methods listed above for some reason.
Copyright © 2003 David Lechnyr <david@lechnyr.com>
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free
Software Foundation. A copy of the license is available at http://www.gnu.org/licenses/fdl.txt.
| Intro | Install | Configure | Troubleshoot | Optimize | PDC | Security |