A

SEMINAR REPORT
ON
“TRIPWIRE”
Submitted in partial fulfillment for the award of the degree
Bachelor of Technology
In
Information Technology Engineering

Session: 2010-2011
Department of Information Technology
Alwar Institute of Engineering & Technology

Affiliated to
Rajasthan Technical University, Kota

SUBMITTED TO: - SUBMITTED BY: -

Prof. L.K.Sharma Sanjeev kumar yadav
Head of Dept: Branch :- I.T
CS & IT Roll No:- 07EAEIT047

1
 ACKNOWLEDGEMENT

It gives us a great sense of pleasure to present the seminar of the B. Tech during B.
Tech. Final Year. His sincerity, thoroughness and perseverance have been a
constant source of inspiration for us. It is only his cognizant efforts that our endeavors
have seen light of the day.
We also do not like to miss the opportunity to acknowledge the contribution of all
faculty members of the department for their kind assistance and cooperation during
the development of our seminar report. Last but not the least, we acknowledge our
friends for their contribution in the completion of the seminar report.

Name : Sanjeev kumar yadav

Roll No. : 07EAEIT047

2
 CERTIFICATE

This is to certify that Seminar Report entitled “Tripwire” which is submitted by Sanjeev
kumar yadav in partial fulfillment of the requirement for the award of degree B. Tech.
in Department of Information Technology of Rajasthan Technical University is a
record of the candidate own work carried out by him under my/our supervision. The
matter embodied in this thesis is original and has not been submitted for the award of
any other degree.

Mr. L.K.Sharma Date: 4-March-2011

Head of C.S.& I.T
A.I.E.T (Alwar)

3
 ABSTRACT

Tripwire is an intrusion detection system. It is a software tool that checks to see

what has changed on your system. The program monitors the key attributes of files
that should not change, including the size, binary signature, expected change of
size, and other related important data’s. Tripwire is an open source program created
to monitor changes in a key subset of files identified by the user and report on any
changes in any of those files. When changes are detected the system Administrator
can determine whether those changes occurred due to normal, permitted activity, or
whether they were caused by a break-in. If the former, the administrator can update
the system baseline to the new files. If the latter, then repair and recovery activity
begins. Tripwire’s principle is simple enough. The system administrator identifies
key files and causes Tripwire to record checksum for those files. Administrator also
puts a cron job to scan those files at intervals (daily or more frequently), comparing
to the original checksum. Any changes, addition, or deletion are reported, so the
proper action can be taken.

4
 CONTENTS

1. INTRODUCTION……………………………………………………………………………….6

2. TRIPWIRE FOR SERVERS ……………………………………………………………..13

3. TRIPWIRE MANAGER ……………………………………………………………………16

4. TRIPWIRE FOR NETWORK DEVICES ……………………………………………18

5. OPERATION OF TRIPWIRE…….………………………………………………………21

6. EXPERIENCES………………………………………………………………………………..26

7. ADVANTAGES…………………………………………………………………………………31

8. CONCLUSION…………………………………………………………………………….....32

9. REFERENCES………………………………………………………………………………….33

5
 INTRODUCTION

Tripwire is a reliable intrusion detection system. It is a software tool that checks to

see what has changed in your system. It mainly monitors the key attribute of your
files, by key attribute we mean the binary signature, size and other related data.
Security and operational stability must go hand in hand, if the user does not have
control over the various operations taking place then naturally the security of the
system is also compromised. Tripwire has a powerful feature which pinpoints the
changes that has taken place, notifies the administrator of these changes,
determines the nature of the changes and provide you with information you need for
deciding how to manage the change.

Tripwire Integrity management solutions monitor changes to vital

system and configuration files. Any changes that occur are compared to a snapshot
of the established good baseline. The software detects the changes, notifies the
staff and enables rapid recovery and remedy for changes. All Tripwire installation
can be centrally managed. Tripwire software’s cross platform functionality enables
you to manage thousands of devices across your infrastructure.

Security not only means protecting your system against various

