[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [Full-Disclosure] write events log to CD?
From:       James Tucker <jftucker () gmail ! com>
Date:       2004-08-30 21:11:50
Message-ID: e92364c3040830141141287475 () mail ! gmail ! com
[Download RAW message or body]

<BIG ASS SNIP>

SUMMARY:
IMHO even using packet writing this is not a good solution for log
handling, but maybe ok for log archiving on a remote log server (which
we would hope not to be compromised until after logs were written, at
worst).

DOWN TO IT:
The principle of using WORM media for storing logs is an interesting
one. The reason for it is obvious; as with the discussion that has
ensued its not quite as simple as it maybe should be.

Most CD formats (i.e. ISO 9660 based) don't really allow for over-time
progressive writing of data, which is why this is difficult. It is
also important to note that with most multi session systems a file
with the same name will only appear once when you "dir" or "ls" the
folder. There are some CD packages which allow you to select the
session you care to read from; I may google one later, but I don't
have one immediately to hand. Remember please that this IS possible,
as nothing on a CD-R is ever re-written on a multi session disc.

The next obvious problem is that multi session-ing actually takes up
more space than just the file you add/change on the disk. In fact IIRC
it's around the region of 20mb, maybe more. This is obviously
inappropriate for appending lines on a few log files (100 bytes with
20mb overhead, about as efficient as drinking water to increase your
blood sugar levels).

Some googled details on packet writing support on CDR's:
"Track at Once writing is a form of incremental writing which mandates
a minimum track length of 300 blocks and a maximum of 99 tracks per
disc. A Track at Once written track has 150 blocks of overhead for
run-in, run-out, pre-gap and linking. Packet writing is a method
whereby several write events are allowed within a track, thus reducing
the overhead. These packets are bounded by 7 blocks for run-in (4),
run-out (2) and link (1)."

A Mode 1 CD is typically 2048 bytes per block, or 2k. Thats 14k
overhead per packet. Lets say maybe we want to use this system to
write logs. Assuming that we know we are going to have overhead and
will deal with it, we can optimise the write frequency based upon this
overhead (in other words how often do we want to have to change the
media in best case?). Of course we can't ever guarantee how BIG the
logs will get, so unless you have a writing rack you may run out of
space and logs wont be written till a new disk. Even with a rack there
would be a delay during the disc change, various malicious actions
could be taken during this time, though I would hope bad stuff has
happened which has already been logged, and that an attacker could not
tell this timing until the system has already logged at least some
actions. Guaranteeing this would be contradictory to most generic
security principles though, no matter how "Mission Impossible" it
sounds to break into a system during the 3/4 seconds it takes a
robotic arm to switch cd's.

So, back to the math... on a CD we have somewhere in the order of
665000kbytes which we can use for our own data (it's more, but this is
well clear of overheads at all levels).
That means we can get over 45000 "packets" onto a packet written cd. I
am not sure how accessible this is, nor could I find any information
on the limitations of writing a high number of "packets" to the CD, I
imagine trying to access a CD with 45k "packets" would have a VERY
high latency as it reads all the overhead portions; furthermore this
would actually end up being a memory intensive process. Its also
important to note that this leaves no space for actual data. Anyway,
to continue...

If we we're to write empty packets every half an hour, we can write
around 20 days worth of packets on a single cd; not too unreasonable
to me. This is still without data however. The likelihood is you will
want to be changing the CD on a daily basis, but the above value will
tell you that if you are planning on changing discs once a day; you
will need to ensure that your logs are no bigger than ~250k / write.
This should be reasonable, but would be easy to attack with log
filling. Again, an automatic disc loader would be most reliable; but
not a perfect solution. We still have the 1/2 hour / write problem,
but for log archiving purposes this may be appropriate.

I don't have too much more time to devote to this, but the concept
using a packet writing system looks ok so far, mind you log filling
(which is used quite allot as its common to find that logs have a
limited size and are overwritten after such a size on many systems)
will completely kill this solution purely for the lack of write speed,
and the log write time delay. What would you expect the system to do
if it cant fit all the data into a single cd packet? (meaning it needs
to be a custom system anyway, file redirection alone wont be safe to
use here).

I think this is an interesting idea, but for general log handling IMHO
it's just not quite good enough, how about DVD's maybe? Probably too
expensive in terms of media though, and the block size is probably
different.


Now, as a final note, the original question was can the Windows event
logs be made to be written somewhere else, this is possible, although
many solutions are unclean.
You can base a solution of this kind on the "eventquery.vbs" script
included with Windows XP. You extend this script to do whatever you
want with the logs and use scheduled tasks to run it frequently.
The event logs themselves are stored in the .evt files found under
your %windir%\system32\config folder. It is also possible you could
copy these out on a regular basis, although you will be duplicating
data if you simply do this.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
[prev in list] [next in list] [prev in thread] [next in thread]