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!
BEEP is a "roll-your-own" protocol standard. See the BEEP web site for more details.
"What luck for the rulers that men do not think." Adolf Hitler
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
What do you use for webserving?
What about database service? MySQL has poor functionality in the fully-GPL version, and PostgreSQL is BSD-licensed.
Either you're an idiot or you're trolling. There is no in between. Personally, I think you're an idiot.
Remember that what's inside of you doesn't matter because nobody can see it.
... to help your ISP to maintain massive logs of your online activities, neatly packaged for law enforcement and other "authorities".
Thanks!
Tuus crepidae innexilis sunt.
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.
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
> Yes. It's the Ellen Feiss protocol.
Nah, beep's an actual protocol. You're thinking of 'bleep'.
25% Funny, 25% Insightful, 25% Informative, 25% Troll
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.
Feel my pain. I admin many large HP-UX machines.
To quote Bill (the Cat) "BLLLLFFFTTT"
If you want Pain then try using AIX...
I do remember seeing a piece of advice for those wishing to become System Administrators...
Find an OS that you hate... Congratulations, you will be working with it for the rest of your life.
After Solaris, I thought HP-UX was bad... Not awful, but bad... Now I deal with AIX...
Z... Admin of AIX, HP-UX, Solaris and Linux boxes... I try to forget the SCO machines.
-- Under/Overrated is meta-moderation, and therefore is Redundant.
Another problem with DNS is that your logs can be "poisoned". DoS attack is a smaller problem when compare to poisoning.
No clue. IANAL. You might try looking through ucop.edu for a liason or contact that can answer your question.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
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.
It's very funny, only yesterday i published on a mailing list my proposal for a new syslog daemon architecture:
:-)
Syslog Daemon Architecture
I wrote this document for the msyslog project.
And then, today, i noticed the sdscsyslog announcement on Slashdot!
There are many similarities between their architecture and my proposal:
- modularity
- extensibility
- scalability, etc.
IANAL, but I would define commercial use as the opposite of "public use" - as a gov't. entity, everything you do is in serving the public good, which would be the antithesis of commercial use. I've seen commercial use defined as "if your entity's domain name ends in .com" - which is reasonable in most cases. This is how ncftpd licenses their FTP server, for instance (last I checked) - it'll work without a license if your domain is .edu or .org - basically anything other than .com (I believe that includes .gov).
Hope this helps!
Cheers.
That's so lame. How many commerical site are:
Well, not exactly.
The traditional syslog is old, broken and dying. It doesn't count.
syslog-ng is cute and has TCP and clever message filtering. But that's all.
msyslog goes beyond that and adds true and reliable SQL logging (SQL in syslog-ng is a joke), PEO message protection (tamper-evident) and a somewhat more extensible implementation. But it stops there.
sdscsyslog is the first attempt to solve all the problems with all the other implementations, and also adds long-awaited features. However, it does not overlap with my proposal, because mine is just... heh, just a proposal, while they already have a running application.
But i agree with you. There is some fragmentation in the Open Source / Free Software world.
Does anyone else find it somewhat amusing that nearly every story about a core unix process, be it an improvement or a security notice, features a thread promoting some DJB utility?
Even more amusing is the obligatory disclaimer about how annoying DJB and his licenses are, the absence of development on some of the packages (djbdns comes to mind), or some other quirk that makes them difficult to replace what's already there.
Very many software products that have "free for non-commercial use" licenses deem use by a state or local govt to be "commercial use" in that the govt agency uses it for internal purposes exactly the same way a commercial business would be using it for their own internal I.T. needs, hence they want you to pay for it. HOWEVER, you could always claim that you're use in a city government I.T. department constitutes your researching the software for acceptability in applications of government comuter systems security.... and we all know how slow government operates, hence you could be researching it for a long, long time :-)
sdscsyslogd-1.0.0 RC4 does not compile on Solaris 8, nor on FreeBSD.
../../src/message/message.h:25, ../../src/outputmod/outputmod.h:23, ../../src/include/chaninfo.h:23, ../../src/include/chaninfo.h:23,
The 'configure' script does not report any problems, and correctly detects the operating system. FreeBSD has some problems with the 'sed' substitutions for "include/const.h".
Using GCC on either platform, the compile pukes in "src/util/netaddr.h". It appears that SDSC syslogd can only successfully compile on Linux, due to use of Linux-specific socket structure declarations in this file?
gcc -DHAVE_CONFIG_H -I. -I. -I../../src/include -I../../src -g -Wall -Wno-inl
ine -Wstrict-prototypes -O2 -pedantic -c `test -f config.c || echo './'`config.
c
In file included from
from
from
from config.c:19:
../../src/util/netaddr.h:98: field `sa' has incomplete type
../../src/util/netaddr.h:99: warning: ISO C doesn't support unnamed structs/unio
ns
../../src/util/netaddr.h:99: warning: no semicolon at end of struct or union
../../src/util/netaddr.h:99: parse error before numeric constant
../../src/util/netaddr.h:100: warning: built-in function `sin' declared as non-f
unction
../../src/util/netaddr.h:102: parse error before '}' token
../../src/util/netaddr.h:102: warning: ISO C does not allow extra `;' outside of
a function
In file included from
from config.c:19:
../../src/outputmod/outputmod.h:75: field `sendTo' has incomplete type
../../src/outputmod/outputmod.h:82: confused by earlier errors, bailing out
I do not deploy Linux. Ever.
That was UDP, not DNS.
Silly braintypo...
or
.com, .org and .net
4. have both
I once worked for an organisation that had something like 30 seperate domains all pointing at the same server. We had about half a dozen virtual servers that pointed to subsets of the site, but most just pointed an the main website.
Democracy isn't about no one telling you what to do. It's about everyone telling you what to do.
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.
do we really need specialized encryption built into each application? why not just use something at the stack level?
For the license.
If this product were to be released under a Free-software license I'd definately consider it on our network. As it is I (and probably many others) will use something else like syslong-ng or metalog, despite the fact that SDSC-syslog seems to be far more technically competent.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.