Make sure to back up all parts of your firewall. That means not only the general-purpose computers you may be using as bastion hosts or internal servers, but also the routers or other special-purpose devices. Rebuilding router configurations usually isn’t easy, and your security depends on having your routers configured correctly.

Put your general-purpose machines on a regular, automated backup system. Preferably, that system should produce confirmation mail when it is running normally and distinctly different messages when it sees errors.

Why not produce mail only when errors occur? If the system produces mail only on errors, you won’t notice the system if it fails to run at all. (Silence is not necessarily golden, as any parent of small children knows. If they aren’t making noise, they’re probably making mischief.)

Why distinctly different messages? If the system produces even vaguely similar messages when it is running normally and when it fails, people who are accustomed to ignoring the success messages will also ignore the failure messages. Ideally, a separate program should check to make sure that the backups have run and to produce messages when they haven’t.

Special-purpose machines like routers change much less often and probably don’t need an automated backup system. (This is fortunate because such machines rarely support them.) When you do make changes, take advantage of any means available to record the configuration. Most systems write their configuration to flash memory and can transfer configurations via FTP. Some of them also have floppy drives. If you can write the configuration to floppy, do so, and store a floppy separate from the machine. Make backups even if you have downloaded the configuration with FTP; you don’t want the router to be completely dependent on another machine. If you didn’t download the configuration with FTP, make an FTP copy as well as the floppy disks. Why? Sometimes it’s easier to find files than to find small physical objects like floppy disks, and sometimes the floppy drive dies when the rest of the router still works. If you cannot write a floppy disk or another backup that the router can read directly, you should at least be sure that the necessary files for FTP are available from multiple places.

Account management — adding new accounts, removing old ones, changing passwords, etc. — is one of the most often neglected housekeeping tasks. On firewall systems, it’s absolutely crucial that new accounts be added correctly, old accounts removed promptly, and passwords changed appropriately. (See your own system’s documentation for how to do all this.)

Establish a procedure for adding accounts; wherever you can, use a program to add them. Even though there shouldn’t be many users on your firewall systems, every one of them is a possible danger, and it’s worth the effort to ensure they’re set up correctly every time. People have an unfortunate tendency to leave out steps or to pause for a few days in the middle of a process. If that gap leaves an account that has no password, you’re creating open invitations to intruders.

Make sure your account creation procedure includes dating the account and that accounts are automatically reviewed every few months. You don’t need to automatically turn them off, but you do need to automatically inform somebody that they’ve timed out. It’s relatively easy to do on a general-purpose computer; it may be harder on other systems, particularly dedicated systems like routers. If possible, set things up so that the accounts can be watched by an automated system. This can be done by generating account files on a general-purpose computer and then transferring them to the other machine, or by generating the accounts on the machine itself, but automatically copying the account files to a general-purpose computer and examining them.

If your devices support reasonably secure protocols that will allow you to centrally maintain accounts, you should consider using them. However, doing user authentication via NIS or Windows domain authentication on firewall machines is not advisable for security and reliability reasons.

You should also arrange to get termination notices from the appropriate authorities whenever someone leaves your organization. Most companies are able to send notices for full-time employees, and most universities can provide graduation notification for students. It may be much harder to keep track of contractors and students who drop out, so you shouldn’t rely on official notifications to tell you about everybody who has left. You may also need to confirm notifications: for example, you may get termination notices for people who are actually converting to contract status, or graduation notices for people who are continuing as graduate students or junior faculty. These people are going to be annoyed if you get rid of all their files (although it’s probably acceptable to temporarily disable their accounts if their status is in doubt).

If you can, set up all accounts on the firewall to have nonreusable passwords (see Chapter 21, for more information on nonreusable password systems). This will prevent people from either guessing or sniffing passwords and may help limit people’s ability to share passwords with each other.

If you are using reusable passwords, or nonreusable passwords with a fixed component, encourage people to change them regularly to help prevent guessing and limit the usefulness of password sniffing. If your operating system supports password aging, you may want to turn it on. Use a relatively long time period — perhaps three to six months. If you time out passwords more frequently (e.g., every month), users will be willing to go to great lengths to circumvent the timeout, and you probably won’t see any real gain in security. Similarly, if your password aging doesn’t guarantee that the user will see a notification before the account becomes unusable, don’t turn it on. Otherwise, you will annoy your users, and you will run the risk of accidentally locking out administrators who have a critical need to use the machine.

