O'Reilly Book Excerpts: Incident Response
Tripwire
|
Related Reading 
Incident Response |
Tripwire
This is the second in a series of excerpts from chapter 7 of Incident Response, published in August 2001 by O'Reilly. This excerpt covers Tripwire, a tool used by sysadmins to detect an intrusion by a hacker on a system. You can use this tools to detect any changes made to your system by a hacker.
Initially developed as a research project at Purdue University, Tripwire is probably the most highly respected tool for detecting unauthorized alterations to operating system and critical application software. Tripwire is now available in the form of a freely available tool from Purdue as well as a commercially marketed and supported tool from Tripwire, Inc.
Tripwire creates a known-state database of cryptographic checksums of all of your operating system and application software, and then periodically compares that known-state against new tests. Two things are vital to note: the initial known-state must be a secure one, and the database and hash function must be unchanged every time the test is redone. If either of these is not the case, the results are likely to be tainted.
With those things in mind, however, Tripwire is a tremendously useful tool for monitoring any change from the baseline configuration of a system. Unlike most of the IDS tools on the market, Tripwire can detect any change due to a known attack or an unknown one. That's one of the things that can make it particularly useful during an incident response operation.
When faced with an incident situation in which recurring changes continue to happen on a system, Tripwire can alert you to clues and help in figuring out what is taking place. Additionally, the freely available version of Tripwire has started to make its way into many of the Linux distributions, so it should be even easier to establish the initial known trusted state of each system.
While reviewing a network some time back, we found a Tripwire configuration that worked particularly well. In the configuration shown in Figure 7-16, none of the machines being monitored with Tripwire were in fact running it. Instead, they all had a backend private subnet on which one system used NFS to mount the filesystems on all of the machines being monitored, and it ran Tripwire on these network-mounted filesystems. Anomalies were then reported immediately to the incident response team.
|
The beauty of this configuration is that an attacker could not see that Tripwire was being used. The actual machine running it only mounted the filesystems, but ran no other network services. Thus, the attacker would have a difficult time connecting to the system running Tripwire. This configuration can be equally effective before and during an incident response operation.
Previously in this series:
Ethereal and NMap -- This is the first in a series of excerpts from Chapter 7 of Incident Response, covering the nmap port scanner and the Ethereal network scanner.
Return to ONLamp.com.
