$Id: README,v 1.8 2001/03/07 02:09:45 tom Exp tom $
 
README for nabou
===================================



Introduction
------------

This is the script called "nabou". Parts of it
are based on another script called "thor.pl" by
Jerry Kilpatrick <jerry@linuxscripts.com>, which
itself is based on a program called sysmon.pl which
was written by a guy named Matthew George
<emoc@vortex.misterweb.com>.

I used thor.pl on several servers but realized
many bugs and found many things, that could be
solved much better. Since the app-record of thor.pl
on freshmeat does no more exist and the Homepage of
thor.pl does also no more exist(the domain still exists,
but there is a 'cking win2k site oberthere...), I
decided to take over maintenance of the script,
give it another name and enhance/debug it myself.
The result is nabou. If you are wondering about its
name - did you ever see episode I ? If you did, you
should know ... but it's nothing meaningful, just to
have a good name ;-)

Nabou is a system integrity checker. 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.



Installation
------------

Installation is really simple, just unpack the tarball,
which you have already done if you are reading this file.
Copy the file "nabou" to somewhere, i.e. "/root/bin"
and change its permissions. I suggest the following mode:
rwx------ root  root  nabou.

You will need an additional perl module which is available
from your local CPAN dealer. But just in case, you don't know
how to find one, here is a download link: 
  http://search.cpan.org/search?dist=Config-General  :-)

BTW. this module was written by me, and in fact, it is based on
code in nabou, but it evloved and became larger and larger, so
I decided some day to release it separately. Read the included README
for installation instructions.

