Preventing Access by Clients on Unauthorized Subnets

A special-purpose server on our network has stringent security requirements. I use a router in front of this server to block all but one authorized subnet from sending packets to ports 137 through 139 on this server, yet Windows 2000 clients that are on unauthorized subnets can still access shared folders on the server. (Non-Win2K—e.g., Windows NT—clients on an unauthorized subnet can't access shared folders.) What am I missing?

Until Win2K, all Windows clients used NetBIOS over TCP/IP (NetBT) to handle file-and-print sharing. NetBT uses TCP ports 137 through 139 as well as UDP ports 137 through 139. To eliminate the shortcomings of NetBIOS and better support DNS, Microsoft enabled Win2K support for Server Message Block (SMB) file-and-print sharing directly on TCP through port 445. (For more information about SMB over TCP/IP, see the Microsoft article "Direct Hosting of SMB Over TCP/IP" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q204279.)

When a Win2K client tries to access a shared folder on a server, the client attempts to connect simultaneously to ports 139 and 445. (By trying both ports, a Win2K client can access Win2K or NT file servers.) If the server responds on port 445, the client sends a reset to the server's port 139 and sets up the SMB session on port 445. Win2K clients in unauthorized subnets can connect because they use port 445 to sneak past your packet filtering. NT clients know nothing about direct hosting of SMB on TCP, so they try to connect only through port 139 and are blocked. If you block incoming traffic to port 445 as well, you should be in good shape.

—Randy Franklin Smith