1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
------------------------------------------------------------------------------
Open Source Tripwire 2.3.1, build 2 Release Notes
March 3, 2001
------------------------------------------------------------------------------
CONTENTS:
- Introduction
- Where to look for help
- Contacting Tripwire
- The Tripwire Policy file
- Known issues
- Differences from Tripwire ASR 1.3
Introduction
------------------------------------------------------------------------------
Welcome to Open Source Tripwire 2.3.1 for Linux. This document contains
up-to-the-minute information on the known issues and behaviors of this
release of Tripwire. Please read this document carefully before installing
Tripwire or reporting any bugs.
We have also included contact information for your benefit. Please
tell us about any bugs you find and also how you feel about our product.
Where to look for help
------------------------------------------------------------------------------
We recommended that you refer to the README file and policyguide.txt file,
for helpful information.
The Open Source Tripwire home page also contains information about this
version of Tripwire, and other resources. Visit this web site at
http://www.tripwire.org.
Contacting Tripwire
------------------------------------------------------------------------------
If you wish to contact Tripwire, Inc. to report bugs or make
feature suggestions, reach us through one of the following:
email:...............opensource@tripwire.org
main site:...........http://www.tripwire.org
development site:....http://sourceforge.net/project/?group_id=3130
The Tripwire Policy file:
------------------------------------------------------------------------------
An example Tripwire Policy file is included with this distribution. This
example policy file, plus the Policy Guide provides enough information to help
you customize a Tripwire Policy file for your own system. Start with tht
example policy file to craete your own custom Tripwire Policy file. The text
version of the Tripwire Policy file is named twpol.txt
Note: The Tripwire Policy is tuned to an 'everything' install of RedHat Linux
7.0. If run unmodified, this file should not generate errors on database
creation, or violations on subsequent integrity checks. However, it is
impossible to provide one policy file for all machines. This example policy
file is written to err on the side of security. Your Linux configuration will
most likely differ from the one our policy file was tuned to. Therefore you
may need to edit the example Tripwire Policy file.
The example policy file is best run with 'Loose Directory Checking' enabled.
Set LOOSEDIRECTORYCHECKING=TRUE in the Tripwire Configuration file.
Known Issues
------------------------------------------------------------------------------
- Open Source Tripwire 2.3.1 has been tested on Linux Kernel 2.2.14 or higher.
- Open Source Tripwire 2.3.1 has been build-tested using GCC 2.95.2 or higher
and Glibc 2.1 or higher.
- Source and Binary RPMs (if provided) require RPM version 3.0 or higher
- Making modifications to an existing policy file requires the use of the
--update-policy mode of Tripwire. This mode ensures that the database on
disk is internally consistent with the policy file. Otherwise, ensuring
that no changes have been made to the filesystem between the last integrity
check and the policy file modification requires several steps. These steps
include disconnecting the machine from the network, running an integrity
check, updating the policy file and reinitializing the database. This update
policy mode allows the same functionality and security of all these in one
step. See the Tripwire section of the Command Reference in the User Manual
for further information.
- Using 'twadmin --create-polfile' to update an existing policy file causes
errors on the next integrity check if the database is not regenerated from
scratch. Errors are generated by rules added or modified from the policy file
used to create the database. However, rules that are removed from the policy
file generate no errors or warnings. Therefore, using '--secure-mode high' on
an integrity check command line does not catch this inconsistency. It is
STRONGLY recommended that you use 'tripwire --update-policy' to keep the
Tripwire database and policy file in sync. See the Tripwire section of the
Command Reference in the User Manual for further information.
- The CLOBBER setting in install.cfg applies to everything except
configuration and policy files. These files, if present, are always
backed up and recreated to avoid the potential of leaving Tripwire in
a state where it cannot run. If you have installed Tripwire over an
existing installation, and wish to keep your old policy and
configuration files, they can be recovered. Use the twadmin command to
print the old configuration and policy files (tw.cfg.bak and tw.pol.bak)
as text files and then re-encrypt them with the Tripwire 2.3.1 site key.
- Specifying a rule that includes both a hash attribute (C, M, S, or H) AND
the access timestamp attribute (a) is not recommended. This causes
every file that was scanned using the rule to show up as having changed
between scans. This is because Tripwire currently does not reset the
access time attribute after it accesses the file to obtain a hash value.
Thus the next scan shows every hashed file as having been accessed (by
Tripwire).
- Specifying a rule that monitors the access timestamp (a) causes every
directory recursed while scanning that rule to show up as having changed
between scans. This is because Tripwire does not reset the access time
attribute after enumerating the directory contents. To avoid this, change
the LOOSEDIRECTORYCHECKING value in the Tripwire configuration file to
true. There are potential security implications for doing this, however
[see the Configuration Reference section of the User Manual for more
information].
- In the event that the umask is set such that files are created non-writeable
by default, the editor launched in interactive integrity check and database
update modes may be unable to save changes made to the report. If the editor
is closed without saving the changes, Tripwire assumes that all items in the
report should be updated, potentially including compromised data in the
database. To exploit this vulnerability, an intruder would require a
previously-compromised account with write access to either the Tripwire
administrator's account or the Tripwire binaries. To work around this issue,
launch a shell from the editor (":shell" in vi), add user-write (chmod u+w
<filename>) permissions to the temp file open in the editor, exit the shell
and force a write to the file (":w!" in vi). To avoid this issue, make
certain that the umask does not contain the user-write bit (0200).
- CAUTION: Tripwire keyfiles are inextricably linked to their associated
signed files. Consequently, if you create a new keyfile and overwrite the
pre-existing keyfile, all files signed with the original key become
unusable.
- When a folder or registry key is specified on the command line during a
Tripwire integrity check, Tripwire *only* scans the specified object. It is
not recursed. To scan and recurse through a specified object, that object
must be a start point for a rule, and may be specified on the command line
with the '--rule-name' parameter.
- When specifying filenames in the policy file, the inclusion of multiple
adjacent path delimiters in the filename may result in Tripwire being unable
to locate or examine the file. To avoid this issue, ensure that paths are
specified using standard naming conventions, and that variables used as part
of a path do not include a trailing or preceeding path delimiter if one
already exists adjacent to the variable.
- The default policy file contains a rule for verifying the integrity of
critical Tripwire components. The database, which must be generated after the
policy file, is included as a component to verify. Therefore the first
integrity check run after a default installation reports a violation that
describes the database as "added". This issue can be avoided by initializing
the database twice after installation, or by creating a zero-length file with
the same path and filename as the database before running Tripwire in database
initialization mode.
- Due to operating system limitations, Tripwire may be unable to scan files
larger than 2 GB on some older the Linux platforms. A non-fatal error is
generated by attempts to access such files. Tripwire will be unable to
retrieve some properties of these files, but otherwise operation is normal.
- If the site keyfile specified in the config file differs from the key used
to create a report or database,twprint is unable to print either of these
files. This is because twprint does not support the "-S" argument with the
capacity to override the default site keyfile. Twprint uses this argument
strictly for validation of the data in the config file.
- Email reports containing high-ascii or multi-byte characters are now MIME
encoded if either the SMTP or Sendmail email reporting methods are specified
in the configuration file.
- If a filename includes character 0x5C, the filesystem may fail to pass the
filename to tripwire correctly, causing tripwire to falsely see the file as
having been removed. If the filename is passed on the command line, Tripwire
is able to correctly interpret the filename.
Differences from Tripwire ASR 1.3
------------------------------------------------------------------------------
Tripwire 2.3.1 is the latest open-source release of Tripwire software. It is a
complete rewrite of the source code from the Academic Source Release (ASR)
versions of Tripwire. Tripwire 2.3.1 is based on the commercial Tripwire 2.x
codebase. Several significant enhancements to original features and
functionality have been created, such as:
- Run-time global Tripwire variables are now stored in a configuration file.
This avoids reliance on some easily compromized environment variables.
- Slight change in terminology:
- Tripwire policy file replaces "tw.config".
- Tripwire configuration file replaces compile-time options.
- More integrity checking options:
- E-mail reporting.
- Running rules based on severity levels or name.
- More secure file handling:
- Cryptographically-signed configuration, policy, and database files.
This eliminates the need for removable or read-only media to store these files, and allows for automated use.
Note: These files are still susceptible to deletion and must be backed up.
- Optionally-signed reports.
- Addition of twadmin and twprint commands provide interface to Tripwire
data files for handling updating, encryption management, and printing.
- Greatly enhanced policy language. We recommend that ASR policy files be
reviewed according to the new specifications and altered accordingly. ASR
policies and rules will not function correctly under Tripwire 2.3.1 without
modification.
- All rules now have a set of attributes that can be associated with them.
(For example, rule names, severity levels, e-mail reporting recipients,
recursion behavior, etc.)
- Generalized grammar to handle future object monitoring.
- Tripwire 2.3.1 uses a different Base64 (RFC 2045) alphabet than Tripwire 1.3.
As a result, signature values will appear to be different for the same file.
For CRC32 hashes, Tripwire 2.3.1 fixes an error in the calculation of this
value, and results will differ by their 'one's complement'. Tripwire 2.3.1
now returns the same CRC32 value as the cksum utility. However, all other
hash values are actually identical, but expressed differently. Generating
signatures with hexadecimal (siggen -h) output will show the identical
values.
- Tripwire is Year 2000 (Y2K) compliant.
=============================================================================
Copyright 2000 Tripwire, Inc. Tripwire is a registered trademark of Tripwire,
Inc. in the United States and other countries. All rights reserved.
Linux is a registered trademark of Linus Torvalds.
UNIX is a registered trademark of The Open Group.
=============================================================================
Permission is granted to make and distribute verbatim copies of this document
provided the copyright notice and this permission notice are preserved on all
copies.
Permission is granted to copy and distribute modified versions of this
document under the conditions for verbatim copying, provided that the entire
resulting derived work is distributed under the terms of a permission notice
identical to this one.
Permission is granted to copy and distribute translations of this document
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation approved by
Tripwire, Inc.
|
