Under "NetBIOS settings", click on "Disable NetBIOS over TCP/IP"įinally, we can install stunnel (Windows binaries are available from ?1().Choose any private network IP address you'll never see in any real network.Select "TCP/IP", and then "settings" (or "properties").Typically you'll need to deselect "client for Microsoft networks" and "File and printer sharing". Deselect all bindings except the TCP/IP ones.Open the "properties" dialog from the contextmenu in the "network connections" overview. When our new "hardware" is installed, you need to assign it an IP and disable NetBIOS activity on it: Don't let windows search for the hardware but choose it from a list ("Advanced").Pick "add a new device" from the bottom of the list.Tell it "yes, I've already connected my hardware" or the wizard will end.Wait for it to search in vain for new hardware.Open the "add hardware" wizard from the control panel.To install one, follow this set of instructions: It turns out that it doesn't do this on loopback network devices. Simply binding stunnel to port 139 is impossible, because of the Windows behaviour where it binds ports 139 and 445 on every interface, even if no actual files are being shared. We will "abuse" this behaviour by tricking it into using this port. Only when that has no service listening either, it will tell the user it couldn't connect. When it finds no service listening there, it will try to fall back to port 139. Luckily for us, Windows has the following odd behaviour: When you click "map network drive" in the filemanager, it will first try to connect to port 445. Unfortunately, the Windows filemanager has no way to specify which port to use when you click "map network drive", so that's not an option. This would mean we need to use another port for our fake "shared folder". (try it, you'll get a "permission denied" message). This means that no other process can ever bind this port. Some background on why this is a problem is in order.Īpparently, when Windows is booted, the kernel binds a socket to port 445 on every real (this is important as we'll see later on) network interface. Of course you can easily test it by connecting to localhost: # smbclient -U yoda //localhost/myshareĬonnecting a Windows client to samba over stunnel is a major hassle. You can run stunnel from rc.conf just like on the server side. As soon as you connect to your machine, the data is encrypted and forwarded to servername. This makes your client act as a samba server, to which you can connect. You'll need to swap the port numbers and put it in client mode. On a Unix client you simply install and run security/stunnel as described above. Even if it gets an error it will just fail silently. Just add stunnel=yes to your /etc/rc.conf: # echo "stunnel=yes" > /etc/rc.conf This can be generated like this: # openssl req -new -nodes -x509 -out stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem # instead of port 139, port 445 will also work, unless you're using Mac OS X clientsĪs you can see, you'll need an SSL certificate/key. # Accept connections on port 800, on any interface The following will be sufficient if you only need the bare minimum to get a secure samba setup: Simple stunnel configuration for a secure samba setup # OpenSSL certificate Then you can copy /usr/pkg/share/examples/stunnel/nf-sample and modify it to your needs. You can install security/stunnel from ?pkgsrc. If you wish to allow only secure traffic, you can let it listen on localhost with the following statement in smb.conf: # Only listen on loopback interface You set up the server just as you would normally, as described in How to set up a Samba Server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |