The front door is guarded. Is the back door?
With a protection service in front, your domain points to the service, the service checks every request, and only clean traffic goes on to your server, the origin. That works as long as the origin's own address stays out of reach.
Once attackers have it, they skip the front door. A flood sent straight to the origin never meets the protection, and the server goes down as if there were none. Attackers know this, and finding the origin is often the first thing they try.
Eight ways out
1. DNS history
Public DNS history services keep every address a name has ever pointed to. If your domain pointed straight at your server before you added protection, the old address is one search away.
2. Other names on the same server
mail, ftp, cpanel, dev, staging or direct: any record that points to the same machine without protection gives its address away.
3. Emails your website sends
Password resets, order confirmations and contact forms sent by the web server itself carry its address in the email's headers. Anyone can request a reset and read them.
4. Your SPF record
An SPF record that allows your server to send mail lists its address in plain text, in a DNS record anyone can read.
5. Internet-wide scans
Scan search engines connect to every IPv4 address and record what answers. If your server hands your domain's certificate or home page to anyone who connects by IP, a search for your domain finds it.
6. Outgoing requests
When your application fetches a URL for someone, such as a pingback, a link preview, a webhook test or an avatar, the request comes from your server's address. An attacker only needs to give it a URL they watch.
7. IPv6
An AAAA record that points straight at your server, next to an A record that points to the protection, sends part of the traffic, and attackers, around it.
8. Pages that talk too much
Error pages, debug output, phpinfo(), server status pages and response headers sometimes print the server's address or internal names.
Twenty minutes, from an attacker's chair
- List every DNS record of your domain, including mail and TXT records, and look for your server's address.
- Look your domain up in a DNS history service and in a scan search engine such as Censys or Shodan.
- Request a password reset or send a contact form to yourself, and read the full headers of the email.
- Connect to your server's address directly over HTTPS, without your domain, and see what it shows.
If any of these shows the address, assume attackers have it too.
Make the address useless, then make it new
Allow only your protection
The fix that matters most: in your server's firewall, or your hosting provider's network firewall, accept ports 80 and 443 only from your protection service. A known address then gets an attacker nothing. Exempt the service from automatic blocking tools such as fail2ban too, so forged traffic cannot get it blocked.
Move to a new address
If your server's address was public for a long time, ask your provider for a new one after the firewall is in place, and never point a public DNS record at it.
Send mail through a mail service
Send your website's email through an SMTP relay or a transactional email service. The headers then show the service, and your SPF record names the service instead of your server.
Clean up the rest
Remove or protect the other names, drop direct AAAA records, answer requests for unknown hosts with nothing, turn off pingbacks you do not use, and keep debug and status pages off the public internet.
On Shieldify, step 5 of the setup, Lock down your server, gives the one address to allow and the tools to exempt. If you are being attacked through a leaked address right now, start with the first 15 minutes.