Sep 13 2023

Understanding DDoS simulation testing in AWS

Category: DDoS — disc7 @ 9:04 am

https://aws.amazon.com/blogs/security/understanding-ddos-simulation-testing-at-aws/

Distributed denial of service (DDoS) events occur when a threat actor sends traffic floods from multiple sources to disrupt the availability of a targeted application. DDoS simulation testing uses a controlled DDoS event to allow the owner of an application to assess the application’s resilience and practice event response. DDoS simulation testing is permitted on Amazon Web Services (AWS), subject to Testing policy terms and conditions. In this blog post, we help you understand when it’s appropriate to perform a DDoS simulation test on an application running on AWS, and what options you have for running the test.

DDoS protection at AWS

Security is the top priority at AWS. AWS services include basic DDoS protection as a standard feature to help protect customers from the most common and frequently occurring infrastructure (layer 3 and 4) DDoS events, such as SYN/UDP floods, reflection attacks, and others. While this protection is designed to protect the availability of AWS infrastructure, your application might require more nuanced protections that consider your traffic patterns and integrate with your internal reporting and incident response processes. If you need more nuanced protection, then you should consider subscribing to AWS Shield Advanced in addition to the native resiliency offered by the AWS services you use.

AWS Shield Advanced is a managed service that helps you protect your application against external threats, like DDoS events, volumetric bots, and vulnerability exploitation attempts. When you subscribe to Shield Advanced and add protection to your resources, Shield Advanced provides expanded DDoS event protection for those resources. With advanced protections enabled on your resources, you get tailored detection based on the traffic patterns of your application, assistance with protecting against Layer 7 DDoS events, access to 24×7 specialized support from the Shield Response Team (SRT), access to centralized management of security policies through AWS Firewall Manager, and cost protections to help safeguard against scaling charges resulting from DDoS-related usage spikes. You can also configure AWS WAF (a web application firewall) to integrate with Shield Advanced to create custom layer 7 firewall rules and enable automatic application layer DDoS mitigation.

Acceptable DDoS simulation use cases on AWS

AWS is constantly learning and innovating by delivering new DDoS protection capabilities, which are explained in the DDoS Best Practices whitepaper. This whitepaper provides an overview of DDoS events and the choices that you can make when building on AWS to help you architect your application to absorb or mitigate volumetric events. If your application is architected according to our best practices, then a DDoS simulation test might not be necessary, because these architectures have been through rigorous internal AWS testing and verified as best practices for customers to use.

Using DDoS simulations to explore the limits of AWS infrastructure isn’t a good use case for these tests. Similarly, validating if AWS is effectively protecting its side of the shared responsibility model isn’t a good test motive. Further, using AWS resources as a source to simulate a DDoS attack on other AWS resources isn’t encouraged. Load tests are performed to gain reliable information on application performance under stress and these are different from DDoS tests. For more information, see the Amazon Elastic Compute Cloud (Amazon EC2) testing policy and penetration testing. Application owners, who have a security compliance requirement from a regulator or who want to test the effectiveness of their DDoS mitigation strategies, typically run DDoS simulation tests.

DDoS simulation tests at AWS

AWS offers two options for running DDoS simulation tests. They are:

  • A simulated DDoS attack in production traffic with an authorized pre-approved AWS Partner.
  • A synthetic simulated DDoS attack with the SRT, also referred to as a firedrill.

The motivation for DDoS testing varies from application to application and these engagements don’t offer the same value to all customers. Establishing clear motives for the test can help you choose the right option. If you want to test your incident response strategy, we recommend scheduling a firedrill with our SRT. If you want to test the Shield Advanced features or test application resiliency, we recommend that you work with an AWS approved partner.

DDoS simulation testing with an AWS Partner

AWS DDoS test partners are authorized to conduct DDoS simulation tests on customers’ behalf without prior approval from AWS. Customers can currently contact the following partners to set up these paid engagements:

