What can be done to properly re-enable the Windows Firewall on a domain?

Solution 1:

What can be done to properly re-enable the Windows firewall on a domain?

Well, the short answer is that it's going to be a lot of work if you decide to forge ahead, and for the record, I'm not sure I would.

In the general case, client firewalls don't provide much security in a corporate network (which typically has hardware firewalls and controls this type of thing at the edge), and malware authors these days are smart enough to use port 80 for their traffic, because virtually no one blocks that port, so you get a lot of effort putting something in place to provided limited security benefit.

Having said that, the long answer is:

1. Inventory applications and their connectivity needs as best you can.
   • If you can safely enable the Windows Firewall with an allow all rule and set logging, this will be a treasure trove of data for determining what apps you have that need firewall exculsions.
   • If you can't collect logging data non-intrusively, you'll have to make do with a simple inventory, or do your logging on users who can handle disruption and intrusive IT activity (like yourself and other techs, for example).
2. Think about your troubleshooting needs.
   • There are things that probably won't come up in a software audit that you need to think about. For example:
     • You might want to allow ICMP (or ICMP from approved address spaces) to make troubleshooting and IP address management not horrible.
     • Likewise, exclusions for any remote management applications you guys use.
     • You'll also probably want to set firewall logging by policy
3. Create a baseline GPO and deploy it to a test group, or multiple test groups.
   • While you can't just do it and let the helpdesk sort it out for everyone, management is going to be a lot more open to piloting the changes with a select group of hand-picked employees, especially if they think there's a valid security concern.
   • Pick your test group carefully. It might be wise to use IT folk first, then widen the group to include people from other departments.
   • Obviously, monitor your test group and stay in constant communication with them to quickly resolve issues you didn't catch the first time around.
4. Roll out the change slowly, and in stages.
   • Once you've tested it to your satisfaction, you should still exercise caution, and not just push it out to the whole domain at once. Roll it out to smaller groups, which you'll have to define according to your organization's structure and needs.
5. Make sure you have something in place to handle future changes.
   • Just making it work for what you have in your environment now isn't going to be enough, because you will end up with new applications on your domain, and you'll have to make sure the firewall policy is updated to accommodate them, or someone above you will decide the firewall is more trouble than it's worth and will have the policy removed, eliminating and the work you've put into it so far.

Solution 2:

Edit: I would just like to state that there is nothing inherently wrong with Windows Firewall. It is a perfectly acceptable part of an overall defense-in-depth strategy. The fact of the matter is, most shops are too incompetent or too lazy to be bothered to figure out what firewall rules are needed for the applications that they run, and so they just force it off ubiquitously.

If Windows Firewall, for instance, prevents your domain controllers from doing their job, it's because you didn't know what ports Active Directory needed before you turned the firewall on, or because you configured the policy incorrectly.

That's the bottom line of the matter.

First, communicate with your project managers, your bosses, your stake holders, your change advisory cabinet, whatever the process is in your company, and inform them all that you will be undergoing a gradual remediation involving the Windows Firewall in order to increase the overall security posture of your environment.

Make sure that they understand that there are risks. Yes, of course we'll do everything we can, all the planning that we can, to ensure that there will be no interruptions, but don't make any promises. Trying to whip an old domain into shape is hard work.

Next, you have to inventory applications that are in use in your environment and what ports they require. Depending on the environment, this can be very difficult. But it has to be done. Monitoring agents? SCCM agents? Antivirus agents? The list goes on.

Develop a Windows Firewall GPO that includes custom rules for your enterprise applications. You may require multiple policies with different scopes that apply to different servers. For instance, a separate policy that applies only to web servers for ports 80, 443, etc.

The built-in Windows Firewall policies will be very helpful to you, as they are perfectly scoped to accommodate most common Windows activities. These built in rules are better because they don't just open or close a port to the entire system - they're scoped to very specific process and protocol activity taking place on the machine, etc. But they don't cover your custom applications, so add those rules to the policies as auxiliary ACEs.

Roll out in a test environment first if possible, and when rolling out to production, do so in limited chunks first. Don't just plop the GPO on the entire domain on your first go.

That last statement is probably the best piece of advice that I can give you - roll out your changes in very small, controlled scopes.

Solution 3:

Okay, I'm about to suggest something that may or may not get you in trouble, but it's what I use when I'm turning on the firewall.

Nmap. (Any port scanner would do.) I fear I don't trust documentation of what ports are in use. I want to see for myself.

Background: I'm from an academic environment where student laptops rubbed elbows with our servers (Ugh!). When I started using nmap on my own servers, we had no IDS, either, so I could nmap at will and no one would notice. Then they implemented IDS and I'd get emails forwarded to me that basically said, "NETWORK PORT SCAN ATTACK ON YOUR SERVER FROM YOUR WORKSTATION!!!!!" and I'd reply and say, "Yep, that's me." Heh. After awhile they developed a sense of humor about it. ;)

I also used nmap on workstations, for example, to look for conficker. Nmap would likely turn up the AV management ports, any other management software ports, etc. (Desktop will be very crabby if you break their management software.) It might also turn up unauthorized software, depending on your environment.

Anyway. Some environments will freak out about nmap and some won't even notice. I generally only nmap my own servers, or workstations for a specific purpose, which helps. But yes, you probably want to clear that you're going to be running a port scan with anyone who might freak out on you.

Then, you know. What Ryan Ries said. Management/change management/group policy/etc.

Solution 4:

I don't believe there's any utilities available from Microsoft on this, but if I were to use Windows Firewall on our domain (it's enabled where I work) I would ensure the following:

1. Exceptions exist for all remote administration tools (WMI, etc etc)
2. Create IP range exceptions on domain workstations to allow administrative servers (such as SCCM/SCOM, if you have them) to allow all traffic.
3. Allow end users to add exceptions to the domain profile only for software in case you miss some things (and you will).

Servers are a bit of a different beast. I currently have the firewall disabled for our servers because enabling it caused many problems even with exceptions in place. You basically have to apply a blanket "skeleton" policy for all servers (disallowing unsafe ports, for example) then going to each server and individually customizing settings. Because of this, I can see the reason a lot of IT folk just disable the firewall. Your perimeter firewall should protect these machines enough without their own firewalls. However, sometimes it's worth the effort to individually configure servers for high-security environments.

As a side note, Windows Firewall also governs use of IPsec, so if that's used you need the firewall anyway.