Notes:
|
|
|
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
Integrity checkers are very useful for finding Trojan programs and backdoors like Rootkit. Theoretically they are also useful for maintenance, but in reality this goal is pretty difficult to achieve. Perl-written (or Python-written) integrity checkers are more flexible and thus have an edge over C-written tools like Tripwire. Mixed TCL+C tools are probably the most flexible approach, but both Perl and Python are OK "as is". Perl based checkers are now moved to a separate page: Perl-based Integrity checkers
The most popular integrity checker for Unix, Tripwire never was able to supersede its beginning as a student project. A free version of Tripwire realistically can only be used in a limited way for static servers like appliances. A commercial version is a little bit more flexible, but not by much. Moreover an introduction of central console for all Tripwire instances created an additional security risk.
The fairy tails that Tripwire can detect or prevent host intrusions as a standalone application are not credible. Theoretically it can, but the tool itself is so inflexible that it largely defeats its purpose. On Linux in most case you might have more success with RPM-based checking that with Tripwire.
If you really have some time to spend you can install Tripwire on a regular server; just do not try to write all-encompassing rulebase, this is a proven road to nowhere ;-). Older versions of tripwire are strictly file oriented and you need to list all the files and directories you need to check. Newer version (commercial version 4.0 and later) permit specification of all files in the directory (better late then never ;-)
Still the best policy in using Tripwire is to limit yourself to a few critical system and configuration files (for example used in the rootkits), plus several critical configuration files. Actually control of configuration files is more important and here Tripwire while weak, can at least can provide some return on investment. If you are thinking about using Tripwire for tracking changes, please think again. This is possible by writing custom scripts, but there are better tools for the same purpose. One problem is that if you do not compare with the baseline, you compare with the set of attributes. Also if you control both directory and a file in this directory, then for each change Tripwire will complain twice. In old times there was an option -loosedir which would prevent tripwire from complaining about directory modification time updates that can filter out some noise. Later it became a configuration option.
|
| 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 |
Mar 31, 2004 (securityfocus.com)This article is written with the open source host integrity applications Osiris and Samhain in mind, however the material presented is certainly not unique to these applications.
... ... ...
The basic idea behind host integrity monitoring applications is that they detect and report on change to the system. It gets most interesting when a change is unauthorized or unwanted. Much of the monitoring is focused on the file system. However, other environmental vectors can be monitored as well. For example, Samhain has the ability to search for rootkits and monitor login and logout activities. Osiris has the ability to monitor the state of loaded kernel extensions and the details of changes to the local user and group databases. Detected change is reported in the form of log files, syslog, the Windows Event Viewer, and possibly emailed to an administrator.
... ... ...
To better appreciate the role a host integrity system serves, imagine you find a new link to /etc/passwd that has been created in /tmp, a new kernel module that gets loaded without your knowledge, or a new user gets mysteriously created. How would you know if and when these types of changes occurred? There are commands that can be used to look for these happenings, but how would you know if and when to run them? What if these commands that you depend on for finding such changes were altered to hide specific information? Now, imagine you have hundreds of hosts that need to be monitored regularly to look for changes such as these.
Table One, below, compares features of some popular host integrity applications.
Samhain Osiris INTEGRIT AIDE Monitors Files yes yes yes yes Monitors Kernel yes yes no no Platforms Linux, FreeBSD, AIX 4.x, HP-UX 10.20, Unixware 7.1.0, Solaris 2.6, 2.8, and Alpha/True64 Windows NT/2k/XP, Mac OS X, Linux, Solaris, FreeBSD, OpenBSD Linux, FreeBSD, Solaris, HP-UX, Cygwin Linux, FreeBSD, OpenBSD, AIX Unixware 7.1.0, Solaris True64, BSDi, Cygwin Multiple Administrators no yes no no Supports Modules no yes no no License GPL BSD style GPL GPL Centralized Management yes yes no no Signed Databases yes no no no Database Integration yes no no no Table One: a comparison of popular host integrity applicationsMore information on the above products can be found on their websites:
Samhain - http://la-samhna.de/samhain/
Osiris - http://osiris.shmoo.com
INTEGRIT - http://integrit.sourceforge.net/
AIDE - http://www.cs.tut.fi/~rammer/aide.html
NewsForge takes a look at integrity checkers. "Each integrity checker is a little different, so do some research before deciding on one. There are many excellent integrity checking applications out there, but the one I recommend and prefer is called afick (Another File Integrity ChecKer). Afick offers several advantages over integrity checkers such as Tripwire and AIDE. The first and foremost difference is that afick is written in Perl, which gives it the advantage of speed. Afick finishes the initialization of the database that stores filesystem attributes almost a minute faster than AIDE. Being written in Perl also means that afick is highly portable between operating systems."
Table of results (alphabetic order)
AIDE FCheck Integrit Nabou Osiris Samhain Tripwire Version 0.10 2.07.59 3.02 2.4 4.0.5 1.8.4 2.3.1-2 Date Nov 30, 2003 May 03, 2001 Sep 08, 2002 Aug 30, 2004 Sep 27, 2004 Mar 17, 2004 Mar 04, 2001 PGP Signature YES NO YES YES YES YES NO Language C Perl C Perl C C C++ Required libmhash md5sum (or md5) PARI/GP library + about 11 Perl modules OpenSSL 0.9.6j or newer GnuPG (only if signed config/database used) Log Options stdout, stderr, file, file descriptor stdout, syslog stdout stdout, email central log server (email+file on server side) stderr, email, file, pipe, syslog, RDBMS, central log server, prelude, external script, IPC message queue stdout, file, email, syslog DB sign/crypt NO NO NO sign NO sign sign+crypt Conf sign/crypt NO NO NO NO NO sign sign+crypt Name Expansion regex NO NO see remarks regex glob (shell-style) NO Duplicate Path NO NO NO NO NO Warns Exits PATH_MAX OK OK NO OK NO OK OK Root Inode see remarks NO OK NO OK OK OK Non-printable NO NO NO NO NO OK OK No User OK OK OK see remarks OK OK OK No Group OK OK OK see remarks OK OK OK Lock OK Hangs Hangs Hangs Hangs Times out Hangs Race Hangs Hangs Hangs Hangs Hangs OK Hangs /proc NO NO Hangs Hangs NO OK NO /dev OK OK OK OK OK OK OK Crea/Del OK OK OK OK OK OK OK
By Brian Wotring
- Paperback: 450 pages
- Publisher: Syngress; 1 edition (June 1, 2005)
- Language: English
- ISBN: 1597490180
- Product Dimensions: 9.2 x 7.1 x 0.9 inches
- Shipping Weight: 1.6 pounds. (View shipping rates and policies)
- Average Customer Review:
based on 5 reviews.
Excellent one-of-a-kind book on an overlooked security discipline, August 7, 2005
Host Integrity Monitoring Using Osiris and Samhain (HIM) is an excellent book on a frequently overlooked security discipline. Most people who hear about host integrity monitoring nod their heads and agree that performing it is a good idea. These same people usually don't implement HIM, and frequently cannot count the number of hosts, operating systems, and applications working in their enterprise. Thankfully, HIM provides a way to use open source tools to help remedy this situation. Consistent with the Visible Ops methodology, HIM provides guidance on how to keep track of host integrity.
Reviewer: Richard Bejtlich "TaoSecurity.com" (Washington, DC) - See all my reviews
When writing HIM, author Brian Wotring could have easily concentrated on the program he coded -- Osiris. Luckily for readers, Brian chose to address his program and another open source host integrity monitor -- Samhain. By comparing and contrasting these two programs, readers learn more about each and understand the capabilities and limitations of each application's approach to the HIM problem. Consistent with this dual methodology, Brian explains how to install Osiris on both Unix and Windows platforms. (Samhain is mainly a Unix solution.)
The first third of the book provides background information on HIM rationales and planning. I was initially inclined to skip ahead, but I found the explanations of monitoring various system elements to be helpful. Brian's view of security closely mirrors my own, but he approaches it from a host-centric view. He still accepts that prevention eventually fails and that preparation for incident response is a necessity, not a luxury. Brian also correctly uses the term "threat" and recognizes threats are not vulnerabilities. Bravo.
The middle third and some of the final third of the book deal exclusively with installing and configuring Osiris and Samhain. The instructions are wise and very thorough. I was impressed by guidance on how to compile and install Osiris on Windows from source, using MinGW and MSYS. I also liked the book's frequent use of FreeBSD as a Unix reference platform.
I found a few minor issues with HIM, and one major drawback that prevented a five star review. First, I disagree with the statement on p 19 that "most attacks originate from within the network by authorized users." The annual CSI/FBI study has repeatedly shown this to not be true; rather, insider attacks, when they do occur, are typically more damaging that those perpetrated by outsiders. Second, I found some minor rough editing, e.g. "Nimbda" repeatedly used in place of "Nimda." Third, and most important, it would have been extremely helpful to have shown case studies of Osiris and Samhain in action when detecting configuration changes and/or intrusions. I left the book with a lot of ideas on installation and configuration, but it would have been helpful to see case studies on using host-based data to identify intrusions.
I am adding HIM to my recommended reading list for system administrators. HIM gives administrators the documentation and theory they need to add another critical tool to their security arsenal. I would like to see a second edition that adds case studies, and perhaps chapters on using Radmind for open source change management.
security incident and as a host-based intrusion detection tool to help detect unauthorized file system changes (this also makes them useful monitoring tools for existing change control procedures, though that is not the focus of this article). The concept is simple: the administrator creates a configuration file that lists the critical system files and directories that the FIA tool should monitor, then uses the FIA tool to create a database that tracks common parameters about those files, such as permissions and ownerships, file size, and MAC times, along with one or more cryptographic checksums over the file contents (typically via common hashing algorithms like MD5, SHA-1, etc.). The FIA tool is then re-run periodically, and the current state of the file system is compared to the values stored for the various files in the database -- if there are any discrepancies, the files are flagged as having been modified and a report is generated.
The canonical problem with FIA tools, however, is protecting the database generated by the FIA tool, as well as the binary for the FIA tool itself, from unauthorized tampering by attackers who gain root access to the system. After all, if the attacker installs a rootkit and then updates the FIA database for the system to reflect the new state of the file system, then the administrator may be unaware of the attacker's changes. Similarly, the attacker could modify the FIA tool binary to either ignore or lie about the state of files installed by the attacker.
Lately, however, I've been experimenting with a different approach. The concept is to store FIA databases and binaries for the various systems being monitored on a central, highly secure system on a protected network -- call this the FIA management server. Periodically from cron, we run a script on the FIA management server that uses scp to copy the FIA database and binary to a given system and then runs the FIA tool on that remote system via SSH. Any report output and/or updates to the FIA database can then be pulled back to the FIA management server via scp, and all traces of the FIA tool can then be removed from the remote system.
I've been using Tripwire [sourceforge.net] (and Tripwire Portable [frenchfries.net]) for years. Recently I have started using Samhain in its place and have been quite happy with it. Some useful features that it has which Tripwire doesn't is the ability to monitor kernel system call tables for changes (a common attack vector), and to run as a daemon to alert on changes immediately. Its definitely worth a look.Syngress 2005.
ISBN 1-597490-18-0. $44.95. Index, three appendices.Reviewed by Bob Bruen 09/16/05
We all know and love Tripwire, even if we still use the non-commercial version. It was one of, if not the, first complete tool for managing file integrity. The name comes from the alarm set off because a file was changed in some way. There are other tools that are popular and are still free. This book covers two of those tools, Osiris and Samhain.
Host intrusion detection systems are not quite as widespread in use as the network intrusion detection systems, generally because the number of hosts can be large. Each one requires time and attention, making a network approach more efficient, but not necessarily more effective. It seems that a blended approach would be useful and that appears to be common. The important machines on the network get good host monitoring and the less important are left to fend for themselves. The minimal blending is simply running an NIDS and some HIDS.
A still better approach might be to really integrate both approaches so that there is a distributed set of HIDS with a central management system. Perhaps this could part of the non-commercial version. Moreover, it would nice to have a sophisticated method to manage change on a host. After all, system file changes should be thoughtfully managed anyway. The intruder changes can be caught up the relentless change management system. Without any criticism of file integrity monitoring, it is not enough by itself because other things happen on a system and intruder code can be hidden in places other than the disks.
Osiris came into being as a few Perl scripts which eventually evolved into a extensive and sophisticated package. The architecture is geared toward central management with encrypted communications. The hosts will naturally require a client to be installed, which is a drawback of any HIDS, but otherwise nothing is stored on the host. The central manager does the heavy lifting. This is not unlike an application which needs to be installed on every computer on the LAN, something that is done all the time, but it is still overhead.
Samhain is similar to Osiris in its architecture of client, server and manager, but the clients initiate communication with the server. The Osiris manager initiates the communication with the clients required to keep a port open. The local situation will probably dictate which is the preferred method. Samhain offers the ability to run different scans on different schedules instead of running everything at one time. Both Osiris and Samhain run on Linux, BSD and Windows, but not with the exact same feature set or ease of configuration. This can be a bit of a problem, but still helpful in a heterogeneous environment.
Although the book is about Osiris and Samhain, there is a wealth of information about host integrity monitoring systems (HIMS). The advances in rootkits, intrusion techniques and defenses require us to update what we know. Anything learned ten years ago may still be valuable, just incomplete for today's environment. I always like books that are well written and provide good information, so I recommend Wotring's work to help bring you up to date
Trojans, rootkits, and DDoS agents are a sad reality. It's a little disheartening to think that software exists which, given a chance, can install unwanted files on your system, overwrite or destroy your own files, send your data or user input elsewhere, or use your computer to attack another system.
The more advanced among you may be smiling and smugly thinking "that's why I run a Unix system". True, there are fewer nasties out there which target Unix systems, but they do exist. Further, as the Unix user base increases, so will the amount and frequency of exploits against Unix systems. Fortunately, as a FreeBSD user, there are many utilities available to you, as well as many good habits that you can teach yourself. The next two articles will discuss these utilities and habits.
To identify a potential compromised Unix box is some what of an arcane art, though there are some simple things to look for.Always keep an eye on the un-seen trust relationships. Who mounts who via NFS? Who has who in their .rhosts, .shosts, or hosts.equiv? Who has a .netrc from that host?
- Examine syslog entries, process table, and file systems to see if there are any "odd" messages, processes, or files. Examples are 2 inetds running, ssh running as EUID root but not UID root, core files for RPC services in /, new setuid/setgid programs, files quickly growing in size, df not closely matching du, perfmeter/top/BMC Patrol/SNMP monitors not matching vmstat/ps output, Higher than normal outbound network traffic.
- Check the /etc/passwd & /etc/shadow for accounts that don't belong or should not have passwords.
- Check the /.rhosts, /etc/hosts.equiv, /.ssh/known_hosts and ~/.rhosts for new entries that don't belong.
- If you see anything that you suspect, then install a sniffer on a second host, and watch for connections to/from that host, and at the same time, back the machine up as evidence for later analysis and evidence. Then contact your local CERT for assistance in examining the other hosts in your network, and recovering your site.
http://software.newsforge.com/article.pl?sid=05/02/14/1620218
Title Check your filesystems' integrity with afick Date 2005.02.18 3:00 Author Brian Warshawsky Topic With new threats showing up every day, administrators find it increasingly hard to establish continued trust with their filesystems. Luckily, it's easier than you might think to maintain omniscient control of your filesystem. Through effective use of a filesystem integrity checker, you can keep a watchful eye on every aspect of an important machine's filesystem.
There are several filesystem integrity checker applications, both commercial and open source. I chose to deploy afick, because it is written in Perl, which makes it lightweight and easily portable between different operating systems. Though by nature designed for the command line, afick also has an optional Webmin module and a graphical interface written in perl-Tk.
For this article we will focus on the command-line implementation on a SUSE Enterprise 8.0 server, but what you see here should be applicable to just about any *nix distribution.
Installation
You can either download and build afick from the source code, or, if you're using a package-based distribution, you can install from an RPM or Debian binary packages. Let's walk through building it from source. To begin, download and unpack the latest version, navigate to the afick directory, and run the following command:
# perl Makefile.plSince you aren't installing the GUI, you can safely ignore any errors about missing perl-Tk modules.
Next, type
make installto install the console tool. When your machine finishes copying all the necessary files, afick will be installed on your system. Installation is only half the battle, though. The real fun lies in the configuration and testing phase.Configuration
Afick begins by creating a database of values representing the current state of your filesystem. When you run it later in update mode, afick compares the current filesystem to the original and notes changes.
The exact attributes of your filesystem that are checked are controlled by a configuration file. Afick provides a default configuration file for both Linux and Windows in the directory where it was originally unpacked. In our case, we are interested in the file linux.conf. You can modify a wealth of options in this file, but we will focus only on the essentials.
Afick provides multiple ways to check every file and directory on your system, so no one configuration file is going to work for everyone. For instance, I am running PHPNuke on a Web server that includes forums, which are going to change constantly as users post items and change their preferences. I don't want those changes dumped into my mailbox every day, possibly burying something important. Someone else with a static Web site, however, might want to see that that content is never changed unexpectedly, and would therefore closely monitor that directory. It takes a bit of trial and error to fine-tune afick (or any other integrity checker for that matter) for your specific needs.
Let's begin by initializing the database with the command:
# afick -c /[path_to_linux.conf]/linux.conf -iThe
-ctells afick where to find the configuration file it should use, while the-iinstructs it to make an initial copy of the filesystem database. This process will take a few minutes. Once it has finished, let your server run for a while, then compare the databases with this slightly different command:
# afick -c /[path_to_linux.conf]/linux.conf -kThe
-kargument tells afick to compare the current filesystem against the database specified in the first line of the linux.conf file, which is the initial database. Any changes will be noted on stdout.Repeat this process a few times until you're getting a feel for what is changing and how so. For instance, if you've got busy log files somewhere outside of /var, they might produce a bundle of changes every time you run afick, which will create white noise around potentially useful data. After you've got a list of repeat offenders, you can tune the linux.conf file.
The linux.conf file actually has a decent description of all the file attributes you can monitor, including device, inode, permissions, owner, last time modified, and several others. You can even create your own rule sets for certain types of files and directories. For instance, you don't want afick reporting warnings about the individual files in /var/log being modified, as these files are going to be modified almost constantly on some systems. To create a rule set that would check the user and group ownership, the device they reside on, and the permissions, you would first add:
#alias
specialrule = u+g+d+pThen, to apply this custom rule to the /var/log directory, you would add the following line to the =/Dir section of the conf file:
/var/log specialruleIf you want to define a rule set that ignores the /tmp directory, checks only the files ending in .backup in /root, and ignores all files in /home/user that end in .old, you would add the following lines to the alias section of the config file.
!/tmp
/root/*.backup special_rule
exclude_re := /home/user/.*\.oldAfick recognizes the standard Unix wild cards and regular expressions in rule sets. With a little bit of tweaking, you can tune afick to completely monitor your filesystem in all the necessary places, while ignoring the spots that would generate useless noise.
After you've spent some time tweaking your configuration file you need to ensure that afick itself cannot be modified. The most secure way to accomplish this is to put the database, found by default at /var/lib/afick/afick.pag, somewhere that is write-only. Unfortunately a diskette isn't an option because of the size of the afick database; my database is roughly 15MB for a 4GB server. I recommend using an Iomega Zip disk for a couple reasons. Primarily, you can switch a Zip disk from read-only to read-write with the flip of a switch. This is convenient because every time you make a change to your filesystem you'll need to update the database to clear the warnings that afick will produce every time it runs thereafter, which could lead to wasting a lot of CDs if you tried to deploy the database on a CD-R.
No matter where you store your database, you still need to tell the configuration file where to find it. Mount your Zip drive (or your CD) and copy /var/lib/afick/afick.pag to your mount point. Then change the entry for the database location in the first section of the config file to represent the path to your removable media.
database=/mnt/zip/afickIn addition to storing the database on read-only media, I also choose to err on the side of paranoia, and I keep my config file on read-only media as well. In this case, it's a diskette that I've write-protected. This doesn't prevent afick from being run with a separate config file created locally on the server, but it does allow me to be sure that no small detail within the file can be changed without someone physically touching my servers.
Automating it
The final step in configuring afick is automating it. (Note that this is not strictly necessary if you wish to run afick only after certain tasks.) The easiest way to automate afick is with the afick.cron script included in the original directory where you unpacked the source code. If you installed via an RPM, then afick.cron was implemented upon your installation, and should be emailing root as changes occur. If you followed the instructions here and installed from source, you have to add it manually. At your command prompt, just type:
crontab -e
0*/2 * * * root /[path_to_afick.cron]/afick.cronThen save and exit the editor. This tells your operating system to run afick once every two hours and mail the results, if any, to root.
Updating it
Every time you make a change to a filesystem, you'll want to update the afick database. Unfortunately, this is a point where security can begin to become an inconvenience. You must physically be at the server to change the Zip disk to read-write mode so the database can be updated.
To initiate update mode, simply replace the
-kin the afick command line with-u. This will update the database to include any changes that have happened since the last time afick was run. Since afick will continue using the new database to ensure file integrity, you should always run afick once in compare mode before updating it, to be sure that the database you are about to create won't report recently compromised system commands or files as legitimate. As a further level of protection, afick has built-in integrity checks it performs on its own executables to ensure that afick itself hasn't been modified.On a short side note, you can also use the update feature of afick to monitor exactly what changes a program's installation procedure makes to a filesystem by using the update feature immediately before and immediately after the installation. This is extremely useful in situations where you cannot verify the authenticity of an application before you install it. Just make sure when you test it with afick that you don't do so on a mission-critical machine. You can also use afick for retroactive testing to ensure uninstalling the software actually returns your filesystem to its previous state.
The future of afick
Afick is a work in progress. In recent conversations, developer Eric Gerbier said he intends to include in future releases a daemon-enabled version that doesn't rely on cron to run afick, thus delivering real-time filesystem monitoring. An option to export afick's results in HTML/XML is in the works for version 3.0, due out sometime in the next few months.
No system will ever be completely safe from malicious users and unauthorized access. If a machine under your control becomes compromised, you must have the proper precautions in place to quickly mitigate the damage and restore services. With a file integrity checker such as afick in place, when that dreaded day comes, you will be prepared to determine exactly what has happened (or is happening) and react accordingly.
In order for afick, or any other file integrity checker, to work as needed, you'll need to take special care in observing the general actions and changes in your filesystem in order to correctly and efficiently craft your configuration rules. Once you've done that, it's just a matter of staying on top of the ever-changing filesystem. Update regularly and update often, so as to catch problems as they begin, and not when it's too late. If you make these practices a regular part of your daily administration routines, you'll be prepared to react efficiently to a breach in security should the need arise.
Brian Warshawsky has built, supported, and administered mission-critical IT infastructure for the United States Naval Research Laboratory, Virginia Commonwealth University, RichmondAir Wireless, and is currently employed by Sungard Collegis at Virginia State University.
Ed Schaefer and John Spurgeon
Verifying the integrity of files is an important systems administration task. Well-known systems administration authority Æleen Frisch says that "minimally, you should periodically check the ownership and permissions of important system files and directories." One method for verifying files is to take a snapshot of the system in a pristine state and compare it against subsequent snapshots.
You can use a product such as Tripwire (http://www.tripwire.com), or create your own such as our Entrap utility. Entrap is a suite of Korn shell scripts that compares two snapshots of a system and reports the differences. When two snapshots are compared, Entrap reports information about files that have been added, deleted, and modified.
An Entrap snapshot includes the file characteristics displayed by the command ls -ild, as well as optional file signatures, such as md5. Filtering rules may be set up to instruct Entrap to ignore specific files and/or attributes when comparing two snapshots.
In this column, we'll explain Entrap's configuration file. We'll discuss the commands used to take a snapshot, filter snapshots, and compare two snapshots. We'll review the directory structure, present an Entrap example, and include a high-level description of the Entrap scripts. We conclude with what's in the tarball and possible Entrap enhancements.
The stated early (10 November 2002) roadmap for that new rpm-4.2 release is to include:
a) file classes (think: sanitized file (1) output in dictionary, per-file index).
b) file color bits (think: 1=elf32, 2=elf64).
c) attaching dependencies to files, so that a refcount is computible.
d) replacing find-{provides,requires} with internal elfutils/file-3.39.
e) install policy based on file color bits
f) --excludeconfig like --excludedocs with the added twist that an internal Provides: will be turned off, exposing a Requires:. This will provide a means to install all %config files from a separate package if/when necessary.
and teaching tripwire to read file MD5's from an rpm database.
rpm-4.2 will be the next release of rpm.
changetrack is a program to monitor changes to files. If files are modified one day, and the machine starts working incorrectly some days later, changetrack can provide information on which files were modified, and help locate the problem. Changetrack will also allow recovery of the files from any stage.
Homepage: http://changetrack.sourceforge.net/
Tar/GZ: http://changetrack.sourceforge.net/change3_16.tar.gz
Debian package: http://packages.debian.org/stable/utils/changetrack.html
Demo site: http://changetrack.sourceforge.net/cgi-bin/changeweb.cgi
From:
aleph1@securityfocus.com
Date: Thu Oct 18 2001 - 12:29:56 PDT
Writing Tripwire Policy Files
Tripwire Policy File Generator 0.62 by Pjotr Prins (http://freshmeat.net/users/pjotrp/) Monday, October 15th 2001 13:11 Categories: System :: Installation/Setup, System :: Logging, System :: Systems Administration About: Tripwire Policy File Generator uses a Perl script - mktrippol.pl - that writes a Tripwire policy file from an existing Linux setup. While it targets ROCK Linux it can really be used for any system. The script reads its commands from a Tripwire policy file 'template' using name expansions. It has a few nice facilities like list expansion, directory walks, variable adding etc. Changes: Support for tripwire installations in /opt/tripwire/sbin/. License: GNU General Public License (GPL) URL: http://freshmeat.net/projects/mktwpol/ -- Elias Levy SecurityFocus http://www.securityfocus.com/ Si vis pacem, para bellum
Sasha Pachev
pluglist@plug.org
Mon, 28 Apr 2003 21:40:31 -0600
Hello, everyone: For those not familiar with Tripwire, it is an intrusion detection tool that tracks unauthorized modification of critical system files. The home site of Tripwire is http://www.tripwire.org I have been setting it up on our company's systems at my new job, and ran into a problem. The default policy file listed so many non-existent files that it would have been very tedious to go through every one of them and comment it out by hand. To my surprise, I could not find a tool that would do this automatically, so I quickly put together a simple perl script to solve the problem: --begin--- #! /usr/bin/perl while (<>) { if ($_ =~ /(\/[\w\-\.\/]+)/ && !($` =~ /#/)) { $_ = "#$_" if (! -e "$1"); } print $_; } --- Input is the default policy source file on STDIN or as first argument, output on stdout is the new policy source file. Some pedants will probably comment that my regexp does not cover every legal character you could possibly find in a file. However, such characters are not found in the default policy file names, so I did not worry about it. Let's hope somebody finds this useful. If you know of an easier solution for this problem, I would like to hear about it. -- Sasha Pachev Create online surveys at http://www.surveypro.com/
dave@nic.comHost Integrity Monitoring Best Practices for Deployment by Brian Wotring
| installwatch 0.5 |
| Installwatch is very useful when you install a new package you've just compiled and want to keep track of changes in your file system. It monitors created and modified files, directories, permissions. It's very fast because it does not need a ``pre-install'' phase and it's not fooled by files added or modified by concurrent installations. It works with dynamically linked ELF programs. |
Claymore 0.2 by Sam Carter, Platforms: Linux
Claymore is an intrusion detection, and integrity monitor system. This release is a little more polished than before, but it still assumes that you know how to setup a crontab file. It is still fully functional, :-). To accomplish it's design goals, it reads in a list of files stored in flat ASCII, and uses md5sum to check their integrity against that recorded earlier in a database. If the database is placed on a read-only medium such as a write-protected floppy, then it should provide an infallible record against remotely installed trojan horses. Thus by monitoring the integrity of the file system, claymore will serve as an aid in intrusion detection.
Download Sentinel for Linux (tar.gz file) - Available [ Sentinel v1.2.1c+ ] [ Sentinel v1.2.1c ] Sentinel is a fast file scanner similar to Tripwire or Viper with built in authentication using the RIPEMD 160 bit MAC hashing function. It uses a single database similar to Tripwire, maintains file integrity using the RIPEMD algorithm and also produces secure, signed logfiles. Its main design goal is to detect intruders modifying files. It also prevents intruders with root/superuser permissions from tampering with its log files and database. Disclaimer: this is not a security toolkit. It is a single purpose file/drive scanning program. Available versions are for linux (tested on all current Slackware and RedHat releases), with Irix versions soon to be added on.The tool can be downloaded from: http://zurk.sourceforge.net/zfile.html
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: June 05, 2008