summaryrefslogtreecommitdiff
path: root/docs/htmldocs/securing-samba.html
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2003-08-15 18:26:34 +0000
committerJelmer Vernooij <jelmer@samba.org>2003-08-15 18:26:34 +0000
commitd069dacb6e17866dd5d3862e1837a9cae008644f (patch)
treec1b660005d31583819c7f43f79168a3332150a85 /docs/htmldocs/securing-samba.html
parentcedd66b6e67f4c463eaa072f0e6d87ee1f55718e (diff)
downloadsamba-d069dacb6e17866dd5d3862e1837a9cae008644f.tar.gz
samba-d069dacb6e17866dd5d3862e1837a9cae008644f.tar.bz2
samba-d069dacb6e17866dd5d3862e1837a9cae008644f.zip
Regenerate docs
(This used to be commit dc33e94161e4fc1ca6bf66a321c708c89bb276e3)
Diffstat (limited to 'docs/htmldocs/securing-samba.html')
-rw-r--r--docs/htmldocs/securing-samba.html192
1 files changed, 192 insertions, 0 deletions
diff --git a/docs/htmldocs/securing-samba.html b/docs/htmldocs/securing-samba.html
new file mode 100644
index 0000000000..492780765e
--- /dev/null
+++ b/docs/htmldocs/securing-samba.html
@@ -0,0 +1,192 @@
+<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="samba-doc.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">&lt;<a href="mailto:tridge@samba.org">tridge@samba.org</a>&gt;</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">&lt;<a href="mailto:jht@samba.org">jht@samba.org</a>&gt;</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#id2910685">Introduction</a></dt><dt><a href="securing-samba.html#id2910722">Features and Benefits</a></dt><dt><a href="securing-samba.html#id2910796">Technical Discussion of Protective Measures and Issues</a></dt><dd><dl><dt><a href="securing-samba.html#id2910816">Using host based protection</a></dt><dt><a href="securing-samba.html#id2910915">User based protection</a></dt><dt><a href="securing-samba.html#id2910975">Using interface protection</a></dt><dt><a href="securing-samba.html#id2911042">Using a firewall</a></dt><dt><a href="securing-samba.html#id2911098">Using a IPC$ share deny</a></dt><dt><a href="securing-samba.html#id2911187">NTLMv2 Security</a></dt></dl></dd><dt><a href="securing-samba.html#id2911245">Upgrading Samba</a></dt><dt><a href="securing-samba.html#id2911271">Common Errors</a></dt><dd><dl><dt><a href="securing-samba.html#id2911289">Smbclient works on localhost, but the network is dead</a></dt><dt><a href="securing-samba.html#id2911314">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="id2910685"></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><p>
+A new apprentice reported for duty to the Chief Engineer of a boiler house. He said, &quot;Here I am,
+if you will show me the boiler I'll start working on it.&quot; Then engineer replied, &quot;You're leaning
+on it!&quot;
+</p><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="id2910722"></a>Features and Benefits</h2></div></div><div></div></div><p>
+There are three level at which security principals must be observed in order to render a site
+at least moderately secure. These 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 &quot;tcpwrappers&quot;, or it may be done be using <span class="emphasis"><em>interface based exclusion</em></span>
+so that <span class="application">smbd</span> will bind only to specifically permitted interfaces. It is also
+possible to set specific share or resource based exclusions, eg: 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 way of setting Access Control Entries in an Access
+Control List on the shares themselves. This is discussed in the chapter on File, Directory and Share Access
+Control.
+</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2910796"></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="id2910816"></a>Using host based protection</h3></div></div><div></div></div><p>
+ 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.
+ </p><p>
+ One of the simplest fixes in this case is to use the <a class="indexterm" name="id2910838"></a><i class="parameter"><tt>hosts allow</tt></i> and
+ <a class="indexterm" name="id2910852"></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 'localhost' (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 a
+ <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="id2910915"></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>
+ What this does is, it 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="id2910975"></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 behaviour using options like the following:
+ </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 '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.
+ </p><p>
+ If you use the above and someone tries to make a SMB connection to
+ your host over a PPP interface called 'ppp0' 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="id2911042"></a>Using a firewall</h3></div></div><div></div></div><p>
+ 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.
+ </p><p>
+ 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:
+ </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="id2911098"></a>Using a IPC$ share deny</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 that 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 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.
+ </p><p>
+ If you use this method then clients will be given a <span class="errorname">access denied</span>
+ 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.
+ </p><p>
+ 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="id2911187"></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]
+ &quot;lmcompatibilitylevel&quot;=dword:00000003
+ </pre><p>
+ </p><p>
+ 0x3 - 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]
+ &quot;NtlmMinClientSec&quot;=dword:00080000
+ </pre><p>
+ </p><p>
+ 0x80000 - NTLMv2 session security. If either NtlmMinClientSec or
+ NtlmMinServerSec is set to 0x80000, 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="id2911245"></a>Upgrading Samba</h2></div></div><div></div></div><p>
+Please check regularly on <a href="http://www.samba.org/" target="_top">http://www.samba.org/</a> 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="id2911271"></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 then 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 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="id2911289"></a>Smbclient works on localhost, but the network is dead</h3></div></div><div></div></div><p>
+ This is a very common problem. Red Hat Linux (as do others) will install a default firewall.
+ With the default firewall in place only traffic on the loopback adapter (IP address 127.0.0.1)
+ will be allowed through the firewall.
+ </p><p>
+ The solution is either to remove the firewall (stop it) or to 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="id2911314"></a>Why can users access home directories of other users?</h3></div></div><div></div></div><p>
+ &#8220;<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 that I can
+ use to configure samba to enforce that only a user may map their own
+ home directory.
+ </span>&#8221;
+ </p><p>&#8220;<span class="quote">
+ User xyzzy can map his home directory. Once mapped user xyzzy can also map
+ *anyone* else's home directory!
+ </span>&#8221;</p><p>
+ This is not a security flaw, it is by design. Samba allows
+ users to have *exactly* the same access to the UNIX filesystem
+ as they would if 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>
+ This means that if your UNIX home directories are set up
+ such that one user can happily cd into another users
+ directory and do an ls, the UNIX security solution is to
+ change the UNIX file permissions on the users home directories
+ such that the cd and ls would be 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 does allow the setup you require when you have set the
+ <a class="indexterm" name="id2911373"></a><i class="parameter"><tt>only user</tt></i> = yes option on the share, is that you have not set the
+ valid users list for the share.
+ </p><p>
+ Note that only user works in conjunction with the users= 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:
+ </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="samba-doc.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 16. Interdomain Trust Relationships</td></tr></table></div></body></html>