Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 4 down vote accepted

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...

share|improve this answer
Would FTP be any better? – EternallyGreen Jul 6 '09 at 11:51
No - FTP is not secure (everything, including authentication, is sent in plain) and can be a pain with firewalls due to its multiple-connections-for-a-single-session nature. SFTP/SCP as provided by most SSH services would be a good alternative to FTP or Samba without a tunnel/VPN arrangement. – David Spillett Jul 6 '09 at 12:31

you definitively do not want to do it... at least not to windows. ports to forward [both samba and windows]: tcp 135, 139, 445. possibly - but not necesarly 135-139 udp.

part for accessing windows workstation

135, 445 tcp are multiplexed for plenty of purposes - including remote registry access, remote management, communication with domain controllers. they are target for plenty of warms exploiting older vulnerabilities. more bugs will probably show up sooner or later.. you do not want to get exposed to them.

i suggest you only forward port 3389 tcp [ remote desktop ] and use 'local resource sharing' of disks via remote desktop connection. this protocol seems to be less exploited than microsoft's smb/rpc. if possible use some different port, limit connections to trusted source range of ips and - preferably dont do it at all, use vpn for instance openvpn.

part for accessing linux box

that's other story - i would not be so scared of exploiting samba, but still - data would go unencrypted over wild internet. i think really vpn terminated on linux would be nice. if it's impossible - just smbmount windows shares on linux, make them available over scp from linux, redirect port 22 on the router - you can use winscp to access your files but have quite a lot peace of mind.

share|improve this answer
What do you mean "to windows"? Can you use more specific terminology, like "server" and "client"? THanks. – EternallyGreen Jul 6 '09 at 11:43
Oh, do you mean that the kids would all have to forward ports on their home routers to access as a client? If so, then Fffffffff......orget that! – EternallyGreen Jul 6 '09 at 11:45
you'd forward ports only to the computer that will have ssh server [ linux box ], you'd be connecting only to it and from it reaching other network shares you have at home. – pQd Jul 6 '09 at 13:09

You'll need port forwarding for 135,137-139, and 445.

CIFS (and LANMAN and Co.) all have one thing in common when you expost them to the internet:

They are trouble waiting to happen.

  • LANMAN/SMB hashes can be easily broken in a reasonable time
  • CIFS can still be attacked like any other service (dictionary, brute-force, etc.)
  • A single attempt to log in as an administrator will result in the administrator's hash being transmitted if you are using LANMAN/SMB
  • Nothing says hacker 'lovin like exposing a service that provides total administrative access to servers (instead of narrowing the focus of access)
  • Having both the admin password (from the mentioned transmitt/crack) and access to the service that will accept that password with loving arms: priceless.
share|improve this answer

One way to port forward CIFS and other protocols is through SSH.

SSH allows the use of keys and encrypted authentication, with the convenience of adhoc TCP tunnelling ensures that one would hardly need to open any ports except SSH (and maybe FTP and such) through the NAT.

But if you need permanent SMB connection over WAN, better way is to invest in a VPN infrastructure.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.