Protecting the Machine and Backups (Building Internet Firewalls, 2nd Edition)

10.12. Protecting the Machine and Backups

Once the bastion host has been fully configured and is in operation, protect the physical machine and make sure that its backups are protected from theft or other compromise.

10.12.1. Watch Reboots Carefully

How will you know if someone has breached security? Sometimes, it's painfully obvious. But sometimes, you'll have to draw conclusions from the behavior of the system. Unexplained reboots or downtime on the system may be a clue. Many attacks (e.g., modifying a kernel) can't succeed unless the system is rebooted.

On the bastion host, crashes and reboots should be rare occurrences. Once the bastion host has been fully configured and is in production, it should be a very stable system, often running for weeks or months at a stretch without a crash or a reboot. If a crash or a reboot does occur, investigate it immediately to determine whether it was caused by some legitimate problem or might have been the result of some kind of attack.

You might want to consider configuring the bastion host so that it doesn't bring itself up automatically after an attempted reboot. That way, if someone does manage to crash or force a reboot of the machine, you'll know about it: the machine will sit there waiting for you to reboot it. The machine won't be able to come back up until you decide it should do so. Many machines treat crashes and explicit reboots differently, and while most of them will let you disable an automatic reboot on a crash, it may be harder to disable an automatic reboot after a clean shutdown that requests a reboot. Even if your machine does not appear to allow you to disable autobooting, you can usually cause autoboots to fail under Unix by configuring the machine to autoboot from a nonexistent disk. (Be sure to leave instructions on how to boot the machine by hand with the machine.) Under Windows NT, you can simply edit boot.ini to set the timeout to -1, and it will wait forever for a human being to specify what operating system to boot. This has the advantage of being self-explanatory to an operator sitting in front of the console.

10.12.2. Do Secure Backups

Backups on a bastion host are tricky because of trust issues. Who can you trust?

You definitely don't want internal machines to trust the bastion host enough for it to dump to their tape drives. If the bastion host has somehow been compromised, this could be disastrous. You also don't want the bastion host to trust the internal machines; this could lead to subversion of the bastion host by (well-intentioned) internal users, or to attack from some host pretending to be an internal system.

Common remote backup mechanisms (for example, those used by the BSD dump and rdump programs) will probably be blocked by packet filtering between the bastion host and the internal systems anyway. Therefore, you will normally want to do backups to a tape device attached directly to the bastion host. Under no circumstances should you rely on backing up the bastion host to disks that remain attached to the bastion host. You must do backups that are removed from the bastion host so they cannot be accessed by an attacker who compromises it.

Fortunately, because the bastion host is an infrequently changing machine, you won't have to do frequent backups. Once the bastion host is fully configured and in production, it should be very stable. A weekly or even monthly manual backup will probably be sufficient.

Backups of the bastion host aren't done just to guard against normal system catastrophes like disk crashes. They're also a tool that you can use later to investigate a break-in or some other security incident. They give you a way to compare what's currently on the bastion host's disk with what was there before the incident.

If you're only doing weekly or monthly backups, how you handle logging becomes an issue. If the bastion host is not being backed up daily, you must do your logging to some system other than the bastion host itself. If an incident does occur, the logs are going to be critical in reconstructing what happened. If it turns out that your only copy of the logs was on the (compromised) bastion host, and backups of the logs haven't been done for three weeks, you're going to be severely hampered in your investigative efforts.

As with all backups on all systems, you need to guard your bastion host backups as carefully as you guard the machine itself. The bastion host backups contain all the configuration information for the bastion host. An attacker who gets access to these backups would be able to analyze the security of your bastion host without ever touching it. The information these backups provide might possibly include a way to break in without setting off any of the alarms on the bastion host.

10.12.3. Other Objects to Secure

In addition to securing the backups, you will need to physically secure anything else that contains important data about the machine. This includes:

The log files
Any alternate boot disks you use to do maintenance
The Emergency Repair Disks for Windows NT bastion hosts (including account data!)
The documentation for the details of the bastion host configuration

Although secrecy is not sufficient to give you security, it's an important part of maintaining security. You should treat the configuration details of your bastion hosts as proprietary information, available only to people you trust. Anybody who has this information can compromise your firewall.