Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Integrity Checking Bulletin, 2003

slipwire.pl

slipwire.pl is a simple filesystem integrity checker implemented in perl. It compares the SHA-1 hashes of files to an initial state and alerts the user of any changes. slipwire also records extensive file information such as inode number, last-modified time, filesize, uid, gid, etc, and can also report changes in any of these.

www.demon.de - Nabou

Nabou is a system integrity monitor. That means, it runs every night and watches for changes on files. If a file has changed in any way, it will inform you by email(if you prefer that). Beside of this it can also look for changed or added user accounts, cronjobs, weird processes and suid files. And you can define your own checks using inline scriptlets.

It stores the properties for each file in a dbm database and will warn you if something has been changed on a file. The most important thing to check for, is the MD5-checksum. This checksum will never be the same if the file content has changed even if only one letter has changed. But you can also look for some other properties, like ownership or filemode. See the section configuration for more details on that!

You can use nabou as an Intrusion Detection System or simply as a system monitor.

Beside filesystem integrity you can use nabou as process monitor as well, in this special mode it can run as a daemon in the background and inform you if it finds a weird process. Take a look at the sample process monitoring config.

Nabou can also monitor crontab entries, UID 0 user accounts, User accounts and Listening TCP/UDP ports.

nabou requires perl and some Perl Modules.

If you are interested, here is a sample report generated by a nabou check run.

freshmeat.net Project details for Integrity Checking Utility -- Perl

ICU (Integrity Checking Utility) is a Perl program used for executing AIDE filesystem integrity checks on remote hosts from an ICU server and sending reports via email. Remote sessions are initiated via ssh.

fcheck is GPL licensed perl code written by Michael A. Gumienny.

It's source can be downloaded from various sites (debian)

The current version is 2.7.59

Description: IDS filesystem baseline integrity checker. The fcheck utility is an IDS (Intrusion Detection System) which can be used to monitor changes to any given filesystem.
.
Essentially, fcheck has the ability to monitor directories, files or complete filesystems for any additions, deletions, and modifications. It is configurable to exclude active log files, and can be ran as often as needed from the command line or cron making it extremely difficult to circumvent.

Paranoid Penguin Verifying Filesystem Integrity with CVS by Michael Rash

...CVS is a tool used primarily by software developers to help organize and provide a version structure to a set of source code. One of its most useful features is the ability to keep track of all changes in a piece of source code (or ordinary text) over time, starting from when the code initially was checked into the CVS repository. When a developer wishes to make changes, the code is checked out of the repository, modifications are made and the resulting code is committed back into the repository. CVS automatically increments the version number and keeps track of the changes. After modifications have been committed to the repository, it is possible to see exactly what was changed in the new version relative to the previous (or any other) version by using the cvs diff command.

Now that we have a basic understanding of the steps used to administer Tripwire for a system, we will show how CVS can be leveraged in much the same way, with one important enhancement: difference tracking for plain-text configuration files. If one of your machines is cracked, and a user is added to the /etc/passwd file, Tripwire can report the fact that any number of file attributes have changed, such as the mtime or one-way hash signature, but it cannot tell you exactly which user was added.

A significant problem for intrusion detection in general is that the number of false positives generated tends to be very high, and host-based intrusion-detection systems (HBIDS) are not exempt to this phenomenon. Depending on the number of systems involved, and hence the resulting complexity, false positives can be generated so frequently that the data generated by HBIDS may become overwhelming for administrators to handle. Thus, in the example of a user being added to the /etc/passwd file, if the HBIDS could report exactly which user was added, it would help to determine whether the addition was part of a legitimate system administration action or something else. This could save hours of time since once it has been determined that a system has been compromised, the only way to guarantee returning the system to its normal state is to re-install the entire operating system from scratch.

Collecting the Data