attacks but also means taking quick and decisive actions when your system is
attacked. First of all we must find out whether our system is attacked or not, earlier
system logs were certainly handy. You can see evidences of password guessing
and other suspicious activities. Logs are ideal for tracing steps of the cracker as he
tries to penetrate into the system. But who has the time and the patience to examine
the logs on a daily basis?

Penetration usually involves a change of some kind, like a new

port has been opened or a new service. The most common change you can see is

6
that a file has changed. If you can identify the key subsets of these files and monitor
them on a daily basis, then we will be able to detect whether any intrusion took
place. Tripwire is an open source program created to monitor the changes in a key
subset of files identified by the user and report on any changes in any of those files.
When changes made are detected, the system administrator is informed. Tripwire ‘s
principle is very simple, the system administrator identifies key files and causes
tripwire to record checksum for those files. He also puts in place a cron job, whose
job is to scan those files at regular intervals (daily or more frequently), comparing to
the original checksum. Any changes, addition or deletion, are reported to the
administrator. The administrator will be able to determine whether the changes were
permitted or unauthorized changes. If it was the earlier case the n the database will
be updated so that in future the same violation wouldn’t be repeated. In the latter
case then proper recovery action would be taken immediately.

Motivation
A cautionary tale
Ellen runs a network of 50 networked Unix computers representing
nearly a dozen vendors – from PCs running Xenix to a Cray running Unicos. This
morning, when she logged in to her workstation, Ellen was a bit surprised when the
“lastlog” message indicated that “root” had logged into the system at 3 am. Ellen
thought she was the only one with the root password. Needless to say, this was not
something Ellen was happy to see. A bit more investigation revealed that someone –
certainly not Ellen – had logged on as "root," not only on her machine but also on
several other machines in her company. Unfortunately, the intruder deleted all the
accounting and audit files just before logging out of each machine. Ellen suspects that
the intruder (or intruders) ran the compiler and editor on several of the machines.
Being concerned about security, Ellen is worried that the intruder may have thus
changed one or more system files, thus enabling future unauthorized access as well
as compromising sensitive information. How can she tell which files have been altered

7
without restoring each system from backups? Poor Ellen is faced with one of the most
tedious and frustrating jobs a system administrator can have – determining which, if
any, files and programs have been altered without authorization. File modifications
may occur in a number of ways: an intruder, an authorized user violating local policy
or controls, or even the rare piece of malicious code altering system executables as
others are run. It might even be the case that some system hardware or software is
silently corrupting vital system data.

In each of these situations, the problem is not so much knowing that

things might have been changed; rather, the problem is verifying exactly which files –
out of tens of thousands of files in dozens of gigabytes of disk on dozens of different
architectures – might have been changed. Not only is it necessary to examine every
one of these files, but it is also necessary to examine directory information as well.
Ellen will need to check for deleted or added files, too. With so many different systems
and files, how is Ellen going to manage the situation? This scenario could prove
tedious and labor intensive for even the most well-prepared system administrator (yes,
even Ellen). Consider the problems with simple check listing schemes:

The resulting challenges

Some established techniques for monitoring file systems for potentially dangerous
changes include maintaining checklists, comparison copies, checksum records, or a
long history of backup tapes for this kind of contingency [4, 2]. However, these
methods are costly to maintain, prone to error, and susceptible to easy spoofing by a
malicious intruder. For instance, the UNIX utility find(1) is often used to generate a
checklist of system files, perhaps in conjunction with ls(1). This list is then saved and
compared using diff(1) to determine which files have been added or deleted, and to
find which files have conflicting modification times, ownership, or sizes. An added level
of security could be added by augmenting these lists with information from sum(8) or
cksum(8), as is done by the crc check program included with COPS [3]. However,

8
numerous shortcomings in these simple check listing schemes prevent them from
being completely trustworthy and useful. First, the list of files and associated
checksums may be tedious to maintain because of its size and lack of locality (files
are located all over the disk). Second, using timestamps, checksums, and file sizes
does not necessarily ensure the integrity of each file (e.g., once intruders gain root
privileges, they may alter timestamps and even the checklists at will). Furthermore,
changes to a file may be made without changing its length or checksum generated by
the sum(8) program. And this entire approach presumes that ls(1), sum(8), and the
other programs have not been compromised! In the case of a serious attack, a
conscientious administrator must not assume that these files have remained
unchanged without strong proof. But what proof can be offered that is sufficient for this
situation?

