diff options
Diffstat (limited to 'docs/docbook/projdoc/securing-samba.xml')
| -rw-r--r-- | docs/docbook/projdoc/securing-samba.xml | 364 |
1 files changed, 0 insertions, 364 deletions
diff --git a/docs/docbook/projdoc/securing-samba.xml b/docs/docbook/projdoc/securing-samba.xml deleted file mode 100644 index 52e07f2206e..00000000000 --- a/docs/docbook/projdoc/securing-samba.xml +++ /dev/null @@ -1,364 +0,0 @@ -<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>[IPC$]</smbconfsection> -auto-share. The <smbconfsection>[IPC$]</smbconfsection> 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"/>. -</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</name></smbconfoption> and - <smbconfoption><name>hosts deny</name></smbconfoption> 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</name><value>127.0.0.1 192.168.2.0/24 192.168.3.0/24</value></smbconfoption> -<smbconfoption><name>hosts deny</name><value>0.0.0.0/0</value></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>[global]</smbconfsection> section put: - </para> - - <para><smbconfblock> -<smbconfoption><name>valid users</name><value>@smbusers, jacko</value></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</name><value>eth* lo</value></smbconfoption> -<smbconfoption><name>bind interfaces only</name><value>yes</value></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 untrustworthy - hosts. - </para> - - <para> - To do this you could use: - </para> - - <para><smbconfblock> -<smbconfsection>[IPC$]</smbconfsection> -<smbconfoption><name>hosts allow</name><value>192.168.115.0/24 127.0.0.1</value></smbconfoption> -<smbconfoption><name>hosts deny</name><value>0.0.0.0/0</value></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</name><value>%S</value></smbconfoption> - option in the <smbconfsection>[homes]</smbconfsection> share definition. - </para> - - <para> - The <smbconfoption><name>only user</name><value></value></smbconfoption> works in conjunction with the <smbconfoption><name>users</name><value>list</value></smbconfoption>, - so to get the behavior you require, add the line : - <smbconfblock> -<smbconfoption><name>users</name><value>%S</value></smbconfoption> -</smbconfblock> - this is equivalent to adding - <smbconfblock> -<smbconfoption><name>valid users</name><value>%S</value></smbconfoption> - </smbconfblock> - to the definition of the <smbconfsection>[homes]</smbconfsection> share, as recommended in - the &smb.conf; man page. - </para> - </sect2> - -</sect1> -</chapter> |