When migrating from Windows Server 2003 to Windows Server 2012 R2, you should take some time do reassess the way that client firewalls are configured for the servers in your organization. The uncomfortable reality is that on many internal organizational networks, server (and client) firewalls are disabled entirely.
This happens because time pressed administrators are trying to solve some sort of connectivity problem between computers. They find that if they turn off the firewall everything works well. If they turn it on and make a rule for the type of traffic that should be let through, it sometimes doesn’t work. Rather than enable logging and figure out what’s really going on in terms of the traffic, their response is “stuff this for a game of soldiers” and simply disable the firewall.
If I had a dollar for every server running Windows Server 2003 on an internal network with Windows Firewall disabled that I’ve encountered, then I’d be able to afford quite a few of those new Lego Hellicarriers.
The firewall that shipped with Windows Server 2003 got a bit of a bad rap. And because it got a bit of a bad rap, some administrators have made a habit out of disabling the computer firewall rather than working with it.
One of the reasons used to justify doing this is that the servers are on a protected internal network anyway, so the firewall isn’t really needed.
As mentioned in a previous article, the internal organizational networks of 12 years ago are very different to the internal organizational networks of today. 12 years ago portable computers were rare. Today they make up the majority of computers connected to corporate networks. Portable computers are a bit like cats. The moment they are out of your sight, you have absolutely no idea what they get up to. Or what they will drag back onto the protected internal network when they return.
So when migrating from Windows Server 2003 to Windows Server 2012 R2, make sure one of the things you don’t do is turn off Windows Firewall. Because you never know what the cat dragged in.
In terms of configuring Windows Firewall, you can use group policy to ensure a consistent set of basic rules across all servers, and then configure unique server specific rules on a case by case basis. Enable and use firewall logs to diagnose which rules you need to create, rather than just turning off the firewall once you start getting frustrated with it.
Sure, Windows Firewall isn’t going to protect against everything, but that’s not why you use it. Security is about taking many small steps that incrementally improve protection. Even if you don’t think highly of Windows Firewall, a server with it switched on is better protected than a server without it at all.