The resulting wishlist

A successful integrity checking scheme requires a high level of automation – both in
generating the output list and in generating the input list of files. If the system is
difficult to use, it may not be used often enough – or worse, used improperly. The
automation scheme should include a simple way to describe portions of the filesystem
to be traversed. Additionally, in cases where files are likely to be added, changed, or
deleted, it must be easy to update the checklist database. For instance, files such
as /etc/motd may change weekly, or even daily. It should certainly not be necessary to
regenerate the entire database every time this single file changes to maintain
database accuracy. Ideally, our integrity checking program could be run regularly from
cron(8) to enable detection of file changes in a timely manner. It should also be
possible to run the program manually to check a smaller set of files for changes. As
the administrator is likely to compare the differences between the “base” checklist and
the current file list frequently, it is important that the program be easy to invoke and
use. A useful integrity checker must generate output that is easy to scan. A checker
generating three hundred lines of output for the system administrator to analyze daily

9
would be self-defeating – this is probably far too much to ask of even Ellen, our
amazingly dedicated system administrator! Thus, the program must allow the
specification of filesystem “exceptions” that can change without being reported, and
hence reduce “noise.” For example, changes in system log file sizes are expected, but
a change in inode number, ownership, or file modes is cause for alarm. However, a
change in any value stored in the inodes (except for the access timestamp) for system
binaries in /bin should be reported. Properly specified, the integrity checker should
operate unobtrusively, notifying Ellen when a file changes outside the specified
bounds. Finally, assuming that Ellen wants to run the integrity checker on every
machine in her network, the integrity checker should allow the reuse and sharing of
configuration files wherever possible. For example, if Ellen has twenty identical
workstations, they should be able to share a common configuration file, even allowing
machine-specific oddities (i.e., some software package installed on only one
machine). The configuration should thus support reuse to reduces the opportunity for
operator error.

1
0
 BASIC PURPOSE OF TRIPWIRE

Almost the same principle is used in computers. If any

change is met upon while comparing the old values to the new ones, or if any data is
being manipulated on the spot, the logs are checked for intrusion and then detected,
after which all the changes can be undone.

Tripwire is a free and open-source1 software tool. It

functions as a host-based intrusion detection system. It does not concern itself directly
with detecting intrusion attempts in real time at the periphery of a computing system
(as in network intrusion detection systems), but rather looks for and reports on the
resultant changes of state in the computing system under observation
Intruders usually leave traces of their activities (changes in the system state). Tripwire
looks for these by monitoring key attributes of files that should not change—including
binary signatures, size, expected changes in size, etc.—and reporting its findings.

While useful for detecting intrusions after the event, it

can also serve many other purposes, such as integrity assurance, change
management, policy compliance, and more.

A Host-based Intrusion Detection System (HIDS),

as a special category of an Intrusion-Detection System, focuses its monitoring and
analysis on the internals of a computing system rather than on its external interfaces
(as a Network Intrusion Detection System (NIDS) would do)

1
1
TRIPWIRE RELATED TOPICS

Open source describes practices in production and

development that promote access to the end product's source materials—typically,
their source code. Some consider it as a philosophy, and others consider it as a
pragmatic methodology. Before open source became widely adopted, developers and
producers used a variety of phrases to describe the concept; the term open source
gained popularity with the rise of the Internet and its enabling of diverse production
models, communication paths, and interactive communities. Subsequently, open
source software became the most prominent face of open source practices.
The open source model can allow for the concurrent use of different agendas and
approaches in production, in contrast with more centralized models of development
such as those typically used in commercial software companies. "Open source" as
applied to culture defines a culture in which fixations are made generally available.
Participants in such a culture are able to modify those products and redistribute them
back into the community.

