Managing and migrating firewalls
What do you need to work with it and how do you stay consistent as things change? And when change means more than a new configuration, there isn’t a simple way to replace one brand of firewall with another. What’s the best way to manage such a migration?
Back in the day, a firewall was a simple product. It usually only had two interfaces. And it also usually only had one purpose. To let specific incoming network traffic get to the inside. And often, to only let specific network traffic to get to the outside. Because of this, it was very common to treat firewalls as ‘fire and forget’ devices. You had set up and tested the rules so you could ignore it until those rules (or the hardware itself) needed upgrading.
Of course, things didn’t stay that simple for long.
Network complexity grew quickly, and so did the requirements for firewalling. Extranets, local hosting in a DMZ, and VPNs for business-to-business or employee-to-business use all add to the number and complexity of and interaction between rule sets. Firewalls gained more interfaces too, as wireless LAN and DMZ usage grew. However, tools and practices for firewall management have not kept up with this more complex environment.
Firewalls are still the technological equivalent of city walls for the businesses you work with. So who is looking out from the walls, making sure the barbarian hordes of exploits and attacks are kept out? And who is responsible for making sure those walls are kept in the best possible condition?
Making sure those questions are answered leads directly to the processes for firewall management. Firstly, there are the monitoring and alerting processes. These take the logged results of the activity of the firewall, and turn those into general information about the state of traffic flowing on the network, but also provide specific warnings on any situation requiring urgent attention.
Secondly, there are the processes by which the firewall is kept updated – whether those are software upgrades, new or changed rule sets, or new functionality. These processes will be similar to the procedures used to manage changes to any other devices in customers’ IT infrastructure.
Firewalls, no matter who manufactures them, have always had the ability to log the actions they take on the network traffic flowing through them. It soon became obvious that this amount of data was beyond the ability of the firewall itself to store, let alone analyse. So the ability to send this data to a separate logging server, usually running the UNIX Syslog daemon (or a port of syslogd to another operating system), was designed into early firewalls. Logging to syslog servers remains the most common way of capturing firewall activity. However syslog servers are just simple capture-and-store mechanisms, receiving packets of information via TCP/IP and storing those on disk. This means any analysis of the captured data must be done by other programs, reading and parsing those captured logs. Some software manufacturers have taken the model further. They have combined a syslog capture mechanism with the ability to analyse the captured logs as a whole – providing a one-stop mechanism to monitor the functioning and performance of the firewall.
Unfortunately, software of that type is rather expensive – around £200 per device monitored. At the cheaper and free end of the market are a large number of syslog capture programs, but other than displaying (and occasionally colourising) the incoming log information many provide no additional analysis ability, requiring you to watch and understand what the firewall is telling you.
For a less complex network, Firegen (www.eventid.net/firewalls/) is available for a range of different devices and firewalls. Its reporting is comprehensive though it does not perform summarisation over time.
For customers using Sonicwall devices, there are three dedicated products for log analysis. For five devices or fewer, Sonicwall Viewpoint (www.sonicwall.com/us/pr...) provides both instant access to information on in-progress attacks and comprehensive reporting on firewall activity. It provides a wealth of information and trend analysis in easy-to-understand graphical reports. For larger networks, Sonicwall Global Management System combines Viewpoint’s reporting abilities with the ability to remotely configure Sonicwall devices. And the Sonicwall Universal Management Appliance provides all the functionality of the Global Management System in a dedicated hardware device. The most commonly used free or open source log analyser is FWAnalog. (http://tud.at/programm/fwanalog/). This is a UNIX shell script that parses and summarises a range of common firewall logfiles into a form that can be displayed by the free logfile analyser Analog (www.analog.cx). Though it hasn’t been updated in some time, it is maintained in at least two Linux distributions: Debian and Ubuntu. The reporting is pretty basic, but gives enough detail to give an overview of the network.
Monitoring or alerting?
Log analysis can provide you with two different views into the data flows at the firewall. Both are important, but in very different ways. For the network administrator, real-time alerting is the reactive feed of information, enabling you to identify and counter threats to the network.
Periodic monitoring – daily, weekly and monthly views of aggregate data – is the proactive feed of information, allowing you to take a much higher-level view of traffic flows in order to identify the network traffic trends that need to be fed into medium and long-term network planning.
Any network administrator needs to be informed of alerts coming from their firewall. Whether this is as simple as a syslog server that displays high status alerts in a window or as complex as a feed into a company-wide ticketing and alerting system, if serious warnings from the firewall can go unheeded then there is little point in having a firewall at all. Wouldn’t you want to know instantly if its administrator password had been changed?
A network administrator needs to be aware of two different kinds of alerts. There are those that indicate potentially anomalous behaviour or unexpected changes. These include password changes, but also rule changes, configuration changes, reboots, and so on. While the vast majority of these will only indicate expected behaviour, each needs to flagged – for the ones that are not expected behaviour are critically serious and need immediate action by the administrator.
You also need to keep a careful eye on threshold alerts. These are alerts that indicate that a particular class of network activity is occurring excessively. For example, a PC with a bad network card may flood the network with traffic, degrading the service for other network users. A threshold alert monitoring for traffic levels over time would allow the network administrator to spot and rectify this. Other examples of threshold reports that would be of interest include volumes of specific traffic types – heavy SMTP traffic from a workstation PC (over 60 messages an hour, say) may indicate a problem with an application or a bot infection, unexpectedly heavy traffic of specific types from outside the network may indicate attempted attack.
What is ‘unexpectedly heavy traffic’ though? Without knowing what the average traffic levels and average traffic types are on the network, there is no way to know what is different from the norm (a particular user might regularly send large amounts of email). This is why periodic monitoring is required. It is the way you establish a baseline picture of your network: expected volumes (both overall and per-device), expected traffic types, usual levels of intrusion attempts, types of intrusion attempts and so on. With the understanding of your network this information provides, it becomes easier to spot unusual behaviour.
Monitoring of the daily reports is especially important. Because it’s here you’ll first see things crop up that may be serious enough to demand attention, yet are not in the rules to set off an instant or threshold-based alert. And comparing the latest daily report to those in the recent past will give a clear indication of emerging trends in network traffic that may require attention or further monitoring.
When I look at the firewall of a new client, the very first thing I check is whether it is running the most recent firmware or for the product. More than nine times out of ten, it isn’t. Experience tells me that if there is no maintenance being carried out on the firmware or OS of a firewall, then there certainly will be not much being done on its rule and feature sets.
The average network environment is not a static environment. New threats happen, business needs change, hardware goes wrong. Firewall monitoring tells you that. It can’t be right to ignore the state of your firewall until it goes badly wrong. Proactive maintenance is needed, based on the information you get from your monitoring logs. Such maintenance does not need to be onerous, or difficult. But it does need to be done. There are several items that need to be maintained on a firewall. First are the rule sets controlling network traffic. Are they all correct and relevant? Have any been superseded or have fallen out of use? Have there been any IT security policy changes that require a re-modelling of the rules? Are there any particular forms of traffic, or network locations, that seem to require further investigation? It may be time to put in specific rules in order to analyse areas like these in more detail.
Modern firewalls can provide much more than simple network traffic control. All of their additional functionality, whether that is virus scanning, email filtering, intrusion detection or content filtering needs maintenance. While some of this functionality will get updated automatically (virus definitions in particular), it is still necessary to keep these functions and their performance under review, in order to make sure that they are not interfering with business needs, and to make sure that they are configured and updated properly.
As well as the general management for performance, updates and business drivers, it is also important to keep an eye on the wider network security community, in order to keep informed about potential new threats. Often, sources such as the Internet Storm Center (http://isc.sans.org), in particular their reports and trends pages, can provide early warning of problems that may be proactively dealt with by local firewall configuration.
Each company considering the idea has its own reasons for migrating to a new firewall. They are many and varied, but fall into certain categories.
Firstly, there’s technology renewal. As mentioned before, firewalls tend to be in the ‘it just works’ category. But technology infrastructures have their own lifespan and will eventually be replaced. In this case, firewall replacement comes as a natural part of a larger infrastructure renewal project.
Gaining additional features is a very strong reason for migration to a new firewall device. Devices aimed at mid-sized companies have added many features over and above simple firewalling – they often now have the ability to perform content filtering, virus scanning and to provide proactive intrusion detection. These features are often of sufficient importance to make a firewall migration worthwhile for its own sake.
In addition, don’t underestimate personal choice! Often, a migration is done just because the person in charge of the IT is more comfortable with one brand of firewall than another. Whether that is because of support, or merely familiarity with the feature set or way of working, individual preference is a common reason for firewall changes.
The fun really begins after the decision to migrate has been made. In all but the largest companies, firewalls are single points of failure, and right on the critical path of network function. This can make migration a challenge – especially considering there are nearly no automated tools for the task.
It is definitely an inconvenience that firewalls cannot export their configurations, settings and rule sets in a format that is interchangeable with other firewalls. It leaves the process of documenting the state of the firewall open to human error and it means someone is going to have to go through every setting by hand, checking and recording. There are of course specialist security and firewall consultants you can partner with to perform the work, but with careful planning, there is no reason why a firewall migration project should be more complicated or less successful than any other migration of infrastructure to new hardware.
Like any project, the only way of achieving a successful outcome is to know from the start what that outcome should be. This is especially important in firewall migrations, where the migration itself is often only seen as a technical part of another project – providing VPN access, for example. But the fact that the migration needs to be carried out gives you an opportunity to evaluate the other functions currently performed by the firewall, to see if they are still necessary,
or whether they can be improved.