mirror of
https://github.com/samba-team/samba.git
synced 2025-01-26 10:04:02 +03:00
181 lines
18 KiB
HTML
181 lines
18 KiB
HTML
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 15. Securing Samba</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="locking.html" title="Chapter 14. File and Record Locking"><link rel="next" href="InterdomainTrusts.html" title="Chapter 16. Interdomain Trust Relationships"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 15. Securing Samba</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="locking.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="InterdomainTrusts.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="securing-samba"></a>Chapter 15. Securing Samba</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Andrew</span> <span class="surname">Tridgell</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:tridge@samba.org">tridge@samba.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">John</span> <span class="othername">H.</span> <span class="surname">Terpstra</span></h3><div class="affiliation"><span class="orgname">Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jht@samba.org">jht@samba.org</a>></tt></p></div></div></div></div><div><p class="pubdate">May 26, 2003</p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="securing-samba.html#id2918114">Introduction</a></dt><dt><a href="securing-samba.html#id2918159">Features and Benefits</a></dt><dt><a href="securing-samba.html#id2918244">Technical Discussion of Protective Measures and Issues</a></dt><dd><dl><dt><a href="securing-samba.html#id2918263">Using Host-Based Protection</a></dt><dt><a href="securing-samba.html#id2918364">User-Based Protection</a></dt><dt><a href="securing-samba.html#id2918424">Using Interface Protection</a></dt><dt><a href="securing-samba.html#id2918507">Using a Firewall</a></dt><dt><a href="securing-samba.html#id2918564">Using IPC$ Share-Based Denials </a></dt><dt><a href="securing-samba.html#id2918648">NTLMv2 Security</a></dt></dl></dd><dt><a href="securing-samba.html#id2918707">Upgrading Samba</a></dt><dt><a href="securing-samba.html#id2918731">Common Errors</a></dt><dd><dl><dt><a href="securing-samba.html#id2918750">Smbclient Works on Localhost, but the Network Is Dead</a></dt><dt><a href="securing-samba.html#id2918774">Why Can Users Access Home Directories of Other Users?</a></dt></dl></dd></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2918114"></a>Introduction</h2></div></div><div></div></div><p>
|
||
This note was attached to the Samba 2.2.8 release notes as it contained an
|
||
important security fix. The information contained here applies to Samba
|
||
installations in general.
|
||
</p><div class="blockquote"><blockquote class="blockquote"><p>
|
||
A new apprentice reported for duty to the chief engineer of a boiler house. He said, “<span class="quote">Here I am,
|
||
if you will show me the boiler I'll start working on it.</span>” Then engineer replied, “<span class="quote">You're leaning
|
||
on it!</span>”
|
||
</p></blockquote></div><p>
|
||
Security concerns are just like that. You need to know a little about the subject to appreciate
|
||
how obvious most of it really is. The challenge for most of us is to discover that first morsel
|
||
of knowledge with which we may unlock the secrets of the masters.
|
||
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2918159"></a>Features and Benefits</h2></div></div><div></div></div><p>
|
||
There are three levels at which security principals must be observed in order to render a site
|
||
at least moderately secure. They are the perimeter firewall, the configuration of the host
|
||
server that is running Samba and Samba itself.
|
||
</p><p>
|
||
Samba permits a most flexible approach to network security. As far as possible Samba implements
|
||
the latest protocols to permit more secure MS Windows file and print operations.
|
||
</p><p>
|
||
Samba may be secured from connections that originate from outside the local network. This may be
|
||
done using <span class="emphasis"><em>host-based protection</em></span> (using samba's implementation of a technology
|
||
known as “<span class="quote">tcpwrappers,</span>” or it may be done be using <span class="emphasis"><em>interface-based exclusion</em></span>
|
||
so <span class="application">smbd</span> will bind only to specifically permitted interfaces. It is also
|
||
possible to set specific share or resource-based exclusions, for example on the <i class="parameter"><tt>[IPC$]</tt></i>
|
||
auto-share. The <i class="parameter"><tt>[IPC$]</tt></i> share is used for browsing purposes as well as to establish
|
||
TCP/IP connections.
|
||
</p><p>
|
||
Another method by which Samba may be secured is by setting Access Control Entries (ACEs) in an Access
|
||
Control List (ACL) on the shares themselves. This is discussed in <link linkend="AccessControls">.
|
||
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2918244"></a>Technical Discussion of Protective Measures and Issues</h2></div></div><div></div></div><p>
|
||
The key challenge of security is the fact that protective measures suffice at best
|
||
only to close the door on known exploits and breach techniques. Never assume that
|
||
because you have followed these few measures that the Samba server is now an impenetrable
|
||
fortress! Given the history of information systems so far, it is only a matter of time
|
||
before someone will find yet another vulnerability.
|
||
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918263"></a>Using Host-Based Protection</h3></div></div><div></div></div><p>
|
||
In many installations of Samba, the greatest threat comes from 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.
|
||
</p><p>
|
||
One of the simplest fixes in this case is to use the <a class="indexterm" name="id2918285"></a><i class="parameter"><tt>hosts allow</tt></i> and
|
||
<a class="indexterm" name="id2918298"></a><i class="parameter"><tt>hosts deny</tt></i> options in the Samba <tt class="filename">smb.conf</tt> configuration file to only
|
||
allow access to your server from a specific range of hosts. An example might be:
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24</tt></i></td></tr><tr><td><i class="parameter"><tt>hosts deny = 0.0.0.0/0</tt></i></td></tr></table><p>
|
||
The above will only allow SMB connections from <tt class="constant">localhost</tt> (your own
|
||
computer) and from the two private networks 192.168.2 and 192.168.3. All other
|
||
connections will be refused as soon as the client sends its first packet. The refusal
|
||
will be marked as <span class="errorname">not listening on called name</span> error.
|
||
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918364"></a>User-Based Protection</h3></div></div><div></div></div><p>
|
||
If you want to restrict access to your server to valid users only, then the following
|
||
method may be of use. In the <tt class="filename">smb.conf</tt> <i class="parameter"><tt>[global]</tt></i> section put:
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>valid users = @smbusers, jacko</tt></i></td></tr></table><p>
|
||
This restricts all server access to either the user <span class="emphasis"><em>jacko</em></span>
|
||
or to members of the system group <span class="emphasis"><em>smbusers</em></span>.
|
||
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918424"></a>Using Interface Protection</h3></div></div><div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
You can change this behavior using options like this:
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>interfaces = eth* lo</tt></i></td></tr><tr><td><i class="parameter"><tt>bind interfaces only = yes</tt></i></td></tr></table><p>
|
||
This tells Samba to only listen for connections on interfaces with a
|
||
name starting with <tt class="constant">eth</tt> such as <tt class="constant">eth0, eth1</tt> plus on the loopback
|
||
interface called <tt class="constant">lo</tt>. 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.
|
||
</p><p>
|
||
If you use the above and someone tries to make an SMB connection to
|
||
your host over a PPP interface called <tt class="constant">ppp0,</tt> then 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 Samba process.
|
||
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918507"></a>Using a Firewall</h3></div></div><div></div></div><p>
|
||
Many people use a firewall to deny access to services they do not
|
||
want exposed outside their network. This can be a good idea,
|
||
although I recommend using it in conjunction with the above
|
||
methods so you are protected even if your firewall is not active
|
||
for some reason.
|
||
</p><p>
|
||
If you are setting up a firewall, you need to know what TCP and
|
||
UDP ports to allow and block. Samba uses the following:
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td>UDP/137 - used by nmbd</td></tr><tr><td>UDP/138 - used by nmbd</td></tr><tr><td>TCP/139 - used by smbd</td></tr><tr><td>TCP/445 - used by smbd</td></tr></table><p>
|
||
The 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.
|
||
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918564"></a>Using IPC$ Share-Based Denials </h3></div></div><div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
To do this you could use:
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[IPC$]</tt></i></td></tr><tr><td><i class="parameter"><tt>hosts allow = 192.168.115.0/24 127.0.0.1</tt></i></td></tr><tr><td><i class="parameter"><tt>hosts deny = 0.0.0.0/0</tt></i></td></tr></table><p>
|
||
This instructs Samba that IPC$ connections are not allowed from
|
||
anywhere except from the two listed network addresses (localhost and the 192.168.115
|
||
subnet). Connections to other shares are still 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 valid username/password for your host.
|
||
</p><p>
|
||
If you use this method, then clients will be given an <span class="errorname">`access denied'</span>
|
||
reply when they try to access the IPC$ share. Those clients will not be able to
|
||
browse shares, and may also be unable to access some other resources. This is not
|
||
recommended unless you cannot use one of the other methods listed above for some reason.
|
||
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918648"></a>NTLMv2 Security</h3></div></div><div></div></div><p>
|
||
To configure NTLMv2 authentication, the following registry keys are worth knowing about:
|
||
</p><p>
|
||
</p><pre class="screen">
|
||
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
|
||
"lmcompatibilitylevel"=dword:00000003
|
||
</pre><p>
|
||
</p><p>
|
||
The value 0x00000003 means send NTLMv2 response only. Clients will use NTLMv2 authentication,
|
||
use NTLMv2 session security if the server supports it. Domain Controllers accept LM,
|
||
NTLM and NTLMv2 authentication.
|
||
</p><p>
|
||
</p><pre class="screen">
|
||
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
|
||
"NtlmMinClientSec"=dword:00080000
|
||
</pre><p>
|
||
</p><p>
|
||
The value 0x00080000 means permit only NTLMv2 session security. If either NtlmMinClientSec or
|
||
NtlmMinServerSec is set to 0x00080000, the connection will fail if NTLMv2
|
||
session security is not negotiated.
|
||
</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2918707"></a>Upgrading Samba</h2></div></div><div></div></div><p>
|
||
Please check regularly on <ulink url="http://www.samba.org/">http://www.samba.org/</ulink> for updates and
|
||
important announcements. Occasionally security releases are made and
|
||
it is highly recommended to upgrade Samba when a security vulnerability
|
||
is discovered. Check with your OS vendor for OS specific upgrades.
|
||
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2918731"></a>Common Errors</h2></div></div><div></div></div><p>
|
||
If all of Samba and host platform configuration were really as intuitive as one might like them to be, this
|
||
section would not be necessary. Security issues are often vexing for a support person to resolve, not
|
||
because of the complexity of the problem, but for the reason that most administrators who post what turns
|
||
out to be a security problem request are totally convinced that the problem is with Samba.
|
||
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918750"></a>Smbclient Works on Localhost, but the Network Is Dead</h3></div></div><div></div></div><p>
|
||
This is a common problem. Red Hat Linux (and others) installs a default firewall.
|
||
With the default firewall in place, only traffic on the loopback adapter (IP address 127.0.0.1)
|
||
is allowed through the firewall.
|
||
</p><p>
|
||
The solution is either to remove the firewall (stop it) or modify the firewall script to
|
||
allow SMB networking traffic through. See section above in this chapter.
|
||
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2918774"></a>Why Can Users Access Home Directories of Other Users?</h3></div></div><div></div></div><p>
|
||
“<span class="quote">
|
||
We are unable to keep individual users from mapping to any other user's
|
||
home directory once they have supplied a valid password! They only need
|
||
to enter their own password. I have not found any method to configure
|
||
Samba so that users may map only their own home directory.
|
||
</span>”
|
||
</p><p>“<span class="quote">
|
||
User xyzzy can map his home directory. Once mapped user xyzzy can also map
|
||
anyone else's home directory.
|
||
</span>”</p><p>
|
||
This is not a security flaw, it is by design. Samba allows users to have
|
||
exactly the same access to the UNIX file system as when they were logged
|
||
onto the UNIX box, except that it only allows such views onto the file
|
||
system as are allowed by the defined shares.
|
||
</p><p>
|
||
If your UNIX home directories are set up so that one user can happily <b class="command">cd</b>
|
||
into another users directory and execute <b class="command">ls</b>, the UNIX security solution is to change file
|
||
permissions on the user's home directories such that the <b class="command">cd</b> and <b class="command">ls</b> are denied.
|
||
</p><p>
|
||
Samba tries very hard not to second guess the UNIX administrators security policies, and
|
||
trusts the UNIX admin to set the policies and permissions he or she desires.
|
||
</p><p>
|
||
Samba allows the behavior you require. Simply put the <a class="indexterm" name="id2918859"></a><i class="parameter"><tt>only user</tt></i> = %S
|
||
option in the <i class="parameter"><tt>[homes]</tt></i> share definition.
|
||
</p><p>
|
||
The <a class="indexterm" name="id2918883"></a><i class="parameter"><tt>only user</tt></i> works in conjunction with the <a class="indexterm" name="id2918899"></a><i class="parameter"><tt>users</tt></i> = list,
|
||
so to get the behavior you require, add the line :
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>users = %S</tt></i></td></tr></table><p>
|
||
this is equivalent to adding
|
||
</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>valid users = %S</tt></i></td></tr></table><p>
|
||
to the definition of the <i class="parameter"><tt>[homes]</tt></i> share, as recommended in
|
||
the <tt class="filename">smb.conf</tt> man page.
|
||
</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="locking.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="InterdomainTrusts.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 14. File and Record Locking </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 16. Interdomain Trust Relationships</td></tr></table></div></body></html>
|