Pragmatism , as a school of philosophy, is a collection of

many different ways of thinking. Given the diversity among thinkers and the variety
among schools of thought that have adopted this term over the years, the term
pragmatism has become all but meaningless in the absence of further qualification.
Most of the thinkers who describe themselves as pragmatists point to some
connection with practical consequences or real effects as vital components of both
meaning and truth. The precise character of these links to pragmata is, however, as
diverse as the thinkers who do the pointing.

1
2
 TRIPWIRE FOR SERVERS

Tripwire for Servers is a software that is exclusively used by

servers. This software can be installed on any server that needs to be monitored for
any changes. Typical servers include mail servers, web servers, firewalls,
transaction server, development server etc, Any server where it is imperative to
identity if and when a file system change has occurred should b monitored with
tripwire for servers. For the tripwire for servers software to work two important things
should be present – the policy file and the database.

The tripwire for Servers software conducts subsequent file checks,

automatically comparing the state of the system with the baseline database. Any
inconsistencies are reported to the Tripwire Manager and to the host system log file.
Reports can also be emailed to an administrator. If a violation is an authorized
change, a user can update the database so changes no longer show up as
violations.

FLEXIBLE POLICY LANGUAGE

The power behind Tripwire technology lies in its highly

configurable policy language. The policy file is how a user directs Tripwire for
Servers to monitor specific files or directories. The flexible policy tool can be
customized to fit the needs of each and every server. With the release of version
4.0, policy file creation has become even easier. From Tripwire Manager 4.0, a
graphical policy editor allows users to select the files and directories, along with the
scanning options that need to be monitored in each integrity check. Included in the
products are default policy files for each supported operating system to make it easy
for the user to set up which files should be monitored. In the latest version, wildcard
application is also supported which enables users to add objects to the policy file by

1
3
specifying the file type. In 4.0, objects listed in the policy file but not present on the
user’s machine will no longer be categorized as violations. By only showing
violations caused by added, deleted or changed files, report noise is greatly
reduced. Tripwire policy languages also allow you to group objects around easy-to-
understand rule names and then prioritize them.

The snapshot and the policy file are cryptographically signed with
168-bit Triple DES encryption algorithm that detects any unauthorized tampering.
The default policy file also monitors the tripwire binary files, in short, it uses tripwire
itself to monitor the tripwire.

In the latest version 4.0 in addition to reporting the administrator

which file has changed, when the change occurred and where the change took
place it also to some extend determines who made these changes. Tripwire for
Servers track the identity of who made the change by correlating the information
from the operating system’s event and audit log with the integrity information that is
detected by Tripwire for Servers. It uses this information to provide the identity of
who made a certain change. Since we rely on the operating system to gather this
information, the product only captures the “who” information from the operating
system that track this. Linux and FreeBSD do not track this information. This feature
is called Event Log Correlation.

Each Tripwire for Servers report details when the database was
last updated, providing a quick benchmark of if or when detailing if the data files
have been replaced. In order to replace these files, an attacker requires root or
administrator level privileges and must know where Tripwire for Servers has been
installed. On a properly secured system, gaining this level of access takes time and
leaves physical evidence behind for Tripwire for Servers to detect prior to the

1
4
system being compromised. Methods for reducing the risk of an intruder being able
to replace a Tripwire for Servers installation include:

• Hiding the application by renaming configuration, data, and binary

files and installing to a hidden location.
• Installing Tripwire for Servers to a read-only partition such as a CD-
ROM.

1
5
 TRIPWIRE MANAGER

Tripwire Manger is a fully functional, cross platform management

console that allows system and security professionals to easily manage all
installations of Tripwire for Servers software across an enterprise network. Tripwire
Manager eliminates the need to manually monitor multiple discrete network platforms
and point solutions. Instead, IT professionals have a comprehensive view of data
integrity status from a single centralized console. Tripwire Manager also enables you
to view and analyze reports from installations of Tripwire for Servers. With Tripwire
Manager you can retrieve an integrity system, which is made up of the configuration,
database, policy, local and site key, from a single “golden” machine which can then
be distributed to as many servers that need to be compared against this snapshot. In
version 4.0 of the Tripwire Manager you can create and modify policy files by using
graphical policy editor. This GUI will scan the remote file system of a Tripwire for
Servers installation and provide you with an easy mechanism for editing or creating a
policy file without having to know the policy file syntax. Tripwire Manager can
manage the functions of Tripwire for Servers on up to 2500 machines.

