Just to cover the material posted earlier in some greater detail, here is the results of some casual googling on the open TCP and UDP ports listed earlier:

135/tcp open loc-srv
135/udp open loc-srv

Location Service. This is the infamous RPC portmappper "svchost.exe" (supporting "DCE services" for remote hosts), focus of a recent NT/2k/XP vulnerability. It listens for both TCP and UDP packet types.

The idea of an RPC (remote procedure call) portmapper was invented by Sun Microsystems, and is both good (useful for network programming) and bad (raises security challenges). Its operation means you can code network daemons without assigning them ports, and instead have them request the portmapper for an assignment. The challenges are several: (1) It leaks valuable information about the system to the bad guys. (2) Its complexity means it's a likely place for vulnerabilities to crop up. (3) When you hear of such vulnerabilities, disabling it might be prohibitively painful, because too much relies on it. (It's a single point of failure for other things.) (4) Because it assigns ports dynamically to services that rely on it, those services no longer run on predictable ports, which makes them much harder to protect.

For all of those reasons, a running portmapper tends to make security people antsy. If it must be left running (e.g., because of NFS or NIS/NIS+ daemons, on Unix boxes), then security folk will try to heavily protect it.

123/udp open ntp

Network Time Protocol server. Just to clear up a point of frequent confusion: Many users, reading these reports, have as their initial reaction "Oh, Network Time Protocol sounds desirable. I definitely want my machine to have the correct time and be sync'd to atomic clocks. That's really cool. I certainly wouldn't want to turn that off or block it." But that's confusing two very different things: It's one thing to want your machine to be an NTP client and quite another to want it to be an NTP server. That item (and this list generally) consists of server broadcasts that XP is offering up to the world at large.

137/udp open netbios-ns

NetBIOS name server for SMB file/print services. In other words, this is the broadcast of resource-name information that would show up in other people's Network Neighbourhood listings, and corresponds to Samba's nmbd.

138/udp open netbios-dgm

NetBIOS datagram server for SMB file/print services. This is the broadcast of your system's actual file/print data to the wide world, and corresponds to Samba's smbd.

139/tcp open netbios-ssn

NetBIOS Session Service. Remote access to NT domain SID / host SID / browse-list information and guest-user login (NULL session). Very worrysome information leakage of security-sensitive information, there.

500/udp open isakmp

Key management (isakmp/oakley). This is Internet Key Exchange ("IKE") negotiation traffic for Kerberos5 authentication to Active Directory domains.

1025/tcp open NFS-or-IIS

On some hosts, this is IIS, NFS, or network blackjack, but on XP/W2k it might be (but see note on ports 1024+, following) the Task Scheduler service (MSTask.exe) listening for....? I can't even imagine why on Earth it would want to accept task requests from remote. Words fail me. To disable it, disable "Task Scheduler" in the services list.

If that is indeed what it is, then (to reiterate) it's a crying shame that it's so non-obvious how to make Windows services bind only to the localhost (aka loopback) network interface and not outside interfaces, so that they can be accessible from the local machine but not elsewhere.

"NET STOP Schedule" at the command line will do a runtime halt of the service.

1031/udp open iad2
1032/udp open iad3

Per IANA (as reflected in the standard Unix /etc/services list[1]), these are both supposed to be "bbn iad". In other words, they were assigned to Bolt, Beranek, and Newman (a firm that was one of the Internet's architects) for some long-forgotten project. However, in this case, they're in the range (1024 and up) that Windows NT and pieces thereof (MSTask, DNS Manager, Microsoft Exchange Administrator, WINS server, etc.) usually uses for dynamically assigned ports. If a server listens on a port but does not care what port number it uses, the portmapper assigns it one of those port numbers.

Often on a Windows box these are Microsoft RPC/DCOM services. Since the clients use the port mapper (port 135) to find the service, it does not need to reside on a fixed port number. (This is similar to how Sun RPC services work, though they use a different underlying protocol and a different portmapper port, number 111 TCP and UDP).

See: [link|http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q154/5/96.ASP&NoWebContent=1|http://support.micro...SP&NoWebContent=1] ...on how to regulate the Microsoft RPC portmapper's port usage via a Registry key (e.g., for the benefit of a firewall, so you can predict exactly what ports will be used).

1900/udp open UPnP

Universal Plug and Play Simple Service Discovery Protocol (SSDP) server, letting other hosts do discovery of its hardware offerings over networks and letting those offerings appear in those hosts' My Network Places listings. As one wag puts it, "UPnP/SSDP is the technology that, in years to come, will allow our refrigerators and can openers to send e-mail to our automobiles and softball mits. When the promise of IPv6 is realized such that every grain of sand on every beach can have a MAC address, Universal Plug 'n Play will undoubtably let remote hackers know we are running low on butter, and enable leet TCL scripts to lock us out of our own cars."

5000/tcp open UPnP

Universal Plug and Play: Specialised sort of Web server, advertising UPnP information via HTTP.


The above analysis is necessarily uncertain because it's based on an entirely outside view of the XP host (from a remote Linux box running nmap). Because of that, there is some guesswork (in particular cases) about what XP process is actually responsible for listening on a specific network port. Relevant to that problem, an intereseting tool:

[link|http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/proddesc/fport.htm|http://www.foundston...roddesc/fport.htm]

Quoting the Web site:

[Foundstone, Inc. "fport"] (TCP/IP process-to-port mapper) reports all open TCP/IP and UDP ports and maps them to the owning application. This is the same information you would see using the 'netstat -an' command, but it also maps those ports to running processes with the PID, process name and path. Fport can be used to quickly identify unknown open ports and their associated applications.

Late addition: My mother-in-law tried that program, and on the ports of interest it gives almost no useful information, saying just "system" as a description for most of them. Additionally, it lists processes binding to loopback only along with those binding to outside network interfaces, making no distinction between them. Still, maybe worth the download.

I also saw reference to a tool called "Inzider" to do pretty much the same thing. [link|http://ntsecurity.nu/toolbox/inzider/|http://ntsecurity.nu/toolbox/inzider/]

If you're running a Windows machine, it'd be an excellent idea to run such a utility to determine for certain what specific process is serving up each broadcast network service. You may or may not be able to act usefully on that information -- such as turning off pointless, resource-wasting network daemons or restricting them to localhost -- but knowing is better than not knowing,and at least you have a fighting chance of doing something less indiscriminate and scattershot than global blocks of thousands of ports (a la Microsoft Internet Connection Firewall, ZoneAlarm, BlackICE, etc.).

[1] I have a copy of someone's expanded version at [link|http://linuxmafia.com/~rick/linux-info/services-augmented|http://linuxmafia.co...ervices-augmented]

Rick Moen
rick@linuxmafia.com