gog&magog
		Unix systems integrity monitor

0. Disclaimer
This package is public domain. It is maintained by C.Parisel
(cparisel@hotmail.com)
Use and modify at your own risk. 
Please notify me for bug reports, suggestions, or if you want
to join the package development.

1. What is systems integrity?
The worst damage a hacker can make to your system is not necessarily
a high profile disruption, like deleting a root partition or corrupting
a database. 
Such strikes may have desastrous short-term consequences,
but when you think about it, today's cheap backup technology allows 
to recover smoothly from the worste situations and bring the servers back 
to normal with relatively small hassle. And once the system is up
again, you can be sure the sysadmin will get the hacker's message
and will go paranoid over security issues: as a result, the cracker
has little chance to break in again, at least using the same technique.
So in the high profile case, the first blow is severe, but there is no
second one...
Now imagine the nasty situation when you have an unsollicited guest
wandering about your network: all the intruder does is look up some
repositories, in search for value-added commercial information... No
harm... that is, no harm to your system. But for your company? 
And you may never know there is someone around!
So how can you get around this?
Even the most cautious hacker cannot live on your servers without leaving
some kind of tracks. I'm not talking about the accouting information
that he can easily overwrite if he has got sufficient privileges. I'm
talking about vital steps the hacker has to do to remain on the system.
Among those steps, an important one is ensuring to keep a valid password.
If you ask your users to change their password frequently, the guy may
decide to add an entry into the password table for himself, or make some
scripts that can grant him more privileges in the future, when he loses
the current password. In any case, how are you going to spot the changes
on your servers? There are so many places a binary, or a table can be
altered or added. This is where systems integrity monitoring becomes
useful: the whole purpose of the stuff is taking the tedious task of
checking off the shoulders of human beings. 
Equally, integrity check plays an important part in environment
requiring multiple superusers (for historical or practical reasons):
this way you can chase up what is being done to the system, before it
gets completely messy!

2. How does it work?
Systems monitoring may be split into two separate tasks: 
  - collecting information
  - analysing information
In the current implementation of gog&magog, each task is performed 
via a specific program: the collecting phase is handled by "gog" (see 2.1),
the analysis is done by "magog" (see 2.2)

  The programs have been designed with the major UNIX flavours in mind: 
AIX, Solaris, SunOS HP-UX and Linux. 
gog has been successfully tested on those platforms, so you shouldn't 
meet any major problem with the installation and usage.
magog has been tested on Linux only. Although magog is written in Bourne-Shell
and should work well on major systems, please report all bugs to 
the package maintainer (see DISCLAIMER section).

  2.1 Collecting information
  On each monitored host, a cron job calls the script 
  /usr/local/bin/magog. The script creates a file named /tmp/hostname.chk
  where all relevant information about the host is stored. What information
  are we talking about? 
    - complete pathname
    - permissions
    - owner name
    - group name
    - a checksum (relying on /usr/bin/cksum)
  of all the files under scrutiny. 

  A typical line taken out of a /tmp/hostname.chk file will look like:

lrwxr--r--:root:sys:/etc/backup:2860616517 4009 /etc/backup
  ^          ^    ^   ^           ^          ^    ^
  |          |    |   |           |          |    |
  |          |    |   |           |          |    +----- checksum 1/3 (name)
  |          |    |   |           |          +----------  " 2/3 (size)
  |          |    |   |           +---------------------  " 3/3 (CRC)
  |          |    |   +--------------------------------- name
  |          |    +------------------------------------- group
  |          +------------------------------------------ owner
  +----------------------------------------------------- permissions

  For directories, CRCs don't make sense, so the format is:

drwxr-xr-x:bin:bin:/etc/acct:

  Sysadmins can make their own list of files to be monitored, and put it
  into a configuration file that may be passed on to the gog command line:

gog ./my_config.txt

  The configuration file is a plain list of instructions. The
  instructions have three parts:
    -an operator
    -a separator ":"
    -a target (full file or directory pathname)
  Supported operators are currently: include-directory, exclude-file 
  and exclude-directory.  Support for OS dependant instructions will 
  be added(?) in the next release.

  Configuration file sample:  ("my_config.txt")
 
exclude-directory:/usr/local/lib 
include-directory:/usr
exclude-file:/etc/utmp
include-directory:/etc

  The order you type the instructions doesn't matter: it is always interpreted
  as "include first, then exclude".

  2.2 Analysing the data
  Once the data has been gathered on each individual host, it has to be
  transferred to the machine in charge of the processing. Let's call it
  the central host. 
  On this machine, a profile has to be set for each host: it contains
  the "valid" image of the system for that host. Profiles are kept in
  /var/local/integrity/hostname.chk
  They are generated by gog on the remote hosts at installation time,
  but the sysadmin will have to copy them over by hand (i.e FTP or equiv)
  to the proper location on the central host.
  Once the profiles are set up, the data analysis tool magog can be applied
  to subsequent udates of the hostname.chk files.
  magog is located on the central host only, in /sbin. It sticks to 
  the following command line:

magog [-all|-ftp|chk] <servers list...>

  <servers list...> is a list of hosts which profiles have been defined
  on the central host (i.e they are stored in /var/local/integrity).
  -ftp open an FTP session to every host in the list in order to get a
    fresh copy of the /tmp/hostname.chk file
    The copies are placed in /tmp, on the central host.
  -chk compare the /tmp files to their original images in 
    /var/local/integrity.
  -all combine -ftp and -diff

  Automated FTPs (options -ftp and -all) require a login name and password
  to enable the FTP connection. If you provide a list of servers rather 
  than a single server on the command line, the account is assumed
  to be the same on all the machines. You are strongly advised to use
  non-root accounts: as a general security rule, root users should not be
  allowed to make direct remote connections (FTP, Telnet, ...)