Fundamentals of Origin Server Protection

Servers host applications and services; therefore, they are the center of all web, mobile, and API applications.

These origin servers are under constant attack as hackers run probes to exploit open vulnerabilities and launch large-scale DDoS attacks that could bring down the entire infrastructure.

Therefore, ensuring availability and protecting the integrity of origin servers is paramount.

This article will cover what, why, and how of origin protection.

Why Should One Protect Origin Servers?

It is a given that a server going down is far more debilitating than a single application going down. After all, a server may host many applications.

An origin server could be exploited in multiple ways, including:

Unknown Application

An RCE or XSS vulnerability in an application that was sunset but still accessible over the public web. Since the other applications are hosted on the same origin server, they are compromised, too.

Application Vulnerability

An SQLi vulnerability on an application that allows hackers to exfiltrate data from all the other applications hosted on the same origin server

Server Vulnerability

An exploit that targets the vulnerability in the server to bring down all the applications hosted on the server.

DDoS Attack

A DDoS attack that targets one application could force the server to use all the resources for serving this application, and then all the other applications go down.

Direct-to-Origin DDoS Attacks 

Direct to Origin DDoS Attack  (D2O) is a type of attack where malicious traffic is directly targeted at the origin server of a website or application, bypassing defenses such as CDNs or WAF. This approach aims to overwhelm the server’s resources and cause service disruption by flooding it with a high volume of requests or traffic. 

How to Protect Origin Servers?

There are six ways to protect the origin servers.

1. Maintain an Inventory of Your External Attack Surface

As discussed earlier, an origin server could be brought down through a weak link on any application.

It is, therefore, important to understand all the applications hosted on the origin server and either bring down applications that are no longer in use or protect all the critical applications behind a WAAP.

2. Perform Penetration Testing

Once you have the entire external surface, the next step is to perform in-depth penetration testing on the server and all the applications hosted on the origin server.

This activity will give an accurate understanding of open vulnerabilities across the origin server and the applications hosted on it.

Since the applications constantly change, it is a best practice to perform periodic penetration testing. Depending on the criticality of the application or the compliance guidelines, it is recommended to do pen testing every 6-12 months.

3. Patch Vulnerabilities Regularly

Have patching programs so that all the vulnerabilities identified in the previous step are patched regularly.

Every month, 200-300 zero-day vulnerabilities also get discovered. It is important to stay on top of zero-days through patch Tuesdays and other news bulletins and apply these patches as soon as possible.

4. Implement a Content Delivery Network (CDN)

A CDN server sits between the user sending a request and the origin server. Since it sends back cached content for static pages, no load is transferred to the origin.

While a CDN cannot help in case of a vulnerability attack, a CDN could provide a first layer of defense against DDoS attacks.

5. Implement a Load Balancer

Similar to a CDN, a load balancer essentially divides the incoming traffic.

The only difference is that the traffic is divided among various origin servers so that one server is not overwhelmed.

This offers a very basic level of protection against DDoS attacks.

6. Implement a WAAP / WAF

A WAAP or a WAF is the most important defense against all vulnerabilities, DDoS, and bot attacks.

A WAAP sits on the edge and does deep packet inspection by breaking the connection. It’ll thoroughly inspect the contents of the traffic, reconstruct the entire packet, and then forward only clean traffic to the origin server.

In case it is a cloud WAAP, you will have, by default, protection against even the network layer attacks (SYN flood, TCP/IP hijacking, etc.) as these attacks hit the network of the WAAP provider.

That said, one of the organizations’ biggest mistakes is putting only critical applications behind a WAAP. When you do that, there’s a big chance that the origin server could be attacked via the applications that a WAAP does not protect.

So, it is best to maintain an inventory of all applications on the origin server and remove the application as an internet-facing asset or put it behind a WAAP.

D2O Attack Through WAF Bypass 

WAFs use reverse proxies to filter requests to an application’s public domain like www.example.com, ensuring only valid traffic reaches the origin server. Despite these protections, the origin server can still be directly accessible on the internet.  

Attackers can discover the origin server IP through techniques like regex searches in search engines, enabling them to launch direct-to-origin DDoS attacks.  

These attacks bypass WAF defenses by targeting the server’s IP address, such as 153.42.1x.5xx, rather than its public domain name.  

Implementing an ‘allow list’ policy on the origin server is recommended to mitigate such risks. However, this is challenging due to requests from multiple IP addresses, including those dynamically assigned by the WAF. 

Origin Protection on the AppTrana WAAP

One common problem is the management of multiple dynamically assigned IP addresses by the WAF.   

AppTrana’s unique architecture uses a static set of IP addresses (NAT IPs) to forward requests to the application Origin. This allows application administrators to include WAF’s NAT IPs in their server’s allow list, ensuring protection against Direct-to-Origin Attacks. 

Unlike many WAAP vendors, Origin protection is provided by default in all AppTrana plans. 

As part of the onboarding process, customers change the DNS settings so that AppTrana serves as a reverse proxy and all the traffic hits the AppTrana servers. 

Then, the customers whitelist AppTrana IPs and block traffic from all other IPs. When done for all applications hosted on the origin server, the customer portal displays that the origin server protection has been enabled. 

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.