During the past week, our engineering team and I have been having a discussion about what to do about a problem involving the use of Microsoft SMS to patch laptops connected via SSL VPN.  The issue is the apparent requirement that we open NetBIOS ports through the SSL VPN device so SMS can communicate with its client-side agents.  Repeated discussions with Microsoft haven’t turned up any alternatives.  So what’s the problem?  Why not allow NetBIOS traffic to and from the Internet?

What is NetBIOS
NetBIOS is a transport protocol that Microsoft Windows systems use to share resources.  For example, if a PC running Windows wants to connect to and access a share on a file server, it probably uses NetBIOS.  There have been some changes in recent days, however, that allow this connection without it.  SMB, the method used to access file and printer shares, can also run independently of NetBIOS over TCP ports 139 and 445.  Both of these approaches, however, tend to increase the attack surface of a network.

The ports that we’d have to open to the Internet are UDP/137, UDP/138, and TCP/139.  Unfortunately, the most popular attacker target is NetBIOS and against these ports.  I’m going to use the vulnerabilities associated with port 139 to demonstrate how an attacker can use NetBIOS to plan and execute an attack against an organization’s network.

Once an attacker discovers an active port 139 on a device, he can run NBSTAT to begin the very important first step of an attack—footprinting.  With the NBSTAT command, he can obtain some or all of the following information:

  • Computer name
  • Contents of the remote name cache, including IP addresses
  • A list of local NetBIOS names
  • A list of names resolved by broadcast or via WINS
  • Contents of the session table with the destination IP addresses

With this information, the attacker has information about the OS, services, and major applications running on the system.  He also has private IP addresses that the LAN/WAN and security engineers have tried hard to hide behind NAT.  And that’s not all.  The lists provided by running NBSTAT also include user IDs.

If null sessions are allowed against IPC$, it isn’t difficult to take the next step and connect to the target device.  This connection provides a list of all available shares.

Defending against external NetBIOS connections
If NetBIOS has to be allowed, the first step is to ensure that only a very small number of devices are accessible.  As you’ll see, leaving your network open to external NetBIOS traffic significantly increases the complexity of system hardening.  Complexity is the enemy of system assurance.

Next, ensure that the exposed systems are hardened by,

  • Disabling the system’s ability to support null sessions
  • Defining very strong passwords for the local administrator accounts
  • Defining very strong passwords for shares, assuming you absolutely have to have shares on exposed systems
  • Keeping the Guest account disabled
  • Under no circumstances allowing access to the root of a hard drive via a share
  • Under no circumstances sharing the Windows or WinNT directories or any directory located beneath them
  • Crossing your fingers

So now what
So it’s possible to open the perimeter to NetBIOS traffic—possible but not very smart.  In my opinion, the only systems that should be exposed to this type of traffic should be locked down tight.  Further, the more systems exposed the greater the chance that something will be missed, allowing an attacker to gain a foothold.  I’m not alone in coming to this conclusion.

In an article titled “A Quantitative Study of Firewall Configuration Errors”, Avishai Wool of Tel Aviv University, lists leaving the NetBIOS service open on the perimeter as number eight in his list of the top twelve firewall configuration errors.  Wool wrote, “These frequently attacked services are very insecure.  Allowing any NetBIOS service to cross the firewall in any direction is an error” (Computer, June 2004, p. 62).

And let’s not omit Microsoft’s position on this.  The following is from Microsoft’s “Threats and CounterMeasures Guide”:

“To help secure [an exposed system], you can greatly reduce its attack surface if you disable server message block (SMB) and NetBIOS over TCP/IP. It will be difficult to manage servers that operate under this configuration, and they will be unable to access folders shared on the network. However, these measures effectively protect the server from compromise through the SMB and NetBIOS protocols. Therefore, you should disable SMB and NetBIOS over TCP/IP for network connections on servers that are accessible from the Internet” (p. 301).

This is okay for servers in the DMZ, but we would face some network and access functionality issues if we took this step for our internal systems.

So is it okay to open up the perimeter to NetBIOS traffic so SMS can access our remote systems?  Under the circumstances, I think I’ll stick with my original position—no way.