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 and Mark Zielinski 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.