Apache Security - Ivan Ristic [107]
mod_security-time2
The mod_security rule engine has completed analyzing the request. Now you can see how much overhead mod_security introduces. The request is about to be processed by an Apache handler.
mod_security-time3
The response has been generated and is about to be sent to the client.
These measurements are useful when used in a custom log together with information provided by the mod_logio module, because to make sense of the numbers you need to know the number of bytes sent to, (format string %I) and from, (format string %O) the server:
CustomLog logs/timer_log "%t \"%r\" %>s - %I %O -\
%{mod_security-time1}n %{mod_security-time2}n \
%{mod_security-time3}n %D
Each entry in the log will look something like this:
[19/Nov/2004:22:30:08 +0000] "POST /upload.php HTTP/1.1" 200
- 21155 84123 - 673761 687806 5995926 7142031
All times are given in microseconds, relative to the beginning of request processing. The following conclusions can be made out of the line given in the previous example (with the figures rounded to the nearest millisecond so they are easier to read):
Apache spent 674 milliseconds reading the request (with the body included).
mod_security spent 14 milliseconds analyzing the request (time2-time1).
The response was generated in 5,308 milliseconds (time3-time2).
It took the client 1,146 milliseconds to receive the response (%D-time3).
The client sent the request data at approximately 31 KBps (%I/time1).
The client received the response data at approximately 72 KBps (%O/(%D-time3)).
File Upload Interception
A special case of audit logging occurs when files are uploaded to the server. Since mod_security supports the multipart/form-data encoding, you can choose to keep the uploaded files:
SecUploadKeepFiles On
SecUploadDir /var/www/logs/files
The SecUploadKeepFiles directive can have one of three possible values:
Off
Files are not kept.
On
All files are kept.
RelevantOnly
Only files that are part of a rejected request are kept.
Application Logs
Include the application logs on the list of logs you monitor. At the very least, you should integrate the logs of the application engine with the rest of the logs. For example, configuring PHP to send errors to the Apache error log (described in Chapter 3) removes one thing from the TODO list. For each application, you should do the following:
Determine (from the documentation, or by talking to the programmers) what logs the application produces.
Classify logs according to the material they contain. How sensitive are the application logs? They are often verbose and may contain passwords and credit card numbers.
Implement log rotation.
Consider the following five recommendations to increase the security of your application logs:
The application logs will have to be written to by the web server processes and, thus, have to be owned by the web server user. Do not jeopardize the security of the main Apache logs because of that! Create a separate folder in which to keep the application logs and allow the web server process to write there.
Being owned by the web server user, application logs are in danger since an attacker will most likely come through the web server. To minimize the danger, implement a custom rotation script to periodically rotate the logs. The idea is to move the logs to a separate directory, change the ownership (to root), and change the permissions (so the web server user cannot get to them any more).
If the sensitive data in the log files is not needed (or is needed for a limited time only), consider removing it from the logs at the same time as the rotation.
If you can, move the logs from the server altogether. A complete discussion on centralized logging strategies can be found below.
If you cannot get the logs out of the server, consider encrypting them on a regular basis with a public encryption key (while not storing the private key on the same server).
Logging as Much