			gog&magog
		Unix systems integrity monitor
               	        RELEASE 4

0. Disclaimer and License

This package is Public Domain, except GogCipher that should not be used
for commercial purposes (GogCipher is thus free but restricted).
You can use RELEASE 3 commercialy instead.

Gog&Magog is maintained by C.Parisel (cparisel@hotmail.com)

Use and modify at your own risk. 
Please notify me for bug reports and suggestions
Release 3.x can be downloaded from Metalab:
http://metalab.unc.edu/pub/Linux/system/security/
Release 4.x can be downloaded from Multimania:
http://www.multimania.com/cparisel/gog

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 files and libs 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 a similar 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 three major reasons why you may consider monitoring your resources:
 - dispatched administration: for historical or practical reasons, several 
   users have root permission on one or many hosts of your network
 - opened environment: the network is directly connected to the 'outside'; 
   incoming/outgoing messages don't go through a firewall.
 - untrusted intranet: your LAN is well protected from external intruders
but very loose as far as internal access is concerned. (Eg: academic
institution, wide corporate network, basic remote access server, former
employees accounts not systematically closed...)

The first two cases tend to disappear nowadays, so you see most of the time, 
the answer is... no!
Still places under pathological exposure or industries relying on 
mission 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 / Untrusted intranet

  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 will 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&4.3, HP-UX 10&11, Solaris 2.5 
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(see DISCLAIMER in the first section).
If you wish to activate the GogCipher encryption module, you will have to
have an ANSI C compiler ready on your system. This is not a problem with
Linux and AIX, but you may have to play a bit with HP-UX and Solaris.
No matter the platform, GogCipher should work like a charm if
compiled with a decent GNU gcc compiler... :-)

  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 simply:

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, 
  exclude-directory, and private-key.  

  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 
(simple) 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 (guess what?) 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 an unknown 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 that 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. GogCipher

  5.1 What is encryption all about?

  Encryption is a mathematical map between two sets of messages: clear
  messages and ciphered messages. Some encryption mecanisms are not
  reversible (such as the UNIX crypt function which encodes the login
  passwords), others are.
  RSA encryption is a class of algorithms belonging to the later category:
  a clear message M is encoded into a crypted message C thanks to a 
  special code, called a private key (PRV).
  The process can be reversed and you can decode C to get the original
  M provided you are aware of another special code: the public key PUB.
  Anybody on earth who knows PUB can decode any message C encoded with
  the help of PRV.
  The following section gives more technical details about it, so if
  you are bored to death and find me a real headache, just skip to 5.3

  5.2 E=mc2, a.k.a the Einstein corner...

  Here is a BRIEF account of RSA wizardry: that's just a primer, and
  roughly all I know. If you want to slam your head on walls and become
  a cryptoguru, I suggest you get more material at www.rsa.com

  First, take two big primes p and q. The product yields n:

n=p*q

  Then build a function Phi(n)=(p-1)*(q-1) and pick up an integer e
  so that 1<e<Phi(n) and gcd(Phi(n),e)=1
  (e,n) is your private key.
  In order to get the associated public key, take an integer d so that

d=1/e mod Phi(n)

  If you don't like the idea of an integer being equal to 1/e, you can put
  it another way:

d*e=1 mod Phi(n)

  Looks better, eh? Now your public key is (d,n)

  You get the crypted message C from M by applying the following magic rule:

C=M^e mod n

  (Think about M and C in terms of octet streams rather than text files).
  You see that you only need the private key (e,n) as well as M to infer C.
  Reversely, you can decode C to obtain M if you calculate:

M=C^d mod n

  Once again, the knowledge of the public key (d,n) along with C is
  enough to infer M.

  So... WHAT IS THE TRICK?
  Answer: Euler's Theorem. 
  It claims that if gcd(a,n)=1, then a^(Phi(n))=1 mod n
  Don't ask me to prove it... I'm here to do the easy parts, right? :^)

  In our case, if you remember well, we have e*d=1 mod (Phi(n))
  thus some k satisfies e*d=1+k*Phi(n)
  The magic rule says C=M^e mod n, so:

C^d=(M^e)^d mod n
   =M^(e*d) mod n
   =M^(1+k*Phi(n)) mod n
   =M*(M^Phi(n))^k mod n
   =M*1 mod n   (because of the theorem!)
