gog&magog
		Unix systems integrity monitor
		       RELEASE 3

0. Disclaimer

This package is public domain. It is maintained by C.Parisel
(cparisel@hotmail.com)
Check out latest bug fixes and announcements on www.hec.ca/~cparis/gog
Use and modify at your own risk. 
Please notify me for bug reports and suggestions

1. What is systems integrity?

Systems integrity is a way to ensure core ressources are left unaltered
on a given host. By 'core ressources' we mean the key componants of
the operating system (such as configuration files, binaries, libraries, kernel)
as well as third party tools which impact the host operation 
(like home-made batch jobs for instance).
If you notice any dubious file modification on a machine, you will have to 
recover the original file from a tape or any sort of archive medium: 
the monitor will not do that for you, nor will it prevent the
hack from happening again.

2. Yet another fancy tool... Do I really need it?

There are two major reasons why you may consider monitoring system resources:
 - dispatched administration: for historical or practical reasons, several 
   users have root permission on one or many hosts
 - opened environment: the network is directly connected to the 'outside'; 
   incoming/outgoing messages don't go through a firewall.

Both cases tend to disappear nowadays, so you see most of the time, 
the answer is... no!
Still academic organisations, places under pathological exposure or
industries relying on system critical applications may fall into one of
the above categories.

  2.1 Dispatched administration

  In environments that require multiple superusers, systems integrity is
  a good way to chase up what has been done to the system, that is to 
  detect major upgrades/improvements/hazards(!) along with their various
  side-effects.
  Monitoring prevents things from getting out of control up to the point
  where the station becomes unmanageable.
  Particularly messy/non-responsible superusers can be spotted and have
  their permissions adequately undermined...

  2.2 Opened environment

  The worst damage a hacker can do to your system is not necessarily
  caused by a high profile assault like deleting a root partition, corrupting
  a whole database or injecting a nasty virus.
  Such strikes have disastrous short-term consequences for sure,
  but when you think about it today's cheap backup technology allows 
  smooth and speedy recovery, even in the worst situations. 
  Once the system is back to normal, you can bet the sysadmin will
  get the hacker's message and do his best not to fall in the trap again.
  As a result, the cracker has little chance to break in again 
  at least by using the same technique.
  So in the 'high profile' situation, the first blow is severe but, well,
  there should be no second blow...
  Now imagine the dodgy scenario where 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... It 
  doesn't hurt. That is: it doesn't harm your system. But what 
  about your company assets? 
  You may never know there is someone around!
  That's where systems integrity can play a major role: even the most
  cautious alien cannot live on your servers without leaving
  some kind of prints. I'm not talking about the accounting information
  that one can smartly overwrite if one gets sufficient priviledges. I'm
  talking about crucial steps the hacker has to do to remain on the system.
  Among those steps, keeping a valid password is one of the most important.
  If you ask users to change their passwords frequently, the intruder may
  decide to add his own entry into the password table, or make some
  scripts that can grant him special rights in the future, even if he loses
  his current password. Whatever the trick, there are so many places 
  a binary or a table can be altered, it's unlikely anybody will
  ever spot the change. 
  The whole purpose of systems monitoring is lifting the tedious task of
  global checking off the shoulders of human beings. 

3. How it works

Systems monitoring may be broken into two separate tasks: 
  - collecting information
  - analysing information
In the current implementation of gog&magog, each task is performed 
via a dedicated program: the collecting phase is handled by "gog" (see 3.1),
the analysis is performed by "magog" (see 3.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 AIX 4.2, HP-UX 10, Solaris 2.5.1 
and Linux 2.0, 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 great on standard platforms, some bits may not be
fully portable: please report bugs (and fixes if possible :-) ) to the
package maintainer and check the Home Page (see DISCLAIMER in the first 
section) for hot information.

  3.1 Collecting information

  On each monitored host, a cron job calls /usr/local/bin/magog. 