In keeping with the Tripwire methodology of storing the initial filesystem snapshot on media separate from the system being monitored, we need a way to collect data from remote systems and archive it within a local CVS repository. To accomplish this, we set up a dedicated CVS ``collector box'' within our network. All filesystem monitoring functions will be executed by a single user from this machine. Monitoring functions include the collecting of raw data, synchronizing the data with the CVS repository and sending alerts if unauthorized changes are found. We will utilize the ssh protocol as the network communication vehicle to collect data from the remote machines. To make things easier we put our HBIDS user's RSA key into root's authorized_keys file on each of the target systems. This allows the HBIDS user to execute commands as root on any target system without having to supply a password via ssh. Now that we have a general idea for the architecture of the collector box, we can begin collecting the data.

We need to collect two classes of data from remote systems: ASCII configuration files and the output of commands. Collecting the output of commands is generally a broader category than collecting files because we probably are not going to want to replicate all remote filesystems in their entirety. Commands that produce important monitoring output include md5sum (generates md5 signatures for files) and find / -type f -perm +6000 (finds all files that have the uid and gid bits set in their permissions). In Listings 1 and 2, we illustrate Perl code that collects data from remote systems and monitors changes to this data over time.

Listing 1. collector.pl

In Listing 1, we have a piece of Perl code that makes use of the Net::SSH::Perl module to collect three sets of data from the host whose address is 192.168.10.5, md5 hash signatures of a few important system binaries, a tar archive of a few OS configuration files and a listing of all files that have the uid and/or gid permission bits set. Lines 7 and 8 define the IP address of the target machine as well as the remote user that collector.pl will log in to. Recall that we have the local user's preshared key on the remote machine, so we will not have to supply a password to log in. Lines 10-13 define a small sample list of system binaries for which md5 hash signatures will be calculated, and similarly, lines 15-18 define a list of files that will be archived locally from the remote system. Lines 20-24 build a small hash to link a local filename to the command that will be executed on the remote system, and the output of each command will be stored locally within this file. Lines 27-33 comprise the meat of the collection code and call the run_command() subroutine (lines 36-49) for each command in the %Cmds hash. Each execution of run_command() will create a new Net::SSH::Perl object that will be used to open an ssh session to the remote host, log in and execute the command that was passed to the subroutine.

Listing 2. cvschecker.pl

In Listing 2, we illustrate a piece of Perl code that is responsible for generating e-mail alerts if any of the files collected by collector.pl change. This is accomplished first by checking the current 192.168.10.5 module out of the CVS repository (line 12), executing collector.pl (line 14) to install fresh copies of the remote command output and files within the local directory structure, and then committing each (possibly modified) file back into the repository (line 20). By checking the return value of the cvs commit command for each file (line 20), we can determine if changes have been made to the file, as cvs automatically increments the file's version number and keeps track of exactly what has changed. If a change is detected in a particular file, cvschecker.pl calculates the previous version number (lines 27-36), executes the cvs diff command against the previous revision to get the changes (lines 39-40) and e-mails the contents of the change (lines 47-48) to the e-mail address defined in line

Detecting Intrusions

Now let's put the collector.pl and cvschecker.pl scripts into action with a couple of intrusion examples. Assume the target system is a Red Hat 6.2 machine; HIBDS data has been collected from this machine before any external network connection was established, and the target has an IP address of 192.168.10.5.

Example 1

Suppose machine 192.168.10.5 is cracked, and the following command is executed as root:

# cp /bin/sh /dev/... && chmod 4755 /dev/...

This will copy the /bin/sh shell to the /dev/ directory as the file ``...'' and will set the uid bit. Because the file is owned by root, and we made it executable by any user on the system, the attacker only needs to know the path /dev/... to execute any command as root. Obviously, we would like to know if something like this has happened on the 192.168.10.5 system. Now, on the collector box, we execute cvschecker.pl, and the following e-mail is sent to root@localhost, which clearly shows /dev/... as a new suid file:

From: hbids@localhost
Subject: Changed file on 192.168.10.5: suidfiles
To: root@localhost
Date: Sat, 10 Nov 2001 17:35:13 -0500 (EST)

Index: /home/mbr/192.168.10.5/suidfiles
=======================================================
RCS file: /usr/local/hbids_cvs/192.168.10.5/suidfiles,v
retrieving revision 1.3
retrieving revision 1.4
diff -r1.3 -r1.4
4a5
> -rwsr-xr-x 1 root root 512668 Nov 10 18:40 /dev/...

