In some email I received from Simon Richter, sie wrote:
>
> > > - Possibility to use this protocol on a serial cable: We have a machine
> > > with eight serial ports and no network connection as the log server
> > > here. I don't want to open the log server to the net or even expose its
> > > presence to the casual hacker using nmap.
>
> > This is an implementation issue IMHO.
>
> Not really. The protocol should be able to work without multiple
> channels or out-of-band data, or we need an underlying packet transport
> mechanism. And any additional mechanism increases the possibility of a
> buffer overrun/remote root attack, which I, if I cannot avoid this on the
> server, still want my logging host to be exempt from.
You're confused about what you're using your serial device as. Unless you
are using "custom software" with syslogd, your serial devices are being
treated as storage devices by syslogd, not remote syslog daemons. This
effort is to build/describe a protocol which provides a more reliable and
secure mechanism for syslog daemons to talk to each other - not where they
store messages.
If you want to continue using serial devicse for syslog stuff, I'd suggest
piping syslog messages into gzip and sending gzip output down your serial
lines.
> > > - Compression of equal/similar(?) lines at the originating host.
>
> > This should be accomplished with a repetition count assigned to messages.
> > "Last message repeated NNN times" make it quite difficult to find the
> > original message.
>
> The "last line repeated" stuff has the advantage of having the line logged
> at least once, even if the system crashes later on (DoS attack). We could
> have the receiving host bundle information later on (such as in
>
> 13:30 abc def[123]: ghi
> 13:33 abc 300x def[123] ghi ),
>
> but I still want stuff to be logged on the first occasion.
I think that is an implementation issue. A protocol (which is what we're
here for) should dictate how messages are formatted and sent. That "300x"
thing is fluff and may be represented differently for different
implementations. For example, in nsyslogd, it puts the time of the first
and the last message in the "received X times" message. Also, the time at
which the log entry is made is independant of both of those events.
It is of *vital* importance (as I'm sure audit people will agree) that it
is possible to store each message that is generated and none of this
compression thing with "multiple matching messages received" crap.
Darren
