More Granularity in Your Apache Logs

Apache TrailThe 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

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.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.