On Wed, 21 Jan 2009, RB wrote: > On Tue, Jan 20, 2009 at 12:54, <[email protected]> wrote: >> I think that what he is asking about is what makes logs acceptable or not >> acceptable when doing forensics, and what configurations of rsyslog would >> be acceptable. > > That's still unclear as to whether the logging instances are being > analyzed or they are part of the analysis process (i.e. logging > investigator actions, "interesting" items, etc.).
I think it's the logs being analysed, not logging investigator actions (other than the extent that things the investigators do would be logged if anyone did them) >> for example, rsyslog can be configured to use disk-based queues on >> redundant drives and RELP for network communication, and the result will >> be that rsyslog is _very_ reliable in terms of preserving messages that >> get to it (at the cost of performance, but you can throw hardware at it to >> deal with that) >> >> this is probably acceptable as a log for forensics type work. >> >> but what about the more normal settings? (tcp or udp network >> communications with memory-based queues). those settings can loose data, >> but won't under normal conditions (assuming the network isn't so busy that >> it drops UDP packets) > > Generally speaking, forensics prefers the "save everything, impossible > to lose" approach. A single lost message probably won't break a given > case, but the possibility is definitely there. this is the most paranoid/conservative view, and by this definition there are basicly no logs in existance that meet the forensics requirements > RELP with disk queues > on hardware-redundant drives would probably be a good start if you're > looking to ease future analysis, but it is my opinion that networked > logging of the forensic process is both unlikely and overkill, as most > analysis processes want their logs integrated instead of held as a > separate source. > > One item I have had on my wish-list for quite some time is the ability > to log directly to a UDF VAT filesystem (incremental writes on > write-once optical media). Poor man's WORM, if you will. It would > enable physical assurance that log data is unmodified up to the point > of compromise. Add in the idea of incremental checksums or signing, > and you have an extremely controlled, verifiable log source. Of > course, it doesn't have to be solved in rsyslog-space, but it'd > definitely be useful. frankly, if you really need write-only media, the best thing to do (volume permitting) is to dump to a printer. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
