18.3 Contain and Investigate the Problem

An attack should be contained as soon as possible, especially an attack that affects other networks. Depending on the severity and nature of the attack this may happen right away, or at the behest of the escalation contact.

Containing an attack should always involve removing a system from the network. It is important to do this quickly, before an attacker has a chance to cover his or her tracks. Taking a system off the network has business continuity implications as well, which is why it has to be authorized by an escalation contact. This is especially true in cases where either a large part of the network or the whole network has to be taken offline.

Worms are a prime example of a case where an entire network might have to be taken offline ”to have the worm removed, and prevent it from spreading to other networks. Of course, if the network is taken offline, it is much more difficult to access the software needed to correct the problem (software patches, virus updates, etc.). Any patches needed should be downloaded prior to taking the network offline, and it is probably a good idea to keep a dial-up account with a local ISP, just for such emergencies.

As mentioned previously, when containing a problem, remove the device from the network, but do not power down the system. In most cases, simply disabling the port on the switch is enough. However, if the problem occurs at one of the edge routers, or worse , the firewall, it will be necessary to disconnect the network from the Internet until the attack can be isolated and the system restored.

Powering down a system can actually hinder the troubleshooting process. Many attackers , especially when dealing with viruses and worms, will include software that attempts to format a hard drive or destroy the boot sector of a machine in an attempt to cover the tracks of the attacker. After the system has been powered down, a console connection should be made to the system and any damage should be assessed in that manner.

On Unix systems, while consoled into the server, it is a good idea to grab any information from the history file, as well as any locally stored logs. If it is a Windows-based system, saving information in the event viewer can be useful, as well as any local log files. Of course, any information stored on the affected machine, or machines, should be viewed as suspect until it can be compared with the data on the remote log server.