Open Source Tripwire

Overview A Tripwire check compares the current filesystem state against a known baseline state, and alerts on any changes it detects. The baseline and check behavior are controlled by a policy file, which specifies which files or directories to monitor, and which attributes to monitor on them, such as hashes, file permissions, and ownership. When an expected change occurs, such as upgrading a package, the baseline database can be updated to the new known-good state. The policy can also be updated, for example to reduce noise or cover a newly installed package. This section covers manual setup of Open Source Tripwire. If installing via an RPM or Debian package, or via make install , a setup script will walk the user through the initial setup steps (key generation thru policy creation) and these will not need to be done by hand. Generating Keys The first step is to generate site and local key files. This is necessary because Tripwire policy, configuration, and database files are signed by default, and report files may also be signed. The site key is used to sign config and policy files, while databases and reports are signed with the local key. The idea here is that multiple machines can share a site key, but each will have its own local key. The policy and config files can then be created once and distributed across these machines. Creating a configuration file The next step is to create a Tripwire config file. The config file contains a variety of settings including the locations of Tripwire binaries and key files, email report settings, and parameters that control baseline/check behavior. These settings are explained in detail in the twconfig(4) manual page. This command line reads and validates the config text in /path/to/twcfg.txt, writes the results to tw.cfg, and signs the resulting file with the provided site key: Now it's time to configure which files & directories OST will monitor. A few simple examples of policy rules: The Tripwire policy language is documented in detail in the twpolicy(4) manual page, and default policies for most common operating systems are available in the OST project's policy subdirectory. The next step is to baseline the system for the first time. This step is necessary even if the previous steps are handled by a setup/install script. This creates a database file in the configured directory, typically a file with a .twd extension in /var/lib/tripwire. The optional --verbose argument to init mode lists files and directories as they're being scanned. This runs a check, again with an optional --verbose option that displays what it's doing. Scan results are written to standard out, as well as a report file, which typically has a .twr extension and lives in /var/lib/tripwire/report. If email reporting is enabled, emails will be sent at the end of the check. brings up a text report in the user's preferred editor (as configured in the config file's EDITOR option), with a checkbox next to each detected change. After saving and exiting the editor, the database will only be updated for those objects that remain selected with an [x] . Updating a policy Policy update mode modifies the current Tripwire policy without losing existing baselines. A check is run with the new policy as part of the update process. If this check detects changes, the default behavior is to display the changes and exit without updating the policy or database. To accept the changes and continue with the policy update, use the -Z low / --secure-mode low command line option. This sends a test email to the specified address, using the email settings specified in the config file. A C++ compiler. It's known to build with gcc and clang; OST should work with gcc versions as old as 2.95.2, although gcc older than version 3.1 will need an external STLPort package. A POSIX-like operating system, including Linux, macOS, various BSDs, Solaris, AIX, HP-UX, Minix, Haiku, GNU/Hurd, and others. Windows users can build OST under Cygwin