Using Netsh with Windows Firewall

I’ve always had a liking for homes built of brick. Besides having a kind of “Lord of the Manor” appeal, they also look solidly built compared to many of today’s wood-framed plastic-siding homes. Brick also gives an added sense of security since, who’s going to smash through a brick wall to break into your house?

But then I wonder, wouldn’t your home be even more secure if all the rooms had brick walls and not just the exterior wall of your house? After all, drywall is so fragile you can punch through it if you get really angry (and don’t mind a bit of pain) so it seems like a good idea to make the internal walls brick also. That way if someone breaks into your house they still have to break into each individual room to find the safe where you keep your jewels.

Many corporate networks are just like this today—instead of relying only on a firewall at the perimeter (outside wall) of the network, there are firewalls installed on individual clients and servers (rooms) also to act as another layer of defense against attack. And on networks that run Windows XP on the clients and Windows Server 2003 on the servers, there’s a ready candidate for which host-based firewall to use: Windows Firewall. After all, it’s free!

Unfortunately having firewalls on clients and servers means extra management work as well, but Group Policy can handle that as far as Windows Firewall is concerned (another great reason for deploying Windows Firewall on hosts instead of third-party firewalls from other vendors). Still, there are times when you want to check or modify the configuration of Windows Firewall on some hosts because of problems of some sort, and the command-line tool Netsh.exe is just the thing to do this with.

Get It Working

Let’s say Bob sets up a Windows Server 2003 SP1 machine as a web and file server for internal use in his company. Knowing that the Windows Firewall/Internet Connection Sharing service is disabled by default, he opens the Services console under Administrative Tools and changes the Startup Type for this service to Automatic and then starts the service. So far, so good, but if he had tried opening the Windows Firewall utility from Control Panel he would have been presented with a message asking him whether he wanted to start this service and pointing out that he should reboot his server afterwards to make sure Windows Firewall recognizes that the server is listening for inbound traffic from file and web clients.

Anyway, Bob now wants to enable and configure Windows Firewall on the server but is suddenly called away on an emergency. He sends a quick email to his assistant Mary using his BlackBerry saying “Enable firewall on server so clients can access it—get it working” and walks out the door. Unfortunately his assistant is working from home today but Bob remembered to enable Remote Desktop on the new server, so Mary starts Remote Desktop Connection on her Windows XP SP2 computer and the console of the remote server is displayed.

Now what? Mary could open Control Panel on the remote machine and enable Windows Firewall, but what exceptions does she need to configure on it? Bob was obviously in a hurry when he said “so clients can access it” but what clients? And it’s obviously important because he wants it done today.

Rather than hunt around the Services console looking for additional services that Bob might have enabled on the machine, Mary decides to open a command prompt on the remote machine and pursue a different tack. She starts by typing the following command:

netstat –ano > netstat.txt
notepad netstat.txt

She then examines the contents of the netstat.txt file that opens in Notepad:

Active Connections

Proto Local Address          Foreign Address        State           PID
TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       1664
TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       696
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:1037           0.0.0.0:0             LISTENING       1000
TCP    0.0.0.0:1040           0.0.0.0:0              LISTENING       436
TCP    0.0.0.0:1045           0.0.0.0:0              LISTENING       1220
TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1780
TCP   127.0.0.1:1051         0.0.0.0:0              LISTENING       1856
TCP    172.16.11.182:139      0.0.0.0:0              LISTENING       4
TCP    172.16.11.182:1029     172.16.11.181:445      TIME_WAIT       0
TCP    172.16.11.182:1034     172.16.11.181:135      TIME_WAIT       0
TCP    172.16.11.182:1035     172.16.11.181:1025     ESTABLISHED     436
TCP    172.16.11.182:1039     172.16.11.181:1025     TIME_WAIT       0
TCP    172.16.11.182:1043     172.16.11.181:445      TIME_WAIT       0
TCP    172.16.11.182:1052     172.16.11.181:389      TIME_WAIT       0
TCP    172.16.11.182:1053     172.16.11.181:389      TIME_WAIT       0
TCP    172.16.11.182:1055     172.16.11.181:389      TIME_WAIT       0
TCP    172.16.11.182:1056     172.16.11.181:139      TIME_WAIT       0
TCP    172.16.11.182:1062     172.16.11.181:389      TIME_WAIT       0
TCP    172.16.11.182:1063     172.16.11.181:389      TIME_WAIT       0
TCP    172.16.11.182:1071     172.16.11.181:445      TIME_WAIT       0
TCP    172.16.11.182:1075     172.16.11.181:135      ESTABLISHED     436
TCP    172.16.11.182:1078     172.16.11.181:389      TIME_WAIT       0
TCP    172.16.11.182:1079     172.16.11.181:389      TIME_WAIT       0

Right away it looks to her from this file that the server has the HTTP service installed on it since the machine is listening on TCP port 80. Better check though and make sure this service is actually the one using this port. How does she do this? First she notes the process ID (PID) number associated with these ports which is 1664. Then She types the following commands at the command prompt:

tasklist /svc > svclist.txt
notepad svclist.txt

She then examines the contents of the svclist.txt file, which look like this:

