More Granularity in Your Apache Logs

The Apache Foundation released the new version of their very popular Apache web server. Lot of interesting changes have been introduced in this release. From my point of view (and because it’s one of my favorite topics), a very interesting change is the way Apache handles now its logs. Your web server logs must be properly handled  like any piece of log. But, because web sites remain an important vector of attacks today, more attention must be given to them. Let’s review quickly how to manage your logs with Apache.

Basically, the philosophy remains the same but more granularity has been introduced. For a while, the “LogLevel” directive exists and allows to specify the verbosity of logs written into the error log. The verbosity is defined via severities based on the ones used by Syslog:

emerg	Emergencies – system is unusable.	“Child cannot open lock file. Exiting“
alert	Action must be taken immediately.	“getpwuid: couldn’t determine user name from uid“
crit	Critical Conditions.	“socket: Failed to get a socket, exiting child“
error	Error conditions.	“Premature end of script headers“
warn	Warning conditions.	“child process 1234 did not exit, sending another SIGHUP“
notice	Normal but significant condition.	“httpd: caught SIGBUS, attempting to dump core in …“
info	Informational.	“Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)…“
debug	Debug-level messages	“Opening config file …“

In the previous versions, the directive was available at virtual host and server config levels. The version 2.3.6 already introduced a first change: more (or less) verbosity could be assigned to specific modules. Example:

LogLevel crit mod_ssl.c:info

Note that this feature replace some specific logging configuration at module level like “RewriteLog“. The new version 2.4 introduced a new change. Previously, a LogLevel directory could be defined at two configuration levels (Server Config & VirtualHost). Today, a new one is available: Directory. Combined with modules & directory, more granularity could be defined to really focus on interesting logs. Example:

LogLevel crit
...
<Directory "/webapp/admin">
    LogLevel info
</Directory>
...

This is particularly useful when you need to give more attention to “risky” parts of your websites. Note that this will increase (or decrease) the amount of errors into your error log but this one will remain unique (defined at root level or per virtual host). It’s not possible (yet?) to split errors across multiple files. To debug your configurations and programming issues, eight new levels are now available below “debug“:

trace1	Trace messages	“proxy: FTP: control connection complete“
trace2	Trace messages	“proxy: CONNECT: sending the CONNECT request to the remote proxy“
trace3	Trace messages	“openssl: Handshake: start“
trace4	Trace messages	“read from buffered SSL brigade, mode 0, 17 bytes“
trace5	Trace messages	“map lookup FAILED: map=rewritemap key=keyname“
trace6	Trace messages	“cache lookup FAILED, forcing new map lookup“
trace7	Trace messages, dumping large amounts of data	“| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |“
trace8	Trace messages, dumping large amounts of data	“| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |“

This was a short introduction on the changes brought by the version 2.4. Keep in mind that reducing the verbosity of your logs could be interesting but you could also miss important information.

A last reminder: don’t forget to log the source port in your access.log! With the increase of Carrier Grade NAT use, it’s mandatory to keep this information! I already discussed this topic in a previous post.