/images/site_attributes.png

Software ↑     Config Download Install Modules Procmon Scriptlets Security Usage

back

    NAME
    CONFIGURATION
        MAIN OPTIONS
        DATABASE BLOCK OPTIONS
        KEY BLOCK OPTIONS
        MAIL BLOCK OPTIONS
        BINARY BLOCK OPTIONS
        SUID BLOCK OPTIONS
        DIRECTORY BLOCKS
        DEFINE AND CHECK BLOCKS
    INCLUDE EXTERNAL FILES
        NOTES ON CONFIG BEHAVIOR

 

NAME

nabourc - description of the nabou IDS config file format

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.

MAIN OPTIONS

use_shadow

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

use_mail

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 SHA1. Possible values are:

 SHA1 MD5 MD4 Haval256 SHA2 MD2 

The underlying perlmodule (e.g. "Digest::SHA1") must be installed.

You can tell nabou to generate 2 (or even more) checksums by just defining use_algo several times. Example:

 use_algo SHA1
 use_algo MD5 

Generates two checksums of your files, which adds more security. The output in the report would then look like this example:

   ----[  /var/log/messages  ]----
 
 /var/log/messages:
    (Checksum has changed)
  [Expected] -SHA1.4130f66e4f5113531b7f3bbde73c389008b82352-MD5.c731f5fded792f2832ab8034eb1080d2
  [Observed] -SHA1.fa25b52dadbc0cde259fb9a1379210a99744228f-MD5.f63a4e808b104681f9c70affa392aee3
    (file attributes)
  [E] -rw-r----- 1     root      adm    294390  Sun Aug 29 18:01:09 2004
  [O] -rw-r----- 1     root      adm    298669  Sun Aug 29 18:03:20 2004 
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.

use_temp_sum

this option causes nabou to use a dbm file for storing the results of the current check run instead of a normal hash in RAM. this might be usefull if are having memory problems. But be warned: this could be a security hole, also known as race condition, because a possible attacker could alter this temporary dbm file before nabou compare it's contents with the contents of the regular database!

I suggest you, not to use this options unless you are unable to get nabou running properly.

HINT: You can also configure multiple instances of nabou, where every instance checks other directories!

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

This is just an option for check_files, which means, that nabou should also keep an eye on symlinks (just the links, not it's destinations). The default is to ignore symlinks.

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.

check_ports

this causes nabou to look for listening ports (as marked in netstat -a with »LISTEN«) and the process which has opened the port as well as the user under which it runs. It will inform you about new listening ports, as well about all changes on known listening ports.

DATABASE BLOCK OPTIONS

The db block starts with > and ends with >. An example:

 <db>
        basedir          /home/thomas/nabou/db
	cipher		 IDEA
        sign             1
 </db> 

The following attributes are supported:

basedir

define the base directory which contains the databases. Do not use a trailing slash.

protected

this exists for backward compatibility (2.3 and below). Use sign instead, encrypted databases are no more supported since signatures add more security and the previous encryption of the database was weak.

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)!

sign

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). If you have also turned on protected you will be asked once for the passphrase.

This option causes nabou to cryptographically sign the database contents with your RSA key. This process is not (at the time being) reversible. You may not loose security if you only turn on signature generation and turn off database encryption(protect), because even if an attacker alters an entry, you will be notified of this because the signature will not match the changed entry and the attacker is unable to re-create it.

cipher

One of "DES", "IDEA", "Twofish" or "Blowfish". The default is "DES" and it will only be used if "sign" 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".

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

pwdDB, sugidDB, csumDB, cronDB, miscDB, diskusageDB, portDB

You can also define the filename for the database files, which are then created relative to basepath. If you do not specify them, default file names are used, which is ok in most cases.

KEY BLOCK OPTIONS

The RSA key block starts with "" and ends with "". Example:

PUBLIC <

   PRIVATE <<EOF
      -----BEGIN RSA PRIVATE KEY-----
      wP1VuKTv2Vb6Kr2kaJhJOSG/kCvE9GGVPMERSZYdHoHkf3ZJ6WlUnM/Rt7o2xwPs
      t6zKlZNSZwJkWmgT51XF11sCGDx31C/23F/RCLH3dPnLN6ttipNwHQdEmnCvszHu
      mA6O4CS4pHeVXcWJIcEPg+oMma6Pal8nIvfDHCcMZKxiIdhXPGYVoBSXEJ6KcLm3
      5GSBtR6D1A4xY5+0LwJlALVZNTMZAftKrArAvpavtIPGluLQmKSVaAXu1glAnbpV
      8WSaZW6sGwHsXTzfWFuRiXyUZt/9iVubt71uY0DYPel3u8JyBC0sM7UmGYrg34iH
      2G+L5o9VNATeVknjXfEBAGKi8jE=
      -----END RSA PRIVATE KEY-----
      EOF
