The final important aspect of firewall maintenance involves keeping up to date. You obviously need to keep your system up to date, but before you can do so, you need to keep yourself up to date.
The hardest part of firewall maintenance is staying abreast of the continuous developments in the field. New things are happening every day: new bugs are being discovered and exploited; new attacks are being carried out; new patches and fixes for your existing systems and tools are being made available; and new tools are becoming available. Staying up to date with all these changes can easily be the most time-consuming part of a firewall maintainer's job.
How do you stay up to date? Well, primarily by staying involved. Find a set of mailing lists, newsgroups, web sites, and professional forums you feel comfortable with and follow them carefully. This section describes the most important ways you can keep involved. Appendix A, provides a more complete list, along with contact information.
Several mailing lists might be of interest to anyone who maintains a firewall; instructions for subscribing to them are included in Appendix A. The most important list for folks interested in firewalls is the Firewalls mailing list. This list hosts discussions of the design, installation, configuration, maintenance, and philosophy of Internet firewalls of all types. The main drawback of the list is that it can be very busy; sometimes more than 100 messages per day are posted to the list. To address the problem of volume, a Firewalls-Digest version of the list is also available; Firewalls-Digest subscribers receive all of the same messages that subscribers to the main Firewalls list receive, but the messages are bundled into "digest" format (usually 10 to 20 messages are in a digest).
Another list you should almost certainly subscribe to is the CERT-Advisory mailing list. This is the list to which CERT-CC posts its new security advisories. If you are served by a response team other than CERT-CC (e.g., one of the other teams in FIRST, described in Appendix A), check to see if that team has its own advisory list and subscribe to that one as well as to the CERT-CC list. Your team will probably mirror most of CERT-CC's advisories and may produce advisories of its own that are relevant to its constituency (you) that aren't mirrored by CERT-CC.
Beyond the Firewalls and CERT-Advisory mailing lists, the choices are less clear. There are several geographic or industry-specific firewalls lists (e.g., the Firewall-Developers, Academic-Firewalls, and Firewalls-UK lists). A mailing list called Bugtraq provides detailed discussions of network security holes; if you can wade through the seemingly perpetual flame wars, you can occasionally find some gems there. The Windows NT-oriented list NT-Bugtraq is particularly useful.
There are also product- and package-specific lists for many firewalls products and packages; for example, there are lists for Livingston, Telebit, and Cisco routers and the TIS FWTK. If you are using (or contemplating using) a particular product or package, you should probably subscribe to the list for that product or package, if there is one. Lists of this kind are often an invaluable source of technical support, particularly during widespread security incidents.
Many operating system vendors also have special mailing lists used for distributing security information. Check with your vendor for information about lists they maintain and how to subscribe to them.
In addition to the various mailing lists you might subscribe to, a variety of newsgroups are directly or indirectly relevant to firewalls. Many of these parallel the mailing lists mentioned in the previous section. For example, CERT-CC advisories are posted to the comp.security.announce group, and there are newsgroups for a variety of commercial and noncommercial network products. There is also a newsgroup dedicated to firewalls, comp.security.firewalls. Unfortunately, it is an extremely high-volume newsgroup and contains a large number of absolute beginners asking the same questions over and over again, and an almost equal number of firewall vendors either trying to push their products, or complaining that other people are trying to push products.
The Web changes so rapidly that it's almost senseless to put the names of web sites in print. There are a wide variety of security and system administration sites, ranging from sites put up by attackers (that appear and disappear extremely rapidly) through subscription-only sites run by magazines. Your best bet is to use a web search engine to look for information about the topics that interest you. You usually will get better information from using a variety of sources found this way than from any single site.
Many professional forums are available for your participation. They include conferences, vendor user groups, local user groups, professional societies (such as IEEE and ACM special interest groups), and so on. Many people find attending these events invaluable, not so much for the formal programs presented, but for the contacts they make with other people who have solved problems similar to those they are currently facing.
At this point, one of the best conferences for Internet firewall builders and maintainers is the USENIX Security Symposium (generally held annually). If you are a Unix system administrator, one of the best possible ways you can spend a week each year is at the USENIX LISA[2] conference; Windows NT-only system administrators would be better off at the USENIX LISA-NT conference. You can find more information about all of these conferences and about USENIX in general in Appendix A.
Local user and special interest groups are also a great way to keep in touch between conferences; most meet monthly or bimonthly.
If you take care to keep yourself up to date, then keeping your system up to date is a fairly straightforward job. You just need to deal with whatever new problems you hear about, as you hear about them.
You should be able to collect enough information from the sources described in the previous section to decide whether or not a new problem is a problem for your site in particular. Be aware that you may not be able to determine instantaneously whether a problem applies to your site; it may take a few hours or days for the information you need to become available to you. You may need to make a judgment call about what to do about a particular problem in the absence of solid information, with only vague reports about the problem and its consequences to go on. Which way you err — towards caution or convenience — is going to be dictated by your particular circumstances. These circumstances include the potential problem involved, what you can realistically do about it, how much your site cares about security versus availability and convenience, and so on. Caution would dictate blocking the problem if it's at all possible that it applies to you. Convenience, on the other hand, would dictate waiting to take action until you're fairly sure that the problem does apply to you.
Keep in mind the following principles when you are deciding what fixes to apply and when:
Don't be in too big a hurry to install a patch or a fix unless you have reason to believe that the problem is being, or could be, exploited against you. It's always better to let somebody else go first, to discover what new problems the patch or fix creates. We're not suggesting you should delay very long in installing a relevant patch, but it's often wise to wait at least a few hours or a couple of days to see if the patch blows up on anybody else.
You don't want to apply patches for problems you don't have. If you do apply patches in this way, you run a great risk of introducing new problems. If a patch applies only to a particular piece of software or a particular release, and you don't use that software or that release, don't install the patch. If it applies to features that you don't use in programs that you do use, apply it anyway; you may start using the features in the future, and at that point, you won't remember whether or not you patched it.
While you generally shouldn't apply patches for problems you don't have, be aware that patches for problems you do have may depend on previous patches for problems you don't have. With any luck, the documentation for the patch you want to apply says what other patches (if any) are prerequisites, but this isn't always the case. Sometimes you just have to make your best guess. In such situations, it really helps to be tied in to the support mailing lists and newsgroups concerning your platform; you can ask there and see if anybody else has already figured this out.
[2] LISA used to mean "Large Installation System Administration", back in the days when a large installation meant having more than a dozen machines; today, most sites would qualify under that definition, and the focus of the conference has widened to include all types of Unix system administration—but the name lives on.