Image by arellis49 via Flickr
So you’re going to rip out your old firewall and put in a new one. Ah, lucky you. I’m in the midst of doing exactly that for several sites I manage. Here’s a few things to take into consideration if you’re in the planning stages.
- Communication is key. There’s two levels of communication to consider. The first is the general communication to your organization. While your user community doesn’t need to know what you’re doing exactly (they wouldn’t know a firewall from a burning building), they do need to know when services might be unavailable and for how long. They also should be told what is expected of them, if anything, and after what time they should contact the help desk if services remain unavailable. The second is a technical communication to your IT support staff. Not everyone in IT will care about the details, but they should know about things like IP address changes, new IPS behavior, old/new IPs that should be monitored, process changes, and the like. Consider a conference call with key IT team members to explain in more detail and give the opportunity for questions…which you will answer with politeness and clarity and no heavy sighing or eye-rolling, because you’re not like the others.
- Do an audit. That smell? Yeah – that’s your 5 year old firewall policy rotting with dead, unused objects and rules, each of which might represent a needless security hole. So don’t just take all your old firewall accounts, objects, rules, and tunnels and carry them forward to your new firewall. Even if you have a decommissioning process for systems, contractors, and employees that should ensure an up-to-date firewall policy, the chances are that your policy is fairly necrotic. Don’t carry putrefaction forward.
- Understand behavioral changes. If changing firewall vendors, you need to know the way in which the firewall forwards packets. It’s not always as simple as “if the packet matches a permit rule, it’s allowed.” For example, Cisco firewalls have the idea of “higher security” interfaces to talk to “lower security” interfaces (a concept I detest), but not the reverse in their default way of forwarding traffic. Check Point firewalls don’t allow anything through at all unless expressly permitted via a global policy (a concept I like much better). Deep packet inspection and NAT behavior will vary widely by platform. MTU settings might be different, which could have application impact if PMTUD is broken (you know what ICMP messages are used by PMTUD, right?). If you rely on hairpin routing (traffic entering and exiting the same interface), you need to be sure your new firewall supports it. Is a packet NAT’ted before it is processed by an ACL or encrypted?
- Be ready to troubleshoot. Get a handle on packet sniffing and/or event logging before putting the new firewalls into production. It’s a guarantee that you’ll need that information on the day following the firewall change. If something doesn’t work and your business is impacted, that’s not the time to be figuring out how to parse through hundreds of events per second to find an issue. You will look and feel silly, which will make you stressed. And then you’ll eat the family-size bag of Doritos all by yourself, all 1300 calories worth. Don’t deny it, you know you will.
- Name objects according to a standard. Since you’re building a new policy, name your firewall objects according to a standard. I use a scheme that is LOCATION_HOSTNAME_IP to name objects. That works for me, as it’s helpful in reporting, troubleshooting, grouping, and sorting lists. That might not work for you, but I beg you for the sake the engineer that will come after you, name your objects something meaningful and stick to the scheme. I daydream about making my predecessor read every meaningless firewall object name aloud and then stating very loudly to a company-wide conference call, “I made very bad choices for which others have indescribably suffered. I am very, very sorry and admit my horrible incompetence before you all.”
- Datestamp your rulebase. There is value in putting a date on your firewall rules in the comment field presumably available to you. Every time you modify them, update the datestamp. That is useful in an audit, as you’ll know when the last time was the rule was touched; it’s a basic necrosis meter. I’m not saying that just because a rule is old that it’s no good, but the IT world changes quickly. Any untouched policy object older than 2 years is automatically suspect in my mind. You really think that SMTP rule from 2004 is still valid? Yeah, didn’t think so.
- Don’t forget impacted third parties. Very often, firewalls sit in front of services that are Internet-facing. Will this firewall change impact Internet clients, especially paying ones? If so, does someone in your company need to let them know? Or will you be moving services to a different data center? Is this firewall used to terminate VPN tunnels? Do you need to coordinate a tunnel outage or peer IP change with your extranet partners? I know you’re not one of those engineers who like to make people suffer, so do the right thing here. Just sayin’.
- Be ready to backout. I know; you’re not going back. You’ll never go back. Once you move traffic to the new firewall, you’ll fix the problem in the new environment rather than backout. Yeah. Been there. Fixed that. Added that forgotten object to the access-list. But don’t fool yourself – there are unforeseeable circumstances you could experience on a new firewall platform that will require to go back to the old hardware. Yes, you’d rather fillet your own leg with rusty barbed wire and pour rock salt in the wound first, but face the fact that something you didn’t think of, that no one told you, that’s not your fault could be impacting your business so catastrophically badly that you’ve simply got to backout and reboot your project. So don’t move traffic, rip the old firewall out of the rack, and smash it with glee. You might need it a little longer. A good idea is to have all code, along with each step required to backout, pre-written and ready to roll. You don’t want to have to think hard about the backout steps, because if you’re backing out, it’s probably because of a high-pressure situation.