Example 2

Now suppose an attacker is able to execute the following two commands as root:

# echo "eviluser:x:0:0::/:/bin/bash" >> /etc/passwd
# echo "eviluser::11636:0:99999:7:::" >> /etc/shadow

Note that the uid and gid for eviluser are set to 0 and 0 in the /etc/passwd entry, and also that there is no encrypted password string in the /etc/shadow entry. Hence, any user on the system could become root without supplying a password simply by typing su - eviluser. As in the previous example, after running cvschecker.pl, we receive the following e-mails in root's mailbox:

From: hbids@localhost
Subject: Changed file on 192.168.10.5: /etc/passwd
Delivered-To: root@localhost
Date: Sat, 10 Nov 2001 17:43:17 -0500 (EST)

Index: /home/mbr/192.168.10.5/etc/passwd
=======================================================
RCS file: /usr/local/hbids_cvs/192.168.10.5/etc/passwd,v
retrieving revision 1.2
retrieving revision 1.3
diff -r1.2 -r1.3
26a27
> eviluser:x:0:0::/:/bin/bash

and

From: hbids@localhost
Subject: Changed file on 192.168.10.5: /etc/shadow
Delivered-To: root@localhost
Date: Sat, 10 Nov 2001 17:43:18 -0500 (EST)

Index: /home/mbr/192.168.10.5/etc/shadow
=======================================================
RCS file: /usr/local/hbids_cvs/192.168.10.5/etc/shadow,v
retrieving revision 1.2
retrieving revision 1.3
diff -r1.2 -r1.3
26a27
> eviluser::11636:0:99999:7:::

Conclusion

Finding changes in the filesystem can be an effective method for detecting intruders. In this article we have illustrated some simple Perl code that bends CVS into a homegrown, host-based intrusion-detection system. At my current place of employment, USinternetworking, Inc., a large ASP in Annapolis, Maryland, we use a similar (although greatly expanded) custom system called USiOasis to help verify filesystem integrity across several hundred machines in our network infrastructure. The machines are loaded with various operating systems that include Linux, HPUX, Solaris and Windows, and run many different types of server applications. The system includes a MySQL database back end, a rather large CVS repository and a custom web/CGI front end written mostly in Perl. Making use of a CVS repository to perform difference tracking also comes with an important additional benefit: an excellent visualization tool written in Python called ViewCVS. Storing operating system and application configuration files within CVS also aids several areas outside of detecting intrusions, such as troubleshooting network and application-level outages, disaster recovery and tracking system configurations over time.

samhain labs - samhain

The samhain file integrity / intrusion detection system

Executive summary

samhain is an open source file integrity and host-based intrusion detection system for Linux and Unix. It can run as a daemon process, and and thus can remember file changes - contrary to a tool that runs from cron, if a file is modified you will get only one report, while subsequent checks of that file will ignore the modification as it is already reported (unless the file is modified again).

samhain can optionally be used as client/server system to provide centralized monitoring for multiple host. Logging to a (MySQL or PostgreSQL) database is supported.

Features

Platforms

samhain has been tested on Linux, FreeBSD, AIX 4.x, HP-UX 10.20, Unixware 7.1.0, Solaris 2.6, 2.8, and Alpha/True64. We have reports on smooth installation on OpenBSD and HP-UX 11 systems as well. samhain builds cleanly on Mac OS X, but is not tested by us on this platform. If you have a platform that is more or less POSIX-compliant but is not listed here, we may help you to get samhain running. Just send a mail to [email protected] or use our contact form.

samhain is reported to build and run on Windows 2000 in the Cygwin environment (Cygwin is a free POSIX emulation for Windows). However, please note that Cygwin "uses shared memory areas to store information on Cygwin processes. Because these areas are not protected in any way, in principle a malicious user could modify them to cause unexpected behaviour in Cygwin processes" (from the Cygwin User Guide).

O'Reilly Network Understanding Rootkits [Dec. 14, 2001]

[TL-Security-Announce] TLSA2001017 Adore Worm Advisory

