Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
Open Network Ports on XPSP2
November 16, 2006
Sitting in my hotel room in the middle of the night, dealing with jet lag and severe boredom, inspired me to dig into Windows Internet Connection Firewall (ICF) a bit on my XPSP2 laptop. It’s a Lenovo, domain-joined, though currently on a ‘foreign’ network; these details become relevant.
My first step was to write a simple program which exercises various ICF COM interfaces, including INetFwProfile, INetFwOpenPorts, INetFwAuthorizedApplications, and INetFwServices ICF COM interfaces. A summary of what I found:
- According to ICF, there are no globally open ports on this machine.
- “Enabled” applications (i.e. those granted exceptions) include C:\Program Files\Messenger\msmsgs.exe (i.e. Messenger). I take this to mean that the binary at that path can open any port at will, although I didn’t confirm.
- “Enabled” services include UPnP Framework, with ports 1900 and 2869, as well as Remote Desktop, with port 3389.
I subsequently discovered two additional ways to obtain this information directly from ICF:
- Read it directly from the registry under HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy.
- Using a built-in command-line tool plus a list of arguments, namely: “netsh.exe firewall show config verbose = ENABLE”
Beware – one confusing thing I found about netsh.exe is the way it reports the two separate ICF policies configured on this machine: Domain and Standard. Since I’m off the corporate LAN, the latter is in effect. It’s clear that netsh.exe knows this. Nevertheless, I wasn’t able to find a combination of command-line options that would give verbose output regarding only the profile in effect, i.e. Standard (I haven’t tried it from the corp LAN yet; it may behave better in that situation). So be sure to read the output carefully, especially if you’re offsite.
Anyway, this ICF configuration raises some interesting questions. Such as, what do I need to do if I want all of the exceptions closed, and is there anything it’s not telling me?
Next step: use a port scanner to find out which ports have listeners. Actually, I ran nmap.exe in a self-scan configuration; the results of a scan from a remote machine (something I don’t have access to at the moment) may be different. Still, it’s an interesting data point.
>nmap -sT -P0 my_machine
…
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
3389/tcp open ms-term-serv
For a while, forgetting the loopback consideration, I wasn’t sure how to rationalize the output of nmap with my ICF config. Specifically, why are 135, 139, and 445 open, and what the heck is 1025?
Some web searching taught me the following.
- 139 and 445 are automatically bound by System and are used for Server Message Block (SMB). I’m led to believe that Workstation (i.e. domain-joined client) functionality will fail unless these ports are opened at least outbound, but if you don’t care to offer File and Printer Sharing from this machine, they can safely be disabled inbound. I did not confirm this.
- 1025 is opened by a 3rd party VPN client (IPSSVC.exe) that comes pre-installed on Lenovo machines. It’s considered benign, but again, what the heck?
- 135 is the RPC port mapper. Again, I’m led to believe that notorious DCOM can (and should!) be disabled by blocking inbound connections on this port – especially on a client machine. But loopback still needs to work. And again, I did not confirm this.
Then I finally discovered the proper built-in tool for obtaining some of this information myself. The output below has been trimmed.
>netstat.exe -a -o
Active Connections
Proto Local Address Foreign Address State PID
TCP my_machine:epmap my_machine.domain:0 LISTENING 1244
TCP my_machine:microsoft-ds my_machine.domain:0 LISTENING 4
TCP my_machine:1025 my_machine.domain:0 LISTENING 2012
TCP my_machine:3389 my_machine.domain:0 LISTENING 1176
TCP my_machine:netbios-ssn my_machine.domain:0 LISTENING 4
UDP my_machine:microsoft-ds *:* 4
>tlist | findstr 2012
2012 IPSSVC.EXE
>sc queryex termservice
SERVICE_NAME: termservice
STATE : 4 RUNNING
PID : 1176
>sc queryex rpcss
SERVICE_NAME: rpcss
STATE : 4 RUNNING
PID : 1244
So at least all open ports are accounted for. For the first attempt at locking my machine down, I took the following steps.
- Disable Messenger via the Windows Firewall control panel
- Disable Remote Desktop/RDP via Computer Properties
- Disable Remote Assistance via Computer Properties while I’m at it …
- Disable UPnP via the Firewall cpl
- Disable IPSSVC via the Services cpl
>nmap -sT -P0 my_machine
…
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
So now we’re down to just the three ports opened by System (i.e. PID = 4 in the above netstat output). How do I go about locking those ports down as mentioned above? This handy script, created by Microsoft PSS in response to the Blaster worm. Among various options, the script applies IPSec policies to Web and RPC ports, as well as the additional Blaster-related ports, blocking inbound TCP and UDP. That doesn’t prevent an infected machine from spreading via outbound traffic, but my machine isn’t infected …
I don’t have a good way to test the new config until I can run a scan from a separate machine. And I’m curious to run the same barrage of checks against Vista as well. Stay tuned!
Permalink |1 Comment »
RSS feed for comments on this post. TrackBack URL
really nice post!
but i have just on question; how can i do to activate a service by the command line ? for example termservice.
when i’m on local network i can see using nmap ms-term-serv is opened and the remote desktop works well. but when i execute the same commands over a Vpn connection i can’t detect this service running, even if the svchost.exe is opening the termservice.
PS: i don’t think it’s a firewall limitation.
thanx a lot for your answer if you do.
Comment by adn — August 21, 2008 @ 4:31 pm