Logging in Apache - Room for Improvement
(Page 8 of 8 )

This is only a starting point. The scripts I provided do work, but there are many features that can—and should—be added. For example:

• Error management in the source code. The scripts are very basic, and critical error conditions are not tested. This means that if the database server is down, there will be no logging—and you won’t be aware of it.

• Password management. What happens if you encrypt different rows in your database using different passwords? You will need to make sure you have a mechanism in order to manage this situation. An example could be an extra numeric field that stores the “password number” (meaning: password #1, password #2, and so on) and making the decrypting script aware of those passwords.

• Field separation. It would be a good idea to store different pieces of logging information in separate fields. This would lead to powerful log analysis. Remember that you should always make sure that your decrypting script is able to generate a common log text file.

• Error log. The same script can be used for the error log. In this case, field separation would obviously be pointless.

However, the example I provided should be enough for you to understand the potential of such a solution.

Checkpoints

• Be aware of all your logging options (and problems), and set an ideal environment to enable proper logging regardless of the solution you use. Also clearly document the logging architecture (even if it uses normal files).

• Check logs regularly or delegate a program to do so; notify the offenders whenever possible.

• Minimize the number of entries in the error_log. This might mean notifying CGI authors of warnings, notifying referring webmasters that links have changed, and so on.

• Make sure that there is always enough space for log files (automatic software helps by notifying you of low disk space situations).

• If your environment is critical or attack-prone, log onto a remote machine and encrypt the logging information. In this case, be aware of all the pros and cons of every single remote-logging solution, and try to keep it simple.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

Comments On: Logging in Apache

· I am not having success getting requst times to be logged in apache. I have used...   >>> Post your comment now!

Buy this book...

This article is taken from chapter three of the book Hardening Apache by Tony Mobily (Apress, 2004; ISBN: 1590593782). Check it out at your favorite bookstore. Buy this book now.