 | Chapter 12 Maintaining Firewalls |  |
| Chapter 12 Maintaining Firewalls | |
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 that, 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, magazines, 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.
There are several mailing lists that might be of interest to anyone who maintains a firewall; instructions for subscribing to these are included in Appendix A. The most important list for folks interested in firewalls is the Firewalls mailing list at greatcircle.com. 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; there are sometimes more than 100 messages per day 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 (there are usually 10 to 20 messages per 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 the 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 Academic-Firewalls and Firewalls-UK lists. There is also a mailing list called Bugtraq, where detailed discussions of network security holes take place; if you can wade through the seemingly perpetual flame wars, you can occasionally find some gems there.
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, Morning Star software, 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.
In addition to the various mailing lists you might subscribe to, there are a variety of newsgroups that 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 has been talk of creating a firewalls newsgroup (probably comp.security.firewalls, or perhaps a pair of related newsgroups: comp.security.firewalls.misc and comp.security.firewalls.announce), which would be completely independent of the Firewalls mailing list discussed above.[3]
[3] This may or may not have happened by the time you read this.
Many trade magazines are beginning to include occasional or regular features on firewalls, although there isn't yet an entire magazine devoted to Internet security. (However, it's probably just a matter of time before one appears.) At this point, none of the magazines stand head and shoulders above the rest in terms of their coverage of firewalls. One thing to keep in mind about magazines (even tabloid weeklies like Network World and MacWeek) is their lead time; you often hear about something on the Net - on the various mailing lists and newsgroups discussed above - weeks before it appears in the trade press.
There are many professional forums available for your participation. These 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, then one of the best possible ways you can spend a week each year is at the USENIX LISA conference.[4] You can find more information about both of these conferences and about USENIX in general in Appendix A.
[4] 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.
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. Beware 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.
There are a couple of principles to keep in mind 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. Situations like this are where 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.
|  | |
| 12.2 Monitoring Your System |  | 12.4 How Long Does It Take? |