$Id: README,v 1.2 2006/07/29 17:05:25 rdilley Exp $
=== Passive Syslog Monitor Daemon (PSMD)

by Ron Dilley <ron.dilley@uberadmin.com>

For the latest information on psmd, please see:
http://www.uberadmin.com/psmd/ (coming soon)

== What is psmd?

psmd is short for passive syslog monitor daemon.  psmd listens
on an interface and writes the syslog messages that it sees to
disk along with a hash.  In addition, it can forward system
messages to another system as though the messages came from
the original device.

== Why use it?

I wrote psmd to solve a problem.  I wanted to record all the
syslog traffic on a DMZ when I did not control the systems on
the DMZ or the logging hosts that the systems were sending
traffic to.  After the third security event where I was
unable to get good syslog data from one of these hosts due to
a disk full condition on a central logging server, I wrote
this tool and started running it on a mirrored switch port in
the DMZ.  This not only gave me the log data that I needed on
a system that I controlled (and would not run out of disk
space), it also gave me all the syslog messages reguardless of
the destination host.  This also allowed me to get syslog
messages before a non-rfc compliant syslog relay obscured or
mangled any part of the message.

Figure 1:
---------

                +----------+
                |ext router|
                +-----+----+
+-----------+         |
|dmz servers|+  +-----+----+
+-----------+|--|ext switch|--------------------+
 +-----------+  +-----+----+                    |
                      |                         |
                      |   +----------+          |
                      |   |ss servers|+         |
                   +--+   +----------+|+        |
                   |       +----------+|        |
                   |        +----------+        |
                   |             |              |
+-------+     +----+---+    +---------+   +===========+
|loghost|-----|firewall|----|ss switch|---||PSMD Host||
+-------+     +----+---+    +---------+   +===========+
                   |                            |
                   +--+                         |
                      |                         |
+-----------+         |                         |
|dmz servers|+  +-----+----+                    |
+-----------+|--|int switch|--------------------+
 +-----------+  +-----+----+ 
                      |
                      |
+-------+       +-----+----+
|loghost|-------|int router|
+-------+       +----------+

There are several ways that you can setup psmd.  I will
talk about a few configurations that I have used.  I am
sure there are many ways to skin this cat (no offfense
intended to the cat lovers out there).

* stealth psmd on a service leg where you have no control

This option only requires that you have either a hub or a
mirrored port configured in such a way that the host
running psmd listens on a port with no IP address and that
port can see all the traffic from all of the systems on the
segment.

Once the ports are configured and the host is attached to
the monitor port, run psmd as follows assuming that eth1
is the port attached to the mirrored ss switch port or
ss hub.

psmd -i eth1

* stealth psmd on an internal switch where you have no
  control

This looks the same as the above but requires that the devices
service legs and the external switch can send thier syslog
packets throught walls to internal logging hosts.  There are
some security implications in doing this.

* stealth psmd on a service leg where you have control
  of the systems

This allows you to point all of the systems to either a
phantom loghost on the service leg with the use of static
arp entries and a hub.  Using a switch with a phantom
log server can have some interesting side effects including
all syslog packets being sent to all ports.

* stealth psmd on a service leg where you have control
  of the systems and the firewall

This works better than the phantom log host in that you can
point all of your systems to the firewall IP address but
configure the firewall IP address to drop all inbound syslog
packets silently.  Once that is done, you can configure your
switch and PSMD host as above to watch the traffic on the
service leg.

* active psmd on a service leg where you have control of
  the systems

If you don't have access to the firewalls and you don't want
to setup a phantom loghost.  You can assign an IP address
to the interface that psmd is using to monitor the segment.
There are security implications in doing this.

== Implimentation

On the system that is running psmd, setup two cron jobs. The
first will send SIGHUP signals to the process on a regular
schedule and the second will archive logs.

This cron entry creates a new logfile every 15 minutes.

0,15,30,45 * * * * kill -HUP `cat /var/run/psmd.pid`

The second cron executes a script that archives logs.  I have
used the following commands in archiving scripts.

#
# compress old log files
#
find /var/log/psmd -name '*.syslog' -mtime +3 -maxdepth 1 \
 -exec gzip -9 {} \;

#
# move old log files
#
find /var/log/psmd -name \( -name '*.gz' -o -name '*.md5' \) \
 -mtime +8 -maxdepth 1 -exec mv {} /var/log/psmd/archive \;

#
# move really old files in prep for off-line storage
#
find /var/log/psmd/archive -mtime +120 -maxdepth 1 \
 -exec mv {} /var/log/psmd/to-be-offlined \;

== Security Implications

Assume that there are errors in the psmd source that
would allow a specially crafted packet to allow an attacker
to exploit psmd to gain access to the computer that psmd is
running on!!!  psmd tries to get rid of priviledges it does
not need and can run in a chroot environment.  I recommend
that you use the chroot and uid/gid options.  They are there
to compensate for my poor programming skills.  Don't trust
this software and install and use is at your own risk.

== Bugs

I am not a programmer by any strech of the imagination.  I
have attempted to remove the obvious bugs and other
programmer related errors but please keep in mind the first
sentence.  If you find an issue with code, please send me
an e-mail with details and I will be happy to look into
it.

Ron Dilley
ron.dilley@uberadmin.com