Meine Blog-Liste

  • end of life - Good morning, as you may have already found out, the posts on this blog have been getting less and less. This is caused by the fact that my two honeypots h...
    vor 2 Jahren

Dienstag, 1. September 2015

Apache Logging Forensics (introduction)

The following article was created for a software documentation I have written a year a go. As I buried the software, the documentation was never finished.


The idea of the “MyPyApacheFW” started in 2013.

It was caused by a Webserver. Nothing Fancy, but in risk. It was running a normal Apache PHP content managemant system and investigation showed that it was under heavy attack during the night.

First idea was to simply install the mod_security1 on it and include the OWASP ruleset2, but this just broke the whole system as the standard handling by the CMS lead to many problems not resolvable in easy way.

So, to not just leaving it the way it is, I started my firewall project.

The project is available on GITHUB


Apache Log Entry

When we take a look at “combined logging” which I use to have all log files in one place and no need to run multiple instances at the same time we have basically these fields within the logfile:

Servername or server alias of the server which was accessed.
The source address where the request came from
[30/Dec/2014:12:32:56 +0100]
The Timestamp of the access
"GET / HTTP/1.1"
The GET command which was received
The return code of the GET
The size of data which was send in return of this request

"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2009011913 Firefox/3.0.6"
The information of the client used to perform the GET request.

The GET request

Now, lets take a closer look at the GET request itself.
The request can again be splitted into three things:

Type of the request
Path or URL which was requested
Used HTTP version of the request

The client information

"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2009011913 Firefox/3.0.6"

The client information is pretty much straight forward. It shows the program used to access the website and some basic information on the operating system used. The OS information is mostly taken from the client information, so for what OS the client was build.
Here we see that the client was a Firefox build for windows.

"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2251.0 Safari/537.36"

Another client “seen in the wild” is this Safari build on Mac OS X.

How does it work

When receiving a GET / HTTP/1.1 requested
  • Apache is addressed to deliver the content of / to the client. The representation of / is taking from the Server which was addressed, in our case this is
  • Apache will determine the location of / according to the information within the Server description (normally within /etc/apache2/sites-enabled/SERVERNAME.CONF like in our case 001-oc.conf)
  • / means hereby the source folder described within the directory structure of the conf file
  • It depends on the configured behavior what it will deliver now
    • index.html
    • index.php
    • list of content of the directory

  • Now Apache will find out if the content can be delivered and the return code represents what happened. 302 shows for example that the path was found. Please refer to for a full list of return codes.
  • In addition, Apache calculates the size of the content returned.
  • Apache will place a log entry within the log file (normally within /var/log/apache2/ like in our case other_vhosts_access.log)