The script creates a file named /tmp/hostname.chk where 
all relevant information about the host is stored. Here are the details: 
    - complete pathname
    - permissions
    - owner name
    - group name
    - a fingerprint (relying on MD5 signature, CRC or a user-supplied utility)

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

lrwxr--r--:root:sys:/etc/backup:ef52c310bb4e4ca5d03e63271bcde3b3            
  ^          ^    ^   ^         ^                                 
  |          |    |   |         |                                 
  |          |    |   |         |                                 
  |          |    |   |         |                                            
  |          |    |   |         +----------------------- MD5 signature
  |          |    |   +--------------------------------- name
  |          |    +------------------------------------- group
  |          +------------------------------------------ owner
  +----------------------------------------------------- permissions

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

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

  Sysadmins make their own list of files and stick it
  to 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.  

  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".

  3.2 Analysing the data

  Data gathered on each individual host have to be transferred to the 
  machine in charge of the processing: let's call it the CENTRAL HOST. 
  The way data is retrieved from the central host doesn't depend on the
  the network design: I mean that we don't assume here the servers use 
  NFS, TFTP, RPC or similar optional services. The package
  rests only on the least common protocol denominator: FTP!
  On the central host, a profile must be set for each machine: it will contain
  the "valid" image of the system for that particular 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 /var/local/integrity on the central host (or use the "configure" utility).
  When the profiles are ready, the data analysis tool (magog) can be applied
  to subsequent hostname.chk updates.
  magog needs only be located on the central host, in /sbin. It has 
  a simple 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 -chk

  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 across 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, ...) 

4. GogView

  GogView is the graphical interface introduced in Release 2. One can
think of it as an extra layer between the end-user and magog. 
Installing GogView is optional but we recommend you do so,
because it is quite straightforward and helpful to manage all your hosts
in a user-friendly fashion. 

GogView is automatically set up for you if you run the configure tool
that comes with the distribution. All you have to do is follow the 
(few) instructions.
The graphical control panels are written in HTML for best portability,
so you will have to set up an HTTP server on the central host if you
want to use GogView. 
There are only two control panels, called conf-panel.html and select-panel.html

  * Configuration panel
    Use this screen to add/remove hosts from the hosts list that GogView
    will manage for you.
    Important notes: 
      1) the hosts MUST have a valid profile in /var/local/integrity
      2) /var/local/integrity/* must have read and execute permissions set

    Simply adding a new host will not create a profile "out of the blue":
    you still have to use gog to get a profile, and copy it across or let
    "magog -ftp" copy the file for you.

  * Selection panel
    This screen displays the hosts list that you built with the previous
    panel. If the list is not empty, enter your login name and password
    in the text fields and click on "Get Map" to bring up a visual status
    report for your hosts:
    - a GREEN monitor means the host is OK
    - a YELLOW monitor means there has been exactly one alteration since
      the original profile was made: drill down the link to get the details
    - a RED monitor means several changes have been made to your host:drill 
      down the link for information 
    - a BLACK monitor means the host is unreachable (it may be down, or you
      have supplied a wrong login information)

You have to be aware though, that GogView is less secure than the
command-line basic mode. This is due to the fact that GogView
handles operations through the HTTP user (usually 'nobody')
rather than the root user.
What's more, the password of the FTP account magog is using is recorded 
in the HTTP log. 
You can always run magog by hand rather than having GogView let the
job, however it can be tedious if you have lots of machines to 
monitor. 

These warnings being said, here are a few tips to make GogView as
secure as possible:
 1) Run GogView on a standalone machine that nobody can access except
yourself. A Linux laptop is ideal.
 2) Tune your access.conf HTTP configuration file so that people can't
use the server remotely.
 3) Bar all TCP/IP services
 4) Review the GogView, cgi-bin and /var/local/integrity files permissions.
 5) Do a chmod 700 on the HTTP log file

5. Looks good! How do I install gogmagog on my network?

  A configure script has been introduced in Release 2; it makes the package
easy to customize. See INSTALL.txt for complete steps.