Dos Attack Sim

Investigating a DOS attack with Wireshark

Introduction

In this write up, we are going to simulate a DOS attack to an Apache server running ubuntu. The program to initiate the attack is called Slowloris. This program will be used to send junk traffic to port 80 to cause the Apache server to freeze or crash. Oraclebox will be used to create the environment. Two VMs will be created. One VM for the attacker and another VM for the target. Both VMs will be on the same internal network and separated from the host network. This will prevent any DOS traffic from appearing on the legitimate host network. Wireshark will be used to monitor the incoming attacks to the Apache server.

Setup

I used oracle VM and two virtual machines, Kali Linux and Ubuntu. I will set up an Apache server in the ubuntu VM to simulate a web server with legitimate traffic.

First, I had to make sure both machines “see” each other, that is, the Kali VM can communicate with the ubuntu VM and vice versa. I decided to create an internal network for both VMs for the connection. This will allow both the kali and ubuntu VMS to communicate with each other without being connected to the host computer network.

The internal network will only need two IP addresses. One for the Kali Linux machine and one for the ubuntu machine. I assigned the IP of 192.168.20.20 for the apache server and 192.168.20.19 for Kali VM.

One both addresses are assigned, I had to verify both VMS can now talk to each other. I pinged the ubuntu machine by using the terminal and ping command with the IP of 192.168.20.20. Seeing the Kali VM did receive ICMP acknowledgments successfully, this confirms the Kali VM can communicate with the ubuntu VM.

(Show screen shot of ping)

After receiving a successful ping, it was time to start the apache server in the ubuntu VM.

(Show Screen shot of Apache server

Once I have determined both machines can now talk to one another and the apache server is started, it was time to start the DOS attack within Kali.

I chose to use Slowloris for a couple of reasons. One, legitimate HTTP traffic is used as the junk traffic so this would add a little bit extra challenge to detect on the ubuntu side. Two, Slowloris can also create a large amount of bot net traffic possibility having all traffic connecting to a C2C. Finally, the amount of traffic that Slowloris sends out can simulate a heavy traffic botnet. I decided to use port 80 for the target port as this is required to send the HTTP request traffic to the apache server. This might not slow down the entire computer, however, the web browser experience will show excessive speed reductions or crashing.

I used Wireshark on the ubuntu side to capture the DOS traffic by observing the amount of HTTP request coming from 192.168.20.19 that are never completed. This would be the form of a PSH, RST flag set within the data packet viewable within Wireshark. I let the tool run to generate enough junk traffic so the ubuntu web browser will slow or completely freeze when trying to navigate any webpage.

From the Wireshark screenshot, the source IP address of 192.168.20.19 is sending massive amount of traffic at once to 192.168.20.20 port 80 (Apache server). This excessive amount of traffic within a span of a couple of minutes is causing the Apache web server to slow down or even freeze completing the DOS attack successfully.

Counter measures

Although it’s not possible to prevent a DOS attack from occurring, it is possible to increase the amount of availability of systems while the attack is taking place.

1. Know your networks baseline traffic – This can be done by examining the traffic that is occurring during peak and low times of usage to get a sense of what “normal” traffic will take place. A sudden increase in usage during these times can signify a DOS attack taking place.

2. Continue to monitor to suspicious activity.

3. Have load balancers in place – A load balancer will handle the extra bandwidth a DOS attack consumes while the main servers handle the legitimate traffic. This will only affect the suspected target to go down and not the entire network or system.