If password aging on your system is going to require users to change their password as they are logging in, you need a password program that strictly enforces good passwords. If you don’t do this, people will choose simple passwords in the heat of the moment, honestly intending to change them to better ones later. All in all, you may find it more effective to simply send people notices on a regular basis, even though you’ll get less compliance that way.

Data always expands to fill all available space, even on machines that have almost no users. People dump things in odd corners of the filesystem “just for now”, and they build up there. This causes more problems than you may realize. Aside from the fact that you may want that disk space, this random junk complicates incident response. You’ll end up asking yourself:

Unfortunately, there is no automatic way to find junk; human beings, particularly system administrators who can write anywhere on the disk, are too unpredictable. Another person needs to look around on a regular basis. It’s particularly effective to send every new system administrator on a tour of the disks; they’ll notice things the old hands have become accustomed to.

Auditing programs like Tripwire, discussed in Chapter 10, will tell you about new files that appear in supposedly static areas, and this information will help you keep things straight. You will still need to check all the areas where you intentionally allow changes, and you should periodically go back and re-check the static areas. You will probably get the alert while you still know why you put that file in that place, and that knowledge may wear off over time.

Aside from accumulating junk, your main disk space problem will be logs. These can and should be rotated automatically, and you may want to compress, encrypt, or digitally sign them as well. A program like trimlog (see Appendix B) can help automate the process. You should also consider making a copy of the files on another system.

It is very important to correctly rotate or truncate logs. If a program is trying to write to a log file while you’re trying to move or truncate it, you’re obviously going to have problems. In fact, you may run into difficulties even if a program is simply holding the file open in preparation for writing to it later; notably, you may later discover that the program is still logging to the file you renamed.

Under Unix the normal convention for rotating log files is as follows:

Signaling could involve sending a Unix signal or creating a dummy file that the program checks for.

Most Windows NT programs use the Event Logger to deal with logging. As we discussed in Chapter 12, the Event Logger provides no way to rotate logs, which means that it has to be done by hand or with third-party software. The situation with programs that keep their own logs is not so clear; you will normally need to use a special accompanying tool to rotate a program’s log files or configure the program to rotate the logs based upon some point (for instance, weekly or when a particular size has been reached).

Under both operating systems, it is unfortunately sometimes necessary, particularly when using add-on products, to stop programs or cause them to suspend logging while you truncate or move logs.

You’ll do most of your monitoring using the tools and the logging provided by the existing parts of your firewall, but you may find it convenient to have some dedicated monitoring devices as well. For example, you may want to put a monitoring station on your perimeter net so you can be sure only the packets you expect are going across it. You can use a general-purpose computer with network snooping software on it, or you can use a special-purpose network sniffer.

How can you make certain that this monitoring machine can’t be used by an intruder? In fact, you’d prefer that an intruder not even detect its existence. On some network hardware, you can disable transmission in the network interface (with sufficient expertise and a pair of wire cutters), which will make the machine impossible to detect and extremely difficult for an intruder to use (because it can’t reply). If you have the source for your operating system, you can always disable transmission there; however, in this case, it’s much harder to be certain you’ve been successful. In most cases, you’ll have to settle for extremely cautious configuration of the machine. Treat it like a bastion host that needs to do less and be more secure.

In particular, you should note that Microsoft’s Network Monitor registers a special NetBIOS name when it starts up. It is a blatant advertisement of the fact that you are monitoring the network. The only way to stop it from happening is to unbind NetBIOS from the network interface you’re monitoring, which will also make it impossible to use the Network Monitor Agent on it (not to mention most other Microsoft-native network applications!).

Other forms of network sniffing are more subtle, but also often detectable. Most obviously, network sniffers tend to do a lot of name service requests, in order to find hostnames for the IP addresses. Less obviously, a machine that is accepting all packets often slightly changes the way it handles incoming requests. A group called The L0pht (pronounced “loft”) released an anti-sniffer-sniffer to detect network sniffers, which has led to an arms race, with people developing less and less detectable sniffers, not to mention an anti-sniffer-sniffer-sniffer. These technologies are rapidly evolving; we advise that you deploy the most up-to-date, least detectable sniffer technology available and an anti-sniffer-sniffer on critical networks to help you find sniffers installed by attackers. (Information about getting The L0pht’s anti-sniffer-sniffer can be found in Appendix B.)

