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