Consider the simple perl script (attached). This will put an entry in to
the logs that looks like user bob (or whoever you want) knows the root
password.
My apologies if I do not have the correct syslog facility and priorities
- but this is for demo only :)
The perl script attached can be run by any user (on a default RedHat-7.2
install anyway). The ability for arbitary users to generate real-looking
log entries should be enough to make the logs inadmissible in court.
Dan
#! /usr/bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
use strict;
setlogsock('unix')
openlog('su(pam_unix)', 'cons,pid', 'auth');
syslog('warning', 'session opened for user root');
syslog('warning', 'session opened for user root by bob(uid=123)');
closelog();
exit;
On Tue, 2001-12-04 at 02:34, Tina Bird wrote:
> Pardon me for re-opening this can of worms.
>
> Did we ever come to a consensus, or a pseudo-consensus,
> on due diligence for computer logs as evidentiary
> quality data?
>
> What makes a judge unlikely to admit my logs as evidence?
> - unauthenticated data sources ("anyone can write to this
> datastream, therefore none of it is reliable")
> - lack of time synchronization
> - long term storage that is not tamper-proof
> - no strategy for dealing with all the data once it's collected
>
> I would propose -- for your non-existent
> Joe Average corporate network (I expect there to be
> heated discussion - please tell me where I'm totally
> off base) (and of course bearing in mind that this
> isn't infallible, it's just as good as the "court" can
> expect a "diligent" network or system administrator to
> do):
>
> 1) can't enforce secure transmission protocols throughout
> the network, because standards aren't sufficiently
> evolved -- so standard syslog, SNMP, SMTP are okay for
> transport protocols. (although see #3 below)
> 2) central loghost with NTP or other time synchronization
> throughout the network -- use ongoing record of process
> IDs on logging machines to verify reasonable expectation
> that a particular log message came from a given machine
> (does that make sense? I know what I mean...)
> 3) access control enforced at loghost that limits which
> machines can log -- help reduce likelihood of spoofed
> traffic -- or implement other transports altogether, like
> the serial cable mechanism we've discussed
> 4) loghost is of course totally locked down, SSH only
> access, or console only access, and dumps logs to
> write-once archive format on regular basis
> 5) log review and reduction strategy -- anyone want to
> take a stab? since presumably part of showing that the
> data is reliable is showing that I've thought about how
> I should process it.
> 6) minimum list of machines on that non-existent typical
> network that I should be required to monitor to be
> credible?
>
> Things have been awfully quiet out here lately...
>
> cheers -- tbird
>
> "I was being patient, but it took too long." -
> Anya, "Buffy the Vampire Slayer"
>
> Log Analysis: http://www.counterpane.com/log-analysis.html
> VPN: http://kubarb.phsx.ukans.edu/~tbird/vpn.html
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: loganalysis-unsubscribeat_private
> For additional commands, e-mail: loganalysis-helpat_private
---------------------------------------------------------------------
To unsubscribe, e-mail: loganalysis-unsubscribeat_private
For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Tue Dec 04 2001 - 11:48:42 PST