Clever attackers will assume that you are intercepting packets and will take steps to conceal traffic, whether or not they can actually find your monitoring system. There’s nothing you can do but stay alert.

An intrusion detection system is a piece of special-purpose software designed to figure out if somebody has broken into your site. Intrusion detection systems can range from relatively simple, passive programs that read log files and look for bad things, to extremely complex systems that use special-purpose monitoring devices spread out across a large network, inject fake traffic into the network to see if anybody uses the information, and/or employ sophisticated artificial intelligence techniques to detect subtle forms of abnormal behavior.

Intrusion detection is a big subject, and we can’t cover it fully here. More information can be found in other places (for instance, Stephen Northcutt’s Network Intrusion Detection: An Analyst’s Handbook, New Riders, 1999).

There are two basic techniques for intrusion detection; either systems can know what kind of behavior is bad and set off alarms when it happens, or they can know what kind of behavior is good and set off alarms when anything else happens. Relatively speaking, it’s easier to recognize bad behavior than good behavior. Unfortunately, it’s more effective to recognize good behavior.

Systems that recognize bad behavior use attack signatures, information about what particular attacks look like. For instance, this sort of system would recognize a port scan as an attack because it would know that a series of attempts to contact different ports on the same host was a sign of an attack.

Systems that recognize good behavior use usage profiles, information about what normally happens. For instance, this sort of system would recognize a port scan as an attack because it would know that normally, when somebody connects to a port, the next thing that happens is that they use that port for its normal purpose. In a port scan, the attacker will connect, get a response, and immediately disconnect and try another port. This behavior is outside of the normal pattern and therefore will be detected as an attack.

The difficulty with recognizing attack signatures is that the system can detect only attacks that it knows about. When new attacks are created, the system won’t know about them until a signature is created and added. In addition, it’s often possible to disguise signatures. For instance, the signatures for port scans used to look for multiple connections to different ports from the same source host, so attackers now use multiple collaborating source hosts.

Systems that rely on usage profiles have problems with what are called “false positives”, or cases where they think an attack is occurring but it isn’t. Usage of systems changes over time, and any profile that’s specific enough to catch any significant number of attacks will set off a large number of alarms. Good systems now have false positive rates in the range of about 1-3 percent; unfortunately, that’s 1-3 percent of the events they look at, which in the case of a network usually means 1-3 percent of packets. Since many sites have millions of incoming packets a day, this apparently small error rate can still result in thousands of false alarms a day, which is rarely acceptable.

Intruders also have ways of hiding attacks that will defeat almost all intrusion detection systems. For instance, a patient intruder can scan a network very slowly; most intrusion detection systems look at a few minutes', or maybe a few hours', worth of context at a time. An impatient intruder can bury an attack in a large amount of network traffic, and few systems will be able to keep up.

Similarly, some techniques can be used that defeat almost all attempts at hiding attacks. The most powerful and popular of these is the honeypot, the tempting bait with nothing but a trap behind it. For instance, if you put a machine on your perimeter network that you don’t use for any services, you know that any attempt to connect to it is an attack. It doesn’t matter whether or not it matches an attack signature, or whether or not it fits a normal usage pattern. It’s just obviously wrong.

How much an intrusion detection system can do for you depends mostly on how much time, money, and development effort you can invest in the system. Although intrusion detection is theoretically a very effective technology, actually making it work in practice is not an easy proposition, and it requires constant maintenance and attention. There is no point in having an intrusion detection system unless you have the personnel to keep it up to date and to deal with the alarms that it produces.

In a perfect world, you’d like to know absolutely everything that goes through your firewall — every packet dropped or accepted and every connection requested. In the real world, neither the firewall nor your brain can cope with that much information. To come up with a practical compromise, you’ll want to turn on the most verbose logging that doesn’t slow down your machines too much and doesn’t fill up your disks too fast; then, you’ll want to summarize the logs that are produced.

You can improve the disk space problem by keeping verbose logs offline, on some form of removable media (for instance, tapes, writable CDs, or writable DVDs). Tapes are cheap and hold a lot of data, but they have some drawbacks. They’re not particularly fast under the best circumstances, and log entries are generally too short to achieve maximum performance. They’re also annoying to read data from. If you’re interested in using them, write summary logs to disk and write everything to tape. If you find a situation where you need more data, you can go back to the tape for it. A tape drive can probably keep up with the packets on an average Internet connection, but it won’t keep up with an internal connection at full LAN speeds or even with a T-1 connection to the Internet that’s at close to its maximum performance. CD and DVD writers are even slower, but they’re much easier to read data from. If you have large amounts of disk space to use as temporary storage, they may be an effective solution.

