How to Set Up and Use Tripwire
After everything has been placed in the proper directories, either from a binary package or compiling the sources, the first action to take as root is to generate two robust—that is, hard to guess—passphrases. The first one (site passphrase) is used to encrypt and sign the Tripwire system files. The second one (local passphrase) is necessary to launch the Tripwire binaries.
Theoretically, the Tripwire distribution should include an /etc/tripwire/twinstall.sh script that should prompt the user for passphrases and other information and then perform all the steps below. At the time of this writing, both the Tripwire 2.3.1 RPM package for Fedora Core 4 tested for this article and several on-line tutorials still say to use that script, but it just wasn't there after the installation. In any case, the utility that performs these tasks is twadmin. Because it has a complete man page, and it should be used anyway if you want to change keys after installation, we just show how it works. The actions described above are executed with the following commands:
twadmin --generate-keys --site-keyfile my_home_key ↪--site-passphrase 'Hello LJ readers' twadmin --generate-keys --local-keyfile my_local_key ↪--local-passphrase 'Penguins are cool'
This leaves the two keys encoded in the my_home_key and, respectively, my_local_key files. Remember to copy these two names in the twcfg.txt file before running twadmin:
SITEKEYFILE =/etc/tripwire/my_home_key LOCALKEYFILE =/etc/tripwire/my_local_key
Once the passphrases have been stored, the configuration file must be encrypted in this way:
twadmin --create-cfgfile --cfgfile twcfg.enc ↪--site-keyfile my_home_key twcfg.txt Please enter your site passphrase: Wrote configuration file: /etc/tripwire/twcfg.enc
The procedure to create a binary version of the policy is similar:
twadmin --create-polfile --cfgfile twcfg.enc --polfile ↪twpol.enc --site-keyfile my_home_key twpol.txt
The difference, with respect to the former command, is that now the encrypted configuration file must be passed to twadmin. The reason why the two files must be encrypted is that Tripwire will discover if they are corrupted much more easily than if they were in plain-text format. In order to directly read such files, you need (besides the passphrases, obviously) the -print-cfgfile or --print-polfile options of twadmin.
Once the passphrases and system files are all set, it's time to go into what the documentation calls Database Initialization Mode:
tripwire --init --cfgfile twcfg.enc --polfile tw.pol ↪--site-keyfile my_home_key --local-keyfile my_local_key
By default, the result is stored in /var/lib/tripwire/YOURHOSTNAME.twd. Path and name can be changed in twcfg.txt or given as a command-line option. Eventually, if everything goes fine, you'll be greeted by this message:
Wrote database file: /var/lib/tripwire/YOURHOSTNAME.twd The database was successfully generated
As soon as encrypted system files, passphrases and a complete snapshot of your system are available, Tripwire finally can do the only thing we really care about—that is, to check the integrity of our computers periodically. This is normally accomplished by running the program as a cron job with this switch:
Note that, just to allow secure, automatic usage the program doesn't need passphrases when launched in this way. Consequently, there is no need to write them in plain text anywhere. The integrity report is printed both to STDOUT (so it can be e-mailed to the system administrator) and saved in the location specified by the REPORTFILE variable in the configuration file. How often this operation should be performed depends on how critical the system is and how often it is exposed to external attacks. Although a corporate firewall should be checked daily, a weekly check may be enough for a department print server behind it or a regular desktop.
Figure 1 shows an example of what a Tripwire report looks like. It tells you, for every rule defined in the policy, which of the corresponding files were added, changed or modified. Command-line options are available to check only specific sections of the policy file, or just some files. This could be useful, for example, when nothing was modified in the system, but there is the suspicion that some particular disc or partition was damaged.
The integrity checking procedure also can be interactive. Adding the -interactive switch causes Tripwire to open an editor, after the check, to allow the user to declare which files should be permanently updated in the Tripwire database. This is a manual alternative to the update mode described below.
Articles about Digital Rights and more at http://stop.zona-m.net CV, talks and bio at http://mfioretti.com
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Interview with Patrick Volkerding
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide