Except that on a production system there would be no real users, per se and the logging data would be secured by operational setup. BTW - I have a draft that will be submitted to the IETF on configuring a baseline set of services to provide for a clean system. This is a BCP filing and if adopted will allow auditors to say - set a system up as such and it will likely be ok, all things considered. Todd ----- Original Message ----- From: "Dan Rowles" <daniel.rowlesat_private> To: <loganalysisat_private> Sent: Tuesday, December 04, 2001 2:08 AM Subject: Re: [logs] Due Diligence for Admission in Court > 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 > --------------------------------------------------------------------- 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 - 12:15:37 PST