No matter what you are using to write logs to, you should protect the logs. The data that’s in them may be useful to attackers, and it may be confidential for other reasons. For instance, if you log the contents of packets, you may well be logging encrypted sensitive information. Even if you don’t log packet contents, the information about what packets went where may be private; it’s one thing to log the 434 times that somebody tried to go to an embarrassing web site, and another to have it become public knowledge.

No matter how you’re storing logs, you want to log the following cases:

What are you watching for? You want to know what your usual pattern is (and what trends there are in it), and you want to be alerted to any exceptions to that pattern. To recognize when things are going wrong, you have to understand what happens when things are going right. It’s important to know what messages you get when everything is working. Most systems produce error messages that sound peculiar and threatening even when they’re working perfectly well. For example, in the sample syslog output in Example 26.1, messages 10, 14, and 17 all look vaguely threatening, but are in fact perfectly OK.^[1] (Although these examples are taken from a Unix syslog, exactly the same phenomena can be seen in the Windows NT Event Log; information about setting up logging can be found in Chapter 10, Chapter 11, and Chapter 12.)

If you see those messages for the first time when you’re trying to debug a problem, you’re likely to leap to the conclusion that the messages have something to do with your problem and get thoroughly sidetracked. Even if you never do figure out what the messages are and why they’re appearing, just knowing that certain messages appear even when things are working fine will save you time.

1:  May 29 00:00:58 localhost wn[27194]: noc.nca.or.bv - - [] "GET 
    /long/consulting.html HTTP/1.0" 200 1074  <Sent file: >  
2:  May 29 00:00:58 localhost wn[27194]: <User_Agent: Mozilla/1.0N 
    (X11; SunOS 4.1.3-KL sun4m)> <Referrer: http://www.longitude.example/>  
3:  May 29 00:02:38 localhost ftpd[26086]: 26086: 05/29/95 0:02:38 
    spoke.cst.cnes.vg(gupta@) retrieved  
    /pub/firewalls/digest/v04.n278.Z(15788 bytes)  
4:  May 29 00:15:57 localhost ftpd[27195]: 27195: 05/29/95 0:01:52 
    client42.sct.io connected, duration 845 seconds  
5:  May 29 00:18:04 localhost ftpd[26086]: 26086: 05/29/95 23:26:32 
    spoke.cst.cnes.vg connected, duration 3092 seconds  
6:  May 27 01:13:38 mv-gw.longitude.example user: host 
    naismith.longitude.com admin login failed 
7:  May 27 01:13:47 mv-gw.longitude.example last message repeated 2 times 
8:  May 27 01:15:17 mv-gw.longitude.example user: host 
    naismith.longitude.example admin login succeeded 
9:  May 27 01:19:18 mv-gw.longitude.example 16 permit: TCP from 
    192.168.20.35.2591 to 172.16.1.3.53 seq 324EE800, ack 0x0, win  
    4096, SYN 
10: May 29 02:20:09 naismith sendmail[27366]: CAA27366: SYSERR(root): 
    collect: I/O error on connection from atx.eb.cm, from=<<Mailer- 
    [email protected]>: Connection reset by peer during collect 
    with atx.eb.cm 
11: May 29 02:30:28 naismith named[79]: sysquery: server name mismatch 
    for [172.16.8.25]: (sun.nhs-relay.ac.cv != nhs-relay.ac.cv) (server  
    for cus.ox.ac.cv) 
12: May 29 02:31:00 naismith named[79]: sysquery: server name mismatch  
    for [172.16.8.25]: (nhs-relay.ac.cv != sun.nhs-relay.ac.cv) (server 
    for PANSY.CSV.WARWICK.AC.CV) 
13: May 29 02:47:04 naismith named[79]: sysquery: server name mismatch  
    for [172.16.8.25]: (nhs-relay.ac.cv != sun.nhs-relay.ac.cv) (server  
    for LUPUS.CNS.UMIST.AC.CV) 
14: May 29 07:50:59 mv-gw.longitude.example  8 deny: UDP from 
    192.168.69.250.33072 to 192.168.20.34.33467  
