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 6 Monaten

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.

Introduction


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


2http://spiderlabs.github.io/owasp-modsecurity-crs/

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:



Field
Description
oc.johest.de:80
Servername or server alias of the server which was accessed.
ServerAlias:Port
142.0.41.40
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
302
The return code of the GET
526
The size of data which was send in return of this request
"-"


"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) 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:



Field
Description
GET
Type of the request
/
Path or URL which was requested
HTTP/1.1
Used HTTP version of the request



The client information

"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) 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 oc.johest.de
  • 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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 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)

Montag, 3. August 2015

SendMeSpam: A two stage compromise attack

SendMeSpam: A two stage compromise attack: I am pretty sure you have read the blog post for the php code execution attack. http://sendmespamids.blogspot.nl/2015/07/encoded-bot-execu...

SendMeSpam: HTTP/2 revisited

SendMeSpam: HTTP/2 revisited: As you may know, I published a simple blog post about "HTTP/2 PUSHing malicious content" . This lead to some discussions and more ...

SendMeSpam: HTTP/2 malicious SERVER PUSH (weak POC)

SendMeSpam: HTTP/2 malicious SERVER PUSH (weak POC): HTTP/2 now supports SERVER PUSH messages HTTP/2 adds a new interaction mode whereby a server can push responses to a client ( Section 8.2...

Montag, 20. Juli 2015

SendMeSpam: A two stage compromise attack

SendMeSpam: A two stage compromise attack: I am pretty sure you have read the blog post for the php code execution attack. http://sendmespamids.blogspot.nl/2015/07/encoded-bot-execu...

Sonntag, 19. Juli 2015