Why connect to UDP 137? [Resolved]

Hi guys.

OS: Windows XP SP3

I see a lot of outgoing connections (from “SYSTEM”) to UDP port 137 on internet addresses i.e. addresses outside of the LAN to which my computer belongs. Please tell me why this is necessary.

I am sure there are folks on this forum with knowledge of that protocol.

What is the external IP address that it is trying to connect to?

SYSTEM connecting to UDP 137 on:

This is just a small sample. There were hundreds of entries in the log. All I have to do is surf the net. If I go to Google results, then click on each entry, the log gets filled with these.

I was curious about what is the idea behind trying to connect to UDP port 137.

Thanks for your reply.

UDP on port 137 is Windows NetBIOS Name Service, typically Windows file sharing (on a LAN)… passing System Names, File Shares, etc. Unexplained outbounds on UDP 137, in volume, might indicate a possible worm infection (trying to seek other victims). This being a possibility, you should update your AV definitions & run a scan.

I’m not sure what type of Internet connection you have, but NetBIOS should not really be installed on Internet facing adapters (unless it’s a requirement of your provider). So, you might what to check that as well.

I thought it’s only supposed to be used within the LAN. That’s why I was curious.

If I use a torrents client, I can see hundreds of those outgoing UDP 137 connections in the log, presumably to peers in the torrent.

My internet connection is home broadband, PPPoE.

NETBIOS is disabled in the router, so those outgoing UDP 137 requests will not reach the internet. Please see attached image.

I use Norton AV, and I update them every day, at least once in two days. I will do a full scan again.

Thank you.

[attachment deleted by admin]

Check the properties (Networking tab) of your Internet connection (Control Panel - Network Connections - )… ensure that neither File Sharing or Client for MS Networks is enabled for your PPPoE connection.

Your first post indicated that “System” was responsible for the UDP 137 outputs. If it was a torrent connection then the application responsible would be the torrent client, not System.

For my network connection, the following two are DISABLED:
File and Printer Sharing for Microsoft Networks
Client for Microsoft Networks

The originating application is never a torrent client or a web browser. The outgoing connection to UDP 137 ALWAYS shows “SYSTEM” as the originating application.

A couple of questions, regarding logs. Can you post the CFP log, and the router log? On your router, that is on the Admin tab, System Log.

Netbios traffic has no reason to ever be exposed to the Internet. Its only use is for LAN-only file sharing. If it turns out that the torrent client software you’re using is trying to use Netbios for some reason, I would strongly suggest getting replacement client software. Netbios names are hardly unique across the Internet, and the LAN addresses those names refer to are almost guaranteed not to be unique for any machine behind a NAT box or firewall. It’s not a mistake that a p2p software developer would make. All it does is to identify exposed machines, which would make that p2p software very suspect in its security.

On that basis, I’ll suggest another change to your router setup, to make sure that UPnP is disabled. On the Services tab, the UPnP tab, click disabled if it doesn’t already show as disabled. UPnP will let an application on your machine, like p2p software, to automatically configure port forwarding, so as to bypass any security that is provided by the NAT translation of your router.

I found out the program that wants to connect to UDP port 137 here, there, and everywhere on the internet.

OS: Windows XP SP3
CFP v3.0.24.368

The following program is on my startup list, and starts with every reboot, and is forever running on my machine:
TCPView v2.53

I got it from here:

I cleared CFP log. I killed TCPView. Then I went to a Google results page, and started clicking links for two minutes. I checked CFP log. There was not even one outgoing connection to UDP port 137.

I cleared CFP log. I started TCPView. Repeated what I did above. I checked CFP log. The log had many connection attempts to UDP port 137 on various IP addresses outside my LAN.

Just in case you are interested, the actual rule set I use with CFP currently is attached in the images below. The rules are a big jumble though.

If you need more info, please ask.

Thank you for your inputs, kail and grue155.

[attachment deleted by admin]

TCPView is doing that? That surprises me. The download source is good, so I’m considering then that this is a program bug in TCPView, or one of the system routines that it uses. I’ve got TCPView v2.40, and it doesn’t show this kind of operation. But my version is from before the time that Microsoft acquired Sysinternals.

Application rules do tend to be a bit of a jumble. I’ll guess that creating an application rule for TCPView, and blocking 137/udp (without logging) should get rid of the traffic. Normal DNS name lookups take place over port 53 (usually udp), but are mostly taken care of by Windows itself with a lookup cache service that does all the work. I wouldn’t expect TCPView to have any other reason to reach out to the Internet.

