Alright, here's the setup:
Internet -> Modem -> WRT54G -> hubs -> winxp workstations & linux smb server.
Its basically a home-style distributed internet connection setup, except its at a school. What I want is remote, offsite smb access. I figured I'd need to find out which ports need forwarding and then forward them to the server on the router. I'm told in another question on SF that multiple ports will need forwarding, and it gets somewhat complicated. One of the things I need to know is which ports require forwarding for this, and what complications or vulnerabilities could arise from this. Any additional information you think I should have before doing this would be great. I'm told SMB doesn't support encryption, which is fine. Given I set up authentication/access control, all this means is that once one of my users authenticates and starts downloading data, the unencrypted traffic could be intercepted and read by a MITM, correct? Given that that's the only problem arising from lack of encryption, this is of no concern to me. I suppose that it could also mean a MITM injecting false data into the data stream, eg: user requests file A, MITM intercepts and replaces the contents of file A with some false data. This isn't really an issue either, because my users would know that something was wrong, and its not likely anyone would have incentive to do this anyway.
Another thing I've been informed of is Microsoft's poor implementation of SMB, and its crap track record for security. Does this apply if only the client-end is MS? My server is linux.
Best Answer
The minimum needed to access Windows or Samba shares over a network is port 139 TCP - I've used this to tunnel Samba connections through SSH connections a number of times.
SMB is not an encrypted protocol as you have already found, so I strongly recommend against opening it to the outside world directly instead of allowing users to connect via a secure tunnel such as that provided by SSH or some form of more general VPN. I believe that the authentication method used is safe to perform in the plain (it is a challenge response arrangement that doesn't require plain text credentials to be transferred) so if you can guarantee that content on the shares is not sensitive you can get away with not using a tunnel/VPN but I would still recommend it as an additional level of security if only so that you can control who has access remotely separately from those who have access at all. Also a SSH tunnel or VPN can support compression which will reduce bandwidth requirements when the shares are accessed remotely.
There have been no successful unauthenticated remote attacks reported against Samba in my recent memory, so you are probably safe from that point of view, though again I'd suggest tunnelling the protocol instead of opening it plain. Having port 139 and others open will be an invitation to try if any remotely exploitable issues are found.
Another serious issue will be user password security. If the service is open and a user has an insecure password (either not complex enough, or something guessable by a cracker, and so on) then you have a serious problem. So you need to make sure you have a good password policy in place. Using a VPN like OpenVPN will mitigate this somewhat as people will need to have a keyset for the VPN too, though you can't guarantee that a user will keep their private key safe either...