On Thursday, April 3, 2003, at 11:48 PM, Jason Haar wrote: > On Thu, Apr 03, 2003 at 04:04:43PM -0500, Blaise St-Laurent wrote: >> the more i think about it though, the less i think that database + >> tamper resistance is going to be an syslog issue. If you want to sign >> or at least put a checksum against every line that goes into your db, >> the best way i could think of doing this is to write a trigger on >> insert that calculates the checksum based on the values you supply >> (time, server, msg etc..) and adds it to the appropriate column. I'm > > I may be showing my ignorance here, but can someone explain to me how > checksums *by themselves* actually "prove" the data hasn't been > tampered > with? You are correct, by themselves, they prove 0. I should have said signed (through cryptographic means) without being able to prove that the md5 is authentic, and hasn't also been replaced, my suggestion is pretty much useless. You can protect the database column from writing programatically through permissions in the DB, such that no one can modify the checksum once it is in place, but if the DB is compromised, so to are the contents of that column. > > I mean, if I have a years worth of syslog data, md5 checksum the > files, and > burn them all off onto tape. A year later in court, I can confidently > say > that the syslog data *as it is on the tape* is as valid today as it was > *when the tape was written* (as the checksum will hopefully match). > Burned to tape? wouldn't the read-write nature of the tape induce the possibility of forging the md5? > I mean, as far as legal goes, surely all that this checksumming does it > "prove" the data hasn't been altered *since it was written*. It > doesn't say > anything about me fiddling with it before I checksumed it... > This depends largely on where the concern about tampering is. If the idea is to protect the logs once they have hit the DB, assuming the DB is safe, the above solution more or less works. if the concern is when the log record arrives at the syslog host, then the syslog subsystem should be the one in charge of signing it. However, the only way that we can guarranty that the message wasn't tampered with before then is to have the generating application sign it, something few systems are willing to do. > Surely in court, it's simply about proving your copy of the data > hasn't been > altered since it was written, and then it's *totally* a "reliability > of the > witness" type problem after that...? > I'm not sure if you've read the *extensive* discussion that happened on this list a couple of months ago about what will and will not stand up in court. If you haven't, i strongly recommend it (you can find a transcript on loganalysis.org) it was a fascinating conversation, and several lawyers spoke about their experiences. > Similarly, if you have some nice proprietary "logging server" that can > take > input from syslog clients and it puts it into a checksummed database > you > can't fiddle with as you don't know how it works, then you can still > input > bogus data can't you... > > I don't understand why this issue is always shown off as being a > technical > issue, when it court is usually ends up being a "people issue" (i.e. > do they > trust you)? > absolutely. See above reference for a good discussion. This'll teach me to send out a message before coffee. PS: The other idea, piping the output of syslog-ng into a program that will sign before writing to disk, should still work, but i'm loathe to think of the overhead. My initial investigations haven't really come up with much :( _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Fri Apr 04 2003 - 11:34:47 PST