This commit was manufactured by cvs2svn to create branch 'SAMBA_3_0'.(This used to be commit f0d009c3e91979b0dc3443e16f3f545bcc64cfda)

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>