10. What's the deal with NetBIOS
(UDP port 137)?
NetBIOS requests to UDP port 137 are the most common item you will see in your firewall
reject logs. This comes about from a feature in Microsoft's Windows: when a program
resolves an IP address into a name, it may send a NetBIOS query to IP
address. This is part of the background radiation of the Internet, and is nothing
to be concerned about.
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
10.1 What does it mean to resolve an IP address to a name?
You are familiar with the normal DNS resolution. You type into your web browser
an address like http://www.robertgraham.com/,
but it looks up the web sites name with DNS in order to find IP address. Underneath, it is
really IP addresses that are used for communication.
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
In much the same fashion, the Internet provides a number of capabilities to resolve an
IP address into a name.
10.2 Where do the NetBIOS packets come from? Why does Windows send
On virtually all systems (UNIX, Macintosh, Windows), programs call the function 'gethostbyaddr()'
with the desired address. This function will then do the appropriate lookup, and return
the name. This function is part of the sockets API.
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
- 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
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.
10.3 But my network doesn't run any Windows machines. Why am I
being sent these packets?
It has nothing to do whether you run Windows, NetBIOS, or Samba on your machines.
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.
10.4 Why are reverse resolutions so common?
One would think that a reverse query would be rare. They are instead very common. Here
are some reasons why programs might do reverse lookups.
- 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.
- 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
- 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.
10.5 What is the exact signature I can expect to see?
Windows machines use both a source port of 137 as well as a destination port of 137. In
contrast, if UNIX machines attempt to resolve NetBIOS names (via SAMBA), they will use
dynamic ports above 1024.
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 184.108.40.206.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.
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..!..
10.6 How do I reduce this traffic so I don't get so many?
Windows will not send a NetBIOS query if the initial DNS query comes back in a timely
manner. Let me repeat: Windows only sends NetBIOS queries when the DNS lookup fails.
Therefore, the proximate cause of NetBIOS queries is a fault in the DNS system. The first
thing you should hunt down is the DNS fault causing the DNS PTR queries to fail.
you are seeing a lot of these requests, it probably means you have one of the following
- 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.
10.6.1 What is a DNS PTR query?
For reasons of historical irrelevance, a normal DNS query is called an A record.
A reverse query is called a PTR (pointer) query. The names A and PTR don't really
mean anything; remember that a lot of such things come about because some engineer created
"temporary" names from the top of his head, meaning to change them later, but
they sort of just stick around.
The thing to remember is that A and PTR queries are
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
"220.127.116.11.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/18.104.22.168.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
The upshot is that you probably have a CIDR allocation that breaks PTR queries causing
NetBIOS queries. Harangue your ISP until they fix this.
10.7 What attacks can people go through NetBIOS/137?
There are numerous tools that scan for open shares. The first
popular tool for this was called "Legion" from Rhino9.
Since then, numerous other tools have been created. Some of these
tools will do a lookup on port 137 before connecting to TCP port
Starting in 1999, numerous NetBIOS worms have been seen. These
include ExploreZip virus/worm, Network.VBS VisualBasic script,
and the 911 worm (which also calls 911 out your modem). All of
these worms will attempt connection to you machine.
Sometimes people just scan the Internet looking for people's names.
Since most people leave port 137 open, it is pretty fun.
CERT's Intruder Detection Checklist. If you believe you've
been compromised, this document describes how to go through your
UNIX system and find signs of this intrusion.
If you have evidence of a cybercrime that you believe warrants
the attention of the FBI, this is a good place to start. Note
that you can't simply hand it off to them and say "you take
care of it". They are only willing to take part of you are
willing to spend the necessary time in gathering evidence. For
example, you may have to ship your compromised machine to them.