Now that tripwire itself is fully ready, the next thing we need to do is use it to perform an integrity check.
Iv. maintenance of policy files and profiles if you want to browse the tripwire policy and configuration, but they are stored in binary form or are currently missing, use the following command:
Generate a valid configuration file
# cd/etc/tripwire# Twadmin--print-cfgfile > Twcfg.txt
|
Generate a valid policy file
# cd/etc/tripwire# Twadmin--print-polfile > Twpol.txt
Because valid configuration files and policy files have been encrypted and signed, they are stored in redaction form. If you want to browse them, you need to decrypt them: convert them into plaintext. For security reasons, it is generally recommended that clear-text configuration and policy files be deleted after they are re-signed.
It is important to note that although we can redirect twadmin output to any file, the installation script twinstall.sh requires the policy and profile name in clear text as Twcfg.txt and Twpol.txt.
Modify policy files and configuration files What if you want to change the files and directories that tripwire checked, or if you want to change the default behavior of Tripwire? Follow the example below:
First, the policy and configuration are extracted from the clear text file:
# cd/etc/tripwire# Twadmin--print-polfile > twpol.txt# twadmin--print-cfgfile > Twcfg.txt
|
Changes to the policy file twpol.txt and configuration file Twcfg.txt can be done using a common text editor. For modified policy file twpol.txt and configuration file Twcfg.txt files, they need to be signed again:
# twadmin--create-cfgfile--cfgfile/etc/tripwire/tw.cfg \ --site-keyfile site_key etc/tripwire/twcfg.txt# Twadmin--create-polfile--cfgfile/etc/tripwire/tw.cfg --site-keyfile site_key etc/tripwire/twpol.txt
|
Then we need to reinitialize the database:
# tripwire--init# RM twcfg.txt Twpol.txt
|
It is important to note that we can only edit policy and configuration files in clear text, so unless there are clear text files, you must first convert the policies and configuration files for the encryption signature to clear text. Also, when you modify a file, you may experience the following message:
### Error:file could not to be opened
|
This means that Tripwire did not find the target file, and if it does not exist, we need to remove the reference to the file (or annotate it) from the policy and configuration file and re-sign the policy file. If you simply update the database after the integrity check, there is no need to strictly follow the steps above, but you must do this if you modify the policy or configuration file.
The purpose of the integrity test for configuration integrity testing is to check whether our files have changed since the last time tripwire the files, and we can simply do this by using the following command:
This is a basic command that tells us if the system has been modified. It uses the Tripwire database to compare the current state of the file system against the rules specified in the policy file, and then writes the comparison to the standard output, stamped with time stamp, signed, and then stored as a tripwire report. In addition, we can perform integrity checks on individual or multiple files in the database. If the Tripwire policy includes the following rules:
( rulename = "My funky Files", severity = m) { /sbin/e2fsck -> $ (sec_cr
IT); /BIN/CP -> $ (sec_crit); /usr/tmp -> $ (sec_invariant); /ETC/CSH.CSHRC -> $ (sec_config);}
|
You can then use the following command to view the selected files and directories:
# tripwire--check/bin/cp/usr/tmp
To view all the files for a rule, use the following command:
# tripwire--check--rule-name "My Funky Files"
|
You can also view all rules that have a severity greater than or equal to a particular value, as follows:
# tripwire--check--severity 40
|
For more information about the syntax for policy files, refer to the manual or view the online Help:
Higher security level integrity detection
For greater security, we can store Tripwire's most critical files on read-only media, such as CD-ROMs, or on a write-protected disk that prevents them from being tampered with. The steps are as follows:
1. Copy the site key, local key, and Tripwire executable itself to the appropriate disk, open write protection, and then mount it, such as installing it in the directory/mnt/cdrom.
# mount/mnt/cdrom# ls-l/mnt/cdromtotal 2564-r--r----- 1 root 931 with a few 10:20 site.key-r--r----- 1 root 931 10:20 myhost-local.key-r-xr-xr-x 1 root root 2612200 10:19
|
2. Generate a configuration file in clear text form
# dir=/etc/tripwire# CD $DIR # twadmin--print-cfgfile > Twcfg.txt
3. Edit the configuration file to point to these copies
/etc/tripwire/twcfg.txt:root=/mnt/cdromsitekeyfile=/mnt/cdrom/site.keylocalkeyfile=/mnt/cdrom/myhost-local.key
4. To sign a modified configuration file
# site_key=/mnt/cdrom/site.key# twadmin--create-cfgfile--cfgfile $DIR/tw.cfg--site-keyfile $SITE _key $DIR/ Twcfg.txt5. Update the database and uninstall cd-rom#/mnt/cdrom/tripwire--init# Umount/mnt/cdrom Now, everything is available, if you want to do integrity testing, just insert the CD and enter the command: # mount/mnt/ cdrom#/mnt/cdrom/tripwire--check# umount/mnt/cdromsite keys, local keys, and tripwire executables are protected because they are extremely important and can be compromised. Other files of the tripwire, such as databases, policies, and configurations, need to be signed with both keys and programs, and if the site key, local key, and Tripwire executable are secure, any changes to the files that have been signed with them can be found. Also, before copying/usr/sbin/tripwire to a disc, make sure it is statically linked, meaning that the program's execution does not depend on any dynamic shared libraries, because dynamic library calls are more easily hijacked by attackers when the dynamic shared libraries are applied.
$ ldd/usr/sbin/tripwirenot a dynamic executable
|
In addition to the above methods, we can also use remote integrity testing to improve the security strength.
In order to improve the safety of the inspection, the key tripwire files should not be stored on the tested machine. To this end, we introduce two machines untrusty and trusty. The former is a "tripwire" machine that wants to check its integrity with a single machine; the latter is a secure machine that, ideally, can only be accessed by it, while other machines do not have access to it. In addition, to enable other machines to access remote machines that host site keys, local keys, and tripwire executables, it is common to use rsync (Secure tunneling Technology under SSH) to verify the consistency of originals and copies to trigger integrity checks. The original configuration on the remote machine trusty is as follows:
#!/bin/shremote_machine=untrustyrsync= '/usr/bin/rsync-a--progress--rsh=/usr/bin/ssh ' SAFE_DIR=/usr/local/ tripwire/${remote_machine}vital_files= "/usr/sbin/tripwire /etc/tripwire/site.key /etc/tripwire/${ Remote_machine}-local.key "mkdir $SAFE _dirfor file in $VITAL _filesdo $RSYNC ${remote_machine}: $file $SAFE _dir/ Done
|
Before verifying the local machine, it is necessary to compare the site key, the locals key, and the tripwire executable file with their copy on the remote machine to determine the integrity of the three files. Then run the following code on the trusty (note that the variables here, like Remote_machine, are consistent with the previous script):
#!/bin/shcd $SAFE _dirrm-f logfor file in $VITAL _filesdo base= ' basename $file ' $RSYNC-n ${remote_machine}:$ File. | Fgrep-x "$base" >> logdoneif [-S log]; Then echo ' Security alert! ' else ssh ${remote_machine}-l Root/usr/sbin/tripwire--CHECKFI
|
Rsync is a utility that is commonly used to synchronize files on two machines. It actually built a secure tunnel through SSH, to provide secure authentication between the two machines and to provide cryptographic services for communication between them, provided that you have set up an SSH facility between the two machines, otherwise, rsync will not be able to provide the security features described above.
Here are a few common options to introduce:-progress notifies rsync that output is generated only when local and remote files are different, and the-n option is to allow rsync to not copy files.
For the Fgrep command, it is primarily used to remove all output, except for suspicious filenames. It is characterized by a fixed string rather than a regular expression, and the file name exactly contains some special characters of the common present expression, such as "." Wait Fgrep-x matches the entire line (that is, the file name), so the log file is empty when and only if the local and remote files are exactly the same, triggering an integrity check.
Do you want to store the database remotely? In fact, it is not necessary because the database is signed with a local key and the key is "off", so tripwire alerts if the database changes unexpectedly.
Trusty not only check these important tripwire files, but also have to copy them to Untrusty before the untrusty integrity check:
# scp-p tripwire untrusty:/usr/sbin/tripwire# scp-p site.key untrusty-local.key untrusty:/etc/tripwire/# ssh untrusty-l Root/usr/sbin/tripwire--check
|
High strength Integrity Testing
The above describes the normal strength of the integrity test, but we can continue to improve the test strength, but there is no free lunch, this need to pay the speed and convenience of the price.
So we can create a bootable CD-ROM with a miniature Linux system, tripwire program, and your local and site keys. Then disconnect your machine from all networks, boot the system from the bootable CD, and then use the executable on the disc (not on the hard disk) to check the integrity of the machine's disks. You will then frequently back up your tripwire databases, configurations, and policies in case they are removed by an attacker.
This method requires at least two machines, one of which must be a safe and trustworthy machine (called trusty), and the other is a detected machine (called untrusty). Our aim is to conduct safe tripwire detection for the latter.
The first step is to securely create a bootable CD-ROM that requires:
Creating Cd-rom,trusty on trusty must be a clean Linux system that can be built from a trusted source or binary package, never connected to a network or accessed by a third party, and has the latest security patches.
Configure the CD-ROM startup script to disable all networks.
Use a trusted source or binary package to burn the disc directly.
Create the site and local keys on the trusty.
Then, boot untrusty from the CD-ROM, mount the local disk, and use the program and key on the CD-ROM to create the Untrusty tripwire database. Because databases, policies, and configuration files have been signed with the CD-ROM key, the security of these files on the untrusty is trustworthy. You can then boot the untrusty from the CD before performing the integrity check. In addition, if you just load the CD from the Untrusty and run Untrusty from the CD, the following occurs:
If Untrusty is a dynamic link, it is difficult to ensure the security of the shared library;
It is difficult to guarantee the security of system kernel;
It is difficult to guarantee the correctness of the mount point on the untrusty;
Although this approach provides a very high level of security, it is cumbersome to do so and only if there is a special security requirement. For convenience, we can schedule a cron task to reboot the Untrusty from the CD at the specified time of the night for Tripwire inspection, and then reboot the Untrusty. However, do not let Untrusty itself perform the task because Untrusty is not secure, so cron running on it is unreliable; instead, it should be scheduled for trusty to execute, such as using the SSH batch task to trigger the reboot, because it makes more sense.
