Slashdot Mirror
SDSC Secure Syslog
Wee writes "I saw this morning that the San Diego Supercomputer Center has released Secure Syslog, a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time. It adds security and performance features (modular design, highly scalable), while retaining backwards compatibility. According to their announcement, it is the first syslog implementation to target "syslog-reliable" (RFC 3195) functionality and it is the first syslog targeted at very high performance and forensically-sound auditing. It's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned). If you have high-traffic systems and you need reliable syslogging, this might be a worth a look. Those needing syslogging over TCP/BEEP, sockets, etc as well as UDP might also want to check it out."
...like syslog, for instance. Very extensible, appropriately hieroglyphic configuration, arbitrary manner of operation... it had everything a successful Unix daemon needs.
Except security. Welcome to the 21st Century, syslog.
FYI, this is BEEP
No, it's not Captain Pike's YES/NO beeps
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
free for slow adoption.
the sooner more people can use it, the sooner corporate products will have to support it, and the more secure we all can hopefully be.
after all, we haven't had much luck getting the newer snmp versions deployed.
ostiguy
I suspect that many of the top corporations may find a use for this in wake of all of the "Oops, I lost that important file!" scandals, and the need to trace steps of hackers too.
I see a great future in this and the products that come after it. Kudos to the developers!
If you need syslogging over TCP and want a *way* more configurable system for filtering syslog destinations, including regex filtering and per-host routing, you might want to look at syslog-ng. It works great for me, and is already GPL'ed, so no waiting for a license change.
"I feel that if a person can't communicate, the very least he can do is to shut up." -- Tom Lehrer
"a replacement for the standard Linux/UNIX syslog daemon they've been working on for some time....it's currently under the UC's "free for non-commercial use" license, but they are looking at moving to a completely open license (BSD-style licensing was mentioned)."
Sorry to sound like a weenie, but if its not GPL'd I'm not interested. This is one of those "core parts" I'm usually talking about that needs to be gpl if its going to get included in every distro. I know there are important parts of every linux distro that aren't GPL, but the more software we add that isn't GPL the worse off we are. Don't get me wrong, I'm all for proprietary add-on software(desktop/server apps, games etc) for linux, but the core software, ie base OS, system utilities, desktop WM, internet browser/connection software and basic office capabilities need to be GPL.
If you wanna get rich, you know that payback is a bitch
Set up a locked down host on your network (no services running) except for syslogd. Then other hosts can use remote logging to log to this host. In case of even a widespread system compromise, your locked down logging host is completely safe and your logs can be obtained through console login.
See section "SUPPORT FOR REMOTE LOGGING" in man syslogd.
And as long as you remember root can't have any shell other than
And of course you understand the next maintenance pack from HP will contain a depot that will overwrite key libraries without warning and break the thing completely.
In short, it works just as well on HP-UX as anything else does.
Feel my pain. I admin many large HP-UX machines.
Wow did anyone else notice the Brazil references in RFC 3195?
It's good to know that geek culture still persists and can perimate into even the most serious subjects.
- Serge Wroclawski
Yes. It's the Ellen Feiss protocol.
Modular!
/dev/null is all the syslog I need!
Scalable!
Backwards compatible!
Linux!
RFC 3195 functionality!
high performance!
forensically-sound auditing!
If only it was vertically integrated. Oh well, better luck next time!
till then,
I don't need no instructions to know how to rock!!!!
Standard syslog has several problems which I think are quite serious.
Remote logging is a joke. There is no authentication, and no notification whatsoever that the event was received by the remote syslog daemon. An attacker can fill the remote syslog with garbage data if they so choose.
The records are entirely unstructured and not validated. The timestamp, hostname, and process id are all volunteered by the application, not something that's noted by syslogd.
There is no guarantee whatsoever that an application that has called syslog() will have its messages safely recorded when the function returns. I'm not talking safely tucked away on disk if the system crashes, but even written into the buffer cache by syslogd when syslog(3) returns. See end of post for details.
If syslog's receive buffer is full, syslog(3) will block. This means that if syslogd cannot keep up with the rate of messages, which is a really easy condition to find yourself in given that by default syslogd calls fsync() after every log file update, your system will slow to a crawl. You cannot even login(1) since most systems record this activity to security logs.
P.S. syslog() returns as quickly as possible. Try an experiment. Generate a random number, call syslog() with this number as a string, and then open() /var/log/messages, seek to the end minus 4096 bytes. Try to find the random number. I have tried it 20 times and never has the number been there by the time read() was called. It takes longer than an application doing syslog()/open()/lseek()/read() for syslogd to record it into to the buffer-cache, let alone fsync() it to disk.
Copyright 2002 The Regents of the University of California All Rights Reserved
Permission to use, copy, modify and distribute any part of this SDSC-syslog program for educational, research and non-profit purposes, without fee, and without a written agreement is hereby granted, provided that the above copyright notice, this paragraph and the following paragraphs appear in all copies.
Those desiring to incorporate this SDSC-syslog program into commercial products or use for commercial purposes should contact the Technology Transfer Office, University of California, San Diego, 9500 Gilman Drive, La Jolla, CA 92093-0910, Ph: (619) 534-5815, FAX: (619) 534-7345.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SDSC-syslog PROGRAM, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE SDSC-syslog SOFTWARE PROVIDED HEREIN IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS. THE UNIVERSITY OF CALIFORNIA MAKES NO REPRESENTATIONS AND EXTENDS NO WARRANTIES OF ANY KIND, EITHER IMPLIED OR EXPRESS, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR THAT THE USE OF THE SDSC-syslog SOFTWARE WILL NOT INFRINGE ANY PATENT, TRADEMARK OR OTHER RIGHTS.
SDSC-syslog is developed by Tom Perrine at San Diego Supercomputer Center at the University of California, San Diego. Support for this effort is provided by Commerce Net (CN-NGI01-009).
After some not-so-trivial digging, I found the UC guidelines for releasing software. Essentially, any software written by a UC employee can be made "public" as long as procedures are followed and it's released for non-commercial use (with a license statement accompanying the software stating such).
Bash away at the software's non-GPLness, but I for one think it's pretty spiffy that anything a UC faculty, student of staff member writes can be given away, in source form, to the public. Anyone who works in the private sector who is allowed give away software written on the corporate dime can either speak up or hush up.
Anyway, cut 'em a little slack, would ya? They're trying.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
What do you use for webserving?
... his comment appears to be a more naive equation of Free Software==GPL, which of course is mistaken, as you correctly point out. Free software can be public domain, it can be BSD licensed, it can be Artistically licensed, it can be apache licensed, it can be LGPLed, indeed, it can be licensed under any number of such licenses.
... people often say provactive things in making very valid points.
... he simply needs to educate himself on the nuances of free software licenses, and the difference between free software and the GPL, which is merely a subset thereof. Hardly a sign of idiocy, merely a sign of ignorance, a condition that is easily corrected.
He probably uses apache, although he could be using any one of several free webservers, some of which are in fact GPLed.
Either you're an idiot or you're trolling. There is no in between. Personally, I think you're an idiot.
It is a pity you make such a good point about the diversity of free software licenses available, then ruin it with that sort of inane flamage.
First, he may or may not be trolling. I suspect probably not (but I could be wrong)
Second, to say there is no in between is foolish. Almost as foolish as Dubya's "your with us or you're with the terrorists," which the Iranians quite correctly rebutted with "we are neither with you, nor are we with the terrorists, and you sir are a pathetic simpleton" (a nuance obviuosly lost on our current regime). There is a huge middle ground
Finally, he is hardly an idiot. Naive in equating the GPL with free software, but had his comment replaced the term GPL with "free software" it would have been very valid and on point. The core UNIX utilities and operating system need to be free software, unencumbered by constraints such as "no commercial use" (or the asinine "no use to violate human rights", where the definition of human rights varies from county to county, state to state, and very obviuosly nation to nation). On that point he is correct
The Future of Human Evolution: Autonomy
syslog-ng is nice, it has the advantages of TCP and a smart filtering scheme, but that's all. For example, logging to SQL is very weak, it's more like a hack.
For example, a syslog version that does everything syslog-ng does, and more, and has decent SQL logging, and a sound security mechanism (PEO) is msyslog
However, even msyslog is quite simplistic when compared to sdscsyslog. IMO, sdscsyslog has an extremely intelligent architecture, that allows for easy expansion, and easy implementation of features that neither syslog-ng nor msyslog can dream of.
Although it's nice to see people attempting to improve one of the more regularly broken unix core services, I still think that the whole syslog design of a monolithic central multiplexed logging daemon is the Wrong Design.
Dan Bernstein's multilog, from his daemontools package, is, in my opinion, a good example of the correct way to do logging: a single process logs the stdout and stderr of each daemon, goes to great lengths to ensure that no data is lost, and handles logfile rollover automatically. With this tcpserver/tcpclient utilities from his ucspi-tcp package, it can be simply done over a network as well.
Of course, DJB's code, while source-available, is not in any way Free Software, and daemontools in particular currently is inextricably linked into his extraordinarily dubious "slashpackage" system, making it a potentially annoying choice for anyone reselling or distributing systems based on it. Cronolog, which was originally created to manage apache logs, looks like a promising GPLed replacement for multilog, but despite lots of grumbling along those lines, nobody has written a gpl/bsd replacement for daemontools...yet.
News for Nerds. Stuff that Matters? Like hell.
I think many people could do themselves a great service by simply studying the vsftpd security libraries. Those are generic enough to be used by almost any other application, and provide a solid foundation to write applications that do not fall apart under classic C exploits: buffer overflows, etc.
Check here the vsftpd website.