svn commit: samba-web r320 - in trunk/docs: .

[deryck at samba.org]

Author: deryck
Date: 2004-09-10 21:25:29 +0000 (Fri, 10 Sep 2004)
New Revision: 320

WebSVN: http://websvn.samba.org/websvn/changeset.php?rep=samba-web&path=/trunk/docs&rev=320&nolog=1

Log:

First pass at adding a permanent copy of the notes
on "Protecting an unpatched Samba server" found in
older release notes.

--deryck

Added:
   trunk/docs/server_security.html


Changeset:
Added: trunk/docs/server_security.html
===================================================================
--- trunk/docs/server_security.html	2004-09-09 13:49:54 UTC (rev 319)
+++ trunk/docs/server_security.html	2004-09-10 21:25:29 UTC (rev 320)
@@ -0,0 +1,144 @@
+<!--#include virtual="/samba/header.html" -->
+<title>Samba Server Security</title>
+<!--#include virtual="header_docs.html" -->
+
+  <h2>Protecting an unpatched Samba server</h2>
+
+
+  <p>This following instructions will help provide your Samba server some
+  protection against security vulnerabilities if you are unable to (or until
+  you are able to) upgrade to the patched version. Even if you do upgrade 
+  you might like to thinkabout the suggestions here to provide you with
+  additional levels of protection.</p>
+
+
+  
+  <h4>Using host based protection</h4>
+  
+  <p>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.</p>
+
+  <p>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:</p>
+
+<pre>
+    hosts allow = 127.0.0.1 192.168.2.0/24 192.168.3.0/24
+    hosts deny = 0.0.0.0/0
+</pre>
+
+  <p>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.</p>
+
+
+  
+  <h4>Using interface protection</h4>
+  
+  <p>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.</p>
+
+  <p>You can change this behavior using options like the
+  following:</p>
+
+<pre>
+    interfaces = eth* lo
+    bind interfaces only = yes
+</pre>
+
+  <p>that 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.</p>
+
+  <p>If you use the above and someone tries to make a SMB
+  connection to your host over a PPP interface called 'ppp0',
+  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.</p>
+
+
+  
+  <h4>Using a firewall</h4>
+  
+  <p>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.</p>
+
+  <p>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:</p>
+
+<pre>
+    UDP/137    - used by nmbd
+    UDP/138    - used by nmbd
+    TCP/139    - used by smbd
+    TCP/445    - used by smbd
+</pre>
+
+  <p>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.</p>
+
+
+  
+  <h4>Using a IPC$ share deny</h4>
+ 
+  <p>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.</p>
+
+  <p>To do that you could use:</p>
+
+<pre>
+    [ipc$]
+        hosts allow = 192.168.115.0/24 127.0.0.1
+        hosts deny = 0.0.0.0/0
+</pre>
+
+  <p>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.</p>
+
+
+  <p>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.</p>
+
+  <p>I don't recommend this method unless you cannot use one of
+  the other methods listed above for some reason.</p>
+
+
+  
+  <h4>Upgrading Samba</h4>
+  
+  <p>Of course the best solution is to upgrade Samba to a version
+  where the bug has been fixed. If you wish to also use one of
+  the additional measures above then that would certainly be a
+  good idea.</p>
+
+  <p>Please check regularly on <a href="http://www.samba.org/">samba.org</a> for updates
+  and important announcements.</p>
+
+<!--#include virtual="/samba/footer.html" -->
\ No newline at end of file


Property changes on: trunk/docs/server_security.html
___________________________________________________________________
Name: svn:executable
   + *