I agree, TCPView (I also have 2.53) should not be doing this & it certainly doesn’t use UDP 137 to resolve IPs. As grue says it uses UDP 53 (standard DNS resolve). And, for me, this still doesn’t really explain why CFP is logging the UDP 137s against “System”.

I was a bit surprised to see explorer.exe on the list of Firewall Application rules. That is unusual, can you expand on that one.

Also, Apache… is the web server actually running?

I did a couple of quickie checks. In TCPView v2.53, if I uncheck OPTIONS | RESOLVE ADDRESSES, most of the outgoing connections to UDP 137 were eliminated. But there were one or two. There might be some other explanation for these strays. May be if I restart the router, and reboot the machine, and wait for a while, the results might be different.

I started uTorrent, and within the uTorrent PEERS tab, I checked and unchecked RESOLVE IPS. Again, this made a difference. When RESOLVE IPS was checked, the number of outoing UDP 137 connections was very high. When RESOLVE IPS was not checked, there were still one or two outgoing UDP 137 connections – it was not zero.

I will check again about what exactly TCPView is doing.

Here’s a screenshot of my Application Rules. explorer.exe and apache are expanded here, and apache is not running.

[attachment deleted by admin]

After doing a quick bit of searching, I found this…

Analyzing the traffic from the day before, we have noticed quite a few UDP/137 connections from the machine hosting the FireGen for Pix Analyzer and various hosts on the Internet. We opened the log for the day before and looked-up some of the IP addresses shown in the reports as being accessed on UDP/137. We found that all those IPs appeared in the log at an earlier hour but with other protocols. Later they appear as being queried on UDP/137 (NetBIOS) by the FireGen host. The reason for this is the way MS DNS resolver attempts to perform reverse host name resolution. [u]It will first attempt to use the DNS and if the IP is not resolved it will query the host directly for its NetBIOS name using UDP/137.[/u] The FireGen Log Analyzer was attempting to resolve the name of these hosts during the analysis from the day before. One way to avoid the report being filled with this requests is to exclude the IP address from the analysis (using the "Exclude keywords" settings). To avoid having this kind of traffic generated by FireGen, we implemented a different DNS resolver, a component that would query the DNS server directly with just "pure" DNS requests.
Source: http://www.eventid.net/firegen/pixanalysisarch1.asp

So, it seems that these are possibly direct NetBIOS Resolve requests on UDP 137 for normal DNS requests that have failed… it actually asks the host IP, directly. Wow. I’m not 100% sure on the context of this… as information on this does seem slightly conflicting & rather patchy.

I checked again – twice.

TCPView was running with OPTIONS | RESOLVE IP ADDRESS checked.

For the two logs that were generated with TCPView running, there were several outbound connection requests to UDP 137 on foreign IPs (IPs outside LAN).

For the two logs that were generated with TCPView NOT running, there were zero outbound connection requests to UDP 137 on foreign IPS (IPs outside LAN).

kail, that is a possible explanation.

Kail, I have no idea how you found that, but thank you.

What kail found, set me to doing my own bit of research. It seems this madness is part of WINS - the Windows based name lookup facility. A reference is at http://support.microsoft.com/kb/164176 (which describes the Win2k details, which was the base for WinXP)

I’m going to guess that your machine is configured to use WINS, rather than just standalone TCP/IP. That would set in the Internet Properties of the LAN adapter (Control Panel → Network Connections, right click on the LAN, select Properties, highlight Internet Protocol, click Properties, Advanced, and the WINS tab). Something there is set that shouldn’t be set, and is driving the lookups. It’s going to take trying each option in turn to find out which.

This is my WINS settings for my LAN adapter (static IP, that connects to the internet. Please see attached image. It does allow NETBIOS over TCP/IP.

I would think that the option DISABLE NETBIOS OVER TCP/IP is more appropriate.

[attachment deleted by admin]

Try each of these in turn. First clear the checkbox for LMHost lookup. If that doesn’t stop the queries, then leave the box empty, and select Disable Netbios over TCP. If you have any other machines on your LAN, disabling Netbios over TCP should kill any LAN network shares, as this should give you a completely IP-only interface.

I disabled ENABLE LMHOSTS LOOKUP under WINS, but the outgoing connection requests to UDP 137 persist. I do have shared drives on the LAN.

I will chalk up the UDP 137 connects to some quirk of resolving names/IPs, and leave it at that.

At any rate, NETBIOS traffic is blocked by the router.

Thanks to you both, kail and grue155 for the terrific input.