Strategies and Approaches for Cloud-Based DoS Attacks

Calico and Falco are proven tools to identify, prevent, and tackle DoS attacks in Kubernetes while operations are ongoing. This article will focus on strategies specifically designed to minimize DoS attacks within cloud environments like GCP, Azure, and AWS.

‍

DDoS attacks exhibit distinct patterns across OSI model layers. Attacks at the Application Layer (Layer 7) often involve overwhelming HTTP/s levels by inundating the application with HTTP GET requests or DNS queries. These actions, like the Killnet cyber-attack, are aimed at disrupting services.

‍

Attackers might also trigger DoS situations at TCP (Layer 4) or through UDP/ICMP activities (Layer 3), flooding networks and servers to render them incapable of handling genuine traffic. This isn't solely something attackers could do; it's also a method to stress-test your infrastructure, employing tools to amplify traffic and gauge how effectively your detection systems respond.

‍

Our primary aim is to use CNCF Project Falco to spot signs that suggest a Cloud-based DoS Attack might happen. Falco achieves this by linking up with the audit logging services of cloud providers through specific plugins tailored for each platform. We plan to keep a constant watch on network behavior to set up Falco rules. This way, we can rapidly identify suspicious network behavior, taking proactive steps to stop potential DDoS threats in their tracks.

Steps to Prevent Brute Force DDoS Attack

The first preventive action against Brute force DDoS attacks is to safeguard your web servers. The primary task of any brute attack is to gain access to the server access and make the server unresponsive. The operative behind the brute attack is trying millions of passwords until a correct one is discovered. To thwart any brute force attacks, you must use stringent security policies and create as robust passwords as you can.

‍

Furthermore, most of the cloud service providers also provide tools like rate-limiting which can act as a deterrent against brute force attacks. For example, in their respective documentation, Microsoft Azure, Google Cloud, Amazon AWS, and IBM Cloud all provide rate-limiting functionalities to counter brute-force DDoS attacks.

Account Takeover Prevention

Another way to prevent Ddos attacks is to constantly monitor the login pages of the application and check for any unauthorized access made to user accounts by using leaked or stolen login details. Account takeovers usually happen when someone illegally gains access to somebody else’s account.

‍

There are several ways by which an attacker can enter into a user’s account. Some of the ways include stealing user credentials, and multiple attempts to guess the user’s password. We can integrate Falco into the cloud service provider’s (Azure, GCP, or AWS) audit logging service and detect any unusual logins from suspicious IP addresses.

For example:

<pre class="codeWrap"><code>- rule: Console Login Success From Untrusted IP
desc: Detect a console login success from an untrusted IP address
condition: >-
 aws.eventName="ConsoleLogin" and
 jevt.value[/responseElements/ConsoleLogin]="Success" and not aws.sourceIP in
(trusted_ip_addresses)
output: >-
 Detected a console login success from an untrusted IP address (requesting  user=%aws.user, requesting IP=%aws.sourceIP, AWS region=%aws.region,  arn=%jevt.value[/userIdentity/arn], user agent=%jevt.value[/userAgent])
priority: info
source: aws_cloudtrail
</code></pre>

The IP addresses of all the genuine users can be added to the trusted_IP  list and if anyone logs in to the cloud from an unknown IP address, it can be easily identified as a potential threat.

‍

One can easily refer to these real-time alerts and implement proactive security measures like multi-factor authentication(MFA) on user accounts and also temporarily halt the account until it is verified that the account is genuine. In case a user tries to log in without MFA, the following rule is triggered.

<pre class="codeWrap"><code>- rule: Console Login Without MFA
desc: Detects a console login without MFA.
condition: >-
 aws.eventName="ConsoleLogin" and not aws.errorCode exists and
 jevt.value[/userIdentity/type]!="AssumedRole" and
 jevt.value[/responseElements/ConsoleLogin]="Success" and
 jevt.value[/additionalEventData/MFAUsed]="No"
output: >-
 Detected a console login without MFA (requesting user=%aws.user, requesting  IP=%aws.sourceIP, AWS region=%aws.region)
priority: critical
source: aws_cloudtrail
</code></pre>

It is always recommended to add a security layer in the form of an MFA in your organization. Having said that, there can still be threats of spammers who can disable MFA or delete MFA for a particular IAM group and grant full permission to IAM users. Detection of such spamming is mandatory for cloud service providers.

An example of one such rule is as follows:

<pre class="codeWrap"><code>- rule: Azure Deactivate MFA for User Access
desc: >  Multi-factor authentication requires an individual to present a minimum of  two separate forms of authentication before access is granted. Multi-factor  authentication provides additional assurance that the individual attempting  to gain access is who they claim to be. With multi-factor authentication, an  attacker would need to compromise at least two different authentication  mechanisms, increasing the difficulty of compromise and thus reducing the risk.
condition: >-
 jevt.value[/operationName]="Disable Strong Authentication" and
 jevt.value[/properties/result]="success"
output: >-
 Multi-factor authentication configuration has been disabled for a user
 (requesting user=%jevt.value[/properties/initiatedBy/user/userPrincipalName],  requesting IP=%jevt.value[/properties/initiatedBy/user/ipAddress],
 target user=%jevt.value[/properties/targetResources/0/userPrincipalName])
priority: warning
source: azure_platformlogs
</code></pre>

Detection of Exposure of ACL to Public Internet

Most cloud service providers provide ACL (Access Control List) like features. At Layer 3 and Layer 4 of the OSL level, the ACL can either allow or deny network traffic (both outbound and inbound). To add an additional level of security, you can create customized ACLs for virtual private clouds with rules similar to that of the security group.

‍

Sometimes organizations can open this ACL to the public internet which could create a big loophole for external adversaries to breach the cloud. Air gapping is one option that can prevent external probing but at the same time, it is imperative to say that some applications need to be open for public internet. So what’s the solution?Hers is where the role of Falco is vital since it can efficiently detect whenever the ACLs are set up for public access, especially in cases when it was not essentially required.

<pre class="codeWrap"><code> - rule: Create a Network ACL Entry Allowing Ingress Open to the World
desc: >-
 Detects Access Control List creation allowing ingress open to the world
condition: |
 aws.eventName="CreateNetworkAclEntry" and not aws.errorCode exists and (
not (
 jevt.value[/requestParameters/portRange/from]=80 and
 jevt.value[/requestParameters/portRange/to]=80
) and
not (
 jevt.value[/requestParameters/portRange/from]=443 and
 jevt.value[/requestParameters/portRange/to]=443
) and
(
 jevt.value[/requestParameters/cidrBlock]="0.0.0.0/0" or
 jevt.value[/requestParameters/ipv6CidrBlock]="::/0"
) and
jevt.value[/requestParameters/egress]="false" and
jevt.value[/requestParameters/ruleAction]="allow"
 )
output: >-
 Detected creation of ACL entry allowing ingress open to the world  (requesting user=%aws.user, requesting IP=%aws.sourceIP, AWS  region=%aws.region, arn=%jevt.value[/userIdentity/arn], network acl  id=%jevt.value[/requestParameters/networkAclId], rule  number=%jevt.value[/requestParameters/ruleNumber], from  port=%jevt.value[/requestParameters/portRange/from], to  port=%jevt.value[/requestParameters/portRange/to])
priority: error
source: aws_cloudtrail
</code></pre>

The access control lists help to stop state exhaustion attacks. The attackers generally attempt SYN flooding at layer 3(networking layer). In this attack, a series of connections are initiated to the server without completing them. As a result, the server ends up allocating extensive resources to manage these incomplete connections during the TCP handshake process, rendering the system unresponsive to valid incoming traffic.

‍

SYN flooding involves overwhelming the TCP connection state tables found in various network and security devices, including load balancers, routers, ingress controllers, firewalls, and even application servers (e.g. Apache). Securing access to the network helps thwart these types of attacks, safeguarding against Dyn attacks.

Enhancing Firewall Settings to Counter DDoS Attacks

The web application firewall can be configured to thwart Application layer (Layer 7) attacks. The cloud provider can offer WAF technology, or you can also get it implemented by a third-party service provider. For example, in AWS, the WAF will monitor each incoming HTTP or HTTPS request directed at layer 7 resources. So, this helps you to manage the access to the content according to the attributes of those requests.

‍

The web application firewall uses an access control list to employ rule-based rate limits on the traffic originating from individual IP addresses. All these steps will eventually protect the application from DDoS attacks.

Just like SYN flooding as previously discussed, HTTP/S flooding is another attack method that can cause Denial-of-Service (DoS). To execute HTTP/S flooding, the attackers, and DNS queries that are composed of POST and HTTP GET activities flood the application layer. The main motive of the attack is the consumption of large application resources including memory, bandwidth, and CPU.

‍

From the attacker’s point of view, they should be aware of the loopholes in the target’s infrastructure. This attack could cause application and database processing delays. In case the attack happens, a lot of malicious requests will halt the web service and the user will not be able to use the intended service.

‍

To stop the threat, it is essential to differentiate between the actual traffic and the malicious traffic.In this situation, deploying Falco onto a VM/EC2 instance within your cloud setup can serve as a deterrent against a DDoS attack. By monitoring system calls originating from the host, Falco offers insight into the traffic behavior at the application level.

‍

With Falco, you can establish a checklist of trusted domain names such as google.com or github.com. Any network connection directed towards an IP address not associated with these specified domain names can trigger the designated policy.

<pre class="codeWrap"><code>- list: trusted_domains
 items: [sysdig.com, github.com, google.com]
- rule: Unexpected outbound network connection
 desc: Detect outbound connections with destinations not on allowed list
 condition: >
   Outbound
   and not (fd.sip.name in (trusted_domains))
 output: Unexpected Outbound Connection
   (container=%container.name
   command=%proc.cmdline
   procpname=%proc.pname
   connection=%fd.name
   servername=%fd.sip.name
   serverip=%fd.sip
   type=%fd.type
   typechar=%fd.typechar
   fdlocal=%fd.lip
   fdremote=%fd.rip)
priority: NOTICE
</code></pre>

Filtering Web Traffic

WAF rules can be created by you to sift through web requests using criteria like HTTP body content, HTTP headers, or specific customer URIs. Additionally, leverage ACL regulations to sort web traffic by IP addresses. Similar to Falco's use in identifying vulnerable ACL configurations (open to the public internet), Falco rules can also identify connections directed towards C2 servers typically linked with botnet operations.

<pre class="codeWrap"><code>- list: c2_server_ip_list
items: [1.234.21.73, 100.16.107.117, 100.6.8.7]

- rule: Outbound Connection to C2 Servers
desc: Detect outbound connection to command & control servers
condition: outbound and fd.sip in (c2_server_ip_list)
output: Outbound connection to C2 server (command=%proc.cmdline pid=%proc.pid
connection=%fd.name user=%user.name user_loginuid=%user.loginuid
container_id=%container.id image=%container.image.repository)
priority: WARNING
tags: [network]
</code></pre>

‍

You can feel free to utilize any threat feed that suits your needs. Our c2_server_ip_list was generated using the initial 3 IP addresses from the Feodo Tracker C2 IP Blocklist. The Abuse.ch team offered a simple-to-use user interface to understand the role of IPs used in different attack methodologies like Denial of Service, Trojanized loaders, and Ransomware. Apart from detecting suspected outbound traffic aimed at C2 servers, any inbound traffic directed towards cloud servers is also strictly monitored.

<pre class="codeWrap"><code>- rule: AWS Suspicious IP Inbound Request
 desc: >-
   Detect inbound requests from known suspicious IP sources, such as TOR exit
   nodes, to AWS services.
 condition: >-
   aws.sourceIP in (ti_anon_ips) and not (aws.eventName="ConsoleLogin" and
   jevt.value[/responseElements/ConsoleLogin]="Failure")
 output: >-    Suspicious IP Inbound Request (aws.sourceIP=%aws.sourceIP,
   aws.region=%aws.region, aws.eventName=%aws.eventName, aws.user=%aws.user,
   userAgent=%jevt.value[/userAgent], errorMessage=%jevt.value[/errorMessage])
 priority: warning
 Tags: [Cloud, AWS]
 source: aws_cloudtrail
</code></pre>

You can follow the identical Falco rule logic that can prevent connections made to Tor (a relay Network). But, you should also understand that Tor cannot be considered a good use case as far as DDoS assaults are concerned. Since UDP packets don't require handshakes and neither require cooperation, they are usually sent with the intention of overwhelming the victim's bandwidth. Using Falco, we can identify objectionable UDP traffic at the host and workload level that diverges from typical port 53 traffic.

<pre class="codeWrap"><code>- rule: Unexpected UDP Traffic
 desc: UDP traffic not on port 53 (DNS) or other commonly used ports
 condition: >-
   (inbound_outbound) and do_unexpected_udp_check and fd.l4proto=udp and not
   Expected_udp_traffic
 output: >    Unexpected UDP Traffic Seen (user.name=%user.name
   user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline connection=%fd.name
   proto=%fd.l4proto evt.type=%evt.type %evt.args container.id=%container.id
   evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid
   proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath
   user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid
   group.name=%group.name container.name=%container.name    image=%container.image.repository)
 priority: notice
 source: syscall
</code></pre>

Since Tor does not accept all kinds of data and accepts only some forms of data, known as TCP streams, it is unable to support certain attacks like SYN flooding or carry certain types of data, such as UDP packets. Generally speaking, attackers can carry out a powerful cyberattack without the use of Tor if they have sufficient internet capacity. Having said that, Tor is helpful for data extrusion prior to a DDoS attack because it guarantees the attackers' anonymity.

‍

The company that hosts your data in the cloud probably has ways to block bad computer servers that control viruses, or they might check their list of dangers to see if any connections are originating from these servers. To spot connections or sneaky spying programs that might be risky, using free tools just like Falco can be useful.

<pre class="codeWrap"><code>- rule: Detect reconnaissance scripts
  desc: This rule detects the use of reconnaissance scripts.
  condition: evt.type=execve and reconnaissance_scripts
  output: >-
    Detected reconnaissance script executing (proc.cmdline=%proc.cmdline
    container=%container.info evt.type=%evt.type
    evt.arg.request=%evt.arg.request proc.pid=%proc.pid proc.cwd=%proc.cwd
    proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
    proc.exepath=%proc.exepath user.uid=%user.uid user.loginuid=%user.loginuid
    user.loginname=%user.loginname user.name=%user.name group.gid=%group.gid
    group.name=%group.name container.id=%container.id
    container.name=%container.name image=%container.image.repository)
  priority: warning
  source: syscall
</code></pre>

API Security

Sophisticated website security, such as L7 WAF, should safeguard the specialized commands known as APIs used by applications. APIs act like toolkits enabling smooth app operations, but they also pose risks due to their complex communication. With increased API usage, there's a higher likelihood of potential security breaches. Many companies overlook monitoring these toolkits and lack knowledge about securing or identifying outdated ones.

‍

Carelessness might result in exposing these toolkits, causing issues, particularly if they're from external sources or are not supported anymore.Regrettably, WAFs fail to provide the need for attack prevention, visibility inventory tracking, and risk assessment that are essential for API security.Whenever an API key is established, Falco can identify it, which aids in general audits to verify who made it, and when it was created, and checks the association of Key ID to the project.

<pre class="codeWrap"><code>- rule: GCP Create API Keys for a Project
  desc: Detects the creation of API keys for a project.
  condition: >-
    gcp.serviceName="apikeys.googleapis.com" and gcp.methodName endswith
    ".ApiKeys.CreateApiKey"
  output: >-
    An API key for a project has been created (requesting user=%gcp.user,
    requesting IP=%gcp.callerIP, project
    id=%jevt.value[/protoPayload/request/projectId], key
    id=%jevt.value[/protoPayload/response/keyId])
  priority: warning
  source: gcp_auditlog
  append: false
  exceptions: []