If you have an ext2 filesystem you might also protect
it using chattr: "chattr +i nabou", this makes it
immutable(read only). 
For the paranoid: protect it with LIDS (http://www.lids.org):
lidsadm -A -o /root/bin/nabou -j READ

Copy the provided sample-configuration to a convenient
place, i.e. "/root/.nabourc" and edit this file (read
more on  configuration later in this README).

Create a new directory, where nabou can store it's
databases, i.e. "/var/log/sysdb" and chmod it:
"chmod 700 sysdb". If you run nabou and the database dir
does not exist then nabou will try to create it for you.

Nabou reguires the following perl module to be installed
which is not part of the standard perl installation:
Digest::MD5. You can find it on every CPAN mirror. The
latest package can be found on:
 http://www.perl.com/CPAN/authors/id/GAAS/Digest-MD5-2.09.tar.gz
It contains also the modules Digest::SHA1 and Digest::MD2,
which you can optionally use instead of MD5. See the
description of the config option "use_algo" below.

If you want to use the database-protection mode of nabou, then
must have also the following modules installed: Crypt::CBC,
Crypt::DES (or IDEA, Blowfish or Twofish). These are required
for database-record encryption, which itself will be used for
verification of database-integrity.(see the "Security" note
in the "Usage" section later in this README).

That's all about installation :-)




Configuration
-------------

Nabou uses a config file format similar to the well
known apache-configuration format. Lines starting with
a "#" and empty lines will be ignored. Additional, you
can place a comment after an option, i.e.:
	useshadow	1 # we are using shadow support
You can comment out large blocks using a C-style comment:
/*
passwd  /etc/passwd
shadow  /etc/shadow
shells  /etc/shells
*/

The configuration is devided into several sections. There
are some main-options and some blocks for a special purpose.
Most of the options are simply switches, where a value of
"1" turns it on and "0" turns it off. If you omit an option
then this has the same effect as setting it to 0 (zero).

You can omit an option if nabou provides a buildin default
value, which described for every option.

The main options:

useshadow	1 turns shadow support on, 0 turns it off,
		which is the default.

usemail		A value of 1 causes nabou to mail the report
		to someone (specified within the mail block,
		see below).
		A value of 0 causes nabou to print the report
		to STDOUT, which is the default.

use_algo	you may specify another hash-algorithm than
		the default MD5. Possible values are MD2, SHA1
		and MD5.

use_ls		this option causes an additional line being
		printed in reports, which contains a "ls -l"
		like output for that file. 1 turns this option
		on.


passwd		specifies the location of the file passwd,
		this option is required. The standard place
		is /etc/passwd.
shadow		specifies the location of the file shadow (or
		master.passwd on BSD), it is required if
		useshadow is turned on.
shells		specifies the location of the shells file,
		which contains a list of all valid shells,
		it is required if you use the suid-check. nabou
		will compare the checksum of every shell with
		any suid/sgid file found to find out if it is
		a suid-root shell.
	

check_cron	check for changes in user crontabs.
check_user	check for changed/new/removed useraccounts.
check_root	check for uid/gid root accounts.
check_suid	check for changes/addition/removal of suid/sgid
		files. This check will be performed over the
		whole filesystem but not /proc! Look for the <suid>
		blockoptions below too!
check_md5	outdated, compatibility option for older configs.
		see "check_files" below.
check_files	check for changes of files. nabou can check for
		several attributes of a file, not only the md5
		checksum. See directory block options below.
check_diskusage check for increased or decreased amount of bytes
		used on hardisk by a directory. You can define
		minimum and maximum boundaries on a per-directory
		basis(see below).
check_nabou     0 turns off, 1 turns on, which is the default.
		This option can turn off the default behavior
		of nabou to check it's own database integrity.
		This is only recommended for process monitoring
		and only if you are running a nabou instance, which
		does not do anything other than proc-monitoring!
check_proc	monitor and report weird processes. This option is
		only really usefull for an extra instance of nabou
		for this purpose. Read more about proc-monitoring
	        in the Config and Usage sections.

The database block options:

The db block starts with "<db>" and ends with "</db>".
An example:
<db>
        basedir          /home/thomas/nabou/db
	protected	 1
	cipher		 IDEA
        pwdDB            thorpwd
        sugidDB          thorsugid
        csumDB           thorcsum
        cronDB           thorcron
        miscDB           thormisc
	diskusageDB      thordu
</db>

The following attributes must exist:
basedir		define the base directory which contains
		the databases. Do not use a trailing slash.
pwdDB		the user account database.
sugidDB		the suid/sgid database.
csumDB		the checksum/file-attributes database.
cronDB		the crontab database.
miscDB		this database contains checksums of nabou
		itself and some internals.
diskusageDB     this will only be used if check_diskusage is
		turned on. it contains byte summaries of each
		monitored directory.
protected       boolean value, 1 turns it on, 0 turns it off, which
		is the default. If turned on, nabou will ask you
		for a passphrase if you want to update a database-
		entry for one or more file(s). This option implies
		"readonly", because a passphrase is required for writing
		the databases(if protected is turned on), which
		is not avalable if nabou runs from a cronjob.
		This mode requires the module Crypt::CBC to be
		installed! In addition Crypt::CBC requires at least
		one of Crypt::IDEA, Crypt::DES or Crypt::Blowfish
		to be installed. You will find all these modules on
		your nearest CPAN-mirror. The default algorithm
		used is "DES". If you want to use another one, you
		must set the option "cipher" (see next).
cipher		One of "DES", "IDEA", "Twofish" or "Blowfish".
		The default is "DES" and it will only be used if
		"protected" is turned on and if Crypt::CBC and the
		referred algorithm-module is installed as well. I.e.
		if you set "cipher" to "Blowfish" then you must install
		the module "Crypt::Blowfish".
readonly	boolean value, 1 turns it on, 0 turns it off. The
		default is 0, off. Nabou will not write changes to
		the databases if this option is turned on. This
		allows one to use a read-only mounted disk for db-
		storage. But you are required to update your databases
		manually by using the "--reset" or the "--update"
		command line option (see Usage section for more details
		on using those options)!
pidfile		this is only required, if you use "check_proc" and run
		nabou with the --daemon option, in which case it will
		write it's process id into this file. If it is not specified,
		/var/run/nabou.pid will be used as default. IF you specify
		a file here, please specify an absolute filename. I.e:
		"nabou.pid" or "./nabou.pid" will not work, because
		nabou changes it's working directory many times (if in
		"check_proc" mode!).


The mail block options:

The mail block starts with "<mail>" and ends with "</mail>".
An example:
<mail>
        rcpt            root
        from            root
        subject         report from nabou
</mail>