Before contacting the partners, customers must agree to the terms and conditions for DDoS simulation tests. The application must be well-architected prior to DDoS simulation testing as described in AWS DDoS Best Practices whitepaper. AWS DDoS test partners that want to perform DDoS simulation tests that don’t comply with the technical restrictions set forth in our public DDoS testing policy, or other DDoS test vendors that aren’t approved, can request approval to perform DDoS simulation tests by submitting the DDoS Simulation Testing form at least 14 days before the proposed test date. For questions, please send an email to aws-ddos-testing@amazon.com.

After choosing a test partner, customers go through various phases of testing. Typically, the first phase involves a discovery discussion, where the customer defines clear goals, assembles technical details, and defines the test schedule with the partner. In the next phase, partners run multiple simulations based on agreed attack vectors, duration, diversity of the attack vectors, and other factors. These tests are usually carried out by slowly ramping up traffic levels from low levels to desired high levels with an ability for an emergency stop. The final stage involves reporting, discussing observed gaps, identifying actionable tasks, and driving those tasks to completion.

These engagements are typically long-term, paid contracts that are planned over months and carried out over weeks, with results analyzed over time. These tests and reports are beneficial to customers who need to evaluate detection and mitigation capabilities on a large scale. If you’re an application owner and want to evaluate the DDoS resiliency of your application, practice event response with real traffic, or have a DDoS compliance or regulation requirement, we recommend this type of engagement. These tests aren’t recommended if you want to learn the volumetric breaking points of the AWS network or understand when AWS starts to throttle requests. AWS services are designed to scale, and when certain dynamic volume thresholds are exceeded, AWS detection systems will be invoked to block traffic. Lastly, it’s critical to distinguish between these tests and stress tests, in which meaningful packets are sent to the application to assess its behavior.

DDoS firedrill testing with the Shield Response Team

Shield Advanced service offers additional assistance through the SRT, this team can also help with testing incident response workflows. Customers can contact the SRT and request firedrill testing. Firedrill testing is a type of synthetic test that doesn’t generate real volumetric traffic but does post a shield event to the requesting customer’s account.

These tests are available for customers who are already on-boarded to Shield Advanced and want to test their Amazon CloudWatch alarms by invoking a DDoSDetected metric, or test their proactive engagement setup or their custom incident response strategy. Because this event isn’t based on real traffic, the customer won’t see traffic generated on their account or see logs that drive helpful reports.

These tests are intended to generate associated Shield Advanced metrics and post a DDoS event for a customer resource. For example, SRT can post a 14 Gbps UDP mock attack on a protected resource for about 15 minutes and customers can test their response capability during such an event.

Note: Not all attack vectors and AWS resource types are supported for a firedrill. Shield Advanced onboarded customers can contact AWS Support teams to request assistance with running a firedrill or understand more about them.

Conclusion

DDoS simulations and incident response testing on AWS through the SRT or an AWS Partner are useful in improving application security controls, identifying Shield Advanced misconfigurations, optimizing existing detection systems, and improving incident readiness. The goal of these engagements is to help you build a DDoS resilient architecture to protect your application’s availability. However, these engagements don’t offer the same value to all customers. Most customers can obtain similar benefits by following AWS Best Practices for DDoS Resiliency. AWS recommends architecting your application according to DDoS best practices and fine tuning AWS Shield Advanced out-of-the-box offerings to your application needs to improve security posture.

DDoS Protection Second Edition

The 2023-2028 World Outlook for DDoS Protection and Mitigation

InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory

Tags: AWS, DDoS Protection, DDoS simulation testing

Aug 21 2022

Google says it stopped the largest DDoS attack ever recorded in June

Category: DDoS — DISC @ 1:11 pm
Google says it stopped the largest DDoS attack ever recorded in June

One of Google’s customers was targeted with the largest distributed denial of service (DDoS) attack ever recorded, according to a report the company released this week.

Attributed to Google Cloud Armor Senior Product Manager Emil Kiner and Technical Lead Satya Konduru, the report details the June 1 incident, in which a Google customer was hit with a series of HTTPS DDoS attacks, peaking at 46 million requests per second. 

