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.

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.

Origin Protection on the AppTrana WAAP

Unlike many WAAP vendors, Origin protection is a default in the AppTrana WAAP.

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

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

As discussed earlier, one common problem is that even though the engineering teams protect the application in WAF, the origin server is still accessible to the internet directly.

Though WAF front ends the application and all traffic is routed through WAF, there are chances that the Origin server can be accessed through other means.

One example, when probing other applications on the server, the IP address of the application can easily be found. Then the attackers bypass WAF easily and hit the application directly through the IP.

You can avoid this by checking for origin protection status as part of WAF. In other major WAFs, origin protection is an add-on, but it is enabled by default on AppTrana.

We provide IP address details of AppTrana WAAP and ask customers to block(blacklist) all requests that don’t originate from these IPs.

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