NetBIOS over TCP/IP

NetBIOS over TCP/IP (NBT, or sometimes NetBT) is a networking protocol that allows legacy computer applications relying on the NetBIOS API to be used on modern TCP/IP networks.

NetBIOS was developed in the early 1980s, targeting very small networks (about a dozen computers). Some applications still use NetBIOS, and do not scale well in today's networks of hundreds of computers when NetBIOS is run over NBF. When properly configured, NBT allows those applications to be run on large TCP/IP networks (including the whole Internet, although that is likely to be subject to security problems) without change.

NBT is defined by the RFC 1001 and RFC 1002 standard documents.

Services

NetBIOS provides three distinct services:

NBT implements all of those services.

Name service

In NetBIOS, each participant must register on the network using a unique name of at most 15 characters. In legacy networks, when a new application wanted to register a name, it had to broadcast a message saying "Is anyone currently using that name?" and wait for an answer. If no answer came back, it was safe to assume that the name was not in use. However, the wait timeout was a few seconds, making the name registration a very lengthy process, as the only way of knowing that a name was not registered was to not receive any answer.

NBT can implement a central repository, or Name Service, that records all name registrations. An application wanting to register a name would therefore contact the name server (which has a known network address) and ask whether the name is already registered, using a "Name Query" packet. This is much faster, as the name server returns a negative response immediately if the name is not already in the database, meaning it is available. The Name Service, according to RFCs 1001 and 1002, is called NetBIOS Naming Service or NBNS. Microsoft WINS is an implementation of NBNS. It is worth saying that due to constant development of the way in which the Name Service handles conflict or merges, "group names" varies from vendor to vendor and can even be different by version e.g. with the introduction of a service pack.

The packet formats of the Name Service are identical to DNS. The key differences are the addition of NetBIOS "Node Status" query, dynamic registration and conflict marking packets. They are encapsulated in UDP. Later implementation includes an optional Scope part of the name, making NetBIOS name hierarchical like DNS, but this is seldom used.

In addition, to start a session or to send a datagram to a particular host rather than to broadcast the datagram, NBT will have to determine the IP address of the host with a given NetBIOS name; this is done by broadcasting a "Name Query" packet, and/or sending it to the NetBIOS name server. The response will have the IP address of the host with that name.

It is interesting to note that NBNS is one of the first proper dynamic peer-to-peer distributed name registration services. The NBNS protocol was brought into disrepute by Microsoft: it earned a bad name for being 'chatty', swamping networks with dynamic registration traffic on multiple protocols (IPX/SPX, NBF and TCP/IP) as people badly misconfigured their machines and their networks. The principles implemented in NBNS have been reimplemented many times, including in such systems as ZeroConf and MobileIP.

Datagram distribution service

Datagram mode is "connectionless"; NetBIOS datagrams are sent over UDP. A datagram is sent with a "Direct Unique" or "Direct Group" packet if it's being sent to a particular NetBIOS name, or a "Broadcast" packet if it's being sent to all NetBIOS names on the network.

Session service

Session mode lets two computers establish a connection for a "conversation", allows larger messages to be handled, and provides error detection and recovery.

