On Wed, 20 Oct 1999, Volker Wiegand wrote:
> On overall design:
> What is the scope of this effort? And the desired outcome? First thing is
> a new protocol for the transfer of logging information between different
> machines over a network.
I would put it "over any means of communication". A network can easily be
sabotaged by a remote attacker and is also imposing a risk to the
integrity of the logging machine. A direct serial link is way easier to
secure than an IP stack.
> - It can ease "log transfers" (in analogy to zone transfers)
> So maybe we assign a new port to nsyslog (maybe 714 tcp + udp)?
Again, this requires a TCP network, and I do not think this is a good
idea. I have no problem with using TCP as the transport protocol on less
secure sites, so allocating a WKS is a good thing.
> [Excursion into implementation: you want a local /etc/facilities, which
> can also be implemented with a NIS map, an LDAP service or anything that
> can empower it like /etc/services].
[Excursion into RFC writing: It is up to the system operator to ensure
that the protocol used for distributing /etc/facilities is not subject to
spoofing]
> Within the local machine this touches the config file and the output
> format, and of course the daemons. I would like to keep the basic
> /etc/syslog.conf design, but have more flexibility in extending it.
It is not necessary to keep the old format. I think a section allowing
mappings from old-style facility.severity to /etc/facilities is more
flexible. The new configuration file format is then freely adjustable to
the new requirements.
> On the network layer I would prefer to have a new port assigned (as stated
> above) and some more dedicated fields. Technically in the style of the
> current severity "<1>". Maybe with different enclosure characters or with
> a definition of the positional structure.
I like the way PPP encodes its packets. It is efficient yet extensible.
> - Facility (with the IANA assigned number above)
- Severity
- Sending machine
> - Timestamp (from the sending machine, GMT or even time() format)
> - Hash value / signature / other authentication stuff
- Actual data :-)
> Generally I agree that human readable formats are to be preferred.
I would encrypt the data on the network, as sniffing syslog info is a
valuable source of information to hackers.
> On time stamps:
> Within the local machine, timestamps are probably no big deal. On the air,
> I assume we agree by now that a sending machine includes its own timestamp
> (however accurate that may be) in a message. I could imagine that the
> stamp is enclosed in sqare brackets, and when multiple hops are traversed,
> they could add their own stamp within the brackets, separated by a comma:
> "[t1,t2,t3]". The time stamp format should be fixed. And Y2K safe :-)
The hosts should also add their name, I think. The time could be about
anything in GMT or local time, but should always tell which timezone the
server is in (including DST information, of course).
Simon
PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
