If you troubleshoot day in and day out, you will deal with an amazing amount of data. Because, to find out the cause and get to the bottom of the issue, we look into lot of places. For example: IIS Logs (If we are troubleshooting issues related to websites hosted in IIS), Windows event logs, Network traces, Custom logs in various formats, Process monitor, Performance monitor, ETW traces, Memory dumps, Active directory objects, Registry and what not.

A big challenge when trying to locate responsive information from this MB’s and GB’s of data is how to effectively search through large volumes without over-collecting useless, irrelevant information that can waste precious time and cause delay in resolving the issue.

We use many tools to query this data to make some sense out of it. In this blog, we will discuss about a simple but a powerful tool called LogParser and identifying Denial of Service attacks from IIS Logs.

We have lot of tools and techniques available to identify DOS attacks. But, the classical way is to look at various log files and that’s where LogParser will help us a lot.

Most of the times, when we face performance issues in our server, we may suspect a DOS attack. An easy way to confirm whether our web application is facing a DOS attack or not is to look into IIS logs. Because, IIS records all the requests being served by the web server in the IIS logs.

Let us start with a simple query,

For a normal production server, we will see lot of log files in IIS logfiles folder. One classic way people follow as a preliminary step is to check for patterns in the sizes of those log files. If they see a sudden spike in size, they will pay attention to those log files to check if they have recorded any malicious attempts. Instead of scrolling through that large list of LogFiles in windows explorer, we can leverage LogParser to query the sizes of those files. As I mentioned earlier in this article, we can use LogParser to query Windows File System as well.

The below query will list the size of log files along with Date and time created.

Log File Sizes

The output will be similar to the table below:

Having identified the set of log files either with reference to the time of the issue or based on the size of the file, the very first thing what we should confirm is whether we have unusual traffic to our application or not. The below command will list the number of requests made to each page in our application.

Requests Per Page

If we see unusual number of requests (the best way to find is by comparing the results against a normal set of data), we need to look further to find out the source of those requests.

If our application is not hosted in a load balanced environment, we can make use of the c-ip field in IIS logs. The below command will list the number of requests made by each client ip to our application.

Number of Requests Per Client IP

If our application is behind a load balancer, the c-ip field will not be of much use as it records the load balancer IP. In such cases, we should proactively make sure, the IIS log files record the actual client IP.

We can achieve it by configuring the load balancer to forward the client IP address to the IIS by setting the X-Forwarded-For header and configuring IIS to log the X-Forwarded-For. We can either use the custom fields section in IIS as shown below or use the advanced logging module to log the X-Forwarded-For

We can modify the above query to get the original client IP’s instead of load balancer IP address. Please modify the {Log Field Name} by the alias name you gave to X-Forwarded-For. In this example the Log Field Name would be OriginalClient.

If we find unusual number of requests from a client IP, we should verify whether the client is a normal client or a source of attack. We can possibly do a reverse DNS check to verify the identity of client machine. If found malicious we can then block all the requests from those IP addresses.

There are many tools available for the reverse DNS lookup. To begin with we can simply use ping or nslookup commands as below:

Log Parser itself has a function to do reverse DNS lookup. The below query will list the c-ip and corresponding client names along with the number of requests from those clients.

Reverse DNS Lookup

I have masked the names with (*) in the below output:

Also, comparing the distribution of HTTP Methods, HTTP Response codes and User agent strings from the log files created during the issue with the normal set of log files will help us to get some insights on the issue. The below commands will list the distribution of Methods, status codes and User agent.

Requests per cs-method

Http status count

User agent count

With the help of above queries we can easily identify whether our application had undergone a DOS attack or not from the IIS logs.

Thanks for reading and please leave a comment if you have any thoughts on the content of this blog.