</keys> 

These two keys (the PUBLIC and the PRIVATE key) needs to be created with nabou --genkey.

MAIL BLOCK OPTIONS

The mail block starts with > and ends with >. 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 persons 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.

BINARY BLOCK OPTIONS

The binary block starts with > and ends with >. An example:

 <bin>
        sendmail        /usr/sbin/sendmail
        crontab         /usr/bin/crontab
        lsof            /usr/sbin/lsof
        who             /bin/who
 </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.

lsof

the location of the program lsof, which is used to check for listening tcp/udp ports on your system.

who

the location of the program who which is used to get informations who is executing nabou in case of a potentially violation, which will be mailed to as an aler mail to the administrator.

SUID BLOCK OPTIONS

The suidblock starts with > and ends with >. 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 inherit and recursive attributes, but exclude and include are supported. An example:

 <suid>
	chk_mode	1
	chk_size	1
	chk_uid		1
	chk_gid		1
        <exclude>
          /proc
          /home   # mounted nosuid
        </exclude>
 </suid> 

See the description on the exclude and include options in the section DIRECTORY BLOCKS below. But please note, that includes or excludes within a suid block are matching recursive, that means, if you specify a directory to exclude, then all files and directories within that directory are also ignored. Wildcards are supported anyway.

DIRECTORY BLOCKS

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:

>

and ends with

>

You may define as many directory blocks as you need. Previous versions of nabou had some predefined default checks turned on in case your directory block looked like this one:

 <directory /etc>
 </directory> 

Today it will not do any checks on a dir unless you tell it what to check. it is also possible to define "recursive 1" and nothing more, then it will tell you about added or removed files recursively under that dir, but it will not do any check on any file.

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

If you need more than a few files to be excluded you might consider using an exclude block as the better way of doing such. An example:

 <directory chk_logdir>
       recursive        1
       chk_mode         1
       chk_uid          1
       chk_gid          1
       du_increase	30
       <exclude>
                /var/log/XFree86.0.log
       		/var/log/boot.log
       		/var/log/dmesg
       		/var/log/xdm-errors
       		/var/log/xfs.errors
       </exclude>
 </directory> 
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.

The include statement does not a block notation as the exclude statement does!

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

this option exists for backward compatibility. See chk_hash.

chk_hash

check for changes on checksums. It does hash digest checksum testing depending on your use_algo setting.

chk_size

check for changes on the file size.

chk_shrink

check for file size shrink.

chk_grow

check for file size grow.

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 stat? for details or look at the file dbformat.txt shipped with the nabou tarball.

DEFINE AND CHECK BLOCKS

If you need to define many different files/directories in your config you will soon find it boring to write a complete directory block for each single directory/file.

For that reason a new feature exists, which allows you to define check templates. Once you have defined such a template you can apply it to many directories/files within one check block.

DEFINE BLOCKS

Sample:

 <define chk_logfile>
       chk_shrink       1
       chk_mode         1
       chk_uid          1
       chk_gid          1
 </define> 

This defines a new check template called chk_logfile (you can choose any name you like). This particular template is used to check mode/uid/gid bits and to check if a file shrinks, which is generally not good with logfiles.

You are allowed to use any possible check statement and option which is available for directory blocks too.

One thing is important: if you want to use the exclude or include statement inside a define block, then you must specify the absolute pathname, relative pathnames are not allowed (or: they will not work as you expect!) inside define blocks.

CHECK BLOCKS

Now that we have defined our own check template, we want to apply it to some file within one block:

 <check chk_logfile>
       /var/log/messages
       /var/log/wtmp
       /var/log/faillog
       /var/log/lastlog
       /var/log/kernel
       /var/log/firewall
       /var/log/secure
 </check> 

That's it.

INCLUDE EXTERNAL FILES

There is a very special and useful parameter which allows you include another file:

<>>

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.

NOTES ON CONFIG BEHAVIOR

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.