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:
TCP 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 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
Now she adds a port exception for the HTTP service:
C:\>netsh firewall add portopening TCP 80 HTTP enable subnet
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):
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):
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.
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!
About Mitch Tulloch:
Mitch Tulloch is a writer, trainer and consultant specializing in Windows server operating systems, IIS administration, network troubleshooting, and security. He is the author of 15 books including the Microsoft Encyclopedia of Networking (Microsoft Press), the Microsoft Encyclopedia of Security (Microsoft Press), Windows Server Hacks (O'Reilly), Windows Server 2003 in a Nutshell (O'Reilly), Windows 2000 Administration in a Nutshell (O'Reilly), and IIS 6 Administration (Osborne/McGraw-Hill). Mitch is based in Winnipeg, Canada, and you can find more information about his books at his website www.mtit.com.
This was first published in January 2006