port 137 keeps going

Lately the log of my Linux firewall has become unreadable due to the high
amount of port 137/udp traffic. Traffic rose over 1 packet/minute which is
(was?) somewhat unusual in my 'part of the woods' (an IP block dedicated to
DSL customers of an ISP).

There is only so much room in the kernel message buffer, room which I like
to keep for serious system troubles such as failing disks. At certain times,
the *only* thing in the message buffer was dropped port 137/udp traffic.

So I started asking around.. only to find that more places are seeing the
same rise in traffic, but no real reason why, nor any news reports on the
reasons of increased traffic.

Several reasons exist. Some 'scanners' use this kind of request to find
open machines. Some viruses use this to spread themselves.

An earlier rise has been seen in April/May 2000.
Sans describes this in an article Port 137 scan. They give scanning
activity and a virus named network.vbs as probable reasons for this
traffic.

I captured some of the traffic using tcpdump, giving:

22:03:17.964361 cable.ip.1025 > my.dsl.ip.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x100
OpCode=0
NmFlags=0x1
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(ttl 111, id 62037, len 78)

Compared, doing an 'nmblookup -A' gives in traffic:

22:00:07.416647 unix.machine.34098 > my.dsl.ip.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
TrnID=0x5EC7
OpCode=0
NmFlags=0x0
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(DF) (ttl 245, id 29589, len 78)

Which only sees the differences that the unix nmblookup approach
sets a df bit, and that nmblookup is better at the Transaction ID
(TrnID).