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

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
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):

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.

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!

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.

WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles & tips by a team of leading authors, it remains a favorite within the networking community.

Rate this Tip To rate tips, you must be a member of SearchNetworking.com. Register now to start rating these tips. Log in if you are already a member. Digg This!     StumbleUpon     Del.icio.us    RELATED CONTENT Network Security Application-specific network intrusion detection systems emerge Anomaly-based intrusion protection configuration and installation Preventing hacker attacks with network behavior analysis IPS Rogue access points: Preventing, detecting and handling best practices The TPM chip: An unexploited resource for network security Shifting defenses and dynamic perimeters challenge network security Compliance in a virtualized world: Server virtualization and NAC security Securing the new network architecture: Security for distributed, dynamic networks How to configure Windows Server 2008 advanced firewall MMC snap-in USB storage devices: Two ways to stop the threat to network security Network Security Best Practices and Products 3Com acquisition confirms HP-Cisco battle for China Enterprises demand next-generation firewalls with IPS, app visibility Preventing hacker attacks with network behavior analysis IPS Is there a way to trace my stolen laptop computer? Integrating NAC with network security tools Should organizations separate technical from administrative security? What network equipment is needed to secure a small business LAN? Ethical hacking and countermeasures: Network penetration testing intro Are you on a domain name system (DNS) blacklist database? Rogue access points: Preventing, detecting and handling best practices RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary anti-replay protocol  (SearchNetworking.com) dynamic packet filter  (SearchNetworking.com) HELLO packet  (SearchNetworking.com) packet filtering  (SearchNetworking.com) rule base  (SearchNetworking.com) stateful inspection  (SearchNetworking.com) RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.