Adding or removing recognition of Tripwire for Servers is easy to

do from within the Tripwire Manager console. All you need to know is host name, IP
address and a port number. The Tripwire for Servers database can be updated by
using the database update mode within Tripwire Manager. All communication
between Tripwire Manager and installation of Tripwire for Servers takes place using
Secured Socket Layer (SSL) technology with 168-bit Triple DES encryption. To
protect against unauthorized modification, important files on each Tripwire for
Servers installation are stored in a binary-encoded and signed form. Database,
policy, configuration, and report files generated by the integrity assessment are
protected by using El Gamal asymmetric cryptography with a 1024-bit signature.

1
6
There are mainly two types of Tripwire Manager

• Active Tripwire Manager

• Passive Tripwire Manager

A user can have more than one Tripwire Manager managing the
same set of Tripwire for Servers machines. However, only one can be in active mode
and have complete management control of Tripwire for Servers machines. This
active Tripwire Manager gives a user the ability to update the database, schedule
integrity checks, update and distribute policy and configuration files and view integrity
reports. The other Tripwire Manager are in a passive mode. The passive mode only
allows these Tripwire Manager to view the status of the machines and integrity
reports. Once the active Tripwire Manager shuts down, the next time the passive
Tripwire Manager pings the Tripwire for Servers machine it connects as an active
Tripwire Manager. If more than two passive Tripwire Managers, the one that
connects first to the Tripwire for Servers machine after the active Manager has hut
down becomes the active Manager.

1
7
 TRIPWIRE FOR NETWORK DEVICES

Router, switch, and firewall configurations are critical to overall

network operation. Unwanted changes to configuration files can result in downtime
and security issues and waste hours of staff time searching for the cause. Tripwire
for Network Devices monitors the integrity of routers, switches and firewalls-network
devices that communicate network traffic within and between networks. It helps
network administrator answer the question, “Has the state of my network devices
changed from a known, trusted state? If so, how?”. Problem s with one network
device can seriously disable an organization’s entire network. Network downtime can
result in lost revenue and lost customer confidence. Manual processes to secure
your network devices are available and important. Tripwire for Network Devices
augments and helps guarantee that the security of your network devices remains in
tact. With Tripwire for Network Devices, downtime is minimized. Network
administrators can use Tripwire for Network Devices to quickly investigate and
isolate changes and restore changed configuration files within minutes of an alert.
Tripwire for Network Device includes six primary functions :

• Automatic notification of changes to your routers, switches and

firewalls
• Automatic restoration of critical network devices
• Audit trail from log files and change reports – ideal for
internal/external network audits.
• Baseline archiving and configuration file “Hot Back-up” solution
• Heterogeneous support for today’s most commonly used network
devices
• Sets a framework for autonomic recovery

1
8
 Tripwire for Network Devices does not provide real time
monitoring. It checks your network devices for change according to schedule you set.
Device passwords stored by the software are protected by robust 1024-bit Blowfish
cryptography. The software has four user authorization levels:

• “Monitors” are allowed only to monitor the application. They cannot

make changes to Tripwire for Network Devices or to the devices that the software
monitors.
• “Users” can make changes to Tripwire for Network Devices, such as
add routers, switches. Groups, tasks, etc., but they cannot make changes to the
devices it monitors.
• “Power users” can make changes to the software and to the devices it
monitors.
• “Administrator” can perform all actions, plus delete violations and log
messages as well as add, delete, or modify user accounts.

Tripwire for Network Devices maintains a log of all significant

