summaryrefslogtreecommitdiff
path: root/docs/Samba3-HOWTO/TOSHARG-Securing.xml
diff options
context:
space:
mode:
authorJelmer Vernooij <jelmer@samba.org>2005-06-10 20:29:09 +0000
committerGerald W. Carter <jerry@samba.org>2008-04-23 08:46:44 -0500
commit06aa63b6f19131071800985746b445dee42d91eb (patch)
tree5f7aaa77fc7375919463ae40d05933d44688f071 /docs/Samba3-HOWTO/TOSHARG-Securing.xml
parentb82eb1abe3641a80ad6f431dd2fd625dc229eaed (diff)
downloadsamba-06aa63b6f19131071800985746b445dee42d91eb.tar.gz
samba-06aa63b6f19131071800985746b445dee42d91eb.tar.bz2
samba-06aa63b6f19131071800985746b445dee42d91eb.zip
Large number of small fixes to the layout and the build system.
(This used to be commit 73fac0653c774a8ed8654b064fd63d4e486f6b0f)
Diffstat (limited to 'docs/Samba3-HOWTO/TOSHARG-Securing.xml')
-rw-r--r--docs/Samba3-HOWTO/TOSHARG-Securing.xml366
1 files changed, 366 insertions, 0 deletions
diff --git a/docs/Samba3-HOWTO/TOSHARG-Securing.xml b/docs/Samba3-HOWTO/TOSHARG-Securing.xml
new file mode 100644
index 0000000000..b8d65c08ae
--- /dev/null
+++ b/docs/Samba3-HOWTO/TOSHARG-Securing.xml
@@ -0,0 +1,366 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
+<chapter id="securing-samba">
+
+<chapterinfo>
+ &author.tridge;
+ &author.jht;
+ <pubdate>May 26, 2003</pubdate>
+</chapterinfo>
+
+<title>Securing Samba</title>
+
+<sect1>
+<title>Introduction</title>
+<para>
+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.
+</para>
+
+<blockquote>
+<para>
+A new apprentice reported for duty to the chief engineer of a boiler house. He said, <quote>Here I am,
+if you will show me the boiler I'll start working on it.</quote> Then engineer replied, <quote>You're leaning
+on it!</quote>
+</para>
+</blockquote>
+
+<para>
+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.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Features and Benefits</title>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+Samba may be secured from connections that originate from outside the local network. This may be
+done using <emphasis>host-based protection</emphasis> (using Samba's implementation of a technology
+known as <quote>tcpwrappers,</quote> or it may be done be using <emphasis>interface-based exclusion</emphasis>
+so &smbd; will bind only to specifically permitted interfaces. It is also
+possible to set specific share or resource-based exclusions, for example on the <smbconfsection name="[IPC$]"/>
+auto-share. The <smbconfsection name="[IPC$]"/> share is used for browsing purposes as well as to establish
+TCP/IP connections.
+</para>
+
+<para>
+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">File, Directory and Share Access Controls</link>.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Technical Discussion of Protective Measures and Issues</title>
+
+<para>
+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.
+</para>
+
+ <sect2>
+ <title>Using Host-Based Protection</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ One of the simplest fixes in this case is to use the <smbconfoption name="hosts allow"/> and
+ <smbconfoption name="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:
+ </para>
+
+ <para><smbconfblock>
+<smbconfoption name="hosts allow">127.0.0.1 192.168.2.0/24 192.168.3.0/24</smbconfoption>
+<smbconfoption name="hosts deny">0.0.0.0/0</smbconfoption>
+ </smbconfblock></para>
+
+ <para>
+ The above will only allow SMB connections from <constant>localhost</constant> (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 <errorname>not listening on called name</errorname> error.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>User-Based Protection</title>
+
+ <para>
+ If you want to restrict access to your server to valid users only, then the following
+ method may be of use. In the &smb.conf; <smbconfsection name="[global]"/> section put:
+ </para>
+
+ <para><smbconfblock>
+<smbconfoption name="valid users">@smbusers, jacko</smbconfoption>
+ </smbconfblock></para>
+
+ <para>
+ This restricts all server access to either the user <emphasis>jacko</emphasis>
+ or to members of the system group <emphasis>smbusers</emphasis>.
+ </para>
+
+ </sect2>
+
+ <sect2>
+
+ <title>Using Interface Protection</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ You can change this behavior using options like this:
+ </para>
+
+ <para><smbconfblock>
+<smbconfoption name="interfaces">eth* lo</smbconfoption>
+<smbconfoption name="bind interfaces only">yes</smbconfoption>
+ </smbconfblock></para>
+
+ <para>
+ This tells Samba to only listen for connections on interfaces with a
+ name starting with <constant>eth</constant> such as <constant>eth0, eth1</constant> plus on the loopback
+ interface called <constant>lo</constant>. 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.
+ </para>
+
+ <para>
+ If you use the above and someone tries to make an SMB connection to
+ your host over a PPP interface called <constant>ppp0,</constant> 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.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>Using a Firewall</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ If you are setting up a firewall, you need to know what TCP and
+ UDP ports to allow and block. Samba uses the following:
+ </para>
+
+ <simplelist>
+ <member>UDP/137 - used by nmbd</member>
+ <member>UDP/138 - used by nmbd</member>
+ <member>TCP/139 - used by smbd</member>
+ <member>TCP/445 - used by smbd</member>
+ </simplelist>
+
+ <para>
+ 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.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>Using IPC$ Share-Based Denials </title>
+
+ <para>
+ 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 un-trustworthy
+ hosts.
+ </para>
+
+ <para>
+ To do this you could use:
+ </para>
+
+ <para><smbconfblock>
+<smbconfsection name="[IPC$]"/>
+<smbconfoption name="hosts allow">192.168.115.0/24 127.0.0.1</smbconfoption>
+<smbconfoption name="hosts deny">0.0.0.0/0</smbconfoption>
+ </smbconfblock></para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ If you use this method, then clients will be given an <errorname>`access denied'</errorname>
+ 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.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>NTLMv2 Security</title>
+
+ <para>
+ To configure NTLMv2 authentication, the following registry keys are worth knowing about:
+ </para>
+
+ <para>
+ <screen>
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
+ "lmcompatibilitylevel"=dword:00000003
+ </screen>
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ <screen>
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
+ "NtlmMinClientSec"=dword:00080000
+ </screen>
+ </para>
+
+ <para>
+ 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.
+ </para>
+ </sect2>
+</sect1>
+
+<sect1>
+<title>Upgrading Samba</title>
+
+<para>
+Please check regularly on <ulink noescape="1" 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.
+</para>
+
+</sect1>
+
+<sect1>
+<title>Common Errors</title>
+
+<para>
+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.
+</para>
+
+ <sect2>
+ <title>Smbclient Works on Localhost, but the Network Is Dead</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ </sect2>
+
+ <sect2>
+ <title>Why Can Users Access Home Directories of Other Users?</title>
+
+ <para>
+ <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.
+ </quote>
+ </para>
+
+ <para><quote>
+ User xyzzy can map his home directory. Once mapped user xyzzy can also map
+ anyone else's home directory.
+ </quote></para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ If your UNIX home directories are set up so that one user can happily <command>cd</command>
+ into another users directory and execute <command>ls</command>, the UNIX security solution is to change file
+ permissions on the user's home directories such that the <command>cd</command> and <command>ls</command> are denied.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Samba allows the behavior you require. Simply put the <smbconfoption name="only user">%S</smbconfoption>
+ option in the <smbconfsection name="[homes]"/> share definition.
+ </para>
+
+ <para>
+ The <smbconfoption name="only user"></smbconfoption> works in conjunction with the <smbconfoption name="users">list</smbconfoption>,
+ so to get the behavior you require, add the line :
+ <smbconfblock>
+<smbconfoption name="users">%S</smbconfoption>
+</smbconfblock>
+ this is equivalent to adding
+ <smbconfblock>
+<smbconfoption name="valid users">%S</smbconfoption>
+ </smbconfblock>
+ to the definition of the <smbconfsection name="[homes]"/> share, as recommended in
+ the &smb.conf; man page.
+ </para>
+ </sect2>
+
+</sect1>
+</chapter>