Blocking of SMB ports (PR#2834)

[Andrew Tridgell]

> ...
> 1. Would blocking only incoming on port 139 allow them to block people from
> opening up their machines to the world, while still allowing me access to
> SMB Servers elsewhere.

yes, that is what many sites do (including ANU where I work). 

It doesn't provide 100% protection though, because of some silly handling
of file: URLs in some versions of internet explorer. If a windows user
happens to browse a malicious web page containing a file: URL that points
to a remote SMB server then the browser will try to automatically connect 
to that server and will quite happily send your username/password without
you even knowing that it has done so! 

Note that not all versions of IE are vulnerable ot this. I don't know
exactly which ones are but it certainly may be a concern to your ISP
if they take the attitude that users should be protected from this sort
of thing. There is a web page somewhere that demonstrates this problem.
It is amazing how many NT administrator passwords they have captured!

An incoming only block will only prevent outside users connecting
in, but as the above problem demonstrates there can be some serious 
implications to allowing access to external SMB servers.

> 2. Do I care about port 137 if I'm not using browsing, simply grabbing
> names from a lmhosts & hosts file?

In general port 137 won't be needed for external access as long as your
PC has some way of resolving the netbios name into a IP address. A lmhosts
file or a sutiably configured nmbd can do this for you (see the dns and wins
proxy options)

There is an exception though! Microsoft introduced a workaround for the fact
that their servers require the client to know the netbios name of the server
being connected to (Samba accepts connections as any netbios name). The
workaround involves sending a netbios name status request (on UDP port 137)
for the name '*' then parsing the resulting name list to guess the remote
netbios name. This method fails when the UDP 137 is blocked because of a bug
in almost all MS servers that cause them to always send the reply to port
137 no matter what port number the query comes from. The end result is that
if your client uses this method (I think NT 4 might use this) then it will
fail if your ISP blocks incoming UDP 137 packets.

> 3. Are M$ Clients and Servers and Samba only generating noise on port 137
> when nothing is actually being done (nothing on port 139)?

no. The browse protocol uses UDP/137, UDP/138 and TCP/139, all intermingled
in a rather messy way :-)

So while idle you get browse synchronisation stuff on TCP/139 (the equivalent
of "smbclient -L" calls) plus browse announcements and elections on UDP/138
plus name resolution and registration requests on UDP/137.

Hours of fun can be had staring at sniffer output on an idle SMB network!

> Basically I want to know if they block all traffic on port 137 and incoming
> on 139 I will still be able to access remote SMB servers, but no one will
> be able access my machine with SMB and there will be no traffic when things
> aren't actually happening (for auto-dialling systems).

that's pretty close. Make sure that the UDP background noise doesn't trigger
a auto-dial (block it) and be aware of the file: traps. If UDP/138 doesn't
get through then no browse synch will happen on TCP/139 so all will be quiet
when it is idle. You will get "keep alives" on any actively mounted
connections of course, but that's all.

Cheers, Andrew