actions, including adding and deleting nodes, rules, tasks, and user accounts. All log
entries include a time and date, and identify the user who initiated the process. The
log entries cannot be modified by anyone other than the administrator and can be
copied and pasted into a text file so you can create a library of log activities that are
ideal for network audits.

Device password are stored by the software are protected by

robust 1024-bit Blowfish cryptography. Tripwire for Network Devices has been tested
and can monitor thousands of network devices. Tripwire for Network Devices
software has been tested up to 6,000 network devices running integrity checks every

1
9
10 minutes. With correct configuration, the software can monitor more than 6,000
devices at one time.

2
0
 OPERATION OF TRIPWIRE

At installation time - and whenever any of the monitored objects

change legitimately - a HIDS must initialize its checksum-database by scanning the
relevant objects. Persons in charge of computer security need to control this process
tightly in order to prevent intruders making un-authorized changes to the database(s).
Such initialization thus generally takes a long time and involves cryptographically
locking each monitored object and the checksum databases or worse. Because of
this, manufacturers of HIDS usually construct the object-database in such a way that
makes frequent updates to the checksum database unnecessary.

Computer systems generally have many dynamic (frequently

changing) objects which intruders want to modify - and which a HIDS thus should
monitor - but their dynamic nature makes them unsuitable for the checksum
technique. To overcome this problem, HIDS employ various other detection
techniques: monitoring changing file-attributes, log-files that decreased in size since
last checked, and a raft of other means to detect unusual events.

Once a system administrator has constructed a suitable object-

database - ideally with help and advice from the HIDS installation tools - and initialized
the checksum-database, the HIDS has all it requires to scan the monitored objects
regularly and to report on anything that may appear to have gone wrong. Reports can
take the form of logs, e-mails or similar.

2
1
PROTECTING THE HIDS

A HIDS will usually go to great lengths to prevent the object-database, checksum-

database and its reports from any form of tampering. After all, if intruders succeed in
modifying any of the objects the HIDS monitors, nothing can stop such intruders from
modifying the HIDS itself - unless security administrators take appropriate
precautions. Many worms and viruses will try to disable anti-virus tools, for example.
Sadly, lot of them succeeds in doing so. Apart from crypto-techniques, HIDS might
allow administrators to store the databases on a CD-ROM or on other read-only
memory devices (another factor militating for infrequent updates...) or storing them in
some off-system memory. Similarly, a HIDS will often send its logs off-system
immediately - in some instances via one-way communications channels, such as a
serial port which only has "Transmit" connected for example.
One could argue that the trusted platform module comprises a type of HIDS.
Although its scope differs in many ways from that of a HIDS, fundamentally it
provides a means to identify whether anything/anyone has tampered with a portion of
a computer. Architecturally this provides the ultimate (at least at this point in time)
host-based intrusion detection, as depends on hardware external to the CPU itself,
thus making it that much harder for an intruder to corrupt its object and checksum
databases.

2
2
FLOW CHART SHOWING THE WORKING OF TRIPWIRE

2
3
1. Install Tripwire and customize the policy file
Install the Tripwire software into the system and then specify the
files to be checked by writing the policy files. Using the version 4.0 writing the policy
file is made very easy.

2. Initialize the Tripwire database

The database is initialized with the important key attribute in the
file to be checked. Build database of critical system files to monitor based on the
contents of the new, signed Tripwire policy file.

3. Run the integrity check

Compare the newly created Tripwire database with the actual system files,
looking for missing or altered files, according to the integrity check timing specified
by in the policy file for different files that are to be monitored.

4. Examine the Tripwire report file

View the Tripwire report file to note any integrity violations.

5. If unauthorized integrity violations occur, take appropriate security

measures
If monitored files have been altered inappropriately, the system
administrator have to take immediate action, you can either replace the original files
from backup copies reinstall the program, or completely reinstall the operating
system.

2
4
6. If the file alterations were valid, verify and update the Tripwire database
file.
If the changes made to monitor files are intentional, edit Tripwire’s
database file to ignore those changes in subsequent report.

7. If the policy file fails verification, update the Tripwire policy file
To change the list of files Tripwire monitors or how it treats
integrity violations, update the supplied policy file, regenerate a signed copy, and
update the Tripwire database.

