home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  


Practical UNIX & Internet Security

Practical UNIX & Internet SecuritySearch this book
Previous: 24.5 An Example Chapter 24
Discovering a Break-in
Next: 24.7 Damage Control
 

24.6 Resuming Operation

The next step in handling a break-in is to restore the system to a working state. How quickly you must be back in operation, and what you intend to do about the break-in in the long term, will determine when and how you do this step.

In general you have a few options about how to proceed from this point:

  • Investigate until you have determined how the break-in happened, and when. Close up the holes and restore the system to the state it was prior to the break-in.

  • Simply patch and repair whatever you think may have been related to the break-in. Then restore the system to operation with heightened monitoring.

  • Do a quick scan and cleanup, and put the system back into operation.

  • Call in law enforcement before you do anything else so they can start an investigation.

  • Do nothing whatsoever.

You want to get whatever assurance you can that you have restored anything damaged on the system, and fixed whatever it was that allowed the intruder in. Then, if you have been keeping good backups, you can restore the system to a working state.

The difficulty with determining what failed and allowed an intruder in is complicated by the fact that there is usually little data in the logs to show what happened, and there are few things you can execute to reverse-engineer the break-in. Most break-ins seem to result from either a compromised user password (suspect this especially if you find that the intruders have installed a sniffer on your system), or a bug. If it is a bug, you may have difficulty determining what it is, especially if it is a new one that has not been widely exploited. If you suspect that it is a bug in some system software, you can try contacting your vendor to see if you can get some assistance there. In some cases it helps if you have a maintenance contract or are a major customer.

Another avenue you can explore is to contact the FIRST team appropriate for your site. Teams in FIRST often have some insight into current break-ins, largely because they see so many reports of them. Contacting a representative from one of the teams may result in some good advice for things to check before you put your system back into operation. However, many teams have rules of operation that prevent them from giving too much explicit information about active vulnerabilities until the appropriate vendors have announced a fix. Thus, you may not be able to get complete information from this source.

As a possible last resort, you might consult recent postings to the Usenet security groups, and to some of the current WWW sites and mailing lists. Often, current vulnerabilities are discussed in some detail in these locations. This is a mixed blessing, because not only does this provide you with some valuable information to protect (or restore) your site, but it also often provides details to hacker wannabes who are looking for ways to break into systems. It is also the case that we have seen incorrect and even dangerous advice and analysis given in some of these forums. Therefore, be very wary of what you read, and consider these sources as a last resort.