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.
26.3.1. Keeping 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, "Resources", provides a more complete list, along
with contact information.
26.3.1.1. Mailing lists
Several mailing lists might be of
interest to anyone who maintains a firewall; instructions for
subscribing to them are included in
Appendix A, "Resources". 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, "Resources"), 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.
any 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.
26.3.1.2. Newsgroups
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.
26.3.1.3. Web sites
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.
26.3.1.4. Professional forums
any 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[186]
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, "Resources".
Local user and special interest groups are also a great way to keep
in touch between conferences; most meet monthly or bimonthly.
26.3.2. Keeping Your Systems up to Date
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 a hurry to upgrade
- 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.
- Don't patch problems you don't have
- 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.
- Beware of interdependent patches
- 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.