KNOWNHOST KNOWLEDGE BASE

Hosting Question? Find the Solution - Browse our Guides, Articles, and How-To's

What is a Website Application Firewall?

Category: Common Issues
Tags: # # # # # #

There are many different server environments out there that experience disruptions due to malicious attacks of varying natures. Above all, each of these applications can be susceptible to incidents such as ‘Layer 7’ or ‘Application Layer DDoS’ attacks. This is performed by attempting to saturate network or server resources with traffic floods. A WAF (website application Firewall) can help protect against these incidents.

In this article, we want to go over the different methods you can use to protect your website against such incidents and by providing brief explanations as to what the types of attacks are.

What is an Website Application Firewall?

A website application firewall creates a shield between the web application and the world wide web. It filters and monitors HTTP traffic from all incoming requests towards that application. Filtering out things such as:

  • Bad traffic (such as bots, spam traffic, etc)
  • File inclusions
  • Blacklisted IP’s
  • Malicious injections
  • SQL Injections

By having this in front of your application, you better protect your application from malicious actors.

What is an Application Layer DDoS attack?

The reason that these attacks are called Application layer attacks or layer 7 (L7) is due to method used to attack. Whereas your typical DDoS attack may hit the network layer with things such as volumetric floods, application level attacks focus on depriving the server of its resources to bring it down. This is usually handled through methods such as HTTP Floods.

Common Layer 7 Attacks

The usual application-layer DDoS attack that you often see is HTTP Flooding. This is done by attacking the webserver directly. There are a few different types.

1. General HTTP Floods:

In this type of attack, the malicious actor sends HTTP Requests (GET/PUT) that the webserver would believe to be from a real user of your web application. Attacks of these type are easy to spot as they usually have the same range of IP Addressers, user agents or referrals. These are used in tandem by flooding a specific resource repeatedly until the server stops responding.

170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"
170.249.xxx.xxx - - [01/Oct/2021:10:59:40 -0400] "GET / HTTP/1.1" 200 890 "-" "h2load nghttp2/1.43.0"

As you can see in the above example. The goal is to just simply overload the server with requests. This sort of attack could be easily mitigated by a website application firewall monitoring as it would just block the offending IP triggering its ruleset.

2. Randomized HTTP Floods:

Similar to the general HTTP Flood. These floods only differ in the manner that they are used. Randomized IP addresses, user agents, target URLS, etc — they perform the same GET/PUT requests placing strain on the server. These attacks are likely to be botnet controlled devices that have been maliciously infected with malware.

   2000 170.249.xxx.100 "GET /
   1811 170.249.xxx.164 "GET /7
   1770 170.249.xxx.100 "GET /1
   1748 170.249.xxx.67 "GET /6
   1025 170.249.xxx.16 "GET /3
    906 170.249.xxx.226 "GET /4
    874 170.249.xxx.129 "GET /2
    645 170.249.xxx.99 "GET /8
    458 170.249.xxx.179 "GET /5

In the above example, you can see the different IP addresses hitting various paths numerous times — in this instance, they all occurred in over a few minutes which easily overwhelmed the server. This makes mitigating harder if the malicious actor has a wide-range of IP’s at their disposal.

3. Cache-bypass(cache-busting) HTTP Floods:

This is probably one of the smartest types of HTTP Floods out there. This method of flooding is used against websites that have caching, usually CDN (content delivery network). This method uses variations in query strings to circumvent the caching being provided. As a result, instead of the server returning cached results the CDN or caching service must contact the origin server for every search requests. As these get requested, you begin to see the original server strain under the requests.

These requests can use any variation of key characters in the query or they can focus on dictionary based words.

xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:07 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=aaaaaa" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:08 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=adfaf3" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:09 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=4tfadefa" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:10 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=34tfdefa" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:11 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=34tfdafas" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:11 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=fg6wy5a" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:11 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=dafasdef4" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"
xxx.xxx.xxx.xx - - [01/Oct/2021:12:11:12 -0400] "GET /d/_media/wiki:dokuwiki.svg HTTP/1.1" 200 6709 "https://redacted.com/d/apache?q=daf4fase3" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.54 Safari/537.36"

As you can see in the above example; each request made is a different query. If this website was behind a CDN then this would force a retrieval against the origin server. Hundreds of such requests in a short period of time would place strain against the server.

4. WordPress XML-RPC Floods:

As of 2021, WordPress powers around 39% of the internet. As this number continues to grow, it makes sense that we’ll see more of these as users begin making use of WordPress. This attack takes advantage of WordPress by utilizing pingbacks from other websites. By abusing the pingback feature, they can force other WordPress websites to attack each other in order to verify the existence of the link used to pingback.

This is easily preventable by disabling pingback requests.

Read more about this in detail here:

This is identifiable by the following behavior:

