<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