The mailblock is required if you turned "usemail" on.
The following attributes must exist:
rcpt		the receipient of the report email.
cc		optional, one or more addresses(comma-separated) of
		presns who will receive a carbon copy of
		the email reports.
from   		the sender address of the email.
subject		the subject of the email.
alert		optional, it contains an email-address, which
		will be used for sending out alert-mails if something
		weird has happened with nabou or one of it's databases.


The binary block options:

The binary block starts with "<bin>" and ends with "</bin>".
An example:
<bin>
        sendmail        /usr/sbin/sendmail
        crontab         /usr/bin/crontab
</bin>

sendmail	the location of the program sendmail, which
		is used to mail the report and only required
		if you turn on "usemail".
crontab		the location of the program crontab, which
		is used to check user crontabs and only
		required if you turn on "check_cron".


The suid block options:

The suidblock starts with <suid> and ends with </suid>.
It will only be used by nabou if you turned on suid-checking
by setting chaeck_suid to 1.
The suid block defines what attributes should be checked for
suid sgid files. If there is no suid block configuration or
if the suid block contains no appropriate attributes, then
nabou will use defaults, which is MD5 check and file-mode
check. You can use all chk_* attributes described below in
the directory block. You can set chk_all to 1 if you want
to perform all available checks.
The suid block does not support the exclude, include, inherit
or recursive attributes. An example:
<suid>
	chk_mode	1
	chk_size	1
	chk_uid		1
	chk_gid		1
</suid>




Finaly, the directory blocks. These are the most important
things in the configuration. Each directory block defines
various options for one directory. Thus , you are able to
define different attributes to be checked for each directory.
In general, a directory block stars with:
<directory /some/dir>
and ends with
</directory>
You may define as many directory blocks as you need. There
are several options, which are the default. If you don't
specify any attributes, i.e.:
<directory /etc>
</directory>
then nabou will make a check on md5 checksums on each file
within that directory and it will _not_ recurse on that dir!

These are the options you may define:

recursive	If turned on, then nabou will also check all
		files in subdirectories under that directory.
		The default is 0(off).