2
5
 Experiences
Since the initial release, four versions have been released to incorporate bug fixes,
support additional platforms, and add new features. The authors estimate Tripwire is
being actively used at several thousand sites around the world. Retrievals of the
Tripwire distribution from our FTP server initially exceeded 300 per week. Currently,
seven months after the last official patch release, we see an average of 25 fetches per
week. This does not include the copies being obtained from the many FTP mirror sites
around the net. We have received considerable feedback on Tripwire design and
implementation. We believe that version 1.1 of Tripwire has succeeded in meeting
most of the goals of system administrators needing an integrity checking tool. Most of
the feedback that we received falls into one of the following categories: theory of
integrity checking workability, features needed, operational use of Tripwire.

Securing the database

Because Tripwire reports are only as reliable as its inputs, the design document
stresses the need to ensure the integrity of the baseline database. Namely, we
suggest that the baseline database, immediately after. The copyright on the available
code for MD-2 strictly limits its use to privacy-enhanced mail functions. RSA Data
Security, Inc. has kindly given us permission to include MD-2 in the Tripwire package
without further restriction or royalty. it is is generated, be moved to some secure read-
only media. The most common Tripwire configuration to facilitate this is the use of a
“secure server,” a specialized server receiving extra scrutiny from administrators. A
remote file system is then used to export the baseline database to clients. However,
several sites have gone to much further lengths to maintain the integrity of Tripwire
databases.
At least two sites have considerably modified Tripwire to support alternate channels
for receiving the database and transmitting the report, adding layers for networking
support, encryption, and host authentication. Since then, Tripwire has added full
support for using open UNIX file descriptors to read the configuration and database

2
6
files. This allows system administrators to easily add support for encryption and
compression without having to modify the Tripwire package so drastically. Instead, a
wrapper program (even a shell script) can be used to supply these facilities. It is
interesting to note that mistrust of networked file systems motivate the undertaking of
such modifications to Tripwire.

Concealing Tripwire operation

Several sites have reported going to considerable lengths to conceal the operation of
Tripwire. These system administrators feel strongly that they should not advertise their
security measures or policies. As a result, Tripwire is not being run programs like
cron(8), the conventional means of executing programs on a regular schedule.
Instead, a wide variety of local tools are used. For example, a special daemon is
loaded at system startup, waking only to run Tripwire at a scheduled time. Where cron
is used, indirection is sometimes used to mislead an intruder from immediately seeing
evidence of Tripwire use. In one case, a system administrator uses three levels o
indirection before finally executing Tripwire (e.g., cron runs a script that runs a script
than runs a script that runs Tripwire). We wonder whether these measures to conceal
Tripwire are necessary, or even desirable. One of us (Spafford) has seen an
“underground” publication warning the need for special vigilance when attempting to
crack system running Tripwire. If this warning is true, then Tripwire may have the
ability to deter crackers.

Tracking Tripwire configurations

Tripwire provides a configuration language intended to aid system administrators in
managing larger sites. We were especially interested in how these tools would be
used by system administrators – the Tripwire design document suggests that a core
configuration file could be shared by numerous hosts by using the @@include
directive. From reports we have gathered, this appears to be a less than popul
method. Instead, system administrators create one configuration file to be shared by

2
7
all machines, using the @@ifhost directive to segregate non-common file groups. We
suspect that the overhead of tracking multiple configuration files outweighs the
inconvenience caused by files obfuscated by many “@@ifdef” statements. These
shared configuration files are apparently still manageable, since the number of entries
in the file is not large. (We suspect that if files had to be individually enumerated,
these configuration files be far larger, and therefore unmanageable.) Tripwire has
proven scalable, with documented cases of sites of almost one thousand machines
running Tripwire, as well as sites of only one machine. That system administrators
have done so using a different mechanism than suggested in the design document is
especially interesting.

Simple configuration files

