Ping Flood Attack is one of the oldest known network attacks, and its aim is to saturate the network with ICMP (Internet Control Message Protocol) traffic. ICMP Ping is used to verify the end-to-end internet path operation, where ICMP Echo request packet is sent to the target and an ICMP Echo Reply packet is expected to confirm communication between sender and receiver [6] .

A router, or a host, uses an ICMP echo request (ping) message to test a destination’s reachability. A computer system that receives an ICMP echo request message will respond to it by sending an ICMP echo reply message back to the sender (Figure 1). Using this, an ICMP echo request and reply messages together can test the reachability of a computer on a network [13] . The ICMP echo request and reply messages are identified by the value of the type field in the ICMP message format [14] . If the value of type field is equal to 8, it becomes echo request, if the value of type field is equal to 0, it becomes an echo reply [13] .

These Ping based DDoS attacks are flood of a large number of ping messages

sent to target are known to be quite damaging to the availability of the web- based services. The Ping attack can exhaust the target server’s bandwidth and computing resources [14] . The victim computer continues receiving a Ping mes- sage that generates an ICMP echo reply message sent to the source address of the Echo Request.

A more sophisticated version of a DDoS attack is commonly known as a SMURF attack. A SMURF attack utilizes massive number of ICMP packets of spoofed source Internet Protocol (IP) addresses targeting the victim server’s IP address

(Figure 2). This is achieved by altering the Echo Request sent to the botnet using an IP broadcast address [13] [15] . The larger the Botnet is the faster and the bigger is the flood of Echo reply messages [16] . The increase of traffic reduces the target server’s ability to respond, and can quickly cause a complete denial of service [5] [6] .

In this attack both the ICMP echo request and ICMP echo reply messages are used. While the perpetrator sends ICMP echo request messages to an unprotected broadcast domain for amplifying the attack, the victim computer actually receives amplified attack traffic that comprises mainly of ICMP echo reply messages. If the broadcast domain has N number of computers, then for each ICMP echo request broadcasted in such a domain will generate N number of ICMP echo reply messages that are sent to the victim’s server, due to the spoofed source address in the ICMP echo request messages [13] .

In this scenario-1, we used the Windows Server OS on the Apple’s server hardware platform. In order to analyze the effectiveness of an attack on the server, we found the maximum number of HTTP connections that can be establish on the server without the presence of attack traffic (baseline performance), and then this results were compared with the results obtained in presence of the attack traffic.

In the beginning, the legitimate HTTP connections were established with the server in the absence of attack traffic, and then the simulated attack traffic was introduced in the network and intensity was measured. In order to evaluate the impact of the ICMP based attack traffic, the number of HTTP connections that the server could handle was recorded for various amount of attack traffic ranging from 100 Mbps to 1 Gbps.

The baseline performance of the server with no attack traffic was measured to be 6000 HTTP connections per second. After baseline HTTP connections were established, simulated attack traffic was introduced in the range of 100 Mbps to 1 Gbps to the network. Traffic intensity was measured in the steps of 100 Mbps.

When the PING attack traffic was introduced as shown in Figure 4, the baseline performance of 6000 HTTP connections of the Windows server was maintained up to 600 Mbps of PING attack traffic. However, as the PING flood was increased beyond 600 Mbps, the server’s baseline performance was found to decline. When the attack traffic reached 700 Mbps, the number of HTTP connections declined to 4950 HTTP connections. At 800 Mbps of attack traffic the legitimate connections declined to 350 only. Finally at higher PING flood intensity greater than 800 Mbps, no legitimate connections could be established with the server (Figure 4).

For this scenario-2, we used the Apple’s native MAC OS for the same Apple’s server hardware platform. Comparatively, the Mac OS results were found to be different from that of Windows Server 2012 R2 for the same hardware platform. Baseline performance could be maintained till 500 Mbps of the PING flood. A significant decline in the number of legitimate connections was found at 600 Mbps supporting only 50 legitimate connections under Ping attack (Figure 5). This kind of significant decline in the legitimate connections was found to be at 800 Mbps for Windows Server 2012 R2 OS on Apple’s hardware server platform. Inferring from the performance data, it showed that the Microsoft’s Windows Server 2012 R2 was performing better than Apple’s Mac OS on its native Apple

server hardware platform under Ping flood attack.

PING flood attack in the scenarios 1 & 2 above was based on the ICMP Echo request protocol. A very similar protocol, namely the ICMP Echo reply protocol

is used in the Smurf security attack. In next two scenarios, Smurf based security attack was used to evaluate performance of two different server systems from Microsoft Inc and Apple Inc.

In scenario-3, the Smurf flood attack was used to evaluate Windows Server OS 2012 R2 on the same server hardware platform from Apple Inc. A drastic change was observed in Microsoft’s Windows server performance under the Smurf flood attack compared to its previous performance under PING flood attack. In this scenario, the baseline server performance of the number of legitimate connections fell sharply as the Smurf attack traffic increased beyond 100 Mbps. All legitimate client connections were lost at 150 Mbps of Smurf attack traffic, which is a relatively low attack bandwidth compared to 1000 Mbps or 1 Gbps being common these days. No legitimate client connections could be established with the Microsoft’s server OS running on the same hardware platform from Apple Inc. (Figure 6) for Smurf traffic higher than 150 Mbps.

This seemed quite unusual in the beginning knowing the fact that the server hardware deployed 8 core processors but the whole server system became unresponsive under relatively small volume of Smurf attack traffic of 150 Mbps. Further analysis of the core utilization showed that one of the core maxed out and other cores didn’t share the excess load of the Smurf flood. It was not clear if it was due to the inability of the Window’s server OS in handling the Smurf flood or was it due to the inability of the Apple’s hardware platform in sharing the excess load.

In one of the literatures issued by Apple Inc [19] , Apple gave a statement saying “It’s not possible to split a single thread across multiple cores, although a single core may run multiple threads at the same time. This is one reason that you may sometimes see uneven load distributions across the available cores on your computer”.

In this scenario-4, we used native Mac OS on the same Apple’s server hardware platform. A Smurf attack on Mac OS produced relatively improved resilience of the server compared to the crashing of Windows Server 2012 R2 at 150 Mbps of the smurf attack load. Compared with Windows OS, Mac OS was able to sustain the Smurf attack till 300 Mbps by supporting the baseline performance. When the attack traffic increased, the number of legitimate connections started declining, and all legitimated connections were completely lost after the attack traffic increased beyond 500 Mbps (Figure 7).