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 + *
