How to Sandbag Against IP Target Acquisition for Reverse Proxied/Obfuscated Services

July 5, 2016 | Views: 2187

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here

This article is the counter to my article about finding the obfuscated IPs of a server.

In the pentesting scene and security scenes, one of the more popular methods of securing servers and websites is by obfuscation and/or misinformation. If you can’t find the real IP of a backend server, it’s harder to accurately test it for:

  • vulnerabilities
  • its resistance to a brute force attack
  • bandwidth limits
  • the impact of a DDoS


This is becoming more and more common with services like CloudFlare, RackSpace Opencloud, and numerous others allowing you to hide your servers behind a reverse proxy to mitigate DDoS, manage traffic, cache static items, etc. And, whether it’s a penetration test, investigation, or some other purpose, if you cannot identify the true IP of the backend server, your job is usually much much harder.

In this article, I’ll cover each method my other article covered in how to find IPs – except this article will tell you how to defeat each of those methods and provide a better level of security for your servers.


1. Triggering an Error Page to get the Server and IP Info (This works on so many sites and web applications, it’s astounding. Yet, it’s not hard to protect against either.)
A. If an Apache web server is in use, change ServerTokens value to Prod in the config. Also set PHPs default error level to None on production systems.
B: If Apache, also customize the default error documents and remove all info other than the error code and a friendly message.
C. If IIS, modify the error templates and remove the IP and other debugging info from them.
D: If a Windows server and if DNS Server is running on the system, disable it from external connections.
E: There are other options too, these are just the big ones.


2. Remote File Download Tools (This one can be hard to prevent.)
A: Disabling tools is not, but these tools were made for convenience, not security.
B: Set up the Remote Downloader to use a proxy server. This can be difficult…


3. SPF Records
A: Always route outgoing mail through another server, and make sure that server acts as the message origin. In my network, I compose all outgoing emails to a MySQL database on a remote mailserver. Then, the server has a cron shell script that sends them out in batches every 60 seconds.
B: If sending mail from your main server is unavoidable, at least leave it out of the SPF records. Set the records to ~all or +all instead. This is not a good option, but it’s better than listing the IP blatantly.


4. Shared Hosting Providers and MX Records
A: Set up email hosting on a server elsewhere from the main server.
B: Set up a low-cost spam filtering account at some other provider and use their MX records. They, in turn, will invisibly forward the emails to the correct server you specify.
C: Find a provider that uses a dedicated email hosting system separate from their webhosting servers. This may be hard to find…


5. Outgoing Mail Headers Showing the Source IP
A: Refer to Number 3’s A method. This is gospel! Amazon has an SES service that can do this; Google also has an offering.


6. Alternate DNS Records and Domains Showing the IP
A: Always review every DNS record you have in place, especially CNAMES and A Records. Make sure you use the same protections on all domains that go to the particular service.
B: Just because you didn’t add any records, doesn’t mean the webhost dint add some for you. Godaddy is notorious for this during troubleshooting.


7. Historical DNS Revealing IPs
A: If your site or service ever ran without a reverse proxy or whichever obfuscation method you’re using, the IP IS OUT THERE! Don’t reuse the IP, change it – preferably by more then a few increments.
B: Don’t re-use old IPs unless its unavoidable.

This particular item will help defend against an attacker’s ability to verify he has the correct IP, should he discover it somewhere anyway. If he cannot confirm he found the correct IP, he may write it off as incorrect and move on!


Block all traffic from bypassing your reverse proxy or whatever obfuscation method you’ve employed. If Cloudflare, Whitelist all of Cloudflares origin pull servers, they’re available in their knowledgbase, and block all other traffic – at least to ports 80, 443 and 8080.

It’s usually OK to exempt intranet traffic from this rule, if you must. But, block all WAN traffic from direct IP access.

Another good method of tricking your adversaries would be to add a bogus IP address to your various error pages – perhaps list the IP that hosts the website, which could create some fun for anyone who attempts to attack!

Share with Friends
Use Cybytes and
Tip the Author!
Share with Friends
Ready to share your knowledge and expertise?
  1. Thank you very much

  2. What what what…

    In bullet point 3 you recommend setting the SPF record to ~all or +all, which we learned today in @jrodriguez01 0p3n tutorial will make our domain more readily spoofed for use in Spear Phish attacks and the like against our users/clients. @jrodriguez01 recommends using SpoofCheck of which one of the checks is The domain DNS SPF record does not specify ~ all or -all.
    So we trade one set of problems for another.

    Then in point 4 you seem to be recommending we pass our infrastructure, and it’s possible problems, on to 3rd parties. Instead of fixing problems we ignore them by passing the buck? Granted, for some this is not necessarily a bad option. There are providers with a history and reputation of doing the right thing and doing it both well and with security as a priority.

    Don’t get me wrong, you provided much more good and useful info than these quibbles I’ve highlighted. Historical data will get you every time :-p Glad you included that.
    And keep in mind attackers can take all the time they want to prepare and take as many varying pathways as they choose to. The attacker only has to succeed once whereas we, as defenders, must succeed each and every time.

    • Which would you rather have, spoofed emails, or a brute force running against your main server? I believe i noted that it wasnt a perfect solution, setting the SPF as such is a trade off. And if you have DKIM and DMARC setup like i do on my network, SPF is sort of a moot point. SPF in that case is less important.

      And 4 isnt about passing the buck, its only about getting the buck AWAY from the main server and pointing it anywhere else. That includes pointing it to your own server on a seperate network and ip subnet, thus even if it is discovered the main server is not.

      My points here are also a list of options, im not saying implement A and B and C, im simply providing options, But a lot of people are tied to a hosting companys limitations therefore they would be the ones stuck with the not so fun options.

      Myself i have my own Datacenter Presence, and 6 different CIDR blocks of IPs and IP6 IPs i can setup on to keep things seperated and make them appear to be diverged from each other. I also have a rental cloud system that really is elsewhere that i consider a throwaway, as it is where i put everything that has un-avoidable attack vectors.

  3. Nice, thank you for this 🙂

Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Support Cybrary

Donate Here to Get This Month's Donor Badge


We recommend always using caution when following any link

Are you sure you want to continue?