Image Name                     PID Services
========================= ======== ============================================
System Idle Process              0 N/A
System                           4 N/A
smss.exe                       260 N/A
csrss.exe                      348 N/A
winlogon.exe                   380 N/A
services.exe                   424 Eventlog, PlugPlay
lsass.exe                      436 HTTPFilter, Netlogon, PolicyAgent,
                                   ProtectedStorage, SamSs
svchost.exe                    644 DcomLaunch
svchost.exe                    696 RpcSs
svchost.exe                    748 Dhcp, Dnscache
svchost.exe                    796 LmHosts, W32Time
svchost.exe                    812 AeLookupSvc, Browser, CryptSvc, dmserver,
                                   EventSystem, helpsvc, lanmanserver,
                                   lanmanworkstation, Netman, Nla, Schedule,
                                   seclogon, SENS, SharedAccess,
                                   ShellHWDetection, TrkWks, winmgmt,
                                   wuauserv, WZCSVC
spoolsv.exe                    976 Spooler
msdtc.exe                     1000 MSDTC
vmsrvc.exe                    1120 1-vmsrvc
svchost.exe                   1144 ERSvc
inetinfo.exe                  1220 IISADMIN
svchost.exe                   1288 RemoteRegistry
svchost.exe                   1312 SrmSvc
vpcmap.exe                    1420 VPCMap
svchost.exe                   1664 W3SVC
svchost.exe                   1780 TermService
alg.exe                       1856 ALG
explorer.exe                   972 N/A
vmusrvc.exe                   1412 N/A
wuauclt.exe                   2120 N/A
csrss.exe                     2176 N/A
winlogon.exe                  2204 N/A
rdpclip.exe                   2452 N/A
explorer.exe                  2556 N/A
wmiprvse.exe                  2564 N/A
vmusrvc.exe                   2648 N/A
cmd.exe                       2724 N/A
tasklist.exe                  2964 N/A
wmiprvse.exe                  2988 N/A

She examines this file looking for the the PID noted previously and finds this line:

svchost.exe 1664 W3SVC

This line confirms to her that Bob installed IIS on the server and configured it to run as a web server.

Now Mary has to enable Windows Firewall on the machine and create an exception for HTTP clients to access it. Since she’s already at the command-line on the remote machine, she decides to do this using the Netsh command. First, she views the configuration of Windows Firewall on the server:

C:\>netsh firewall show opmode

Domain profile configuration (current):
——————————————————————-
Operational mode                  = Disable
Exception mode                    = Enable

Standard profile configuration:
——————————————————————-
Operational mode                  = Disable
Exception mode                    = Enable

Local Area Connection firewall configuration:
——————————————————————-
Operational mode                  = Enable

From this command output she confirms that Windows Firewall is currently disabled and needs to be enabled. To do this, Mary types the following command:

C:\>netsh firewall set opmode enable
Ok.

Now she adds a port exception for the HTTP service:

C:\>netsh firewall add portopening TCP 80 HTTP enable subnet
Ok.

To test this, she temporarily minimizes her Remote Desktop Connection window and opens Internet Explorer and types http://172.16.11.182 in the address bar, and here’s what she gets in response (Figure 1):

Figure 1: Accessing the server using HTTP

That sounds like Bob! Always playing the “heavy” as far as his role as administrator is concerned.

Now let’s see what else is running on the server. Mary goes back to the netstat.txt file shown previously and finds the following lines of interest:

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 172.16.11.182:139 0.0.0.0:0 LISTENING 4

This is a sure giveaway that the server is configured as a file server with shared folders on it for these two ports (and two others listed below) are used by Server Message Block (SMB) protocol (Microsoft’s file sharing protocol) as follows:

UDP port 137 is the listening port for the NETBIOS Name Service
UDP port 138 is the listening port for the NETBIOS Datagram Service
TCP port 139 is the listening port for the NETBIOS Session Service
TCP port 445 is the listening port for SMB over TCP/IP

In other words, the first three ports are for SMB over NBT (NETBIOS over TCP/IP) and the last one (new in Windows 2000 and later) is for SMB directly over TCP/IP.

So to access the remote server as a file server, exceptions have to be created for these four ports in Windows Firewall. To do this, Mary types the following commands in the command prompt window open on the remote machine’s desktop:

netsh firewall add portopening UDP 137 blah enable subnet
netsh firewall add portopening UDP 138 blah enable subnet
netsh firewall add portopening TCP 139 blah enable subnet
netsh firewall add portopening TCP 445 blah enable subnet

What’s cool about this approach is that if she opens Windows Firewall from Control Panel on the remote machine’s desktop, it displays the File and Printer Sharing exception as enabled (Figure 2):

Figure 2: File and Printer Sharing is enabled on the server

Mary should then be able to display the shared folders on the remote server simply by clicking Start, then Run and typing \\172.16.11.182 and clicking OK.

Conclusion

Mary could have made her life easier by configuring Windows Firewall from the GUI instead of using Netsh since she was logged on in a remote desktop session anyways with the server, but then she wouldn’t have had the opportunity of learning how to use Netsh, a really cool tool in the administrator’s toolbox!

One final point: before Mary logged off her RDC session she should have typed one more command on the server:

netsh firewall add portopening TCP 3389 blah enable any

Otherwise she won’t be able to connect using RDC to the remote machine because once enabled, Windows Firewall blocks Remote Desktop sessions by default!