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
This archive was generated by hypermail 2b30 : Fri Dec 07 2001 - 08:33:54 PST