REQUIREMENTS

At the moment the system is platform specific - 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.

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. To have the
changes take effect restart idsad. Idsad is restarted by invoking
it with 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 happily run as root, they are designed
to be run in a chrooted jail as an unprivileged user.

Hopefully this will reduce the impact of potential buffer
overflows. You don't want to run the daemons as nobody, since
they do have a security function, so 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 caveat 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
auxillary 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 (replacement of /var/run/idsa will be atomic)

REPLACING SYSLOGD

idsasyslogd can be used to replace the standard system logger
(syslogd). It won't replace klogd, but klogd will use the
replacement system logger if started after idsasyslogd.

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 (for the time being). But mine
has the advantage of being able to run chrooted and knowing 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.
