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 RecordsA: 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 RecordsA: 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 IPA: 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 IPA: 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 IPsA: 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!
Summary: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 FBI.gov website, which could create some fun for anyone who attempts to attack!
