Investigating The Incident - Red Hat ENTERPRISE LINUX 3 - SECURITY GUIDE Manual

Chapter 10. Incident Response 91
10.3. Implementing the Incident Response Plan
Once a plan of action is created, it must be agreed upon and actively implemented. Any aspect of the
plan that is questioned during active implementation can result in poor response time and downtime
in the event of a breach. This is where practice exercises become invaluable. Unless something is
brought to attention before the plan is actively set in production, the implementation should be agreed
upon by all directly connected parties and executed with confidence.
If a breach is detected and the CERT team is present for quick reaction, potential responses can vary.
The team can decide to disable the network connections, disconnect the affected systems, patch the
exploit, and then reconnect quickly without further, potential complications. The team can also watch
the perpetrators and track their actions. The team could even redirect the perpetrator to a honeypot —
a system or segment of a network containing intentionally false data — used to track incursion safely
and without disruption to production resources.
Responding to an incident should also be accompanied by information gathering whenever possi-
ble. Running processes, network connections, files, directories, and more should be actively audited
in real-time. Having a snapshot of production resources for comparison can be helpful in tracking
rogue services or processes. CERT members and in-house experts are great resources in tracking such
anomalies in a system. System administrators know what processes should and should not appear
when running or . Network administrators are aware of what normal network traffic should
top ps
look like when running or even . These team members should know their systems
snort tcpdump
and should be able to spot an anomaly more quickly than someone unfamiliar with the infrastructure.

10.4. Investigating the Incident

Investigating a computer breach is like investigating a crime scene. Detectives collect evidence, note
any strange clues, and take inventory on loss and damage. An analysis of a computer compromise can
either be done as the attack is happening or post-mortem (after the attack).
Although it is unwise to trust any system log files on an exploited system, there are other forensic
utilities to aid in analysis. The purpose and features of these tools vary, but they commonly create
bit-image copies of media, correlate events and processes, show low level file system information,
and recover deleted files whenever possible.
It is also a good idea to record of all of the investigatory actions executed on a compromised system
by using the command, as in the following example:
script
script -q file-name
Replace with file name for the log. Always save the log file on media
file-name
script
other than the hard drive of the compromised system — a floppy disk works particularly well for this
purpose.
By recording all your actions, an audit trail is created that may prove valuable if the attacker is ever
caught.
10.4.1. Collecting an Evidential Image
Creating a bit-image copy of media is a feasible first step. If performing data forensic work, it is a
requirement. It is recommended to make two copies: one for analysis and investigation, and a second
to be stored along with the original for evidence in any legal proceedings.
You can use the command that is part of the package in Red Hat Enterprise Linux to
dd coreutils
create a monolithic image of an exploited system as evidence in an investigation or for comparison
with trusted images. Suppose there is a single hard drive from a system you want to image. Attach
that drive as a slave to the system and then use to create the image file, such as the following:
dd
dd if=/dev/hdd bs=1k conv=noerror,sync of=/home/evidence/image1