Re: [logs] SDSC Secure Syslog

avalonat_private

In some mail from Tom Perrine, sie said:
> 
> Mostly in jest.  But, more, I was hoping that you had RFC 3195 code
> that we could test with, or perhaps had written some
> super-secret-but-it-works BEEP library.

Unfortunately(?) no as I've been busy with other things.

> Aha!  Yes, I suspect that our ideas about input channels, switch
> logic and output channels are *very* similar.  Our config files are
> probably very reminiscent as well.  And your implmentation predates
> syslog-reliable, right?  We also looked at syslog-signed and ...

My implementation predates the IETF group forming (as does syslog-ng).
A bunch of people on the list even convinced me to wander over to the
USA to say a few words at the first BOF for the IETF group :)
CVS locally tells me I started on it in April 1998 but that might
just have been when I started using CVS for it.  Seems like a whole
lifetime ago now!

[...] 
> Way back when, we (Andrew Gross, mostly) played with crypto hash
> chains, with per-host keys for everything from the original client,
> through all the relays into the final storage system.  Yup, it was
> ugly, and the crypto-signing overhead was "amausing".  But you had a
> list of timestamps and hash chains all the way back to the source, IIRC.

That sounds familiar :-)

> However, as bad as it is I suspect that many sites have "solved" the
> performance problem.  Either they just don't bother turning logging
> on, or log selectively, or have spent some time working on syslog
> relay trees, or other methods.

Well, the big problem with lots of data, to me, is not how to collect
it all in a reliable fashion but what do you do with it all ?  Do you
just archive it to CD or DVD on a regular basis in case someone with
a warrant comes knocking or do you generate load graphs or something
else from it ?  Who's going to look at all the log output from 20k
nodes when they're all screaming and sending a message every second ?
I dealing with so much data, there are logistical problems as much as
technical ones to solve that make the technical ones seem trivial.

So, in a sense, what it comes down to is you only spend serious effort
logging data securely that you care about and the rest goes to /dev/null,
whether directly or indirectly.  If you're doing that and the messages
you are interested in only make up a minority of those being generated,
why do you need such high performance as opposed to good filtering on
the sender(s) ?

> However, I must point out, that on more modern hardware (Sun Ultra-1,
> or modern PC) we just haven't seen classic syslog performance as a
> problem, because we are only logging (UNIX) system log data through
> it.  To avoid some of those problems ourselves, we shoot the web logs
> through other means, and the Windows world does its own thing.

I think you'll find that there have been changes to both the
implementation of syslogd (in Solaris) as well as filesystem
changes (Solaris, Linux) that are more to credit than current
hardware technology.

> These days, it still seems that when we lose syslog data, its always
> due to router congestion, and not to problems in the syslog daemon
> code itself.  But as I said, we are already limiting our log
> generation rate.

Ok, so it sounds like you understand the problem of having "too much
data" to process at the central node.

> PCIx running at 166 Mhz does hit about 1 G bytes/sec.  We have 10 Gig
> E hardware in house, as well as the 10 Gig E testing lab.  People are
> seeing "useful percentages of theoretical" (that's all they'll say :-(
> )

So there is a PCI bus (PCIx) that can support high data rates,
what current motherboards support it and what's their internal
data transfer rate like ?

> There's also IBM Infiniband which can run at 2.5 G bits.  If you don't
> mind AIX on Power3 or Power4.

Which is about 1/3 of the speed of PCIx.

> Hmmm, I'll keep that in mind.  Good to know.  But we ditched all the
> Ultra-5s and went back to Ultra 1 and 2s.  The 1s and 2s seemed to
> outperform the U5 by *quite* a bit.

The point I was trying to make was when you're trying to get really
high performance out of standard hardware, you need to tune lots of
corner cases.

Darren
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis