diff options
Diffstat (limited to 'docs/docbook')
| -rw-r--r-- | docs/docbook/projdoc/securing-samba.sgml | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/docs/docbook/projdoc/securing-samba.sgml b/docs/docbook/projdoc/securing-samba.sgml new file mode 100644 index 0000000000..bfedc5456f --- /dev/null +++ b/docs/docbook/projdoc/securing-samba.sgml @@ -0,0 +1,181 @@ +<chapter id="securing-samba"> + +<chapterinfo> + <author> + <firstname>Andrew</firstname><surname>Tridgell</surname> + <affiliation><orgname>Samba Team</orgname></affiliation> + </author> + <pubdate>17 March 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> + +</sect1> + +<sect1> +<title>Using host based protection</title> + +<para> +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. +</para> + +<para> +One of the simplest fixes in this case is to use the 'hosts allow' and +'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><programlisting> + hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24 + hosts deny = 0.0.0.0/0 +</programlisting></para> + +<para> +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 connections as soon +as the client sends its first packet. The refusal will be marked as a +'not listening on called name' error. +</para> + +</sect1> + +<sect1> + +<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 behaviour using options like the following: +</para> + +<para><programlisting> + interfaces = eth* lo + bind interfaces only = yes +</programlisting><para> + +<para> +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. +</para> + +<para> +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 process. +</para> + +</sect1> + +<sect1> +<title>Using a firewall</title> + +<para> +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. +</para> + +<para> +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: +</para> + +<para><programlisting> +UDP/137 - used by nmbd +UDP/138 - used by nmbd +TCP/139 - used by smbd +TCP/445 - used by smbd +</programlisting></para> + +<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> + +</sect1> + +<sect1> +<title>Using a IPC$ share deny</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 that you could use: +</para> + +<para><programlisting> + [ipc$] + hosts allow = 192.168.115.0/24 127.0.0.1 + hosts deny = 0.0.0.0/0 +</programlisting></para> + +<para> +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. +</para> + +<para> +If you use this method then clients will be given a 'access denied' +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. +</para> + +<para> +This is not recommended unless you cannot use one of the other +methods listed above for some reason. +</para> + +</sect1> + +<sect1> +<title>Upgrading Samba</title> + +<para> +Please check regularly on http://www.samba.org/ for updates and +important announcements. Occasionally security releases are made and +it is highly recommended to upgrade Samba when a security vulnerability +is discovered. +</para> + +</sect1> + +</chapter> |