Although Microsoft supports a number of services that are directly based on TCP/IP, many older services are based on NetBIOS and use NetBT on TCP/IP networks. This provides an additional layer of portability for the services, which can run on TCP/IP networks or NetBEUI networks without the difference being visible to the application.
NetBT provides three services:
NetBIOS name service
Datagram service
Session service
Name service is at UDP port 137 and is used to do name resolution; see Chapter 20, for more information. NetBT datagram service is at UDP port 138 and is the NetBT equivalent of UDP, used for connectionless transactions. NetBT session service is at TCP port 139. NetBT datagram and session service are both used primarily for protocols based on Server Message Block (SMB), which is discussed later in this chapter.
NetBT doesn't actually provide much by itself. NetBT is simply a way of running NetBIOS over TCP/IP, and almost all interesting work is done by higher-level protocols (nearly always SMB). NetBT session connections do provide an extremely minimal level of security. A requester must specify the NetBIOS name and the TCP/IP address that it wants to connect to, as well as the requester's NetBIOS name and TCP/IP address. The connection can't be made unless some program has registered to respond to the specified NetBIOS name. NetBT applications could perform authorization based on the requester's NetBIOS name and/or TCP/IP address, but in practice, this is rare. (Since both of these are trivially forgeable in any case, it's just as well.)
NetBT session service can also act as a sort of locator service. An application that's registering to respond to a name can specify another IP address and port number. When a client attempts to connect, it will initially talk to a NetBT session at port 139, but the NetBT session server will provide another IP address and port number. The client will then close the initial connection and open a new connection (still using the NetBT session protocol) to the new IP address and port number. This is intended to support operating systems where open TCP/IP connections can't be transferred between applications, so that the NetBT session server can't simply transfer the connection to a listener. It is not a feature in widespread use.
NetBT datagram service also includes a source and destination NetBIOS name (although not TCP/IP address information). NetBT datagrams may be broadcast, multicast, or sent to a specific destination. The receiving host looks at the destination NetBIOS name to decide whether or not to process the datagram. This feature is sometimes used instead of name resolution. Rather than trying to find an address for a particular name, clients of some protocols send a broadcast packet and assume that the relevant host will answer. This will work only if broadcast traffic from the client can reach the server. We point out protocols where this feature is commonly used.
NetBT name service is covered in Chapter 20. NetBT datagram service uses UDP port 138; session service uses TCP port 139.[3] NetBT session service is always directed to a specific host, but NetBT datagram service may be broadcast. If redirection is in use, NetBT session connections may legitimately be made with any destination port. Fortunately, this is rare and will not happen on Windows NT or Unix NetBT servers.
Direction | Source Addr. | Dest. Addr. | Protocol | Source Port | Dest. Port | ACK Set | Notes |
|---|---|---|---|---|---|---|---|
In | Ext | Int | UDP | >1023 | 138 | [4] | Request, external client to internal NetBT datagram server |
Out | Int | Ext | UDP | 138 | >1023 | Response, internal NetBT datagram server to external client | |
Out | Int | Ext | UDP | >1023 | 138 | Request, internal client to external NetBT datagram server | |
In | Ext | Int | UDP | 138 | >1023 | Response, external NetBT datagram server to internal client | |
In | Ext | Int | TCP | >1023 | 139 | [5] | Request, external client to internal NetBT session server |
Out | Int | Ext | TCP | 139 | >1023 | Yes | Response, internal NetBT session server to external client |
Out | Int | Ext | TCP | >1023 | 139 | Request, internal client to external NetBT session server | |
In | Ext | Int | TCP | 139 | >1023 | Yes | Response, external NetBT session server to internal client |
[4] UDP has no ACK equivalent. [5] ACK will not be set on the first packet (establishing connection) but will be set on the rest. | |||||||
NetBT session service would be quite easy to proxy, and NetBT datagram service is designed to be proxied. Proxying NetBT will not increase security much, although it will allow you to avoid some sorts of forgery and probably some denial of service attacks based on invalid NetBT datagrams.
Although NetBT does have embedded IP addresses, they do not usually pose a problem for network address translation systems. There are two places where IP addresses are embedded: session service redirections and datagrams. Session service redirection is almost never used, and the embedded IP addresses in datagrams are supposed to be used only for client identification, and not for communication. Replies are sent to the IP source address, not the embedded source.
In some situations, changes in port numbers can be a problem because some implementations respond to port 138 for datagram service, ignoring both the IP source port and the embedded NetBT source port. Fortunately, these older implementations are becoming rare.