15: May 29 08:06:16 naismith popper: (v1.831beta) Servicing request  
    from "penta.longitude.example" at 192.168.20.36  
16: May 29 08:06:56 naismith popper: (v1.831beta) Ending request from 
    "penta.longitude.com" at 192.168.20.36  
17: May 29 10:04:02 localhost waisserver1[28430]: -2: Warning: couldn't open  
    wais-sources/firewalls-digest.syn - synonym translation 
    disabled 
18: May 29 16:26:46 mv-gw.longitude.example  8 deny: UDP from 
    192.168.186.11.20 to 192.168.20.34.1937

Most of your logging will probably be done via the Unix syslog facility or some other similar file-based log mechanism. You’ll need to develop log-scanning scripts to analyze each of these log files on a regular basis. Some firewall packages, such as TIS FWTK, come with scripts to analyze and summarize their own logs. You could use these scripts as templates for your own logging, or you could write your own scripts from scratch in awk, perl, or some other suitable language.

As you can see, the log file is verbose and not particularly readable (even with better linebreaks inserted). An unimportant error condition on a distant host (the server name mismatch on nhs-relay.ac.cv) is producing multiple error messages (11, 12, and 13, in this highly condensed version). The log file is also in chronological order which is not particularly the order of importance.

Example 26.2 shows a report based on a log file, with messages arranged in a more useful order and somewhat summarized.

May 27 06:42:07 localhost ftpd[10159]: securityalert: refused passwd 
    file to [email protected] from chen.dialup.zarf.net 
May 27 06:42:10 localhost ftpd[10159]: securityalert: refused passwd 
    file to [email protected] from chen.dialup.zarf.net 
----------------------------------------------------------------- 
May 26 12:33:39 localhost su: nxn to root on /dev/ttyp1 
May 27 01:23:17 naismith su: bart to root on /dev/ttyp3 
----------------------------------------------------------------- 
May 26 12:29:44 naismith kernel: uid 31 on /naismith_b: file system full 
May 26 12:31:33 naismith kernel: uid 31 on /naismith_b: file system full 
----------------------------------------------------------------- 
May 26 02:49:03 naismith named[79]: Malformed response from 
    [192.168.192.2].53 (ran out of data in answer)  
----------------------------------------------------------------- 
May 26 12:14:36 mv-gw.longitude.example 16 deny: UDP from 192.168.69.1.58899 
    to 192.168.20.35.33459  
May 26 12:15:15 mv-gw.longitude.example 16 deny: UDP from 192.168.69.1.58962 
    to 192.168.20.35.33459  
May 27 01:24:05 mv-gw.longitude.example 16 permit: TCP from 
    192.168.20.34.2637 to 192.168.54.72.23 seq BE793A01, ack 0x0, win 
    4096, SYN  
May 27 01:24:11 mv-gw.longitude.example 16 permit: TCP from 
    192.168.20.34.2637 to 192.168.54.72.23 seq BE793A01, ack 0x0, win 
    4096, SYN  
----------------------------------------------------------------- 
FTP:    Connections: 240 
        Files: 733 
        Bytes: 32,747,429 (31.23  M) 
        Seconds: 92,787 (25.77  hours)

In general, it’s safer to write scripts to filter out messages to be ignored (leaving unusual stuff), rather than writing scripts to identify the unusual stuff directly. The reason for this is that you seldom know all of the different messages your firewall might produce. It’s easier to ignore the benign messages than to recognize the dangerous ones.

Log messages fall into three categories:

Setting up the criteria is an iterative process; once a human has examined a mystery message, future examples of that message can probably be classified as either OK or dangerous without being examined again. You’ll change the rules as time goes on.

Log entries often must be considered in context. A message that’s mildly mysterious if it occurs once is cause for serious worry if it occurs every minute. For example, “login succeeded for user smith” is good, unless it’s preceded by three “login failed” messages for every user above “smith” in your password file; in that case, it’s very bad indeed. In Example 26.1, message 9 shows an unexceptional outbound TCP connection, logged just on general principles. It wouldn’t be at all worrying if it weren’t preceded by messages 6 through 8. In context, you know that someone made three failed tries at logging in as “admin”, finally succeeded, and then immediately started an outbound connection. This looks extremely suspicious. Message 7 doesn’t mean anything at all without context.

