• Skip to main content
  • Skip to primary sidebar

DDoS Blog

Cyber Security News

Mitigating Against XML and HTTP-DoS and DDoS Attacks

January 25, 2018 By TheNewsTeam

There are various mitigation techniques specifically to guard against the most destructive kinds of DDoS attacks in the cloud: XML and HTTP-DoS attacks.

Filtering Tree

The XML consumer request is changed into a tree form and uses a virtual Cloud defender to protect against these kinds of attacks. The Cloud defender comprises five steps: sensor filtering, hop count filtering, IP frequency divergence, puzzle and double signature. The first four filters perceive HTTP-DDoS attacks whereas the fifth filter notices XML-DDoS attacks.

Limitation

One way of stopping attackers from exhausting the target network’s bandwidth and computing power is to route the requests to the service providers only after they have been authenticated and validated. To start with, limit the payload size. Then, limit the amount of time allowed for each a SOAP request. Finally, limit the amount of requests a specific user can send within a specified time frame. Packets that do not match these criteria are rejected and the service is blocked for the user for a given amount of time. Limits can also be imposed for the XML parser.

To reduce the impact for the end user in terms of delays, these limitations could only take effect when the system is under attack

Cloud Protector and Decision Theory

A Cloud Traceback (CTB) uses a Service-Oriented Traceback Architecture (SOTA) approach. CTB is deployed at the edge routers so that it can be close to the Cloud network source end to mark all outgoing packets. If an attack is identified, a back propagation neutral network, called Cloud Protector, can be deployed, which means that there is a series of connected units connected to a given weight, spread across input, hidden and output layers. The weights are added to see if the result goes over a certain threshold, which indicates that an attack is taking place. If an attack message is detected, a Reconstruct And Drop (RAD) system removes the message before a victim is harmed.

Defense in Cloud Broker

Users request resources in the Cloud infrastructure through the Cloud broker to ultimately use the web services hosted by the Cloud providers. The Cloud broker, however, introduces a single point of failure into cloud computing, since its unavailability alone can make the entire cloud infrastructure unusable. A DDoS defense system can be placed with the Cloud broker itself to decide whether an application request should be accepted or rejected. The defense system, which draws on DDoS datasets, is incorporated into all the broker entities and the filter is constructed with previous requests. The filter, intended to be scalable to overcome a DDoS, is transparent for the user. This defense mechanism has proved to be adept at detecting and mitigating all listed vulnerabilities to the cloud.

Flexible, Collaborative, Multilayer, DDoS Prevention Framework (FCMDPF)

This framework is comprised of: (i) an Outer attack Blocking (OB) at the edge router; (ii) a Service Traceback Oriented Architecture (STBOA); (iii) a flexible advanced entropy based (FAEB) layer. The OB layer blocks or forwards the incoming request. The STBOA layer is calculated to determine whether the incoming request is launched by a human or by a bot. A puzzle or random number is sent to the client to solve. If answered correctly, the request is forwarded to the next level. Otherwise, it is immediately blocked and a blacklist is updated. The FAEB layer computes entropy of total requests to determine flash crowds or HTTP-DoS attacks.

CAPTCHA to Mitigate HTTP-DoS Attacks

CAPTCHA is an architecture, which migrates HTTP-DoS attacks with a feature extractor, a clustering unit, a workload calculator and a filter. From a navigation log, the extractor module extracts: browsing length ratio, standard stay time and the HTTP request rate to recognize user groups. By using the clustering report, the workload calculator computes the size and density of each cluster. The load is calculated with the computational overhead and the network bandwidth usage. If the workload exceeds a certain threshold for each cluster, the filter offers a mechanism to filter traffic from such sources.

Filed Under: Cloud Computing, HTTP Attack, Mitigation Techniques, XML-DoS Tagged With: CAPTCHA, cloud broker, cloud computing, Cloud DDoS, cloud protector, FCMDPF, filtering tree, HTTP-DoS, limitation, XML-DoS

Primary Sidebar

Directory

  • Accidental DDoS
  • Akamai
  • Arbor Cloud
  • Business Rivalry DDoS
  • China Unicom
  • Cloud Computing
  • Cloudflare
  • Corero Network Security
  • DDoS Case Studies
  • DDoS Foundations
  • DDoS History
  • DDoS Landscape
  • DDoS mitigation
  • DDoS Motivation
  • DDoS Protection Services
  • DDoS Scripts
  • DDoS Tools
  • DNS Amplification
  • DNS Flood
  • DoSarrest
  • Extortion DDoS
  • F5 Networks
  • Genie Networks
  • Google
  • Government
  • Hacktivist DDoS
  • HTTP Attack
  • ICMP Flood
  • Imperva Incapsula
  • Infrastructure-related attacks
  • IoT DDoS
  • IP Fragmentation Attack
  • IP Null Attack
  • Kentik
  • LAND attack
  • MemCached DDoS
  • Mitigation Techniques
  • Multi-vector Attack
  • Nation State DDoS
  • Neustar
  • Nexusguard
  • NTP Amplification Attack
  • Null Routing
  • PING Flood
  • Ping of Death
  • Random Recursive GET attack
  • Recursive GET attack
  • Reflection Attack
  • Script Kiddies DDoS
  • Slowloris
  • Slowloris
  • Smokescreen DDoS
  • Specially Crafted DDoS
  • SSL-based DDoS
  • SYN Floods
  • SYN-ACK Flood
  • Types of Attack
  • Types of Mitigation
  • UDP Flood
  • Uncategorized
  • Verisign
  • Verizon
  • XML-DoS
  • Zero-day DDoS Attack
Copyright © 2017 Disclaimer. Privacy Policy
All product names, logos, and brands are property of their respective owners.