A few days ago, a team of researchers released an interesting paper on the topic of “origin-exposing” attacks that could be used to circumvent cloud-based security solutions. The research focused on always-on cloud-based DDoS mitigation, such as Incapsula Website Protection.
We feel that the paper is an important read, as it helps raise awareness of the significance of some routinely suggested, and yet often overlooked, best-practices for using a cloud-based security solution.
Being one of the cloud-based security providers mentioned in the study, we wanted to use this as an opportunity to revisit these best-practices, which will help you benefit from the ‘security through obscurity’ offered by cloud-based security services.
Best Practices for Concealing Your Origin IPs
1. Set IP Restriction Rules
With Incapsula deployed on the edge of your network, and serving as a proxy for all incoming traffic, there should be absolutely no reason to accept traffic from anywhere but our network. Consequently, we always suggest setting IP restriction rules (i.e., using your firewall or iptables) that will block all traffic from non-Incapsula IP addresses.
Using IP restrictions will block all illegal requests that try to circumvent the Incapsula WAF. On top of that, with IP restrictions in place, your origin will also be immune to scanners, including the ones described in the study, that may try looking for IP data in SSL certificates stored on your server.
For a full list of Incapsula IP addresses and directions for setting IP restriction rules, please visit here.
2. Change Your IP Address
When trying to uncover your origin IPs, perpetrators don’t have to limit themselves to simply resolving your domain name. One of the things that attackers can, and will often do, is dig around for a historical record of your origin address, which is likely to exist on one of the many websites that harvest and store domain information and IP history.
To make this information irrelevant, we strongly suggest that you relocate your origin to a new IP right after activating Incapsula. That way, resolving your domain name will only “expose” our network IPs and attacks on your legacy IP will always miss their target.
Note that this doesn’t mean that you have to change hosting providers, as you are very likely to have an option to relocate to a different IP address on the same hosting service.
3. Avoid Generic Subdomain Names
You always want to rename subdomains that are not protected by Incapsula services. For example, if you are using a subdomain to establish FTP connections with your origin server, avoid the obvious choice of ftp.mydomain.com, and instead go with something more secure and unique like 4exampleftp.mydomain.com.
Note that perpetrators are aware of the existence of such generic subdomains and have means to easily discover them using automated scanners. Once located, the subdomain can be resolved to locate your origin IP address and make your website susceptible to direct-to-origin attacks.
4. Don’t Leave a Trace in DNS Records
Be mindful of your various DNS records and make sure that none of them resolve directly to your origin. The most common example here is an MX record that often points to an email server running on the same machine.
Onboarding cloud-based security services requires you to change your A and CNAME records, but not your MX record or any other record that you have set to point to your main sever. Any of these can be resolved to uncover origin IPs.
Our suggestion is to review your DNS records and remove the ones that are not in use.
In some cases, you may also consider migrating some of your services. In the case of the MX record for example, if origin exposure is your main concern, than the secure thing to do is to migrate your email service to a different server.
5. Lock Down Sensitive Data
One of the things the study mentions is the existence of so-called “sensitive pages” that leak detailed information about a web server. There are various systems and server logs, (e.g., phpinfo), that might be publicly accessible and used to expose sensitive information, including that of your origin IP.
It should go without saying that files like these should never be made public and not only for concerns of direct-to-origin attacks.
6. Disable Visitor-Triggered Outbound Connections
If you are running a WordPress site that uses XMLRPC, your origin IP might be exposed using a pingback request. We recommend disabling pingback, (via server configuration or WAF rules), unless you’re absolutely depending on its functionality.
A somewhat similar, but far less common scenario, can occur as a result of using ‘referer validation’ mechanisms, which inspect the URLs used in the request’s referrer header. If your web application relies on referrer validations, we strongly suggest running them on a different server.
Evaluate Your Risk
Administrators of Incapsula-protected websites looking to improve their origin security can use CloudPiercer—a free online tool offered by the team behind the aforementioned research paper. With this tool, you are able to identify your soft points and address them using a combination of the methods above.
Note that the tool will require validation of ownership, so it’s unlikely that it could be used by perpetrators looking to expose your origin IP.
We also should mention that while running internal tests with the tool, we found that it gave us a false reading while scanning one of our own subdomains. We reached out to the CloudPiercer team, who acknowledged the issue and assured us that it has been fixed. They also confirmed that this particular problem did not affect the findings of their statistical research.
Consider Infrastructure Protection
Security through obscurity is an important side-benefit of using a reverse proxy security service. Having said that, IP masking is not a dedicated solution for protection against direct-to-origin DDoS attacks.
For customers looking for complete origin protection, we suggest our Infrastructure Protection DDoS mitigation service. This dedicated solution re-routes traffic using BGP announcements and cannot be circumvented by any of the attack vectors discussed in the research paper.
Currently, Infrastructure Protection can only be used by website administrators that own an entire Class C IP subnet—the minimal amount required to make BGP announcements. We are, however, already working on a new service called Protected IP, which will provide complete origin protection to websites of all sizes.
The new service is now in the advanced beta stage and will soon be made available to all of our customers.
More questions? Feel free to leave a comment below and we’ll address it. If you want to learn more about Protected IP beta, direct-to-origin attacks, and IP masking best practices, feel free to reach us at support@incapsula.com.
Try Imperva for Free
Protect your business for 30 days on Imperva.
