Blue Screen of Death Observed for Microsoft Windows Server 2012 R2 under DDoS Security Attack ()
Received 31 March 2016; accepted 4 July 2016; published 7 July 2016
1. Introduction
Nowadays, huge and long-lasting DDoS attacks as high as 600 Gbps are being observed against organizations and are making headline news frequently [1] . DDoS attacks have far-reaching consequences and leave a lasting impact on the victim organization by affecting the trust of the customers, loss of data and loss of revenue. The attacks launched had become more and more sophisticated and vicious, such as the ransomware attack in which attackers demanded ransom to decrypt sensitive medical information which they had encrypted by exploiting an unpatched vulnerability in an application server [2] . It has been predicted that the occurrence of such attacks could increase in 2016 [3] . Under such circumstances, it is very crucial that organizations take a closer look at the inherent vulnerabilities and the host-based defense mechanisms available in the servers that have been deployed in their offices, and such measures would greatly decrease the chances of falling prey to attacks [4] .
The inherent vulnerability due to incomplete TCP-SYN handshakes was identified as early as 1994 [5] . TCP SYN based DDoS attack is considered a common type of denial of service attacks [6] and many server platforms lack sufficient protection against this attack. Many schemes have been suggested to defend against this DDoS attack, however, not many server platforms are automatically implementing effective protections against such attacks.
The first TCP-SYN attack, also known as SYN flood attack, was reported in 1996 [7] . Since then, network system security has been improved to a great extent through the development of technologies such as Intrusion Detection and Intrusion Prevention Systems, Firewalls, Proxies and through the implementation of several strategies such as SYN cookies [8] , packet filtering based on sender IP addresses, reducing the SYN-RECEIVED timer, recycling the oldest half-open Transmission Control Block (TCB), SYN cache [9] to name a few.
Most of these prevention mechanisms are used as an external mechanism (such as intrusion prevention system) to protect a server against a TCP SYN flood attack with varying results. Nevertheless, it is important for a server operating system to deploy on its platform in-built security to defend itself in the event that all the external protection mechanisms may have failed or compromised. Active research needs to be done to improve the ability of the Operating Systems to withstand and defend against DDoS attacks on its own to some extent as a part of host based defense mechanism.
Being one of the highest used server and client operating system in the world, earlier versions of Microsoft Windows operating systems have been evaluated previously [11] - [17] . Over the years, security of the server systems has improved and has become less vulnerable to attacks compared to their predecessors. There has been improvement in the protection mechanisms developed by Microsoft in the subsequent server operating system, however, more remains to be done.
2. TCP/SYN Attack
TCP, a layer-4 protocol, was implemented to ensure reliable data delivery. Hence, TCP forms an integral part of the Internet. Along with reliability, it also provides flow control and congestion control. Flow control is employed to prevent the sender from overwhelming the receiver by sending data at a rate higher than the receiver can accept. Congestion Control is used to make sure that the buffers of routers located at the core of the Internet do not overflow (Figure 1).
TCP ensures data reliability by creating a connection between the sender and the receiver through a three-way handshake mechanism, hence TCP is known as a connection-oriented protocol. In the first step of the three-way handshake, the sender sends a connection request by setting the SYN bit in the TCP packet to 1. The second step involves the receiver sending a SYN-ACK packet with both SYN and ACK bits set to 1 upon receiving the SYN request from the sender. In addition to sending SYN-ACK, the receiver also allocates buffers and variables for each TCP connection. In the third and final step, the sender sends an ACK packet to the receiver and allocates buffers and variables following which the connection is set up [10] .
This mechanism in the TCP connection establishment that requires that the receiver (server) allocate resources before the completion of the three-way handshake is exploited in the TCP/SYN attack. To launch this
![]()
Figure 1. Legitimate three-way handshake.
attack, an attacker commands his botnets to send a volley of SYN packets to the victim. For each SYN packet the victim receives, the victim is forced to send a SYN/ACK packet and allocate resources. With increasing number of SYN requests, the server keeps on allocating resources, and this keeps the victim server too occupied to be able to handle the connection requests of legitimate users leading to a denial of service (Figure 2).
3. Experimental Set Up
In the experiment, simulated TCP-SYN attack traffic is sent to the victim server simultaneously from multiple networks. In order to observe the impact of the attack in an organization-like environment, legitimate or client traffic is also sent to the server simultaneously along with attack traffic.
The first TCP-SYN attack was performed using the experimental set up is shown in Figure 3. The victim server is a Dell Power Edge T320 tower server with Intel Xeon E5-2407 v2 quad core processor and 8 GB RAM. As mentioned earlier, Windows 2012 R2 Standard Operating System has been installed in the victim server. Since the objective of this experiment is to evaluate the inherent protection mechanism of the server Operating System, the only protection mechanism that was active on the server platform was the Windows Server 2012 R2 firewall.
4. Evaluation
In order to analyze the effect of the attack on the server, the maximum number of HTTP connections that the server can establish in the absence of attack traffic is determined (baseline performance). This result is then compared with the results obtained when the server experienced attack.
Initially, the legitimate HTTP connections were established with the server in the absence of any attack, and then the simulated attack traffic was introduced in the network and intensity was measured. In order to observe the impact of the attack traffic, the number of HTTP connections that the server could handle was recorded for different magnitudes of attack traffic ranging from 1 Gbps to 6 Gbps.
The baseline or nominal performance of the server in the absence of attack traffic was measured to be at the rate of 54,000 HTTP connections per second. In the absence of attack, the server could successfully handle all
![]()
Figure 4. HTTP connection establishment for the victim server under TCP SYN attack.
the HTTP connections. Once the baseline HTTP connections were established, then simulated attack traffic was gradually introduced into the network and traffic intensity was measured.
Due to the attack traffic, the number of legitimate connections that the server could handle was observed to decrease. When the server experienced 1 Gbps of the attack traffic the HTTP connections were found to be 32,000 connections as opposed to the initial baseline value of 54,000 connections. It was observed that under the attack traffic of 2 Gbps, the number of HTTP connections further dropped to 25,000 connections per second, and for 3 Gbps of attack intensity, no HTTP connections could be established with the server.
The HTTP connections were measured under different attack traffic conditions. Figure 4 shows the drop in the number of HTTP connections under different magnitude of attack traffic.
Table 1 displays the number of HTTP connections that the server could handle at different magnitudes of attack traffic.
It was observed that under 3.1 Gbps attack traffic, the server crashed in 3 minutes and displayed a Blue Screen of Death (BSoD) which displayed a Watchdog Violation Error (133) before restarting. Figure 5 shows the BSoD displayed by the server.
It was further observed that as the attack traffic increased, the server took less time to crash. Figure 6 displays
![]()
Table 1. Number of HTTP connections established by the server under SYN attack traffic.
![]()
Figure 5. Blue screen of death (BSoD) displayed before the server crashed under 3.1 Gbps attack traffic.
![]()
Figure 6. Duration of time the server is able to withstand the attack traffic before crashing.
the time it took for the server to crash under different attack traffic that was measured starting from 3.1 Gbps to 6 Gbps. To solve this problem, the Windows Server 2012 R2 OS was updated with the updates available from Microsoft [18] - [21] but the server continued to crash under the attack. It can be seen from Figure 6 that the server crashed in (as little as) 1.5 minutes when it experienced a 6 Gbps of SYN attack traffic.
5. Conclusion
Windows Server 2012 R2 being one of the most used server Operating Systems, is expected to have a reasonable host based protection against security attacks including Distributed Denial of Service (DDoS) attacks. The experiments show that the inbuilt protection mechanism of Windows Server 2012 R2 is not effective enough against a common type of DDoS attack namely the TCP SYN flood attack. It is highly recommended for the network security managers worldwide to evaluate their servers’ performance against a range of prescribed security attacks before their deployment in the production network.
Acknowledgements
The support for this research is provided in part by the US National Science Foundation under Grant No. 0421585.
NOTES
*Corresponding author.