Stealth Server Setup: Hide Your Server Infrastructure from Detection

Most servers are discovered through one or more of these channels: DNS records, SSL certificate transparency logs, port scanning, BGP routing announcements, and referral links in web content. Understanding each discovery vector lets you systematically eliminate them. DNS records are the most common discovery path. If you have an A record pointing yourdomain.com to your server IP, anyone can look up that IP. Even with Cloudflare proxying, historical DNS records in passive DNS databases (SecurityTrails, Shodan, VirusTotal) often contain the real server IP from before Cloudflare was enabled. SSL certificate transparency (CT) logs are a frequently overlooked discovery vector. Every TLS certificate issued by a Certificate Authority is logged in public CT databases (crt.sh, Censys). If you request a Let's Encrypt certificate for yourdomain.com with your server IP as the destination, that certificate and its associated hostname are now permanently and publicly logged. Attackers routinely monitor CT logs for new certificate issuances to discover new servers. Port scanners like Shodan, Censys, and FOFA continuously scan the entire IPv4 address space. Any open port on your server is indexed by these systems. A server with port 22 (SSH), port 80 (HTTP), and port 443 (HTTPS) open will appear in Shodan within hours of provisioning. Referral links in web content can expose your server IP if your website makes requests to external services that log the referring IP. Analytics scripts, CDN resources, and embedded fonts all send your server's IP to third parties.

Eliminating DNS and certificate exposure requires deliberate choices at each layer. For DNS: use Cloudflare as a proxy for any domains that need to be publicly accessible. Enable "Proxied" mode (the orange cloud in Cloudflare DNS settings) so your real server IP is never exposed in DNS records. Cloudflare's anycast network presents its own IPs to the world and forwards traffic to your origin. Before enabling Cloudflare proxying, check that your server IP has never been in a DNS record - if it has, it may already be in passive DNS databases. For services that do not need clearnet access: use a .onion address instead of a domain. No DNS record, no certificate transparency log entry, and no IP exposure. For SSL certificates: if you must have a clearnet HTTPS site, be aware that the certificate issuance will create a CT log entry. Mitigate this by ensuring Cloudflare proxying is in place before requesting a certificate (use Cloudflare's Origin Certificate feature rather than Let's Encrypt - Origin Certificates are not logged in public CT logs), or accept that the domain-to-server association is public and rely on other anonymity layers. If you need a non-Cloudflare HTTPS setup, consider wildcard certificates from a provider that supports DNS-01 ACME challenges - these can be issued without exposing your server IP if DNS validation is used rather than HTTP validation.

Every open port on your server is a potential discovery point and attack surface. Stealth server configuration minimizes open ports to the absolute minimum required for your use case. Use a strict firewall policy that defaults to deny: ```bash # UFW default deny all ufw default deny incoming ufw default allow outgoing # Only allow what you need: ufw allow 2222/tcp # SSH on non-standard port ufw allow 443/tcp # HTTPS only (no plain HTTP) ufw enable ``` For SSH: move it to a high, random, non-standard port (e.g., 47832). Configure SSH to not respond to authentication attempts from IPs that have not knocked on a port sequence first. Port knocking adds a layer of obscurity that removes SSH from passive scanners entirely: ```bash apt install knockd -y # Configure /etc/knockd.conf with a port knock sequence # After knocking sequence (e.g., port 7000, 8000, 9000), SSH is opened for that IP only ``` For web services: never expose port 80 (HTTP). Run HTTPS only on 443. If you are using Nginx as a reverse proxy to application services, bind the application to 127.0.0.1 rather than 0.0.0.0 - this prevents direct access to your application port from the internet. Disable ICMP (ping) responses. While this will not fool a sophisticated scanner (they can detect hosts via other methods), it removes your server from the most basic host discovery scans: ```bash echo "net.ipv4.icmp_echo_ignore_all = 1" >> /etc/sysctl.conf sysctl -p ```

Even with minimal open ports and Cloudflare proxying, traffic analysis can reveal what your server is doing. Traffic obfuscation makes it harder to determine the nature of your server from network-level observation. TLS fingerprinting is a technique where the specific parameters of your TLS handshake (cipher suites, extensions, order) uniquely identify what software is running your server. Tools like JA3 and JA4 can identify Nginx, Apache, or specific application frameworks from just the TLS handshake. Configure Nginx with custom cipher suite ordering to reduce fingerprint uniqueness: ```bash # In nginx.conf ssl_protocols and ssl_ciphers directives, # use a non-default ordering that does not match known fingerprint databases ssl_protocols TLSv1.3; ssl_prefer_server_ciphers off; ``` HTTP response headers are fingerprinting vectors. Default Nginx installations send "Server: nginx/1.18.0" in every response. Remove or modify this: ```bash # In nginx.conf http block: server_tokens off; # Add custom headers to further obscure: add_header Server "Apache" always; ``` For Tor hidden services, traffic obfuscation is handled by the Tor protocol itself. Tor traffic appears as encrypted HTTPS to network observers, with no way to determine the destination or content. If you are running a VPN service on your stealth server, use WireGuard on a non-standard port (default is 51820/UDP - change this to something above 40000) and combine it with obfuscation tools like obfs4 if the VPN traffic itself needs to be hidden from DPI (Deep Packet Inspection) systems.