To put it in perspective, they compared the attack to “receiving all the daily requests to Wikipedia (one of the top 10 trafficked websites in the world) in just 10 seconds.”

“This is the largest Layer 7 DDoS reported to date — at least 76% larger than the previously reported record,” they wrote.

In June, Cloudflare announced it had stopped the largest HTTPS distributed denial of service (DDoS) attack ever recorded at 26 million requests per second, surpassing a then-record attack of 17.2 million requests, which at the time was almost three times larger than any previous volumetric DDoS attack ever reported in the public domain.

Both Cloudflare and Google have expressed concerns about the evolution of DDoS attacks in recent years as they grow in frequency and exponentially in size.

“Today’s internet-facing workloads are at constant risk of attack with impacts ranging from degraded performance and user experience for legitimate users, to increased operating and hosting costs, to full unavailability of mission critical workloads,” Kiner and Konduru explained. 

The engineers said the attack started at 9:45 a.m. PST on June 1 and featured more than 10,000 requests per second. Within eight minutes, it grew to 100,000 requests per second. According to the report, Cloud Armor Adaptive Protection detected the attack and issued a “recommended rule” to block the incoming traffic, which the target’s security team put into place.

Two minutes later, the attack grew to its peak of 46 million requests per second before ending a little over an hour later.

“Presumably the attacker likely determined they were not having the desired impact while incurring significant expenses to execute the attack,” they wrote.

The hackers behind the attack used more than 5,000 source IPs from 132 countries to launch the attack, with the top 4 countries – Brazil, India, Russia and Indonesia – contributing about 31% of the total attack traffic.

https://

therecord.media
/google-says-it-stopped-the-largest-ddos-attack-ever-recorded-in-june/

DDoS Protection

Tags: ddos, DDoS Protection

Feb 22 2022

Why DDoS is still a major attack vector and how to protect against it

Category: DDoS — DISC @ 9:51 pm
Why DDoS is still a major attack vector and how to protect against it

What is a DDoS attack?

Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks aren’t new cyberattack vectors; They go all the way back to the early 1970s when modern commercial and enterprise networks emerged.

DDoS is a cyberattack in which the adversary seeks to make a machine or network resource unavailable to its intended users by temporarily or indefinitely disrupting services of a host connected to a network. It doesn’t peruse any private data or get control over the target’s infrastructure; it just aims to bring the service down.

In today’s world, specifically with COVID, which accelerated organizations’ digital transformation, web presence is a must for just about any business. In this environment, DDoS attacks can be very destructive.

Main ingredients of DDoS attacks

Ingredient # 1 – Botnet

A botnet is a group of infected, compromised machines with malware controlled by malicious software without the knowledge of the machine owner. It ranges from ordinary home or office PCs to IoT devices. Compromised machines called bots or ‘zombies’ are used to launch DDoS attacks, spread SPAM, or perform other malicious activities orchestrated by the attacker.

One of the most infamous Botnets is ‘Mirai,’ which used hundreds of thousands of hijacked IoT devices. The creators of the Mirai botnet, Josiah White, Paras Jha, and Dalton Norman, who were all between 18 and 20 years old when they built Mirai, managed to hijack IoT devices by scanning the Internet for vulnerable IoT devices with factory-set usernames and passwords, log into them, and infect them with the Mirai malware.

The Mirai botnet was used in multiple DDoS attacks between 2014 and 2016 and, when the creators felt the heat coming from the authorities, they published the Mirai source code in a Hackers’ forum in an attempt to cover their tracks. All three were eventually indicted, plead guilty, and are now fighting crime with the FBI. Amazing how life turns out.

Just like we have COVID variants and mutations, Mirai also evolved and its source code mutations have been used in the wild by hackers. Okiru, Satori/Fbot, Masuta, Moobot, and more than 60 other Mirai variants are out there.

Ingredient # 2 – Command and Control

Star topology of a DDoS attack

DDoS Protection 

Tags: DDoS Protection, major attack vector