----- Original Message ----- From: "Richard Welty" <rweltyat_private> To: <loganalysisat_private> Sent: Friday, December 07, 2001 8:48 AM Subject: Re[2]: [logs] Due Diligence for Admission in Court > On 07 Dec 2001 10:16:36 +0000 Dan Rowles <daniel.rowlesat_private> wrote: > > > 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...... > > the problem is very hard, because there are numerous potential points where > security can be compromised. If one of the PFS based loggers is used this will greatly limit instantaneous damage from any intrusion. > > even if we can guarantee that the messages are from the box in question, > can we guarantee that the box itself hasn't been compromised? The real issue is in building systems that survive being compromised and keep on working. > > if i were trying to guard server logs, and were limited to the current > syslog as described in the informational RFC, i'd probably tunnel the > syslog text, either using ssh as described by another writer, or using an > IPSec applicance in front of a group of servers. i'd then configure things > on the receiving end of the syslog stream to only accept messages that come > from the tunnel. > > another option, which might take a little development, or which someone > might already have out there, is to replace syslogd on the server(s) you > wish to monitor with a modified version which could, say, log locally and > also forward the messages over something like stunnel to a suitably > configured syslogd on the receiving end. > > if i were modifying syslogd in this manner, i'd probably also take the > opportunity to install some code that computes running hashes (MD5 or SHA1) > and sends them someplace "safe" to provide a method of checking data > integrity at a later date. > > richard > -- > Richard Welty Averill Park Networking > rweltyat_private Unix, Linux, IP Network Engineering, Security > rwelty@krusty-motorsports.com 518-573-7592 > > > --------------------------------------------------------------------- > 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 : Mon Dec 10 2001 - 11:55:35 PST