diff options
Diffstat (limited to 'docs/Samba-HOWTO-Collection/TOSHARG-Securing.xml')
| -rw-r--r-- | docs/Samba-HOWTO-Collection/TOSHARG-Securing.xml | 366 |
1 files changed, 366 insertions, 0 deletions
diff --git a/docs/Samba-HOWTO-Collection/TOSHARG-Securing.xml b/docs/Samba-HOWTO-Collection/TOSHARG-Securing.xml new file mode 100644 index 0000000000..b8d65c08ae --- /dev/null +++ b/docs/Samba-HOWTO-Collection/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> |