The discussion of these NetBIOS packets crops up over and over again on firewall/incident mailing lists. In this section, I've tried to come up with the "definitive" answer to this question.

Note that you will see NetBIOS scans, such as from hackers running the Legion NetBIOS scanner or other scanners. In this case, you'll likely see a scan of your entire address range. The important thing to remember is that few NetBIOS packets are from hostile intent.

We call DNS a directory service, where the word directory has the same meaning as in phone networks. In the U.S., we can dial directory assistance at 411 rather than looking up a name in the phone book. Either way, the goal is to lookup a name, and receive a number.

In a similar manner, sometimes you have a number, and you want to find the name. Let's say that you have caller ID and somebody calls you with the phone number (212) 555-1038. This doesn't tell you who this is, so you want to do the reverse lookup and discover the person's name.

In much the same fashion, the Internet provides a number of capabilities to resolve an IP address into a name.

The key thing to remember about gethostbyaddr() is that it is virtual. It doesn't specify how it resolves an address into a name. In practice, it will use all available mechanisms.

If we look at UNIX, Windows, and Macintosh systems, we see the following techniques:

• DNS in-addr.arpa PTR queries sent to the DNS server
• NetBIOS NodeStatus queries sent to the IP address
• lookups in the /etc/hosts file
• AppleTalk over IP name query sent to the IP address
• RPC query sent to the UNIX NIS server
• NetBIOS lookup sent to the WINS server
• etc.

Windows systems do the /etc/hosts, DNS, WINS, and NodeStatus techniques.

In more excruciating detail, Microsoft has a generic system component called a naming service. All the protocol stacks in the system (NetBIOS, TCP/IP, Novel IPX, AppleTalk, Banyan, etc.) register the kinds of name resolutions they can perform. Some RPC products will likewise register an NIS naming service. When a program requests to resolve an address, this address gets passed onto the generic naming service. Windows will try each registered name resolution subsystem sequentially until it gets an answer. (Side note: User's sometimes complained that accessing Windows servers is slow. This is caused by installing unneeded protocol stacks that must timeout first before the real protocol stack is queried for the server name.).

The order in which it performs these resolution steps for IP addresses can be configured under the Windows registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider. Of course, that doesn't help you the firewall admin.

The process is simply that a program requests the name for an IP address, and sends this request to all the protocol stacks. If the NetBIOS stack receives such a request, it always sends a NetBIOS query to the IP address. It doesn't matter if you have (or haven't) an existing NetBIOS connection to the machine.

In other words, the only requirement necessary in order to receive such packets is that you have an IP address.

ping.exe

If the user executes a ping -a 192.0.2.168, then Windows will attempt to find the name for that address. This doesn't happen so often.

tracert.exe

The traceroute program finds all the hops between the client and the server. Users sometimes do this from the command-line. The most common source of this is from programs that automatically traceroute the servers the user visits. Note that if they are tracing through several hops, you will get separate queries for each hop.

Microsoft's IIS web server

Microsoft's webserver has the option to log the machine name of the client accessing the web site. Each time one of your users behind your firewall browses an IIS-based server, you'll get a query for the name of the user's machine.

Logfile analyzers

Even if name resolution is disabled on the webserver, the site administrator may run the webserver logfiles through a reporting tool like Webtrends. Most of these tools have the ability to resolve IP addresses to names. At this stage, you will see a flury of port 137 packets from the address the tool is run from (which may be different from the original webserver). This is especially a problem because they request such a huge amount of DNS PTR queries that they overwhelm the DNS server. Thus, even though DNS queries would normally be resolved, they might fail during analysis of a log file, thereby generating NetBIOS queries. Since these logfiles analyzers are often run on a scheduled (i.e. nightly) basis, you may see such activity from the same host during the same period of the day.

Client apps

Beyond web browsing, reverse IP name resolution is a fixture in many Windows client apps like IRC, ICQ, and so forth.

Personal firewalls

Personal firewalls will attempt reverse resolution of the IP addresses. The "auto-learning" personal firewalls that prompt the user for each outgoing connection can be particular offenders in this regard. If BlackICE Defender sees an intrusions attempt, it may also do its own NetBIOS lookups independently from the underlying Windows system.

Note that starting in late 1999, desktop security tools like personal firewalls have exploded. This means that the number of NetBIOS queries have dramatically risen.

Also, see section 10.6 for an explanation of how a simple configuration error in DNS can cause you to be suddenly flooded with such requests.

If the Windows box is trying to find the name for the IP address 192.0.2.21, it will do the following steps:

• Lookup the DNS "PTR" record for 21.2.0.192.in-addr.arpa; this request is sent to the local DNS server, which recursively forwards the query to the appropriate DNS server as required.
• If the DNS answer comes back, it won't query NetBIOS. If a negative response comes back, it will immediately query NetBIOS. If the DNS server times-out, it will wait 14-seconds, then query NetBIOS.
• When resolving with NetBIOS, it will send out a "NodeStatus" query that is sent to the 192.0.2.12:137 from x.x.x.x:137. (I.e. the query is sent to the IP address being resolved to its port 137, and is sent from the Windows machine port 137).
• The NetBIOS request is a "NodeStatus" query that looks up the name "*". It is 50 bytes worth of data (58 including the UDP header, 78 including the IP header, 92 including an Ethernet header).
• Three NetBIOS queries are sent with a 1.5 second timeout.

The personal firewall BlackICE Defender will may do its own NetBIOS queries separate from the underlying Windows OS. These will look like UNIX queries from dynamic ports, and have longer, progressive timeouts of 15-seconds, 30-seconds, and 1-minute.

Packet Dump

The packet looks something like the example below. For more information about interpreting this, please see my sniffing FAQ at http://www.robertgraham.com/pubs/sniffing-faq.html.

ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol        
IP: ID = 0x3E16; Proto = UDP; Len: 78                                   
UDP: Src Port: NETBIOS (137); Dst Port: NETBIOS (137); Length = 58      
NBT: NS: Query req. for *<00...(15)>                                   
    NBT: Transaction ID = 57032 (0xDEC8)                               
  + NBT: Flags Summary = 0x0000 - Req.; Query; Success                 
    NBT: Question Count = 1 (0x1)                                      
    NBT: Answer Count = 0 (0x0)                                        
    NBT: Name Service Count = 0 (0x0)                                  
    NBT: Additional Record Count = 0 (0x0)                             
    NBT: Question Name = *<00...(15)>                                  
    NBT: Question Type = Node Status Request                           
    NBT: Question Class = Internet Class                               

00000:  00 E0 18 E0 0C E7 00 40 05 A4 79 32 08 00 45 00 .......@..y2..E.
00010:  00 4E 3E 16 00 00 80 11 2F CE 0A 0A 00 09 C0 00 .N>...../.......
00020:  02 A8 00 89 00 89 00 3A 14 AB DE C8 00 00 00 01 .......:........
00030:  00 00 00 00 00 00 20 43 4B 41 41 41 41 41 41 41 ...... CKAAAAAAA
00040:  41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
00050:  41 41 41 41 41 41 41 00 00 21 00 01             AAAAAAA..!..

If you are seeing a lot of these requests, it probably means you have one of the following DNS issues.

• Your DNS servers are slow; the Windows machine needs a response within 14 seconds.
• Your link is unreliable/congested, causing the DNS queries to be dropped.
• You haven't configured the PTR entries within your DNS server.
• Your ISP doesn't forward the PTR queries to your DNS server.
• The client's ISP cannot handle CNAME -> PTR indirection for CIDR addresses.
•  

Note that in this day/age with CIDR and address blocks smaller than 255 members, a lot of ISPs don't know how to forward DNS PTR requests to your server.

No matter what you do, you will still get requests because of configuration errors on the client's ISP. However, making sure the issues above are resolved on your own DNS servers will be an important first step.

The thing to remember is that A and PTR queries are unrelated.

When you register your domain name (example.com) you go to the owner of .com (Network Solutions) and purchase the address. As part of your registration, you tell Network Solutions something to effect "Please pass any DNS queries for the domain example.com to my DNS server ns1.example.com which is located at the IP address 192.0.2.168".

Thus, when resolving www.example.com, you first ask .com for the DNS server for example.com, which is ns1.example.com/192.0.2.168. You then ask that server for the A record for www.

Now going the reverse direction is a bit tougher. When trying to figure out who owns the IP address 192.0.2.3, you've got a problem. What is the first step? The solution was to query for a PTR record with the pseudo-name that looks something like "3.2.0.192.in-addr.arpa". Like the .com domain, the .arpa domain is run by a special company. It forwards the requests to the backbone ISPs, which then forward the request to the smaller ISPs and customers.

This forwarding mechanism is easily broken due to CIDR addresses. An ISP may assign 192.0.2.[0.127] to one customer, and 192.0.2.[128-255] to another customer. In order to fix this issue, the ISP must support special CNAME records that delegate lookups. For the network 192.0.2.128/25, then the CNAME record would look like 128/25.0.2.192.IN-ADDR.ARPA. This is kinda complex, easy to get wrong, and the administrators at ISPs often don't know how to do it right.

Please see CNAME -> PTR indirection described in RFC 2317 for more details on this. Also see http://www.dns.net/dnsrd/ for extensive DNS resources.

Conclusion

The upshot is that you probably have a CIDR allocation that breaks PTR queries causing NetBIOS queries. Harangue your ISP until they fix this.