
SRS is a program that streams a copy of a client's logs as specified
by the syslog.conf file to a trusted server on a remote site.  It
provides strong authentication and secure communications between the
client and the server through an SSL tunnel.  It is intended as a
replacement for syslogd.

See the file INSTALL for installation instructions.  See LEGAL for
license terms and other legal issues.  


FEATURES

 o  Secure logging.  All communications are automatically and
    transparently encrypted.  SSL (Secure Socket Layer) v3.0 is used for
    the authentication and encryption.  A conventional cipher (3DES,
    RC4, etc.) for encrypting the session.  Encryption is started before
    SRS authentication, and no data is streamed or transmitted in the
    clear.

 o  No special configuration of syslogd is needed (with the exception of 
    running setup.sh); everything that syslogd provides in regards to 
    functionality can be provided by SRS.

 o  Never trusts the network.  Minimal trust on the remote side of
    the connection.  Minimal trust on domain name servers.  Pure SSL
    authentication never trusts anything but the private key.

 o  The client SSL authenticates the server machine in the beginning of
    every connection to prevent trojan horses (by routing or DNS
    spoofing) and man-in-the-middle attacks, and the server SSL 
    authenticates the client machine before accepting any commands or
    requests from the client. On top of this, SRS will send its own 
    challenge cookie.

 o  Client and server keys are generated by RepSec, Inc. Each client and
    server is provided a unique key.

 o  A complete syslogd replacement.


WHY USE SRS

Currently, all system events are recorded in the system logs generated
by syslogd as dictated by the syslog.conf file.  In the event of a system
compromise effecient attackers will attempt to erase all record of the 
intrusion by erasing the corresponding logs of his/her activities.

If some form of remote logging is not performed, it may be impossible
to determine what happened to the system and by whom during the attack.  
If you use remote logging without any authentication or encryption (as 
the normal syslogd does), you risk losing that data if the remote machine 
is compromised or the data altered before reaching its desired destination. 
You also have a high risk of this data being sniffed, altered, or fake entries 
added by an attacker. SRS prevents both of these.

By streaming a copy of the local system logs to a remote location through 
an encrypted tunnel, it provides a mechanism to review the incidents against 
a host if the system and its logs are compromised.

Encryption, authentication, and integrity protection are required to
secure networks and computer systems.  SRS uses strong cryptographic
algorithms to achieve these goals.


OVERVIEW OF SECURE REMOTE STREAMING

   SRS client   The client program runs on the host machine.  It 
		monitors data being written to syslog, and streams
		a copy of the syslog entries real-time in to an
		SRS streaming server.  Data is streamed only after 
		it performs authentication, and sets up the SSL 
                tunnel. The client then performs the functionality 
                of syslogd.

When started, the SRS client connects to the primary _info_ server, 
verifies the server's authenticity, exchanges keys (in a manner which
prevents an outside source from eavesdropping).  Note: Diffie-Hellman
is used for the key exchange. Next, the SRS client will verify it's
running the latest software, and if not, it will request the latest
version from srs@repsec.com. As soon as the request is received, RSI staff
will contact you. After this, the info server will pass the SRS client a
specific list of streaming servers the client can stream to (this list is
updated dynamically).

The SRS client will then disconnect from the info server, and connect
to the first streaming server in its list.  It will continue down
the list until it connects to a streaming server.  At this point, the
same encryption/authenticaiton scenario as that of the info server 
will commence. If it is unable to connect to any streaming servers (however
unlikely), it will start spooling data to a local spool file, while continously 
looping through the list; trying to connect to a streaming server. Once 
it is able to, it will send over the spooled data and continue normally.

Upon successful authentication, the streaming server will pull from
the SRS client, a copy of syslog.conf, and create the appropriate
logs on the streaming server.  The SRS client will then stream real-
time all the host's syslog entires to the streaming server as they 
are written locally (this is all encrypted and this information will
remain confidential).


SSL AUTHENTICATION 

SSL authentication is based on public key cryptography.  The idea is
that there are two encryption keys, one for encryption and another for
decryption.  It is not possible (on human time scale) to derive the
decryption key from the encryption key.  The encryption key is called
the public key, because it can be given to anyone and it is not
secret.  The decryption key, on the other hand, is secret, and is
called the private key.

LEGAL ISSUES

See the file LEGAL for all legal information.
THERE IS NO WARRANTY FOR THIS PROGRAM.

In some countries, particularly Russia, Iraq, Pakistan, and France, it
may be illegal to use any encryption at all without a special permit.

Note that any information and cryptographic algorithms used in this
software are publicly available on the Internet and at any major
bookstore, scientific library, or patent office worldwide.


Bug reports should be sent to srs@repsec.com.


ABOUT THE AUTHORS

This software was originally written by Matt Conover <mattc@repsec.com> 
and Mark Zielinski <markz@repsec.com> in the United States for RepSec, Inc.

ACKNOWLEDGEMENTS

Many people have contributed to the development of this software: Brian
Martin, Jay Dyson, Brian Matthews, and everyone else that helped in the
basic development.

SRS incorporates the SSL implementation written by Eric Young
(eay@mincom.oz.au), a library providing an interface for Secure 
Socket Layer applications.

Special thanks: a special thanks goes to Solar Designer for 
source/security audits, bug fixes, and his ideas.

We would also like to acknowledge and thank Bruce Schneier and Chris Hall 
of Counterpane for their work in implementing the SSL code/libraries into 
the SRS code, and providing a secure cryptographic enviroment.


Copyright (c) 1998 RepSec, Inc. 

