Darren Reed wrote:
> In some email I received from Chris Calabrese, sie wrote:
> [...]
> > > > - Message formats are not in scope of this WG (if formed)..
> >
> > What exactly does this mean? If it means that the implementation is free
> > to store records any way it likes on the disk, then I agree. I disagree
> > if it means the WG produces a document that merely says something like:
> > "Logs are sent as an uninterpreted ascii stream over port TCP port XXX,
> > with IPsec as an option for authentication and confidentiality."
> >
> > Without structure in the messages, we're still stuck with the current mess
> > where programs can't parse logs without all kinds of special log-specific
> > knowledge.
>
> The message that came out of the BOF was that this is a different problem
> to the original one (of investigating the security problems inherent with
> the current proyovol), being looked at, and may even be the responsibility
> of a different group (such as IDWG - Intrusion Detection). The IETF does
> not encourage or support redundant and separate efforts being made to work
> on the same thing.
So this essentially limits us to the current protocol which sends a numeric
facility, a numeric severity, and then a textual message.
In that case, here's my proposal for protocol changes (this is off the top of my
head folks).....
1. The number of facilities be greatly extended. Facility names and concepts
should be chosen to be OS independent (i.e., they should work at least for
all major *NIX variants and for NT). I think this may require coordination
with the IEEE POSIX community and X/Open.
2. Transports be expanded from the current UDP over IPv4 to: UDP (ipv4/6), UDP
w/ IPsec (v4/v6), TCP (v4/v6), TCP w/ IPsec (v4/v6), and TCP w/ TLS (v4 only
- presumably all v6 implementations have IPsec).
3. The TCP versions must allow record "streaming" with appropriate connection
management to shut down the stream if idle, etc.
4. TLS/IPsec modes should support signing only and encrypting and signing.
5. All modes should support chaining of timestamps so that you can show that a
process generated a log at T on A, A sent to B at T', and B sent to C at
T". If this is considered excessive then just the initial timestamp (since
the final timestamp can be stuck in without protocol support.
6. TLS/IPsec modes should support chaining of signatures and timestamps so that
you can show A sent to B, who sent to C. If this is considered excessive,
then it should be dropped since most logs will only go through one hop (or
through transparent proxies if multi-hop), and the implementation can store
final-hop signatures without special protocol support.
7. The RFC should include recommendations for ULM-like tags to be used in the
message.
Implementation wise, I'd go with:
1. /dev/log be replaced with /dev/log/facility-name. This way, access to the
facilities can be protected by file permissions. A set of Unix-oriented
guidelines should also be drawn up for this indicating that, for example,
only root can write to /dev/log/KERN, only members of group mail can write
to /dev/log/MAIL, etc.
2. syslog.conf be extended from the original version to allow filtering by
regular expressions, '|' (pipe-to) destinations, flags to identify what
transport mechanisms and security levels to use when sending logs remotely,
flags to identify who transport mechanisms and security levels to require
when receiving logs, and what hosts to receive logs from.
3. Storage of logs on disk include the ability to store signature information
passed by TLS, IPsec, or generated locally.
4. Hooks be included (where it's easy to do) to extend the system to store log
records in a database, with encryption, etc., etc.
5. The message format generated from the options to logger(1) and syslog(3) be
ULM-like tags. Additionally, facility, priority, and timestamp information
should be stored in the log datastore with ULM-like tags. Options to
syslog() and logger() should be extended (requires X/Open and/or IEEE
support here) to specify passing of user-name, tty, and other process
oriented information. All told, this would mean the system could
automatically generate tags at least for 'identifier' (usually program
name), user-id, tty, process-id, thread-id, facility, and priority.
6. Utilities be included to query stored log records, including signature
verification, search by data attribute (get me everything with facility=mail
and originating-machine=fubar.mycompany.com), etc. This will allow
decoupling of the record storage format with the ability to process the
records. This utility could also be submitted to the IEEE and/or X/Open as
the standard interface to logged data.
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
