×
Community Blog Cloud Security for Websites - HTTP Flood Protection

Cloud Security for Websites - HTTP Flood Protection

This article explains how to analyze and prevent HTTP flood attacks on websites using Alibaba Cloud's Web Application Firewall.

By Zhu Chaojian (Fengfan)

When your Website is under an HTTP flood attack, you must first try to restore services by enabling HTTP flood protection in the Emergency mode on Web Application Firewall (WAF). Emergency mode is applicable to the protection of Web and HTML5 applications, but not APIs and native apps, which may be mistakenly blocked. To protect APIs and native apps, we recommend that you customize HTTP flood protection rules based on attack features.

This article explains how you can analyze and prevent HTTP flood attacks on websites using Alibaba Cloud's WAF. To learn more about the details of HTTP Flood Protection on WAF, visit https://www.alibabacloud.com/help/doc-detail/43443.html

1

Implementing HTTP Flood Protection

The process of implementing HTTP Flood Protection is straightforward. First, we analyze logs of requests to identify attack features. Then, we block malicious requests by using tools based on attack features.

Before analyzing logs, let's look at the common features of HTTP flood attacks on Websites.

  1. The attacked URL receives highly concentrated access requests.
  2. Attack source IP address initiates highly concentrated access requests.
  3. Source IP addresses used by the attacker are concentrated in several IP address segments or provinces.
  4. Same Referer and User-Agent headers are used in access requests.

Practice

Analyze logs based on the preceding attack features. For example, the Website, www.xxxx.cn , which has a maximum of about 130,000 queries per seconds (QPS) sent during a specific time period:

2

We can identify the attacked URL based on HTTP flood attack features by using Log Service, which is an automatic analysis tool.

Analyze Logs

Query results returned by Log Service indicate that most requests are sent to the URL: //xxx/index.php, which normally does not have such a high access volume.

3

After identifying this attack, configure HTTP flood protection in the WAF console to protect this URL.

Configuring HTTP Flood Protection

Enter the attacked URL obtained through log analysis, select Exact Match, set the check interval to 10 seconds, set Visits from one single IP address to 5, and set Blocking type to Block and the duration to 30 minutes.

4

If the number of requests from an IP address exceeds 5 within 10 seconds, WAF blocks this IP address for 30 minutes. This rule is strict, and the access frequency can be adjusted based on your services.

If protection is not effective, you can configure a stricter rule. Alternatively, you can select Human-machine Identification. With this blocking type, WAF returns a special snippet of code to the client, along with status code 200, and determines whether the client runs the code properly. If the client runs the code properly, the client passes authentication and can access the Website.

If the client fails to run the code, the client IP address is added to a blacklist for a specific time period. We recommend selecting the Human-machine Identification blocking type for a Website architecture, where Anti-DDoS Pro or Content Delivery Network (CDN) is deployed at the frontend of WAF.

Mine Attack Features

When Website services are gradually restored, continue to analyze logs to identify more accurate attack features for further protection.

Analyze the distribution of client IP addresses

Based on the analysis of the real client IP addresses, the following image shows the Top 10 IP addresses and their geographic locations, which does not reveal obvious exceptions.

5

Analyze the User_Agent header

Many requests use "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5" in the User_Agent header, which seems to be the Firefox browser in a MacOS. However, the Website services are provided in the form of apps. As a result, they are rarely accessed with requests sent from MacOS. Moreover, Firefox does not appear in User_Agent headers that are recorded during normal access periods. We can determine that the User_Agent header containing Firefox is suspicious.

6

Based on this attack feature, we use HTTP ACL policies of WAF to control access from attacks that use this User_Agent header. You can configure a new rule to block requests with a User_Agent header that contains Firefox, as shown when adding a rule.

7

The preceding protection policy based on combined filter condition effectively ensures the normal delivery of services.

0 0 0
Share on

Alibaba Clouder

2,599 posts | 764 followers

You may also like

Comments