How Tripwire is used on workstations with minimal disk resources proved surprising.
Although the Tripwire configuration file allows considerable flexibility in specifying files
and directories to monitor, configuration files for these workstations consist of only one
character: “/” Thusly, Tripwire scans all the local disk partitions under the root
directory, collecting the default MD5 and Snefru signatures. For some sites, this has
proved adequate for all their machines!

Frequency of Tripwire runs

The Tripwire design document recommends running Tripwire in integrity checking on a
regular basis (e.g., daily) to ensure that file system tampering can be detected in a
timely manner. However, there have been two reported cases of sites running Tripwire
far more frequently. In fact, these sites motivated the feature addition to skip certain
signatures by specifying it on the command line. Because they were running Tripwire
on their machines hourly and with all signatures enabled, the Tripwire runs were not
completed by the time the next Tripwire run started! (The authors were left wondering
what these machines did besides spending all the CPU cycles computing file
signatures.)

2
8
Validating the integrity checking scheme
We have gathered at least seven cases of sites who have detected intruders by using
Tripwire. In at least two of these cases, the penetration was widespread, with system
programs and libraries replaced with Trojan horses. Potentially less exciting than
these stories, but equally inspiring, are the dozens of stories we have received of sites
using Tripwire as a system administration enforcement tool. System administrators
report having found hundreds of program binaries changed, only to find that another
system administrator had made the changed without following local policy. There has
also been one reported case of a system administrator detecting a failing disk with
Tripwire. All three classes of stories seem to validate the theory behind integrity
checking programs. Although the foundations of integrity checkers have been
discussed in [1, 2, 4], when Tripwire design was started in May 1992, no usuable,
publically available integrity tools existed – undoubtedly providing one of the primary
motivations for writing Tripwire.

Evaluating Tripwire portability

Tripwire has proven to be highly portable, successfully running on over 28 UNIX
platforms. Among them are Sun, SGI, HP, Sequents, Pyramids, Crays, Apollos,
NeXTs, BSDI, Lynix, Apple Macintosh, and even Xenix. Configurations for new
operating systems has proven to be sufficiently general to necessitate the inclusion of
only eight example tw.config files.

Frequency of file system changes

According to system administrators, the ability to update Tripwire databases is among
its most important features. Files seem to change for many unforeseen reasons.
Consequently, the database is updated regularly. The addition of the interactive
update facility in Tripwire was among the most enthusiastically received features.
(Allowing database updates was a request that was explained away for almost two
months during the beta test period in 1992. That they acquiesced and still used

2
9
Tripwire despite its lack of ability to update the baseline database without regenerating
the entire database astounds the authors. In hindsight, at least.)

3
0
 ADVANTAGES

Tripwire Integrity Management solutions give organizations visibility into service

affecting changes and, in the process, increase security, instill process
accountability, and improve system availability.

• Increase security
Tripwire software immediately detects and pinpoints unauthorized
change-whether malicious or accidental, initiated externally or internally. Tripwire
provides the only way to know, with certainty, that systems remains uncompromised.

• Instill Accountability
Tripwire identifies and reports the sources of change, enabling IT
to “manage by fact.” It also captures an audit trail of changes to servers and network
devices.

• Gain Visibility
Tripwire software provides a centralized view of changes across
the enterprise infrastructure and support multiple devices from multiple vendors.
• Ensure Availability
Tripwire software reduces troubleshooting time, enabling rapid
discovery and recovery. Immediate detection of change enables the fastest possible
restoration back to a desired, good state.

3
1
 CONCLUSION

Tripwire is a reliable intrusion detection system. It is a software

that can be installed in any type of system where damaged files are to be detected.
The main attractive feature of this system is that the software generates a report
about which file have been violated, when the file have been violated and also what
in the files have been changed. To some extend it also helps to detect who made the
changes. New versions of Tripwire are under research and development. The latest
version under research is the Tripwire for Open Source.

3
2
 REFERNECE

1. www.tripwire.com
2. www.iec.com
3. www.itpaper.com
4. Cryptography and network security – William Stallings
5. Operating System – SilberSchertz
6. Linux for you magazine

3
3
 3
4