**6.2 Three-tier network architecture**

The second infrastructure was designed as per the proposed design having three unique tiered designs. Each tier has different IP address schemes and communicates with others via site-to-site VPN. This design simulated public and private cloud integration. The first two tiers focused only on security protection against network and application layer attacks. The third tier only focused on access to the hosted SaaS application with database backend:

• The first Tier is built around layers 3 and 4 network defense system for IP and TCP defense using hardware firewalls and load balancer. This tier mitigates ICMP (Ping), UDP, or SYN flood attacks.

**25**

**Figure 7.**

**Figure 6.**

*Traditional architecture design (single-tier).*

*Single-tier DDoS attack logs.*

*Cloud Computing Security Services to Mitigate DDoS Attacks*

*DOI: http://dx.doi.org/10.5772/intechopen.92683*

*Cloud Computing Security Services to Mitigate DDoS Attacks DOI: http://dx.doi.org/10.5772/intechopen.92683*

#### **Figure 6.**

*Cloud Computing Security - Concepts and Practice*

attacks on the apps

complete

(**Figure 6**).

**6. Performance analysis**

**6.1 Single-tier network architecture**

below for reference (**Figures 7**–**9**).

**6.2 Three-tier network architecture**

SaaS application with database backend:

ICMP (Ping), UDP, or SYN flood attacks.

on the site for the time being in actual time during an assault.

logs in to until the page has loaded completely

The networks were tested by community and alertness layer attacks with the use of ICMP flooding with a thousand echo requests with increasing buffer size from 3700 to 3805 bytes. The use of DDoS attacks such as LOIC, R.U.D.Y, and slowloris that simulated attacks denied valid users to get admission to the web software portal. When performing the simulated DDoS assaults, the real user monitoring records are taken as the standards, and parameters have been amassed for the logs to assist generated graphs for DDoS attacks. These parameters had been chosen due to the fact that they decide what performance problems the real users are experiencing

• Average ICMP latency (milliseconds) before and during the course of DDoS

• Page load response that refers to time the app pages take to load and figuring out where exactly the time is spent from the time a user logs authenticates and

• App response relates to the percentage time for a page load process to

• Status codes are gathered from the HTTP reputation codes the web server makes use of to communicate with the web browser or person agent

The first framework was structured and implemented in the form of a single inbound and exit gateway. This mimicked the single-tiered level system including standard system design, directing the interfacing with an online interface containing the front end and back end. This simulated the standard cloudbased condition having a basic standard system configuration actualized in a server farm with hardware devices mentioned in the setup environment above

Using the standard design, single-tiered architecture, multi-vector DDoS attacks

The second infrastructure was designed as per the proposed design having three unique tiered designs. Each tier has different IP address schemes and communicates with others via site-to-site VPN. This design simulated public and private cloud integration. The first two tiers focused only on security protection against network and application layer attacks. The third tier only focused on access to the hosted

• The first Tier is built around layers 3 and 4 network defense system for IP and TCP defense using hardware firewalls and load balancer. This tier mitigates

were executed as network floods and volumetric and application layer 7 attacks. These critically overloaded and degraded the computing systems leading to access issues for legitimate users. Logs and data gathered for each attack are displayed

**24**

*Traditional architecture design (single-tier).*


#### **Figure 7.**

*Single-tier DDoS attack logs.*

**Figure 8.** *Single-tier attack results.*

**Figure 9.**

*Single-tier results (with and without network security).*


DDoS assaults were performed at first on the single-level system plan and our proposed three-level system structure and assembled result that demonstrate our proposed half-breed cloud configuration having the main level for accepting inbound traffic from clients and aggressors with layers 3 and 4 gadgets and performing system assault alleviation, utilizing a system firewall blocking ICMP floods. The inbound traffic was then permitted to stream to the second level which alleviated application-level assaults utilizing a WAF. Here utilizing F5 and Cisco gadgets intelligently, we had the option to square 80% of the assaults. This was assembled subsequent to contrasting the assault information and single-level system arrangement. The three-level system configuration is executed in a test server farm with Cisco and F5 arrange gadgets for steering, VPN, and exchanging. We utilized VMware and Microsoft operating system servers with a SQL server as backend database to mimic cloud-based SaaS applications. DDoS assault reproductions were performed on the three-level engineering to check the patterns for system and application-level