exclude		you may specify a filename which nabou shall
		ignore. You may specify multiple exclude lines
		one for one file. You may use shell-wildcards
		for filenames. An example:
		<directory /dev>
			exclude tt*
			exclude pt*
		</directory>
		If you want to ignore files under a subdirectory,
		then you are required to specify this file/dir
		relative to the directoy block. An example:
		<dir /usr/local>
			exclude share/blackbox/*
		</directory>
		In the example below, /usr/local/share/blackbox/*
		will be ignored.
		The "exclude" attribute cannot used together
		with the "include" attriute (see above).

include		You may specify one or more include lines.
		If an include attribute occurs within a directory
		block (or more than one), then nabou will only 
		look for the file(s) specified by include. It
		will ignore all other files under that directory!
		You cannot use shell-wildcards with the include-
		attribute! An example:
		<directory /home/vasall>
			include .history
			include todo
		</directory>
		The "include" attribute cannot be used together
		with the "exclude" attribute.

du_decrease	A percent value, the default is 10%. This will only
		be used if you turn check_diskusage on. nabou will
		print a message if the diskusage of a monitored
		directory decreases under the specified minimum
		percentage.
		Excluded files will not counted.
		If you use one or more include statements, then only
		the diskusage of these files will be counted. 

du_increase	A percent value too, like the one above. You will
		get a message if the diskusage of a monitored
		directory increases over the specified maximum
		percentage.

inherit		This is a very special attribute. It takes a
		directory name as argument, which must be defined
		as a directory block somewhere in the configuration.
		It causes the directory to inherit all attributes
		defined from the specified directory block. Please
		note, that you cannot specify additional attributes
		if you are using "inherit", because all attributes
		are used from the inheritted block! An example:
		<directory /bin>
			chk_md5	 	1
			recursive	1
		</directory>
		<directory /sbin>
			inherit		/bin
		</directory>
		In this example, nabou will do an md5-checksum
		lookup and do a recursive lookup for the directory
		/sbin.
		If the "inherit" attribute refers to a directory,
		which is not defined within the configuration, then
		nabou will warn you about this and use the default 
		attributes chk_md5=1 and recursive=0.

You can specify one or more file attributes nabou shall look for:
chk_md5		check for changes on MD5 checksums. This option has
		the same name even if you specified another hash
		algorithm than the default MD5 (MD2 or SHA1)!
chk_size	check for changes on the file size.
chk_mtime	check for changes of the modification time.
chk_uid		check if owner of the files has changed.
chk_gid		check if group of the files has changed.
chk_nlinks	check if the number of links to a file has
		changed.
chk_mode	check if the mode of files has changed.
chk_ino		check if the filesystem inode has changed.

The attributes above will be used, if you turn on "chk_all"!

The followng attributes can also be checked:
chk_dev		the device number of the filesystem
chk_ctime	inode change time
chk_blocks	the number of blocks allocated on a filesystem.
chk_custom	see the section "Custom scriptlets" below!

The following file attributes cannot be checked with nabou:
access time: that's senceless, because, the accesstime changes
when nabou calls stat(2) on a file! And the attributes rdev,
and blcksize. See the manpage of stat(2) for details or look
at the file dbformat.txt shipped with the nabou tarball.






There is a very special and useful parameter which allows you
include another file:
<<include /root/anotherfile>>
nabou reads its contents on this position as if is was written
overthere. An example:
--- mail.rc ---
<mail>
	rcpt	tom@daemon.de 
	from	root@localhost
	subject	nabou report
</mail>
--- end ---

--- nabou.rc ---
<<include mail.rc>>
...
--- end ---

If you run nabou in multiple instances, say one checks only for
suid files once a week and another one checks only for files
every day, but both instances shall to use identical mailoptions,
you can use the construction above.



Nabou does not follow symlinks (at the moment, this may change
in a future release), because of some program's tendencies to have
circular symlinks which will run you out of memory pretty fast.
And that's evil.

You can see a complete configuration example in the file nabourc
shipped with the nabou tarball.


Custom Scriptlets:

This is the really funny part :-)

You can extend the functionality of nabou by writing "inline scripts",
(I name them "scriptlets" from now on). All of this stuff is done
inside the nabou configuration file. You can define any number
of scriptlets. After defining a scriptlet you can refer to it by
using the directory block option
	chk_custom    name
The parameter to "chk_custom" must be the name of a defined scriptlet.
nabou will call this scriptlet on every file within a directory.
That means, you need to refer to a scriptlet on a per-directory
basis. See the example below.

The scriptlet itself must be written in valid perl5. nabou will save
this code in an anonymous sub and call it using a closure. This "sub"
will get 3 arguments from nabou, a File object, the current
directory and a string containing the current message for the
current file. If the message is empty no other check found something,
if is is not empty it contains the explanation of what nabou
already found about this file.
The File object needs some further explanation:
You can access every file attribute by using the -> notation.
Possible attributes are "size", "uid", "atime" and so on (see
dbformat.txt for more available attributes).
Beside of these, there are two more attributes: "filename" and
"md5". filename returns the file name of the current file
(the absolute file name!). md5 returns the checksum of the current
file. This maybe a MD5 checksum but can also be SHA1 or MD2, which
depends on your configuration(see "use_algo" above!).

If you want complete integration of the scriptlet into the nabou
workflow, then you need to return a message, you don't have to
print it just out to STDOUT!

One or more script(s) must be defined using the <script> block.
This block starts with <script> and ends with </script>. Inside the
block you need to define the code using a so called here-document.
The name of this here document must be the "script-name" followed
by an end identifier after the magical "<<" characters.
nabou will read evrything in until the end identifier occurs.
There is no space, tabulator or anything else allowed after this
identifier! The name that you give the scriptlet will be used later
for referencing to, by using the "chk_custom" attribute in the
directory block.

An example:
--- snip ---
<script>
	test <<EOF
		my($file, $dir) = @_;
                return "SIZE of " . $file->filename . ": " .
		$file->size . " bytes\n";
        EOF
</script>

<directory /tmp/test>
	chk_md5		1
	chk_mode	1
	chk_custom	test
</directory>
--- snap ---

In this example nabou will run the following sub:

sub {
 my($file, $dir) = @_;
 return "SIZE of " . $file->filename . ": " .
 $file->size . " bytes\n";
}

on every file it finds in /tmp/test.

Additional you access the complete namespace of nabou. This is
powerful, but also danger. But a really good use of this case is
that you can access the %config hash, which contains a data
structure of the whole configuration. You could create your own
configuration block, which will be used by your scriptlet!
An example "custom" config block (which will simply ignored by
nabou itself, but it will be loaded into %config!):
<test>
	user	max
	pass	nim9w
	port	31733
</test>

Inside your scriptlet you can access to the values inside <test>
using the following method:
$user = $config{test}->{user};
or
$pass = $config{test}->{pass};

There are two sciptlet names which have a special purpose: BEGIN
and END. The BEGIN scriptlet will be executed only once at startup
IF it exists, and the END scriptlet will be executed only once at
the end respectively IF it exists. This is very usefull if you
want to open e file or database, which your scriptlet(s) later can
use.
An example:

<script>
        test <<EOF
                my($file, $dir) = @_;
                print TEST " DIR: $dir\n";
		print TEST "FILE: " . $file->filename . "\n\n";
		return "";
        EOF

        BEGIN <<EOF
                open TEST, ">/home/thomas/nabou/test" or die $!;
        EOF

        END <<EOF
                close TEST;
        EOF
</script>
<directory /usr>
	chk_custom test
</directory>

As you can see, the "test" scriptlet, which will be executed for every
file under /usr prints a line to a filehandle "TE". Under normal circum-
stances this wouldn't be possible, because it were not opened somewhere
before. But if you define a BEGIN scriptlet as in the example above, 
which opens this filehandle, then the "test" scriptlet can access this
handle.
You need to know, that both the BEGIN and the END scriptlets are not
evaluated as a anonymous sub-routine. They are evaluated inside the main
namespace, in other words, variables which you define here are accesible
globally!

A note to return values of scriptlets: If you don't want the scriptlet
to cause a match, then you need to return an empty string:
return "";
otherwise it would be a match and appear in the nabou report!




Process Monitoring
-------------------

Another feature of nabou is to monitor running processes and to send
out a report in case it finds something weird. But how does nabou know,
if a process is weird? Good question. It uses the /proc filesystem.
Because of this fact you cannot use this feature of nabou if you are
running a system without a /proc filesystem enabled. Nabou cannot use
the /dev/kmem device!
Nabou gathers a list of all running processes with all properties it
can get from /proc. Most properties are those, which you can see when
you use "ps". But there are also some other, very interesting properties.
Currently it uses 4 different methods to find out if a process could
be dangerous:
1. If the real user id of the process is different from the effective
   user id. This is the case if it is a set uid program, i.e. xterm
2. The same as above(1.), but is uses group id.
3. If a process' commandline does not match it's absolute filename.
   i.e. if it appears in "ps" as "nfsd" but the executable is "/tmp/sush".
4. If the process is detached from any terminal (connected to tty 0)
   and is actually running (state R).
(5.) additional you can define your own check using inline perl script-
   lets. See the previous sub-section on writing and using scriptlets
   and the proc-related scriptlet section below.
If you use nabou for process monitoring, you can use the "-D" option,
which causes nabou to turn itself into the background (using fork(2).
You can also define exceptions for processes which should be ignored
furing the normal run, like xterm's or so.

See the provided example config file  "psrc" for a demonstration.

The <proc> config block:
it starts with <proc> and ends with </proc>. It is used by the process
monitoring routines of nabou. It may contain one or more of the
following options:

argv		You can define a name under which nabou appears in
		process listings if it is in daemon mode (-D). nabou
		will ignore it's own /proc entry silently.

chk_uid		1 turns it on, 0 off. eport a process if ruid and
		euid does not match, if it is a set uid program.
chk_gid		1 turns it on, 0 off. Report a process if rgid and
		egid does not match, if it is a set gid program.
chk_argv	1 turns it on, 0 off. Check if the visible commandline
		matches the executable which is actually running.
chk_rundet	1 turns it on, 0 off. Report running detached processes.

chk_custom	requires a scriptlet name, which will be executed on
		every process running and must return a message in case
		of a match. see below.

report_old	Nabou can remember already reported processes. This
		option defines how long should nabou remember the
		process' entry until reporting it again. This option 
		requires minute values, the default is 0, in other words
		the default is to always report.
refresh		Seconds. how long should nabou wait between refreshes
		in the proc filesystem. Please note, that it will eat
		some host performance if the intervall is too small.
		A good value is 20 or 30 seconds.

report		a comma separated list of process properties which
		should be reported if nabou finds a weird process.
		You will find a complete list of all available pro-
		perties below in the proc-sciptlet subsection. An example:
		pid, uid, euid, tty, exe, cmdline, cwd.
		Alternately you can use "ps", which will cause in one line
		per process. The format will be similar to the helper
		script called "ps" in the subdir "supplement".

noreason	1 turns it on, 0 off. The Default is 0(off). If turned on,
		no reason will be printed out why the process has matched.
		This is only useful in combination with "report = ps".

Additional you can define exclude blocks, which starts with
"<exclude /path/to/program>" and ends with "</exclude>". Every exclude
block may contain the following options:

cmdline		the visible commandline, i.e. "-bash". You can define
		multiple "cmdline"'s, which is useful for scripts, i.e.:
		cmdline		/root/bin/checkusers.sh
		cmdline		/root/bin/checksnort.sh.
		You can also use perl regular expressions here, but be very
		careful!

md5		the MD5 checksum of the program, create it using "md5sum"
		which is part of every linux installation (should be I
		mean)

uid		The user id the process runs as.

An example:
<exclude /bin/bash>
                # login shells
                cmdline -bash
                md5     c36b467680f96a6c63053df2c0df379e
</exclude>

Process monitoring and custom Scriptlets:
as I mentioned above you can use custom perl scriptlets with the process
monitoring mode of nabou too, and it works similar to the scriptlet
engine in the file-system mode. But a scriptlet gets other parameters
from nabou: a Process object and a message about the checks already done.
The Process object contains all available information about the current
checked process. If the message is empty no other check found something,
if is is not empty it contains the explanation of what nabou
already found about this file.
An example:
<script>
        test <<EOF
                my($prc, $lastmatch) = @_;
		if($prc->exe =~ /^\/tmp\/.*sh.*$/) {
			return "shell running from /tmp!";
		}
		else {
			return "";
		}
        EOF
</script>

As you can see, you can access every property using the arrow notation:
cmdline is: $prc->cmdline, the pid is: $prc->pid.

Here is a list of all available properties, which can also be used for
reporting (see above about the "report" option!):

cwd 	- current working directory
cmdline - visible commandline as seen by "ps"
pid 	- the process id
exe 	- the absolute filename to the executable running, i.e. /bin/bash
uid 	- real user id
euid 	- effective user id
suid 	- saved user id
fuid 	- file user id
gid 	- real group id
egid 	- effective group id
sgid 	- saved group id
fgid	- file group id
comm 	- similar to cmdline
fdnum   - (internal) number of open filehandles
fh      - a hash of all open files, the keys are the file descriptors
	  (filenumber).

see a more detailed description of the other properties in the proc(5)
manpage: "man proc", look for "stat Status information about the process":

	state ppid pgrp session tty tpgid flags minflt cminflt majflt
	cmajflt utime stime cutime cstime counter priority timeout 
	itrealvalue starttime vsize rss rlim startcode endcode startstack 
	kstkesp kstkeip signal blocked sigignore sigcatch wchan nswap 
	cnswap exit_signal

There is a complete (tested) sample configuration supplied with nabou
called "psrc", which you can use as a starting point. Addional, there
is a script called "ps" supplied in the sub directory "supplement", 
which you can use to see a complete ps-like listing with the following
informations: PID RUID EUID RGID EGID FH TTY EXE CMD.



Runninig nabou
-------------

Before you can install nabou as a daily cronjob, you need to
run it once with the -i or --init commandline flag. This causes
nabou to initialize it's databases based on your configuration.
An example:
	nabou --init --config /root/.nabourc

Please note, that the output of the initial run of nabou can
become very large! You may redirect this output to a file:
	nabou --init --config /root/.nabourc > init-log

nabou will ask you for a passphrase if the <db> block option
"protected" is turned on and save the encrypted passprase in
the file "keydb" in your naboudb basedirectory. The phrase will
be encrypted using crypt(1), which is a one-way algorithm.
This passphrase will be used later if you want to use the
--update or --reset option.

If you are using a nabou instance for process-monitoring only
as demonstrated by the sample "psrc" supplied with the package,
then the options -i or -r are redundant.

If the --reset or --init(or -i/-r) flag is supplied, nabou will
not mail out a report even if usemail is turned on.

Now you are ready to install it as a daily cronjob. An example:

30 0 * * * /root/bin/nabou --config /root/.nabourc > /dev/null 2>&1

This crontab entry runs nabou every day at 00:30.


There is another commandline option which you can use to re-
initialize it's database: -r or --reset. But be very careful with
this option.

If you only want to update the database entry for one file, you can
use the option "-u" or "--update", which requires a filename as
argument. If the <db> block option "protected" is turned on, then
nabou will ask you for a passphrase. If the environment variable
$NABOU_PASSWD is set, this value will be used as passphrase.
If you omit a filename for --update then nabou will perform a normal
run based on the current config, which is the same as running nabou
without any options (beside --config).


You can also run multiple instances of nabou, but better use
different databases for every instance. If every instance should
use some identical config options, you might make use of the
include statement mentioned earlier in the "Configuration" section.


You can run nabou with the "-q" or "--quiet" flag, which causes
it only to report changes. In other words, if nothing changed, no
report will be sent/printed.

You can view the contents of a nabou database by using the command
line flag "-d" or "--dump". This flag requires the database name as
argument and dumps out a comma separated list, one line for one file.
The meanings of each field are described in the file dbformat.txt.
The dump will be a little bit formatted, time values will be
converted to human-readable values (just as the date command tells
you), uid and gid values will be converted to their representations
(i.e. 0 = root and so on).
If you prefer to get the raw contents unformatted then you can use
the flag "--raw" in addition to the --dump or -d flag.


Some notes on security:
	Nabou behaves very, very paranoid if the <db> block option
	"protected" is turned on! In fact, it uses the key, which
	you supplied the first time (--init) for an additional data-
	base field. This field contains an encrypted copy of the 
	record for that file.
	If you run nabou from crontab (without any options but
	--config), then it will NOT update the databases! Instead it
	will only warn you about changes. The next time it runs, it
	will warn you again, and so forth, until you log on and update
	the database yourself using the commandline-flag "--update"
	without any parameters. Nabou will ask you for the passphrase
	and use this passphrase to decrypt the encrypted record-field.
	If the result is identical with the exiting(old) record, then
	it will update that record and create a new encrypted field
	based on that new record.
	If the result does NOT match, then something weird has happend
	with the database. In this case, it will not update the record
	and send out an email to the receipient specified in <mail> - 
	alert or to "root" if not specified.

	If you turn on "readonly" or "protected"(which automatically
	turns on "readonly" too), then I recommend you to protect your
	databases. There are severyl ways for protecting files from
	being written. You can use a read-only mounted medium, or you
	can protect the files using chattr(1). The very best and most
	secure way is to use LIDS (http://www.lids.org). You can secure
	the complete nabou database directory and you might protect
	nabou and you config-file(s) as well:
	lidsadm -A -o /root/db -j READ
	lidsadm -A -o /root/bin/nabou -j READ
	lidsadm -A -o /etc/nabourc -j READ
	If LIDS is well configured, then only root logged in from a local
	console is able to turn off LIDS and thus to perform a nabou
	update. Remote users, and even root, are not able to turn it off,
	and because of this - not able to perform an update of nabou.
	
	If you use such a setup, then you can be sure you will be informed,
	if someone nasty got root and installed a trojan horse or added
	a new UID 0 user account or something else.



Availability
------------

You can find the latest versions of nabou on one of the following
locations:
http://www.daemon.de/software.html
http://www.0x49.org/nabou





Support and Feedback
--------------------

If you encounter any problems using nabou or if you have some
suggestions or bug reports, feel free to drop me an email:

Thomas Linden <tom@daemon.de>.




Finaly, thanks for choosing nabou - keep the world secure!

