Simple - Add the hashes of the executables to the logging data as "certified applications". You can do this by regularly running an IDS like Tripwire AIDE or COPS. Build it in with timestamps and also show commands and processes in execution as part of the proofing model. T. ----- Original Message ----- From: "Dan Rowles" <daniel.rowlesat_private> To: <loganalysisat_private> Sent: Friday, December 07, 2001 2:16 AM Subject: Re: [logs] Due Diligence for Admission in Court > Hmmm.... I can think of a few real world situations where you would want > users to have access to a box, but would also want to ensure that the > logs were reliable. > > But my real point I suppose is that authenticity is an important > requirement for logs. If my log files say that my http server, dns > server, mail server said "x", I want to know that message "x" really > *did* come from the daemon in question, and not, for example, from a > hacker / malicious user. > > How you would implement this, though...... > > Dan > > > > > On Tue, 2001-12-04 at 19:51, todd glassey wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Fri Dec 07 2001 - 11:00:06 PST