Sessions are established by exchanging packets. The computer establishing the session attempts to make a TCP connection to port 139 on the computer with which the session is to be established. If the connection is made, the computer establishing the session then sends over the connection a "Session Request" packet with the NetBIOS names of the application establishing the session and the NetBIOS name to which the session is to be established. The computer with which the session is to be established will respond with a "Positive Session Response" indicating that a session can be established or a "Negative Session Response" indicating that no session can be established (either because that computer isn't listening for sessions being established to that name or because no resources are available to establish a session to that name).

Data is transmitted during an established session by Session Message packets.

TCP handles flow control and retransmission of all session service packets, and the dividing of the data stream over which the packets are transmitted into IP datagrams small enough to fit in link-layer packets.

Sessions are closed by closing the TCP connection.

Security vulnerabilities

Web servers are typically - but not exclusively - the first point of impact for internet-based attack vectors. Local area network (LAN) ports, by design, advertise information and consequently often become the focus of the most attacks upon Client-Server networks. Many services that are vulnerable to such means of attack, can - dependent on organizational impact to work-flows - safely be disabled. This is particularly true of network services that are inherently intranet-centric.

Two such vulnerable network protocols that provide services are: the Server Message Block (SMB) protocol and NetBIOS over TCP/IP. Both services can reveal incredible amounts of detailed and vital security information about an exposed network. When not mitigated, NetBIOS over TCP/IP and SMB provide recurring vectors for malicious attacks upon a network. Specifically, NetBIOS provides attackers with a means to map the network and also freely navigate a compromised intranet. In regards to public Web Servers, neither service is necessary for the successful operation of a public Web server and disabling both services in such scenarios can greatly enhance the security status of a network.

Decreasing relevance in post-NT Client-Server Networks

In relation to post-MS Windows 2000 / NT, client-server based networks, NetBIOS is effectively becoming a legacy protocol. NetBIOS was also developed for non-routable LANs. In most post year 2000 networks operating Windows 2000 or later, NetBIOS effectively offers backwards compatibility for network devices that predate compatibility with DNS. A central role of NetBIOS in Client-Server networks (and also those networks that have networked peripheral hardware that also predates DNS compatibility) is to provide name resolution to computers and networked peripherals. Further, it allows for such networked hardware to be accessed and shared and also enables the mapping and browsing of network folders, shares and shared printers, faxes, etc. In its primary capacity, it acts as a session-layer protocol transported over TCP/IP to provide name resolution to a computer and shared folders. To that end, Windows 2000-based, Client-Server networks - and later - do not require this insecure means of name resolving and addressing or navigating of network shares.[1]

Troubleshooting NetBIOS

Nbtstat

Nbtstat is designed to help troubleshoot NetBIOS name resolution problems.[2] When a network is functioning normally, NetBIOS over TCP/IP (NetBT) resolves NetBIOS names to IP addresses. It does this through several options for NetBIOS name resolution, including local cache lookup, WINS server query, broadcast, LMHOSTS lookup, Hosts lookup, and DNS server query.

The nbtstat command removes and corrects preloaded entries using a number of case-sensitive switches. The nbtstat - a < name > command performs a NetBIOS adapter status command on the computer name specified by < name> . The adapter status command returns the local NetBIOS name table for that computer as well as the MAC address of the adapter card. The nbtstat -A < IP address > command performs the same function using a target IP address rather than a name. Nbtstat is a diagnostic tool for NetBIOS over TCP/IP. It is included in several versions of Microsoft Windows. Its primary design is to help troubleshoot NetBIOS name resolution problems.[1]

Path: C:\Windows\System32\nbtstat.exe

Environment: 32-bit

Command processor: C:\Windows\System32\cmd.exe, and not C:\Windows\SysWOW64\cmd.exe

There are several commands involved with Nbtstat that allows several options such as: local cache lookup, WINS Server query, broadcast, LMHOSTS lookup, and Hosts lookup. It is not for DNS server query.[3]

Syntax

nbtstat [-a RemoteName] [-A IPAddress] [-c] [-n] [-r] [-R] [-RR] [-s] [-S] [Interval]

The common parameters are:[4]
nbtstat -c: displays the contents of the NetBIOS name cache, the table of NetBIOS names and their resolved IP addresses.
nbtstat -n: displays the names that have been registered locally on the system.
nbtstat -r: displays the count of all NetBIOS names resolved by broadcast and querying a WINS server.
nbtstat -R: purges and reloads the remote cache name table.
nbtstat -RR: sends name release packets to WINs and then starts Refresh.
nbtstat -s: lists the current NetBIOS sessions and their status, including statistics.
nbtstat -S: lists sessions table with the destination IP addresses.

See also

External links

References

  1. ↑ http://technet.microsoft.com/en-us/library/cc940063.aspx
  2. ↑ Microsoft TechNet Documentation
  3. ↑ "Microsoft Corporation". www.microsoft.com. Retrieved 2016-04-13.
  4. ↑ Microsoft Nbtstat Documentation
This article is issued from Wikipedia - version of the 9/30/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.