The four security flaws sought out by the Adore worm are:

a. wu-ftpd: Buffer overrun; due to improper bounds checking, SITE EXEC may
enable remote root execution, without having any local user account
required.

b. nfs-utils: Flaw in the rpc.statd daemon can lead to remote root break in.
Please note that the nfs-utils package will replace the
packages knfsd and knfsd-client. The package knfsd-client
contains the rpc.statd daemon.

c. LPRng: Vulnerability due to incorrect usage of the syslog() function.
Local and remote users can send string-formatting operators to the print-
er daemon to corrupt the daemon's execution, potentially gaining root
access.

d. bind: Buffer overflow in transaction signature (TSIG) handling code.
This vulnerability may allow an attacker to execute code with the same
privileges as the BIND server. Because BIND is typically run by a
superuser account, the execution would occur with superuser privileges.

SANS Global Incident Analysis Center Adore Worm

Adore worm replaces only one system binary (ps), with a trojaned version and moves the original to /usr/bin/adore. It installs the files in /usr/lib/lib. It then sends an email to the following addresses: [email protected], [email protected], [email protected], [email protected]
Attempts have been made to get these addresses taken offline, but no response so far from the provider. It attempts to send the following information:

  • /etc/ftpusers
  • ifconfig
  • ps -aux (using the original binary in /usr/bin/adore)
  • /root/.bash_history
  • /etc/hosts
  • /etc/shadow

Adore then runs a package called icmp. With the options provided with the tarball, it by default sets the port to listen too, and the packet length to watch for. When it sees this information it then sets a rootshell to allow connections. It also sets up a cronjob in cron daily (which runs at 04:02 am local time) to run and remove all traces of its existence and then reboots your system. However, it does not remove the backdoor.

New worm targets unprotected Linux systems, 04-05-01

At risk, SANS said, are Linux systems that haven't been protected against vulnerabilities known as rpc-statd, wu-ftpd, LPRng and the Berkeley Internet Name Domain (BIND) software. LPRng is installed by default on servers running Red Hat 7.0, according to SANS, while BIND refers to a series of holes in the Redwood City, Calif.-based Internet Software Consortium's BIND server software.

All of those vulnerabilities are well-known and can be blocked by readily available patches. But Adore and other worms like it can easily find exposed systems because IT managers frequently don't have time to install every security patch and bug fix that's released, said Eric Hemmendinger, an analyst at Aberdeen Group Inc. in Boston.

F-Secure Computer Virus Information Pages Adore

Adore is a worm, that spreads in Linux systems using four diffrent, known vulnerabilities already used by Ramen and Lion worms. These vulnerabilities concern BIND named, wu-ftpd, rpc.statd and lpd services.

When Adore is running, it scans for vulnerable hosts from random Class B subnets on the network. If vulnerable host is found, attempts to download the main worm part from a web server located in China, in a similar way that Lion worm does.

After the worm has been downloaded to the victim machine, it is stored in to "/usr/local/bin/lib/" directory and "start.sh" is executed launching the worm.

At the start, "start.sh" replaces "/bin/ps" with trojanized version that does not show processes that are part of the worm. The original "/bin/ps" command is copied "/usr/bin/anacron".

The script also replaces "/sbin/klogd" with a version that has a backdoor. The backdoor activates when it receives a ping packet with correct size, and opens a shell in the port 65535. Orginal "klogd" will be saved to "/usr/lib/klogd.o".

The worm sends sensitive system data, including contents of the "/etc/shadow" file to four different email addresses.

Adore also creates a script file "/etc/cron.daily/0anacron". This file will be executed by the cron daemon with the next daily run. At this time, the worm will remove itself from the system and restore the original "/bin/ps". All worm related processes except the backdoor will be shut down, and the system will be restarted if "/sbin/shutdown" exists. The backdoor will start after the system has been restarted as the "/sbin/klogd" still contains the backdoor.


All four vulnerabilities have been already fixed by different Linux vendors. Further information is available at:

Debian GNU/Linux: http://www.debian.org/security/

Linux Mandrake: http://www.linux-mandrake.com/en/security/

SuSE: http://www.suse.com/en/support/security/index.html

RedHat Linux: http://www.redhat.com/support/errata/


F-Secure Anti-Virus detects the Adore worm with the current updates.

[Analysis: Sami Rautiainen, F-Secure; April 2001]

chkrootkit -- locally checks for signs of a rootkit

ID FAQ - Analysis of N.F.O hacking- - rootkit

The detection of this intrusion was fairly easy but it shows that a skilled administrator knows what's happening on his machine. The Administrator found a application named "bnc" running as uid=0 (root) and he simply did "find / -name *bnc*" and found that secret directory I mentioned before. He noticed that he had been compromised and handled it very well.

Linux Magazine October 2000 FEATURES System Security

Integrity Checking

So all this process accounting and system auditing is fine, but how do you know that there's not something really sneaky going on? For example, how do you know that the new programs you are installing are not secretly e-mailing sensitive information to some system cracker somewhere? Or, how can you tell if someone has broken into your system and quietly replaced a key system binary, such as the login program, with a "special" version of that program that records your username and password and forwards the information along to someone else?

The answer to these questions is that you need to be able to verify the integrity of your key system files. There are a number of tools available that can do this. When it comes to installing new software, many Linux distributions use the RPM (Red Hat Package Manager) system for their package management. RPM comes with integrity-checking built in. Every package has a unique "checksum" that the package manager can verify in order to determine whether a package has been modified or not. See the man page on rpm for more details.

Another utility that is very useful for verifying the integrity of key system files is the md5sum command. md5sum can be used to create a "fingerprint" of a file. The fingerprint is strongly dependent upon the contents of the file to which md5sum is applied. Any changes to the file will result in a completely different fingerprint. md5sum is commonly used to verify the integrity of package updates that are distributed by a vendor. For example, a typical RPM package update could look something like the following:

f380646e78a1f463c2d2cc855d3ccb2b package-2.2.1-1.i386.rpm.

The md5sum-generated fingerprint belonging to the file package-2.2.1-1.i386.rpm is the 128-bit number printed above (f380646e78a1f463c2d2cc855d3ccb2b). The fingerprint can be used to correlate the integrity of the updated package before it is installed. To verify this file's integrity, you would type:

[dave@magneto ~]$ md5sum package-2.2.1-1.i386.rpm.
f380646e78a1f463c2d2cc855d3ccb2b package-2.2.1-1.i386.rpm.

Running the md5sum command on the file package-2.2.1- 1.i386.rpm produces output indicating that the fingerprints match. This means that the file has not been tampered with. Keep in mind that this method doesn't take into account the possibility that the same person who may have modified a particular package might have also modified the fingerprint.

Another very useful program for verifying the integrity of a number of important system files is named tripwire. Tripwire looks at a number of checksums based on all of your important system binaries and configuration files and compares them against a database of former, known-to-be-valid checksum values for a reference. Thus, changes in any of the files will be flagged.

Setting up and configuring tripwire is not terribly difficult. However, managing tripwire requires daily monitoring of the checksum database and coordination with other users on the system to make sure that authorized changes to configuration files are properly accounted for, while unauthorized changes will be flagged.

It is also a good idea to make a copy of critical system files and store them on removable media to be used as a form of integrity checking. Programs such as /bin/ps and /sbin/ifconfig should always be readily available.

SuSE Security mailinglist checking rpm integrity

Date: Fri, 07 Apr 2000 16:56:20 +1200 (NZST)
From: Volker Kuhlmann <[email protected]>
Message-id: <[email protected]>
Subject: checking rpm integrity

Stupid question: when I download an updated rpm for SuSE, how do I check
whether it's realy come from SuSE???

There is md5sum - but arrrrrrrrgggggggggg it's tedious!!!

Copy the relevant lines out of the SuSE advisory into a new file, edit
out the "ftp://..." part at the front, save, run md5sum -c.
That can't be it, can it?

It does not seem to be a very reliable way to go. I find that

> md5sum -c ~/t/m
update/6.4/kpa1/kreatecd-0.3.8b-0.i386.rpm: FAILED

from

09cbe9a08cf2b0d5d5d0b1963c3edbcd ftp://ftp.suse.com/pub/suse/i386/update/6.4/kpa1/kreatecd-0.3.8b-0.i386.rpm

> md5sum update/6.4/kpa1/kreatecd-0.3.8b-0.i386.rpm
ec64fd1187373f48c02922eb71ae2f7a update/6.4/kpa1/kreatecd-0.3.8b-0.i386.rpm

I know SuSE has published bogus md5 sums before. Has it happen
again? Seems like it. See:
ec64fd1187373f48c02922eb71ae2f7a ftp://ftp.suse.com/pub/suse/i386/update/6.3/ap1/gpm-1.18.1-45.i386.rpm

out of the gpm advisory.

<HERESY>
When I was still using Red Hat, the whole job for any number of downloaded
rpms was done with "rpm -Kv *.rpm".
</HERESY>

Question: why does SuSE not pgp/gpg sign their rpms? It would be much
more user-friendly as well as less error-prone. Or does it take that
much more effort to organise on SuSE's part?

(This is what I was meaning to gripe about for a while :-( )

Volker

Re [Re Security Thread Revival] integrity checking

Re: [Re: Security Thread Revival] integrity checking



Chuck Moss <[email protected]> wrote:
> Yeah I use tripwire a lot now.

> Doesn't help with an audit after the fact.

Sure it does! You can know exactly what was changed.

> What I am thinking about is some kind of rescue floppy/CD that has a
> database of chksums or something like that.  Maybe I can pull them out of
> the original RPMS and build a table or something.

> The trick is to build a good database and have a controlled clean
> independent boot.

Right. If your box is thoroughly cracked, you can't trust the scheduled
tripwire runs. A tripwire/AIDE/etc. cron job is better than nothing, but far
from perfect.

> Anybody done this yet?

Few things:

A rescue CD + floppy is tough, as you can't hold much data on a floppy. Jay
Beale wrote an article on using Tripwire, and setting up a second config for a
smaller, floppy-based database:
http://securityportal.com/topnews/tripwire20000711.html

[I've had better luck with floppy tripwire databases for Solaris, but I expect
that's because Solaris includes so little software. ;-)]

A better option would be having a Zip/LS-120 or both a CD and a CD-R[W] drive,
so you could boot off the CD and use the Zip/LS-120/CD-R[W] to hold a full
integrity-checking database.

RPM verification: Sweth Chandramouli (a DC-area open systems guru) put
together a Perl script that uses RPM's --verify option to check package
integrity. There were a few things I wanted to add, but didn't. :-( If you
rely heavily|exclusively on RPM packages, this is a great way to check things
out if you failed to set up a tripwire/AIDE/etc. database. Not perfect, as 1)
your configuration files are sure to change from the standard package, and
this can't discern your changes from an attacker's changes 2) obviously does
no good for non-RPM software 3) wouldn't catch the addition of new software
that didn't conflict with RPMs, e.g. SUID root shells. Sweth's script should
be on the Bastille-linux-discuss archives,
http://lists.sourceforge.net/mailman/listinfo/bastille-linux-discuss, but I'm
having trouble reaching that site at the moment.

AIDE is a tripwire-like app that is truly Free Software:
http://www.cs.tut.fi/~rammer/aide.html

Two things about AIDE bug me:
 - configuration doesn't seem as flexible as Tripwire, e.g.
   having it check /foo but not /foo/bar or anything under /foo/bar
 - it doesn't monitor directory stat() info, e.g. an attacker could
   chmod a+w /etc and AIDE wouldn't catch it

-Peter

[Jan 25, 2002] BSI Software Toby (Perl alternative to Tripwire) v. 1.1 was released on 6-Dec-2001 A major rewrite of the internal code, and fixes for a few minor bugs.

Toby is another reimplementation of the ever-useful tripwire program. The original tripwire-1.3 is available for free, but ran a bit slow in my test comparisons. Also, newer versions of tripwire are not free for commercial users (no longer true!), but include much cooler crytographic signatures and such. My feeling was that it it would be nice to have a GPL version of tripwire to use with some of my clients.

The first major difference from tripwire is that toby is written in perl. Cryptographic modules from CPAN are used, hopefully ensuring that as better algorithms are found for some routines (eg, MD5) then toby will inherit those improvements.

Currently, there are a few deficiencies in the program. There is no -loosedir option, so directories are strictly checked in the same way as files. Also, the configuration file is really just a perl

[Jan 25, 2002] A new version of The Solaris[tm] Fingerprint Database (1.2) Download: sfpc-1.2.tar.Z and sidekick.sh.Z

For the use of The Solaris[tm] Fingerprint Database - A Security Tool for the Solaris Operating Environment Files
sfpc-1.2.tar.Z - The Solaris[tm] Fingerprint Database Companion (sfpC) is a tool designed to automate the process of querying the Solaris Fingerprint Database (sfpDB).
sidekick.sh.Z - SideKick is a tool developed to automate the collection of MD5 files signatures.

FCheck by Michael A. Gumienny. http://sites.netscape.net/fcheck/ This is an integrity checker written in Perl.

FCheck v2.07.59 provides intrusion detection and policy enforcement through the use of comparative system snapshots. Similar to Tripwire but less cumbersome to operate, FCheck can provide notification of any differences found through use of an event management system, printer, and/or email when any monitored system files or directories are modified, including any additions and/or deletions. Tested on AIX, BSD, HP/UX, Linux, SCO, Solaris, SunOS, and Windows95/98/NT/3.x systems all running PERL 4.0.x or better.

Sun BluePrints OnLine - Articles May 2001

Verifying whether system executables, configuration files, and startup scripts have been modified by a user has always been a difficult task. Security tools attempting to address this issue have been around for many years. These tools typically generate cryptographic checksums of files when a system is first installed.

The Solaris Fingerprint Database (sfpDB) is a free SunSolve Online[sm] service that enables users to verify the integrity of files distributed with the Solaris[tm] Operating Environment (Solaris OE). Examples of these files include the /bin/su executable file, Solaris OE patches, and unbundled products such as Sun Forte[tm] Developer Tools. The list of checksums, generated for a system, must be updated after the system is modified by patch installation and software installations. The issue with these tools has always been verifying that the files used to generate the baseline checksums are correct and current.

The Solaris Fingerprint Database addresses the issue of validating the base Sun provided files. This includes files distributed with Solaris OE media kits, unbundled software, and patches. The sfpDB provides a mechanism to verify that a true file in an official binary distribution is being used, and not an altered version that compromises system security and causes other problems.

rkdet - rootkit detector for Linux

This program is a daemon intended to catch someone installing a rootkit or running a packet sniffer. It is designed to run continually with a small footprint under an innocuous name. When triggered, it sends email, appends to a logfile, and disables networking or halts the system. it is designed to install with the minimum of disruption to a normal multiuser system, and should not require rebuilding with each kernel change or system upgrade.

Re:Some Advice. (Score:2, Insightful)
by dennisp ([email protected]) on Tuesday September 28, @02:09PM EDT (#48)
(User Info)
Actually, I use a slightly modified version of AIDE. It has the same feature set as tripwire as well as a couple of other features. Search on freshmeat with the keyword 'tripwire' and you'll get many similar utilities.

As well as that, I run a tty watching daemon that monitors user commands and pages me and mails a message if someone tries something especially stupid. I also have the regular userland jailed to prevent regular users from doing something stupid as well.

Another tip for the real sysadm nazi is to mount the filesystem with system commands as read only so that idgits can't install their handy rootkit that prevents you noticing what they are doing.

As well as that, you could also set it up to log certain breaking attempts and to automatically send mail to the set arin administrator of that ip range. That sometimes works and is satisfying when I get a reply back stating that the user doing such a thing was deleted (though you'll never get a response if it is a large ISP and doesn't care at all [see uunet dialup users and no responses for repeated spammers and breakin attempts]).
----------
DISCLAIMER: Opinions subject to change if realized idiotic. Therefore flames are not appreciated.



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created: May 16, 1997; Last modified: September 12, 2017