6:53 p.m.
On Wed, 2004-09-08 at 19:33, Thomas Biege wrote:
I prefer binary format too because the semantic of data can easily
and
clearly be gained by using structures.
Binary structures are generally helpful in order to store a significant
effective volume of data, in a small amount of memory, so are
appropriate in the kernel. Outside the kernel, they are usually more of
an impediment to effective audit log processing - just another step you
have to work through before getting useful info.
This helps developing host-based IDSs.
As a developer of several host-based IDSs over the years, I'd have to
disagree. :)
The reason for the lack of HIDS on Linux is a missing syscall
auditing and audit trail mechanism.
But it is just a technical detail not worth discussing about. :) Just
add a switch (or a post-processing tool) and let the admin decide.
Fair enough.
> > Binary records (ie: Stored as binary on disk, rather than
as a
> > transition format between kernel and daemon) can be a real problem -
> > we've run into the following examples:
> >
> > * Trying to conduct forensics investigations on another machine is very
> > difficult:
> > - UID mappings are often different, so UID '123' on one machine,
> > translates to an entirely different user on another. Converting to text
> > format on the host machine at daemon write-time solves this problem.
> > This same problem exists on windows, with SID mappings.
> > - Even if analysed later on the same machine, user 123 may have been
> > deleted.
This happens even in text-format.. there will be always a race between
syscall generation and meaning of audit tokens like IDs, filenames,
sockets, whatever.
Absolutely. As I mentioned earlier, I'd recommend going with a
text-based format throughout, for exactly the reasons you talk about
above. However, binary in-kernel, and as a transition format between
kernel and userspace, does have some advantages (particularly if you are
going to do filtering at the daemon).
IF we're going to go down the path of a binary transit format:
Milliseconds worth of delay is an acceptable risk for most
organisations, for most events. On a per-event basis, the chance of a
user being deleted between picking out the UID in the kernel, and
converting the event to text format when delivered to user-space is very
small.
Try and convert the binary event to text a few months, or years later
however, and you're in real trouble.
An exception is probably the file-related stuff, eg: unlink - by the
time you send the inode to user-space, there's a fair change it's
already gone - which is why I recommended text-conversion of file names
directly in the kernel, which would also assist with the process of
filename matching in the kernel as Olaf proposed.
> > - Trying to view a Windows binary eventlog on a machine
that it was not
> > generated on can cause massive problems - the "string conversion
DLL's"
> > that exist on one machine (eg: exchange server) to translate event
> > strings to text format, may not be installed on another machine, so
> > windows reports garbage.
This is a technical problem of Windows. :)
Absolutely. And there are about a dozen more problems with the windows
implementation of auditing.. and several more in solaris, and ... you
get the idea. However, it is a general point, that illustrates a
potential problem related to binary record format.
> > * Disk forensics are more difficult
> > - There have been situations where a system (including audit log) has
> > been utterly trashed. dd if=/dev/hda | strings (or slightly more
> > targetted tools) can provide some potential audit strings of interest if
> > you can kill the system quickly enough before the attacker does too much
> > overwriting. Pulling out binary data is a little harder when you don't
> > have inodes to work with.
Such a setup is even prone to more errors resulting in problems while
doing post-mortem analysis.
Again, this is just an illustration of the problems of binary formats.
In an ideal setup logs are signed, encrypted, and sent away over a
dedicated secure network to a secure log host on-the-fly.
Keeping the logs only on the disc of an exposed machine is... stupid. :)
Agree. However, keep in mind that 'ideal' is probably not a good term to
use. 'Ideal' means different things to different organisations - some
organisations have a low priority associated with audit log information
(they use it merely as a 'potential problem indicator', rather than
'court admissible data') - so having the overhead of signing and
encrypting log data on the client would be very bad for them.
Keeping logs only on the disk is not something I would recommend
personally in most circumstances, but there are some situations were
even this would be considered 'ideal' for an organisation in the context
of their risk assessment, and within the boundaries of other potential
controls that they have in place.
My point, I guess, is that you can put in as many options into the audit
subsystem as required, in order to meet a perceived 'ideal'
implementation, but as soon as you start mandating them, you start
loosing potential users, as their idea of ideal is likely to be very
different than ours. (eg: halt on audit fail, mandatory encryption,
etc.)
El-quicko summary:
* Binary formats are still non-optimal
* The log that's written out from the daemon REALLY needs to have any
'transitory' binary data mapped to text format (eg: UIDs, filenames). It
would be better for this to happen in the kernel so that race conditions
are less of a problem, but conversion of most data at daemon might be a
reasonable trade-off if required.
L.
--
Leigh Purdie, Director - InterSect Alliance Pty Ltd
http://www.intersectalliance.com/