[syslog-ng] Encrypted messages

todd glassey todd.glassey@worldnet.att.net
Tue, 9 Oct 2001 07:55:46 -0700


----- Original Message -----
From: "Gregor Binder" <gb@rootnexus.net>
To: <syslog-ng@lists.balabit.hu>
Sent: Monday, October 08, 2001 6:37 PM
Subject: Re: [syslog-ng] Encrypted messages


> todd glassey on Mon, Oct 08, 2001 at 05:27:57PM -0700:
>
> Hi,
>
> > The real issue is in building a timestamping regimen and PKI based
crypto
> > service so that the log can be claimed to be "non-repudiated" and can
later
> > for forensic reasons be taken apart.
>
> I think it is going to take a while until it gets there.

I disagree.

> Until then,
> there are various options you have to make a system as syslogd as tamper-
> proof and secure as it can be. Consider creating logfiles with append
> only flags and the like, an besides limiting access to the syslog server
> physically and over the network (using firewalling and client certifi-
> cates), encrypt and sign logs as they are being rotated. You can also
> automate comparison of logs on client/server-side, etc.

Then you are stuck with the underlying FS of the hosting system as part of
the security/access control model and local access can defeat this readily.

>
> > This is way more than just tunneling and BTW, if you need a reason why
this
> > would be a good feature set to add,  are you folks aware that under GLB
and
> > the privacy acts of a number of countries we all as systems admins can
go to
> > jail over what our logs contain.
>
> For one of our customers, we were able to get an agreement with the
> union in charge that we could keep plaintext-logs for five days for de-
> bugging reasons, and instead of just compressing the old logs, they are
> also encrypted and signed with a key that needs a four-eyes passphrase
> to unlock. This is somewhat odd, since I would think that logically the
> process of recording the information in the first place matters, and
> not the storage of this information.

Hmmmm - Still sounds like the System's Admin's were culpable for the OS
Audit Trails...

>
> Besides that, I think it is possible to build a somewhat reliable (in
> all aspects of security) setup with UNIX/syslog-ng/stunnel, and signing
> and integrity checking tools.

Only if synchronous messaging is used to insure delivery of the client's
data to the logging server.

> If "UNIX" is not BSD or Linux, I'd have a
> strong tendency to go compartmented, meaning B1, since there are some
> features that didn't make it into commercial vanilla UNIX yet. Even
> though a very stripped down Solaris properly hardened is good enough
> for all but the most paranoid. Caps and MAC are definitely nice to
> have though.

B1 is no longer a recognized standard. It is a part of the Orange Books
(see: http://www.dynamoo.com/orange/fulltext.htm for a pointer to the Orange
Book itself. The current methodology is the Common Criteria (See:
http://www.commoncriteria.org).

>
> I know that what I'm describing is far away from a completely neutral
> audit trail. But after all this is just about securing syslog, which
> by itself cannot be called a reliable source of information, since the
> actual source (the process logging at a certain facility/priority) can
> always be faked very easily given you have local access.

Given that you have local systems level access. Then you as the Systems
Admin are the weak point in this Audit Model.

> So the main
> goal must be preventing local access to client and server, and
> authenticating and securing the communication between them (which is
> done beautifully by stunnel).

And only accepting information from known sources.

> I'll think about PKI when the networks
> are able to cope with full C2 audit trails going through :)

hey Partner C2 is old hat. Most if not all commercially available OS's will
support C2 and most have a hardened mode that approaches what was known as
B1 as well.

>
> Greetings,
>
> --
>  ____ ____
> /  _/| -  >  Gregor Binder <gb@(rootnexus.net|sysfive.com)>
> | / || _\ \
> \__ Id: 0xE2F31C4B Fp: 8B8A 5CE3 B79B FBF1 5518 8871 0EFB AFA3 E2F3 1C4B
>
> _______________________________________________
> syslog-ng maillist  -  syslog-ng@lists.balabit.hu
> https://lists.balabit.hu/mailman/listinfo/syslog-ng