More Fine-Tuned Firewall Rules

In “Controlling Windows Firewall with PowerShell” and “Hand-Crafted Firewall Rules with PowerShell,” I’ve talked about a number of ways to configure the firewall for maximum usability. This month, I’ll put firewall control to bed with a couple extra details: how to restrict a firewall rule to a specific range of IP addresses, and how to build ICMP-type rules, such as you’d need to allow pings. I’ll finish up with a few useful examples.

So far, you’ve seen that you can create new firewall rules with New-NetFirewallRule, as in this example:

new-netfirewallrule -displayname Mtest -direction outbound -action block -remoteport 3389 -protocol TCP

The essential -displayname parameter is the textual identifier for the rule. If, for example, you wanted to delete the rule with Remove-NetFirewallRule, you’d need either that name or the monster GUID that Windows uses internally to identify the rule. The -direction and -action parameters specify what kind of rule it is, and -remoteport and -protocol are two criteria for filtering the firewall rule. Those filters essentially make the rule’s result (blocking any attempt at sending outgoing packets) take place only if the packet in question is destined for TCP port 3389.

Note that -remoteport has a partner, -localport, that you can use to create a rule triggered by a packet originating from a given port. And in case 3389 isn’t a port you immediately recognize, that’s the one that Remote Desktop uses. Note also that, in this example, I’m building firewall rules that make more sense on a client PC rather than a server machine—for a very important reason. Because these examples work fine on a client, they’re easier and safer to test than rules built for a server. When the time comes to employ some port-blocking rule on a server, just swap -direction outbound with -direction inbound or vice versa, and -remoteport to -localport, and the rule will work fine.

Restricting Rules to IP Address Ranges

If your security needs are so specific that you find yourself compelled to write a new rule rather than using one of the hundreds of prebuilt rules, it’s a good bet that you’ll want your filters to get more specific about IP address ranges. For example, you might want the filters to apply to addresses outside your subnet only after matching a protocol and port, or perhaps you’ve identified a range of IP addresses that you want to block because bad guys use them. For that purpose, you have the -remoteaddress and -localaddress parameters.

This example refines the “block the Remote Desktop port” filter to become “block the Remote Desktop port, except on my subnet” filter. To do that, you add the parameter -remoteaddress Internet, as in:

new-netfirewallrule -displayname Mtest -direction outbound -action block -remoteport 3389 -protocol TCP -remoteaddress Internet

Here, Internet means any address outside of your current subnet. You can test the firewall rule’s efficacy either with Test-NetConnection (which can test only TCP connections), as I showed you in “Hand-Crafted Firewall Rules with PowerShell,” or with Portqry (which can also test UDP connections), as in the following command, which tests to see if the system s1.bigfirm.com responds to Remote Desktop on TCP:

portqry -e 3389 -p TCP -n s1.bigfirm.co

That command would fail, but Windows 8 and Windows Server 2012 systems do Remote Desktop on UDP connections as well, and Portqry would let me test that like so:

portqry -e 3389 -p UDP -n s1.bigfirm.com

The -remoteport parameter also takes intranet (local subnet), -remoteaccess (a subnet I’m accessing via a VPN), DNS, DHCP, WINS, or DefaultGateway (servers acting in those roles). And before you leave that potentially annoying rule on your computer, remember to get rid of it with this command:

remove-netfirewallrule -displayname mtest

You can also give -remoteport a single IP address (e.g., -remoteport 4.3.5.1), a CIDR block of addresses (e.g., -remoteport 10.4.4.1/24), or a dotted-quad subnet (e.g., -remoteport 20.4.4.1/255.255.255.0).

Allowing Ping: ICMP Rules

None of what you’ve seen so far, however, will let you build some of the first rules you probably want from a firewall: rules to enable Ping or other ICMP-related functions. ICMP provides a lot of useful monitoring data, and the functions that produce that data are described by two numbers—a type and a code. Now, if you want to pick through RFC 792, I’m not going to stop you, but a look at the Microsoft article “Internet Control Message Protocol (ICMP) Basics” yields not only those types but also the specific example of what Ping needs from ICMP. It’s type 8 and code 0.

To open all types of ICMP traffic, specify -Protocol ICMPv4 and -ICMPType type:code, as in this example:

new-netfirewallrule -displayname Mtest2 -direction outbound -action allow -icmptype 8:0 -protocol icmpv4

If, on the other hand, you just want to permit all ICMP traffic, use the Any keyword, as in:

new-netfirewallrule -displayname Mtest2 -direction outbound -action allow -icmptype Any -protocol icmpv4

As I’ve observed in earlier articles, Windows Advanced Firewall doesn’t get much respect, and it’s a shame, because it’s essentially “IPSec made simple.” Also, the GUI is really not bad—but GUIs aren’t automatable, and the PowerShell cmdlets give you pretty flexible control. I hope you find a use for New-NetFirewallRule in your security plan!