Blogger Mark Underwood offers tips for upgrading firewalls, having just dealt with his own upgrade experience.
For the small to midsize business, firewall management is just one of the many hats worn by the "network" or "systems" administrator. As a result, a technician is less likely to be intimately familiar with a firewall's internals.
Typically a firewall receives intermittent use--for example, when a new application comes online or a new server is added to the farm. This occasional use is fine for day-to-day operations, but it doesn't provide the comfort zone for intensive work, such as switching from one vendor’s firewall to another or upgrading from a vendor’s low-end model to something more sophisticated.
The issues involved in upgrading a firewall range from the straightforward to the complex, but they are potentially numerous.
After a recent upgrade conducted by a small technology firm, I interviewed the firm's system administrator, Rich Gallo. He provided a lengthy list of concerns, shown grouped into seven categories in Figure B.
Figure B
- Gallo was able to overcome them, but challenges included quirky handling of previously unused external IP addresses by ISP Verizon and coordination with a remote office subnet. Having two technicians working through the issues undoubtedly reduced the chance for errors in manually moving firewall rules for CheckPoint to Cisco.
- Each set of applications had associated ports, IP addresses, and user lists. Where necessary, program managers were contacted to verify current requirements. Where possible, schedules were coordinated with periods of low utilization.
- The firewall upgrade can be an opportunity to rearrange cables routes, move switches, readjust bandwidth handling, or reorganize server cabinets.
- A good test plan is a nontrivial affair, involving testing of not only connectivity but applications. For instance, public-facing applications must be tested from both inside the network and from outside the network using external tools where necessary. It's also prudent to review failover plans and recovery plans--just in case.
- VPNs are a special case that may affect firewall rules. In Gallo's firm, there were site-to-site VPN requirements that needed special attention. There were also client-specific issues, since support was needed for both x32 and x64 clients, Mac, Windows and Linux platforms, and a mix of user familiarity in setting up a VPN. For instance, it was discovered that there was a known issue with Snow Leopard that didn't permit AnyConnect split tunnels to work properly. Administrators will do well to collect details for inside and outside DNS records and shared keys well in advance of the moment of reckoning.
- Firewall rules are the heart of the appliance's capabilities, but they may be represented very differently in the old firewall when compared to the new. This is a good time to document those rules, remove unused rules, and run the new set of rules by application managers. For instance, one new rule may lock down the firewall itself--which is by definition a new rule. And rules should be provided in both a machine-readable, firewall-specific format and a transparently understandable format. One or the other may be needed for recovery after a major incident.
- A new firewall will affect logging and alert processes. Plan to update alerts and log readers to respond to new alerts in ways that can be used by the security analyst (who may be the same person who's performing the upgrade) and others familiar with nominal behavior of supported applications.
via http://www.zdnetasia.com/7-tips-for-replacing-a-firewall-62061404.htm?scid=nl_z_tgis