In a large system, getting context may require correlating log files from multiple hosts. This is one reason for keeping consistent time settings; it is also a reason why people use intrusion detection systems. If you have high volumes of traffic, a complex firewall, or a requirement for strict security, you will probably need an intrusion detection system to help you with the log analysis.

Once you go beyond the obvious (for example, it’s OK for users to log in; it’s not OK for the disk to be bad), how can you tell when you’re in trouble? Some rules of thumb:

You’re going to end up classifying suspicious events into several categories:

The boundaries between these categories are vague. Unless you’re dealing with messages from the first category (i.e., a known nonproblem), it’s going to come down to a judgment call most of the time. It’s impossible to provide an exhaustive list of the symptoms of any of these situations, but here are some generalizations that may help.

You should suspect that someone’s been probing your site if you see:

You should be more concerned if you see any of the following; an attack may be going on:

You should suspect a successful break-in if you see:

Inevitably, you’re going to detect apparent probes of your firewall — packets sent to services you don’t offer to the Internet, attempts to log in to nonexistent accounts, and so on. Probes are the Internet equivalent of someone walking down a line of doors and checking every door knob to see if it’s locked. Probers generally try one or two things, and if they don’t get an interesting response, they move on. If you’re inclined to do so, you can spend a lot of time chasing down such incidents, attempting to figure out where the probes are coming from and who is behind them. However, in most situations, it probably isn’t worth the effort. The novelty of chasing down probes of this kind fades quickly. If you’re getting persistent probes from some site, you might contact the management of that site to let it know what’s going on (in general, it has been broken into and needs to know), but that’s usually about as far as folks need to go in responding to these probes.

It’s unfortunate that on the Internet today, probes are so frequent that the laissez faire attitude we’ve described is often an appropriate one. In good neighborhoods, people don’t get away with trying door knobs. You have a right to be unhappy with people who behave this way and trying to get them to stop is perfectly reasonable. However, you do need to decide where you’re going to spend your energy. Save extreme responses for extreme situations. Treating probers with maximum harshness is just going to convince people that you are unreasonable.

Some people amuse themselves by setting up firewall machines to lead on people who try common probes. For example, they put a password file in the anonymous FTP area that appears to contain user account data. However, if the prober breaks the encrypted passwords, he or she sees a snide message. This is a harmless way to spend your spare time and provides a satisfactory feeling of revenge, but it doesn’t actually improve your security much. It simply annoys attackers, and doing so may cause them to take a personal interest in breaking into your site.

Some people and some firewalls prefer a more active approach to probes, engaging in counter-attacks. A fairly wide variety of things are sold as counter-attacks (firewall marketers find the concept extremely sexy). They range from attempts to find out further information about where the probes are coming from (giving you a start on tracking them down), to automatically configuring the firewall to reject all connections from the probing site, to actual counter-attacks. Regardless of their often remarkably aggressive marketing material, no commercial firewall does anything that can reasonably be described as a counter-attack, for obvious reasons involving liability. This is good because misidentification, loops, and bad feelings often result from even mild automated responses.

For instance, a forged probe purporting to be from a site that does information-gathering when it gets probes and aimed at another such site is almost guaranteed to suck the site administrators into a “Yeah, but you hit me first!” argument. Why would somebody forge such a packet? Because they did something and were annoyed at the response they got. A little forgery can bring a lot of community pressure to bear on somebody who has an overly vigorous probe response. A notable example occurred with somebody whose response to anonymous FTP attempts was to send mail threatening to sue; a widely broadcast email contained a URL that attempted anonymous FTP to the site, causing both resource problems and publicity problems.

Different sites have different opinions about what constitutes a probe, and what constitutes a full-fledged attack. Most people call something a probe as long as they know it’s not going to work, even if it is determined and drawn out. For example, somebody who determinedly tries every possible combination of lowercase alphabetic characters as your root password is not going to succeed and can probably be ignored as a probe until you get tired of reading the log messages. (That kind of attack won’t succeed, no matter how many combinations are tried.) However, if you have the time and the energy, it’s probably worth pursuing people who are making determined attempts, even when you know they’ll fail.

If your logs show that someone is making a determined attack against your system (see the rules of thumb we presented in Section 26.2.4, earlier in this chapter), you probably want to do a little more than sit back and watch. Chapter 27, describes in detail how you should respond to a real security incident.

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.

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: