| As with anything, taking the proper steps to prepare before disaster strikes can make your job significantly easier. If you have poor logging and auditing practices in place, this will make your forensic job more difficult if not impossible . While no one likes to plan for disaster, taking these steps can help you pick up the pieces afterwards. Log Granularity If you have the disk space and the processor time available, turn your logging up to the highest detail level that is reasonable on your servers. This provides a lot more information in case you need to reconstruct something from the logs and is useful for troubleshooting server problems as well. You will probably want to play with the settings to find the level of log detail that makes sense for you. In Windows, you can adjust your logging granularity by going to Event Viewer in Administrative Tools. Click on the properties of each log type (application, security, system) and you can set the logging level of each item. Run a Central Log Server Keeping all your log files locally on each server is a liability from several standpoints. If attackers manage to co-opt a machine, they will have access to the log files to either change them or erase them totally. Utilities are available to help intruders selectively wipe logs files of their activity. At least if they are on another server, the invader has to hack yet another machine to get to them. The popular log server utility syslog is a good tool for this, and most servers, routers, firewalls, and other devices support this format. From a management standpoint, it is a lot easier to have all your logs on one server for reviewing them on a regular basis, and you know they are all synchronized to the same clock. This leads us to the next point. Time Sync Your Servers You should have all of your servers getting their time from a central timeserver rather than relying on the internal clocks. PC clocks are notoriously inaccurate and are subject to drift . You can use the Network Time Protocol (NTP) to get your time from a central server, subscribe to atomic clocks on the Internet, or run your own internal timeserver to ensure that you are getting the correct time. This way, log times will be the same from one server to another so you can correctly follow a sequence of log events. There is nothing more frustrating than trying to put together an attack from logs that have multiple disparate clock settings. Using a public timeserver is highly recommended. Most of these are free and use atomic clocks for the greatest accuracy. This way your logs are more likely to match external log files such as an ISP's files. Public time clocks are available at the following Web sites: -
clock.isc.org -
clock.via.net -
clock.sgi.net -
ttp.nasa.gov -
tick.gpsclock.org | 