</code></pre>

Falco can detect if containers can chat with the Kubernetes API server and this comes in handy when handling work on the cloud managed by services like GKE, EKS, or AKS. It helps us notice any weird actions that could mess things up in Kubernetes. It acts as an alert system, notifying us if there's an attempt to disrupt the system using a particular attack called a denial-of-service (DoS).

<pre class="codeWrap"><code>- rule: Contact K8S API Server From Container
 desc: Detect attempts to contact the K8S API Server from a container
 condition: >
   evt.type=connect and evt.dir=< and
   (fd.typechar=4 or fd.typechar=6) and
   container and
   not k8s_containers and
   k8s_api_server and
   not user_known_contact_k8s_api_server_activities
 output: Unexpected connection to K8s API Server from container (command=%proc.cmdline
pid=%proc.pid %container.info image=%container.image.repository:%container.image.tag
connection=%fd.name)
 priority: NOTICE
 tags: [network, k8s, container, mitre_discovery]
</code></pre>

With Kubeshark, it's now even simpler to identify odd DoS activity or stop a DDoS attack at the API level in Kubernetes. Within a Kubernetes cluster, the Kubeshark tool offers comprehensive monitoring and visibility of all API activity and payloads entering, leaving, and moving between pods and containers. These cloud-native workloads frequently encompass the cloud services they are hosted on.

‍

The service inventory and automatically generated API that Kubeshark provides are helpful because it is derived from API traffic. This way, we can keep an eye on payloads and all the API traffic to identify API anomalies and drift. We can also locate their sources. All cloud-based enterprises, whether or not they use Kubernetes, must automatically monitor POST/GET activity both to illegitimate and valid endpoints or destination addresses. It's important to watch what's normal and what's not, especially for APIs, which are like tools for apps.We suggest always keeping an eye on these things, using tools from outside or inside your company to check for risks.

‍

Can your cloud service automatically notice these risks and stop them right away? For instance, AWS GuardDuty can detect unusual activities that might cause problems, like attacks on different ways information travels, such as UDP, TCP, DNS, and others.

Methods to Stop a Cloud DDoS Attack

To conclude, we must say that there is a need for the application of some stringent mitigating strategies to both the network as well as application layer to stop DDoS cloud attacks.

‍

You can follow the below-mentioned steps to stop the cloud from DDoS attacks.The cloud providers are self-sufficient in mitigating the DDoS attacks and recently Google Cloud stopped the layer7 DDoS attack that faced forty-six million RPS (requests per second) during peak DDoS attacks. The level of security is not available in basic Google cloud service and the business for which the attack was inundated was using Google Cloud’s Armor solution.

‍

In recent times, we're seeing more DDoS attacks being used as tools in state conflicts. Cybercriminal groups rush to set up their networks of infected computers (botnets) to launch successful DDoS attacks, especially in reply to specific political events. DDoS attacks can cause economic, civil, or social damage which further depends on the attacker’s motive and target.

Conclusion

There are several ways by which the Cloud can mitigate the DDoS attack, as discussed in this article. For every web application, Volumetric Attacks (Layer 3) is going to be one of the most popular strategies. Since there is no requirement to wait for a TCP handshake, network flooding methodologies like the UDP reflection attack are perfect since attackers can bombard the application with ICMP or UDP floods.We have witnessed an upsurge in L7 attacks over time that are more advanced and target APIs rather than DNS/HTTP floods.

‍

We know that most of the WAF technologies can't clearly distinguish between real and fake connections to APIs. This means some connections can slip through without being checked properly. Mistakes by developers, improper training or not following the rules can make these connections weak and easy for DDoS attackers to take advantage of. Even when APIs are well coded, they can still be targeted for attacks since they offer high-speed connections to backend systems. So finally, we can assume it is clear now how to stop DDoS attacks in the cloud.