REQUIREMENTS

You will need to run a Linux kernel 2.2.x or newer, earlier 
kernels lack the system call for a trusted local path. It 
has also only been tested on the i386 architecture.

CONFIGURE

  ./configure

To enable support for the apache module mod_idsa run

  ./configure --with-apxs=/path/to/apache/bin/apxs

or edit Makefile.defs after running configure. Makefile.defs
is the only file generated by the configure script.

BUILD

  make

The make process is reasonably modular. Even if the compile of
some modules such as mod_idsa or pam_idsa fails, the remainder
should still be usable and can be installed on a per-directory
basis. The only essential directories are lib/, common/ and server/

INSTALL

  make install

By default the install will go into /usr/local.

Communication between components uses the unix domain socket
/var/run/idsa. /var is used for the socket and logs since it is
the only directory which is guaranteed to be mounted readwrite -
other parts of the file system could be mounted readonly.

CONFIGURATION

idsad.conf is the configuration file for the master daemon. It
contains numerous examples. Edit it to your liking. A simple
configuration file which allows and logs everything

  %true: log file /var/log/idsa/everything

To have the changes take effect restart idsad. Idsad is restarted
by having a new instance kill the previous one (using the -k
option).  Do not use signals - idsad does a chroot() on startup.

Other options are controlled from the command line of the
various daemons. Run a daemon with the --help option to see a
list of options.

RUNNING

In ./etc you will find a sample startup script rc.idsa.  rc.idsa
should moved or linked to /etc/init.d/idsa or /etc/rc.d/init.d/idsa
or whatever your distribution uses. You might want to edit this
file, in particular if you would like the system to run under a
different user. Afterwards link it into the appropriate runlevel
directory.

SECURITY

Read WARNING.

Although the daemons will run as root, they are designed
to be run in a chrooted jail as an unprivileged user. If
run as root the daemons will print a warning to this effect.

It is best not to run the daemons as nobody, since they do have
a security function. Instead create a new system user called idsa

  adduser --system idsa

Then use the -i idsa option when starting the idsa daemons.

Use the -r option to specify a root directory for the chroot()
system call. At the very least no setuid binaries or device files
should be available below this new root. Even better would be
a directory mounted noexec,nodev.

Most daemons will initialize (open files, create sockets and start
subprocesses) as root and should not require any support files in
their chroot jail, with the restriction that a restart of idsad will
also require the restart of the chrooted auxiliary daemons since
/var/log/idsa has to be re-opened, and /var/log/idsa won't be
visible from the chroot jail. If you do not wish to restart the
auxiliary daemons, have idsad listen on several sockets (with -p)
including a socket within the chroot jail.

STOPPING and RESTARTING

The idsa daemons are supposed to run in a chrooted environment. For
this reason they are unable to be restarted with SIGHUP since that
would mean breaking out of the chrooted environment. To acquire the
pid of idsad and idsasyslogd use the idsapid utility. For example,
to find out the pid of the instance listening on /var/run/idsa
use the command

  idsapid /var/run/idsa

So to kill idsad use 

  kill -TERM `idsapid /var/run/idsa`

or

  idsapid -k /var/run/idsa

idsad can kill an already running instance when starting up if
you use the -k option. The replacement of /var/run/idsa will be 
atomic.

REPLACING SYSLOGD

idsasyslogd can be used to replace the standard system logger
(syslogd) and kernel logger (klogd).

rc.idsa-full will run the replacement syslogd and klogd.

If you replace syslogd, idsad and idsasyslogd will have to be run
early during system startup. On some distributions /usr/local or
/usr may not yet be mounted, so you might want to install idsad
and idsasyslogd in /sbin and libidsa in /lib.

WARNING: The original syslogd is much better tested than my
replacement. The replacement also does not yet do remote logging
and is limited to shorter messages. But mine has the advantage 
of being able to run chrooted, can filter on regular expressions
and knows the uid of its clients.

REPLACING TCP WRAPPERS

idsatcpd can be used to replace Wietse Venema's tcp_wrappers.

Replace references to tcpd in /etc/inetd.conf with idsatcpd.
idsatcpd accepts a number of command line options. Restart inetd
after making the changes.

Rules to block services are specified in idsad.conf. In combination
with idsatcplogd and stateful rules it becomes possible to prevent
bulk scanners from grabbing banner information.

WARNING: the original wrappers are better tested and more reliable
than mine. Mine also does not do reverse or ident lookups and is
restricted to TCP over IPv4 only. It won't work with UDP or IPv6.

ADDING mod_idsa TO APACHE

See apache/README. If your apache is reasonably new (some recent
1.3.x version) and it has DSO support enabled, you should just
have to edit Makefile.defs to set APXS to point to the correct
location, do a make install and then update httpd.conf.

WARNING: mod_idsa is poorly tested and has performance implications
if you run sites like yahoo or slashdot.

INSTALLING snoopy.so

See snoopy/README. Snoopy is a preloaded library which will
attempt to intercept calls to execv and execve and check with
idsad before allowing the call to succeed.

WARNING: careless use of snoopy.so may block all exec() 
calls.

ADDING THE PLUGGABLE AUTHENTICATION MODULE pam_idsa.so

See pam/README. pam_idsa can be added the authentication phase
of programs such as login to log and possibly block events.

WARNING: careless use of pam_idsa can lock you out of your system.