52.28.2.139 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.0.1; http://www.muchohogar.com; verifying pingback from 185.103.252.170"
177.153.22.251 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5.1; http://detox.suavidamaisfeliz.com; verifying pingback from 185.103.252.170"
119.9.131.80 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5; http://ruedeseine.com; verifying pingback from 185.103.252.170"
130.185.250.98 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.4.2; http://devoclips.com; verifying pingback from 185.103.252.170"
149.210.165.225 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5.1; http://sng-line.com; verifying pingback from 149.210.165.225"
84.21.137.236 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.3.1; http://www.web-promote.com; verifying pingback from 185.103.252.170"
104.196.107.216 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.4.2; http://homesophy.com; verifying pingback from 185.103.252.170"
89.225.228.230 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5.1; http://89.225.228.230; verifying pingback from 185.103.252.170"
98.129.41.189 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.3; http://www.sscriticalcommunication.com; verifying pingback from 5.154.191.67"
130.211.134.65 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5.1; http://130.211.134.65; verifying pingback from 185.103.252.170"
104.130.159.101 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5; http://www.vmcfortmill.com; verifying pingback from 185.103.252.170"
59.124.159.107 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5.1; http://myhome123.tw; verifying pingback from 185.103.252.170"
198.245.57.157 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.5.1; http://wpadmin.4mobile.cc; verifying pingback from 185.103.252.170"
136.243.152.43 - [-] - [06/May/2016:14:14:12 +0800] redacted.com "GET / HTTP/1.0" 200 162 "-" "WordPress/4.2.4; https://www.leginda.de; verifying pingback from 185.103.252.170"

5. Slowloris Attacks

Although not seen as often as the other layer 7 attacks, Slowloris style attacks are the opposite of what you’d think a DDoS would be. Slowloris attacks do not overload the server with a vast amount of data. Instead, these attacks are performed by keeping connections open to deliver their payloads over a period of time. Doing this in allows the webserver or services connection pools to be exhausted as it waits to receive the entire request. This results in the server from being able to provide connections to other legitimate users.

Slow Loris is typically seen as a massive amount of 408’s against the webserver

27.67.182.32 - - [11/Sep/2021:00:00:22 -0300] "-" 408 - "-" "-"
152.156.222.31 - - [11/Sep/2021:00:02:01 -0300] "-" 408 - "-" "-"
152.156.222.31 - - [11/Sep/2021:00:02:01 -0300] "-" 408 - "-" "-"
190.239.72.229 - - [11/Sep/2021:00:03:41 -0300] "-" 408 - "-" "-"
27.55.90.48 - - [11/Sep/2021:00:06:07 -0300] "-" 408 - "-" "-"
103.25.76.25 - - [11/Sep/2021:00:08:39 -0300] "-" 408 - "-" "-"
201.138.132.156 - - [11/Sep/2021:00:15:46 -0300] "-" 408 - "-" "-"
190.56.50.36 - - [11/Sep/2021:00:20:46 -0300] "-" 408 - "-" "-"
190.56.50.36 - - [11/Sep/2021:00:20:46 -0300] "-" 408 - "-" "-"
186.48.100.11 - - [11/Sep/2021:00:31:39 -0300] "-" 408 - "-" "-"
45.4.54.212 - - [11/Sep/2021:00:31:43 -0300] "-" 408 - "-" "-"
167.57.108.125 - - [11/Sep/2021:00:31:48 -0300] "-" 408 - "-" "-"
190.114.37.236 - - [11/Sep/2021:00:37:19 -0300] "-" 408 - "-" "-"
186.213.138.35 - - [11/Sep/2021:00:44:57 -0300] "-" 408 - "-" "-"
186.213.138.35 - - [11/Sep/2021:00:44:57 -0300] "-" 408 - "-" "-"
186.213.138.35 - - [11/Sep/2021:00:44:57 -0300] "-" 408 - "-" "-"
186.213.138.35 - - [11/Sep/2021:00:44:58 -0300] "-" 408 - "-" "-"

Protecting against Layer 7 Attacks

Now that we’ve gone over the different common attacks, you’re probably wonder how you can go about protecting against them and the answer is rather simple. A WAF will help protect your website against Layer 7.

To be clear, there is no 100% way to completely protect yourself. The only truly protected server is one not connected to the internet. That’s why the keyword for all of this is mitigating.

Mitigation reduces the effectiveness of these attacks against your server allowing your website or applications to continue being served.

To be effective at this, you want a managed website application firewall that is proactive about protecting your server from such incidents. While there are many different website application firewalls out there, the one that we recommend and provide managed assistance with is Imunify360.

Imunify360 is eligible for all KnownHost Managed VPS, NVMe, Cloud and Dedicated Servers.

Conclusion

In this article, you learned a little bit about what Application Layer Attacks are, the different types that are most commonly seen and what sort of security is needed to protect yourself against Layer 7 attacks. While there may be other types of protections out there such as mod_security. A proper WAF is really the way to go.

KnownHost offers 365 days a year, 24 hours a day, all 7 days of the week best in class technical support. A dedicated team is ready to help you should you need our assistance. You’re not using KnownHost for the best web hosting experience? Well, why not? Check with our Sales team to see what can KnownHost do for you in improving your web hosting experience.

Related Articles: