Hello Earthlings!  I have a very special treat for you today!

INTRODUCTION

I'm excited to finally release what was and is the largest syslog
implementation for Unix (or any operating system).  For six months I (et.
al.) worked on this project for RepSec, Inc.  The total source (as
demonstrated in the profile below) for this project was approximately
15,500 lines.  It has its own original protocol to ensure reliability.
Developed for RSI by myself (Matt Conover) and Mark Zielinski with
contributions from Solar Designer (source audits, security fixes, and
optimization), Bruce Schneier and Chris Hall (developed cryptography in
it).  I'm proud of this product, which is I'm bringing it to you now.

RepSec was originally going to release this as a product.  Brian Matthews
originally requested that I develop this for them in May 1998.  The
expected time of completion was around a month (heh).  Because the
project was developed by only a few people (i.e., Mark Zielinski and I), 
progress was slow and burn out an issue.  It remained in beta testing for
several months as our finances slowly dripped away.  When it was finally
labled done (or good enough) in October of 1998, RepSec wasn't ready to
release it.  It's been well over a year now sine the project was
completed, and this source still hasn't seen the light of day.  I tried to
get Brian Matthew's permission to release source several times without
response.  All previous employees (including CEO and president) of RSI are
working elsewhere now.  Since it's been over a year with RSI dead and
dissolved and the source still unpublic, I think I can safely safe profit
loss from the release of this source is minimal.

I've placed an online archive of the source at
http://www.w00w00.org/files/SRS and the full, original source is available
at http://www.w00w00.org/files/SRS.tgz.  This code hasn't been changed in
over a year, and the original comments, TODOs, READMEs, etc. are all still
there.  If there are bugs, you can tell me about them and I can look into
them, but as I previous said, this was an RSI product, and I am not
working with them or developing this product anymore.  I will treat this
the same way I do ShokDial (a wardialer for unix that I'm no longer
developing): you can submit patches/fixes and I will apply them to the
source tree (assuming they are fit) but will not do anything myself.

DETAILS

This and syslogd may NOT be running at the same time.  This is a syslogd
replace--not an enhancer.  They can't be run at the same time because they
both need to read /dev/syslog.  To see whats going on, run with -d or
compile the source with -DDEBUG.  The result will be like that of
client.log and server.log, which I've attached in this document (you can
find them at http://www.w00w00.org/files/SRS/logs).  The client first
parses /etc/syslog.conf (2-3 days and 1000+ lines of C code to parse it!)
and passes the information onto the server.  The parsing is done through
recursive calls to the parsing function.  It then connects to a statically
defined "info server" (primary, or secondary if primary is down) to get a
list of streaming servers.  The client is required to send its
identification and respond to a very basic challenge by the server.  Logs
are then streamed on the server to /var/log/SRS/clients/ID/subID.  If you
had one ID, you were allowed to connect three times simultaneously.  The
logs streamed were logged into separate files, categorized by ID and
sub-ID (i.e., /var/logs/SRS/0001/1).  The info server reads from a list of
streaming servers each time the client requests it.  This was done so that
admins on the server could update the streaming server list dynamically,
so that a client could receive the most up-to-date list (changed when a
server is down or added) without restarting the server.  The client cycles
through the list of streaming servers, until it finds a working server.
If it reaches the bottom, it will pause and jump to the top.  If at
anytime the client is disconnected, it will move on to the next streaming
server in the list (the list is stored in /etc/SRS.servers or some such).
We had originally planned on developing a tool that would connect to each
streaming server, download all the clients logs, and reorganize them.  It
would be useful because the logs could be split across several machines
(i.e., client streams to server A, server A is crashed by an attacker, and
then begins streaming to server B).  We all this to ensure reliability--if
an attacker managed to crash, halt, or lag a streaming server, the client
could move on unharmed.  We also implemented a ping/pong, so that each
side (client and server) could verify the other was still connected and
running smoothly, and if not, disconnect from each other.  We still detect
disconnects by failed recv system calls; this is meant to handle strange
situations where no FIN or RST is ever sent and/or the system becomes
boggled down.

IN THE SOURCE

You have makekeys.[god|client|server] scripts.  It was setup in a
three-tier heirarchy so that you could have a server certificate could
accept any client certificate and a client certificate could accept any
server certificate (scripts/method done by Chris Hall of Counterpane).
You should not need to run these, because the install.sh in the
client/server directory does all the installation stuff for you (including
setting up certificates).  I left our original 'doall' script, which built
the basic *.in's (configure.in, Makefile.am, etc.) through use of things
like automake, autoconf, etc.  I include these in the interests of the
general public--I'm hoping people will find our techniques for automating
the installation process on Unix-derived systems useful.  I included
everything so that you could see everything from a developer's
point-of-view.

Although SSLeay has become OpenSSL, it was SSLeay back in 1998 and I'm no
longer developing it.  You'll also see we said it works on things like
Redhat 3.0.  Redhat is up in the 6.x now, but as I said, we haven't been
developing it.  I assume it will still work on all current versions of the
operating systems we mentioned (Solaris/Linux/BSD).  It has not been
tested on all Linux and BSD flavors, only a few specifics.  We know it
works on BSDI, Redhat, Slackware, and Solaris (through hackery).  We have
defines for things like SUN, BSD, and LINUX in the source for various
include files or conflicting code (i.e., these operating systems handle
/dev/syslog differently).  We found that named pipes work different on
these systems (smile). These should be set up for you by our installation
and configuration scripts (we went through great pains to automate this
all for the customer).

People to thank: Bruce Schneier and Chris Hall (Counterpane Internet
Security), Solar Designer, Mark Zielinski, Brian Matthews, and Brian
Martin

Places I'd like to give hellos: w00w00 Security Development, Bindview
Development, CW Security Research, Technotronic, eEye, Roses Labs, and
UssrLabs.

PROFILE 

Server code:
^^^^^^^^^^^^
*.c = 6287 lines
*.h = 709 lines

scripts = 354 lines

---------------------------

Client code:
^^^^^^^^^^^^
*.c = 7731 lines
*.h = 790 lines

scripts = 176 lines

---------------------------

Generic code:
^^^^^^^^^^^^^
docs = 416 lines
configure files = 101 lines
Makefiles = 600 lines

---------------------------

Total:
*.c = 14018 lines
*.h = 1499 lines

Total code: 15517 lines

scripts = 530 lines
docs = 416 lines
config files = 101 lines
Makefiles = 600 lines

Total source in package: 17164 lines