M=C^d mod n

  The cautious reader will rightfully think the proof works only if gcd(M,n)=1 
  as stated by the theorem definition.  Hopefully it can be generalized even 
  when gcd(M,n)>1 by way of another theorem I will not talk about.

  5.3 GogCipher and encryption 

  GogCipher makes full use of the aforementionned principles, also called
  symmetric keys encryption principles. 

    5.3.1 Who needs GogCipher?
    
    My opinion is GogCipher is for the real paranoid! GogCipher is
    great if you are exposed to the next few situations:
      - Eavesdropping
      - Untrusted /tmp
      - Impressing your neighbours(!)
    
    Nowadays most LANs have moved to 10/100/1000 BaseT, so the
    traditional bus topology of the ethernet has been superseded by a
    star topology. As a result, chances that someone may snoop on
    a network have become extremely remote (because star topologies
    allow to send decoys rather than actual packets to everyone except
    the true recipient).
    However, an individual with the ability to sniff gogmagog FTP transfers
    will pick up the password magog is using for its communications.
    As a result, the individual may hack into various gog clients and
    do whatever havoc he deems enjoyable (for his own sake) in /tmp.
    For example, the hacker could write a batch job that overwrites the
    *.chk profile in /tmp in such a nasty way that everything seems OK from
    the central host point of view.
    GogCipher will prevent this, since the private key is kept in the
    root-protected gog configuration file: so even if /tmp (hence *.chk)
    if corrupted, the profiles will be restored sooner or later, and their
    contents will be screened so the hacker won't know how to fake the
    profile. That's where yet-to-be-introduced timestamps play a crucial 
    role: they ensure the profiles are always different. 
    A hacker cannot replay the same file twice, unless he knows the 
    private key. (Timestamps and serial numbers are explained in 
    section 5.3.4)

    5.3.2 GogCipher unleashed

    Unlike the usual bunch of files supplied in GogMagog distributions, 
    you will notice that GogCipher is written in ANSI C: 
    C is way less portable than Perl or the Shell and that is a bit of 
    a pain. However, it is much more rewarding when lots of CPU power is
    involved which is what happens when one starts encrypting stuff around.
    As I said before, the C routines are robust and should give you little
    trouble to compile as long as you run a suitable GNU C compiler.
    Now let's delve into the inner workings of GogCipher!

    5.3.3 Keys generation (Step 1)

    A random set of public and private keys is generated on the central host 
    by typing the simple command:

nephilim:232#magog -key 

    The public key is stored locally in /var/local/integrity/secret, so
    you don't have to do anything.
    You are a little more involved in the handling of the private key, however:
    PRV is the result of the same command (magog -key):

nephilim:233#magog -key
Paste the next line into the config files of the secured gog clients:
private-key:14D50A6A99F39BB48F#D94AF0B075C7CA9A3 
nephilim:234#

    As shown above, you will have to copy the private-key operator into
    my_config.txt (or whatever your gog config file is named) on EVERY single
    host where you want that extra layer of security.
    An important point is that you don't have to enable encryption on all
    your machines. You can select only the most sensitive ones if you want:
    On the central host side, magog will understand whether such and such
    host is 'GogCipher powered' or not. This is quite worth to pinpoint because
    the ciphering transformation is SLOW. You can save a lot of CPU time by
    carefully selecting which host(s) to secure.

    5.3.4 Magog configuration and the handling of serial numbers (Step 2)

    On the central host, you will have to let magog know about your secured
    hosts. To reach this goal, all you have to do is create a file called
    hostname.serial in /var/local/integrity for every host.
    As one could guess, this file contains a serial number which turns out
    to be some sort of timestamp. The format is:

YYYYMMDD

    Every time you do a 'magog -chk my_host' or 'magog -all my_host', the 
    script will check for /var/local/integrity/my_host.serial
    If that file exists, magog will be able to ftp across the crypted
    profile, decode it and check the timestamp.
    The crypted profiles have a an extra line at the beginning which is a
    timestamp in YYYYMMDD format. If the timestamp is newer than the serial 
    number in /var/local/integrity, it means the freshly downloaded profile 
    has been regenerated on the client side within less than 24 hours: 
    as a result, the serial number is updated in my_host.serial host, 
    and all is fine.
    If the downloaded timestamp equals the serial number, then it is matched
    to the current day of the year (DOY). 
    If it is older than the DOY, magog should report the following:

[my_host]: Stale serial number

    You can suspect that something wrong has happened on the client
    machine, because gog has been off over some period of time.
    If it equals the DOY, then it is OK.

    5.3.5 Gog configuration

    Things are quite straightforward: just copy the private key returned
    by 'magog -key' into the gog configuration file.
    If there is no such operator in the config, gog will disable encryption.

6. Running GogView and GogCipher simultaneously

... is NOT recommended! GogView is a simple and fast tool, whereas
GogCipher is complex and slow. Running GogCipher defeats the great
features of GogView. You have been warned!

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