**27**

**Figure 10.**

**Figure 11.**

*Three-tier logs (network attack).*

*Proposed three-tier architecture.*

*Cloud Computing Security Services to Mitigate DDoS Attacks*

outcomes after the assaults. ICMP flooding was performed with 1000 reverberation demands each with expanding support size (3600–3800 bytes) with each assault. They made the objective server to react and process the ICMP demands, taking cost of CPU assets and at last square substantial solicitations. Application-level assaults were finished utilizing HTTP Flood GET assault with expanding string check and 1200 reverberation demands utilizing "GET/application/?id=479673msg=BOOM %2520HEADSHOT! HTTP/1.1Host: IP" and moderate attachment development mimicking moderate HTTP assault utilizing perl with logs taken from Wireshark.

DDoS attacks were performed on single-tier and the proposed three-tier infrastructure architecture and results gathered for real user monitoring parameters

Device logs gathered for each attack are illustrated in **Figure 11**.

**6.3 Comparing single- and three-tier architectures**

during the network attacks (**Figure 12**).

*DOI: http://dx.doi.org/10.5772/intechopen.92683*

**Figure 10.** *Proposed three-tier architecture.*

*Cloud Computing Security - Concepts and Practice*

**Figure 8.**

**Figure 9.**

*Single-tier attack results.*

• The second Tier provides layer 7 application defense using web application firewalls and customized load balancing rules along with SSL termination. This tier mitigated ARP spoofing, POST Flood, and DNS poisoning and

• Once both network and application attacks are cleaned from the traffic, only legitimate user traffic remained. This traffic is directed to access the private tier cloud (or the third tier), hosting only the SaaS Web portal. After processing and completing the work, user traffic is again reverted to tier 2 for exit instead of tier 1 and following the same traffic route back to the user. This form of asynchronous routing ensures the attackers are not able to execute denial of service attacks that always have the condition of user traffic having the same

DDoS assaults were performed at first on the single-level system plan and our proposed three-level system structure and assembled result that demonstrate our proposed half-breed cloud configuration having the main level for accepting inbound traffic from clients and aggressors with layers 3 and 4 gadgets and performing system assault alleviation, utilizing a system firewall blocking ICMP floods. The inbound traffic was then permitted to stream to the second level which alleviated application-level assaults utilizing a WAF. Here utilizing F5 and Cisco gadgets intelligently, we had the option to square 80% of the assaults. This was assembled subsequent to contrasting the assault information and single-level system arrangement. The three-level system configuration is executed in a test server farm with Cisco and F5 arrange gadgets for steering, VPN, and exchanging. We utilized VMware and Microsoft operating system servers with a SQL server as backend database to mimic cloud-based SaaS applications. DDoS assault reproductions were performed on the three-level engineering to check the patterns for system and application-level

inbound and outbound gateway and traffic routes (**Figure 10**).

detected malwares from inbound user traffic.

*Single-tier results (with and without network security).*

**26**


**Figure 11.** *Three-tier logs (network attack).*

outcomes after the assaults. ICMP flooding was performed with 1000 reverberation demands each with expanding support size (3600–3800 bytes) with each assault. They made the objective server to react and process the ICMP demands, taking cost of CPU assets and at last square substantial solicitations. Application-level assaults were finished utilizing HTTP Flood GET assault with expanding string check and 1200 reverberation demands utilizing "GET/application/?id=479673msg=BOOM %2520HEADSHOT! HTTP/1.1Host: IP" and moderate attachment development mimicking moderate HTTP assault utilizing perl with logs taken from Wireshark.

Device logs gathered for each attack are illustrated in **Figure 11**.
