Re: [logs] SDSC Secure Syslog

bazsiat_private

On Wed, Dec 11, 2002 at 11:00:37AM +1100, Darren Reed wrote:
> In some mail from Balazs Scheidler, sie said:
> > 
> > On Fri, Dec 06, 2002 at 10:33:15AM +1100, Darren Reed wrote:
> > > In some mail from Tom Perrine, sie said:
> > * My opinion about BEEP that it is an overkill. BEEP is simply too
> >   complicated, that's why it is not yet supported by syslog-ng. TCP transport
> >   solves most problems we had with UDP, and using BEEP doesn't give us
> >   anything new or exciting. Encryption can simply be carried out by wrapping
> >   the TCP stream into SSL.
> 
> I have issues with just using syslog over TCP vs UDP due to the record
> boundryless nature of sending data over TCP.  Plain text protocols are
> just too open an invitation for bad programming to introduce security
> problems.

I don't fully agree here. The same stream like behaviour is used (or was
used) on Linux where SOCK_STREAM unix domain sockets were used. In latest
distros they changed this to SOCK_DGRAM though.

Using '\n' as a record terminator is used for instance in Linux kernel
logging, when you tail a file (syslog-ng 2 is able to follow files like tail
-f does), when you receive packets on a TCP session. Record termination
defined by UDP packets boundaries is the exception and not the rule.

Using TCP provides additional benefits:
* using message length over 1024 bytes without IP fragments
* flow control, this is a must, if your network link is congested, and your
  messages are bursty (on a 64k link we lost about 30% of log messages when
  256 long messages were sent in a burst)

I think depending on a complex library to support a protocol (beepcore for
example) might be a worse security decision than using '\n' terminated
lines.

I did not say anything about syslog control messages though, just plain log
messages sent on a TCP connection. I'm trying to avoid control messages if
possible. Pull/push can be described in the configuration, algorithm
negotiations should be done by the SSL implementation (given encryption is
needed), out of band (or urgent) messages can be sent on a separate TCP
channel. The protocol used by syslog-ng (and nsyslogd if it wasn't changed)
is sending data one way only, in fact it could also be shut down for writing
only.

> > * The problem with timestamps should be solved however, being able to send a
> >   complete time on the wire is desperately needed. I'm thinking about either
> >   including a timestamp in UTC + source time zone, or a complete time stamp
> >   with year + zone information. The first would be easier to implement, the
> >   second would be more like the current protocol.
> 
> I would opt for just sending UTC.  I'm not sure the time zone is relevant?
> If it's sending you information, you should know where it is already?
> What you don't know is when something happens there...hence use syslogd
> to tell you :)

Some of my users deployed syslog-ng where sender hosts were located in
different time zones, they told me that they wanted timezones. And as I
don't have installations like those myself, I believe them.

Including time synchronization into the syslog protocol is not good. When
accurate timing is needed there's no match for ntpd. 

Using received stamps is possible with syslog-ng currently (in fact it is
possible to include both received and original stamps):

destination d_messages { 
	file("/var/log/$YEAR/$MONTH/$DAY/messages" 
	     template("$R_ISODATE $S_ISODATE $HOST $MSG\n"));
};

This writes messages like this:

2002-12-11T10:16:42+0100 2002-12-11T10:16:42+0100 balabit bazsi: Test message

The stamp can also be changed to be somewhat more readable (though ISODATE
is a standard), by using $R_FULLDATE and $S_FULLDATE, which is a
syslog timestamp with year information included.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis