david at lang
Jan 21, 2009, 11:55 AM
Post #5 of 8
On Wed, 21 Jan 2009, RB wrote:
> On Tue, Jan 20, 2009 at 12:54, <david [at] lang> 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.
rsyslog mailing list