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!

1 Comment »