Methods to prevent leaking website’s origin server IP behind CDN

18 min readOct 8, 2020

As a beginner of the webmaster, you may know using CDN nodes to avoid leaking the original server’s IP. Meanwhile, you would take some common measures, such as changing the domain hostname on original server, returning null or irrelevant information for unexpected requests.

However, some particulars might be neglected, like the certificate information. I am pretty sure that most people don’t notice the certificate information returned when you are trying to make web server return nothing by configuring the webserver. There’s some more, like: overlook on setting the default return (in Nginx, this will make the server return the first “server{}” block it loads if there’s no hostname included in the request), which is also the most easy-ignored thing.

Note: If you configure the Nginx like this, you will find that even you may think this will return nothing, the certificate information will still be returned.

The only SSL server block in the nginx.conf:

server {
    listen       443 ssl;
    server_name  localhost;

    ssl_certificate      /root/cert.pem;
    ssl_certificate_key  /root/cert.key;

    location / {
        return 444;
    }
}

The certificate information is still be returned:

curl -k https://127.0.0.1 -v
*   Trying 127.0.0.1:443...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=127.0.0.1
*  start date: Feb  12 07:35:46 2020 GMT
*  expire date: Feb  13 07:35:46 2020 GMT
*  issuer: CN=127.0.0.1
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.58.0
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server

This article introduces several methods to avoid hackers/searchers find your original server behind the CDN. However, if you need to protect your server completely, it is far from enough by only doing the things I introduce in this article. Security follows the Liebig’s barrel; any minor inattention will cause an unpredictable consequence. So take care of yourself, you need in charge of your security. The only thing I wrote here is about how to prevent IP leak from the webserver. If there is a neglected place, like design error in the application which causes the IP leak, this won’t help.

Back to the topic, if you extremely, fortunately, solve all issues about IP leaking from any other places, like the application you run. In general, the way hacker use to find your original node is scanning every possible IP by requesting like a regular user, and find the target by filtering the results. In most situation, you can prevent them by setting IP whitelist. But it depends. You may probably don’t know the IP that CDN nodes used for requesting your original server, or they’re changing. Use this policy may likely cause service interruption.

Outline

IP Whitelist

I only mention this for giving some typical common-sense mistakes

Change hostname/listen port
Prevent certification leak from aimless batch scan

Your domain info on the original server would not be inputted the database based on this

If possible, change the port the webserver listened to

Do set the default return rule

Give false information by feigning as other real-existing
Brief conclusion and flow chart

Last but the most important: Think like the searcher who uses the scanner.

Strategies

Assuming Debian/Ubuntu as the system, and Nginx as web server.

IP Whitelist

In fact, the most direct, efficient method to prevent original server IP leak is setting IP whitelist. If you can do so, you should do so. However, do remember the things:

If the CDN provider does not provide IP list they are using, do not use this strategy, or service interruption may occur;
If using HTTPS as the scheme while requesting the original server, you should use iptables instead of Nginx’s build-in access module, or the searcher still can find your server by detecting certificate’s SNI;
Simply only applying IP whitelist if using Cloudflare as CDN may give a chance for searcher to bypass Cloudflare’s protection and make them find your original IP address.

If worth, searcher can upload script to Cloudflare Worker and scan your IP by Cloudflare’s IPs, which can bypass your IP whitelist setting;
Enabling Custom Hostname (Enterprise feature) or Authenticated Origin Pulls/Client Certificate Authentication “correctly” can avoid this issue.

If you are using iptables, do remember to install iptables-persistent, or you may lose your filter rules if reboot:

apt-get install iptables-persistent

Change hostname/listen port

Generally, aimed scanners will scan all IPs with the standard ports(http/80, https/443) with your website’s exposed domain/hostname. So if you can change them, it will usually be okay.

However, if you somehow let the searcher know your hostname, or the IP ranges you use, your origin server has the risk to be exposed. So, do care.

Prevent Certificate SNI Leak patch

The intention of rejecting SSL handshake is preventing certificate’s SNI info leak (or can be easily considered as domain info) from the aimless batch scan. The searcher can build a website-IP relation database based on this for quick search in the feature after the aimless batch scan.

If your Nginx version is higher than 1.19.4, you can simply use the ssl_reject_handshake feature to prevent SNI info leak. Otherwise, you will need to apply the strict-sni patch.

P.S. This measure only works if you want to use HTTPS as the scheme for CDN nodes requesting the original server. If you only tend to use HTTP as the scheme for the requests, you can simply return 444; in default server block and there is no need to continue reading or just skim this part.

Configuration of ssl_reject_handshake (Nginx ≥ 1.19.4)

Two parts are involved in the configuration of the ssl_reject_handshake, default block, and the normal block:

server { # Default block returns null for SSL requests with the wrong hostname
    listen               443 ssl;
    ssl_reject_handshake on;
}

server { # With the correct hostname, server will process the requests
    listen              443 ssl;
    server_name         example.com;
    ssl_certificate     example.com.crt;
    ssl_certificate_key example.com.key;
}

Steps for installing sni-strict patch (Nginx ≤ 1.19.3)

First, install necessary packages:

apt-get install git curl gcc libpcre3-dev software-properties-common \
build-essential libssl-dev zlib1g-dev libxslt1-dev libgd-dev libperl-dev

Then, download the OpenSSL version you need in the release page.

Download the repository openssl-patch:

git clone https://git.hakase.app/Hakase/openssl-patch.git

Based on the OpenSSL version you choose before, switch directory to the OpenSSL code’s directory, and then patch the OpenSSL with the related patch:

cd openssl
patch -p1 < ../openssl-patch/openssl-equal-1.1.1d_ciphers.patch

Note from the developer:
OpenSSL 3.x has many API changes, and this patch is no longer useful. (Chacha20 and Equal Preference patch)
It is recommended using version 1.1.x whenever possible.

Download the Nginx package with the version you need.

Decompress the Nginx package, switch the directory into the Nginx, and patch the Nginx:

cd nginx/
curl https://raw.githubusercontent.com/hakasenyang/openssl-patch/master/nginx_strict-sni_1.15.10.patch | patch -p1

Specify OpenSSL directory in the configure arguments:

./configure --with-http_ssl_module --with-openssl=/root/openssl

N.B. In the actual practice, these arguments are far from making the website work as expection, you need to plus what you need as what you want. For example, if you want your website deployed with http/2 protocol, the argument --with-http_v2_module needs to be added, or the module won't be built.

If you tend to feign your server as other real-existing websites for aimless batch scan, intend to give the scanner false information instead of the null, you can also plus extra arguments here:

./configure --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-http_ssl_module --with-openssl=/root/openssl

P.S. This part is referring to “give false information by feigning as other real-existing websites/CDN nodes” in the outline, which is only for giving the false information to aimless scanner, and this is hard to work greatly for aimed scan. If you only want to show the fake website to unauthorized clients, like handcrafting fake website, making reserved proxy, etc. (and return null information to the aimless scanner), you should skip this part, or only add these arguments for advance.

After configuration, build and install Nginx.

make && make install

And the installation is finished.

To be convenient, I prefer to do these also after then:

ln -s /usr/lib/nginx/modules/ /usr/share/nginx
ln -s /usr/share/nginx/sbin/nginx /usr/sbincat > /lib/systemd/system/nginx.service <<-EOF
[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true[Install]
WantedBy=multi-user.target
EOFsystemctl enable nginx

Configuration of sni-strict patch (Nginx ≤ 1.19.3)

The configuration is similar to ssl_reject_handshake. There are 3 elements needs to be configured:

Control options
The fake(default) server block
Normal server blocks

http {
    # control options
    strict_sni on;
    strict_sni_header on;    # fake server block
    server {
        server_name  localhost;
        listen       80;
        listen       443 ssl default_server; # "default_server" is necessary
        ssl_certificate /root/cert.crt; # Can be any certificate here
        ssl_certificate_key /root/cert.key; # Can be any certificate here        location / {
            return 444;
        }
    }    # normal server blocks
    server {
        server_name  normal_domain.tld;
        listen       80;
        listen       443 ssl;
        ssl_certificate /root/cert.crt; # Your real certificate here
        ssl_certificate_key /root/cert/cert.key; # Your real certificate here        location / {
            echo "Hello World!";   
        }
    }
}

Now, the aimless batch scanner cannot know what website you are running on this server, except the situation that they already know and scan your server with the hostname, which is called aimed scanner.

P.S. return 444; means return literally nothing when it comes to HTTP (not HTTPS) requests. If the openssl-patch not patched, the certification information will still be returned while the client trying to establish TLS connection.

N.B. After strict_sni on; be set, the CDN nodes needs request with SNI or will encounter failure. See as: proxy_ssl_name.

Results

You can see the certificate information is hidden when the option turned on.

Before:

curl -v -k https://35.186.1.1
* Rebuilt URL to: https://35.186.1.1/
*   Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to 35.186.1.1 (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=normal_domain.tld
*  start date: Nov 15 05:41:39 2019 GMT
*  expire date: Nov 14 05:41:39 2020 GMT
*  issuer: CN=normal_domain.tld
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: 35.186.1.1
> User-Agent: curl/7.58.0
> Accept: */*
> 
* Empty reply from server
* Connection #0 to host 35.186.1.1 left intact
curl: (52) Empty reply from server

After:

curl -v -k https://35.186.1.1
* Rebuilt URL to: https://35.186.1.1/
*   Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to 35.186.1.1 (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, Server hello (2):
* error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name

In case, you should know the certification information will still be returned while requesting with the target hostname. Even you have configured client check rules(like: HTTP header check, etc.) after then. This is also why this can only prevent aimless scan: it only works when the attacker doesn’t know what website you are running on this server. To cope with the aimed scan, as original node, I highly recommend changing the hostname, if possible.

Request with the wrong hostname:

curl -v -k --resolve wrong_domain.tld:443:35.186.1.1 https://wrong_domain.tld
* Added wrong_domain.tld:443:35.186.1.1 to DNS cache
* Rebuilt URL to: https://wrong_domain.tld/
* Hostname wrong_domain.tld was found in DNS cache
*   Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to wrong_domain.tld (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, Server hello (2):
* error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name

Certificate info is not returned with if the hostname is wrong

Request with the right hostname:

curl -v -k --resolve normal_domain.tld:443:35.186.1.1 https://normal_domain.tld
* Added normal_domain.tld:443:35.186.1.1 to DNS cache
* Rebuilt URL to: https://normal_domain.tld/
* Hostname normal_domain.tld was found in DNS cache
*   Trying 35.186.1.1...
* TCP_NODELAY set
* Connected to normal_domain.tld (35.186.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=normal_domain.tld
*  start date: Nov 15 05:41:39 2019 GMT
*  expire date: Nov 14 05:41:39 2020 GMT
*  issuer: CN=normal_domain.tld
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET / HTTP/1.1
> Host: normal_domain.tld
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.17.5
< Date: Fri, 15 Nov 2019 05:53:19 GMT
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Connection: keep-alive
< 
abc
* Connection #0 to host normal_domain.tld left intact

Only if the hostname is correct, the certificate info will be returned

P.S. If you know the IP range that the known aimless scanners used, you can use iptables to block them also, as another minor safe protect measure. Such as the IP range of the Censys’s scanner listed below:

162.142.125.0/24
167.248.133.0/24
192.35.168.0/23
74.120.14.0/24

Give false information by feigning as other real-existing websites/CDN nodes

With this strategy, you can give some false information to the aimless scanner to let them build a database with false information. You may want to impose the scanner that your server is a CDN server; you may also want to combine your real site inside to confuse the aimed scanner to make it can not tell the server it detects is the original server or the CDN node, etc.

Personally, I am not willing to use this strategy, because it needs me to consider many factors, like which IDC provider will the real CDN node use (and host my website on the same IDC), the ASN (Autonomous System Number) its IP uses, the ports it opens, the HTTP header info added by CDN, etc., to make sure the searcher will feel confused. This is very plaguy.

N.B. You should set HTTPS as the only scheme for CDN nodes to request your origin server if possible. Otherwise, you need to care if the behavior on HTTP port. Such as the target server/website you want to feign always redirect http/80 requests to https/443 port, but you forget to turn requests to your website on http/80 port to https/443.

P.S. In fact, it is not a bad but not good decision to feign the server as Cloudflare’s CDN server. Because even though we can find Cloudflare’s IP range on official website, which makes you may consider that Cloudflare will only use these IP for CDN nodes, there are some currently-existing servers are actually running Cloudflare’s CDN node application, whose IPs are not included inside the IP list (or they are running the forward-proxy like what I will write next). Once upon a time, I ran a scan and found some servers without using Cloudflare’s IPs which are doing the thing above. Thus, feigning as Cloudflare’s CDN server is a thing: you would not actually need to have/use Cloudflare’s IPs.
However, It is also not a thing, because you must use your own-created(includes both the self-signed or the not) certificate for your real website. As we know, most Cloudflare users use the certificate signed by Cloudflare. If you do want to feign your server as Cloudflare’s, do consider for what purpose you want to do this.

Configuration

P.S. If you don’t know how to install ngx_stream_module, check the steps for installing sni-strict patch for Nginx 1.19.3 or below. The relative is there.

There are 3 main points in the configuration:

Feigning/default block for the port http/80 in the http block;
Feigning/default block for the port https/443 in the stream block;
The block to route your real domain/website to the backend.

Example of the configuration:

load_module "modules/ngx_stream_module.so";

http{ # Design the http block by yourself
    server {
        listen       80 default_server;
        server_name  localhost;
        location / {
            proxy_pass http://104.27.184.146:80; # Feign as Cloudflare's CDN node
            proxy_set_header   Host   $host;
        }
    }
    server {
        listen       80;
        server_name  yourwebsite.com; # If you set https as the only scheme for CDN nodes requesting your origin server, you should not configure the block of your real website in the http{} block, aka here (except that the listen address is "localhost" instead of the public network IP)
        location / {
            proxy_pass http://127.0.0.1:8080; # Your backend address
            proxy_set_header   Host   $host;
        }
    }
}

stream{
    map $ssl_preread_server_name $name {
        yourwebsite.com website-upstream; # Your real website's route
        default cloudflare; # Default route
    }
    upstream cloudflare {
        server 104.27.184.146:443; # Cloudflare's IP
    }
    upstream website-upstream {server 127.0.0.1:8080;} # Your real website's backend
    server {
        listen      443;
        proxy_pass  $name;
        proxy_ssl_name $ssl_preread_server_name;
        proxy_ssl_protocols TLSv1.2 TLSv1.3;
        ssl_preread on;
    }
}

Result

It will return the content with the real-existing certificate of other websites:

curl -I -v --resolve www.cloudflare.com:443:127.0.0.1 https://www.cloudflare.com/

* Expire in 0 ms for 6 (transfer 0x55f3f0ae0f50)
* Added www.cloudflare.com:443:127.0.0.1 to DNS cache
* Hostname www.cloudflare.com was found in DNS cache
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55f3f0ae0f50)
* Connected to www.cloudflare.com (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=4710875; C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=cloudflare.com
*  start date: Oct 30 00:00:00 2018 GMT
*  expire date: Nov  3 12:00:00 2020 GMT
*  subjectAltName: host "www.cloudflare.com" matched cert's "www.cloudflare.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert ECC Extended Validation Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55f3f0ae0f50)
> HEAD / HTTP/2
> Host: www.cloudflare.com
> User-Agent: curl/7.64.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 
HTTP/2 200 
< date: Tue, 06 Oct 2020 06:26:50 GMT
* Connection #0 to host www.cloudflare.com left intact

Succeed to feign as the real website, some results are omitted

Prevent unauthorized access by feigning as other self-handcrafting websites/returning null

Before starting this section, you should know this tactic can only be used while CDN nodes can return something different from normal user. Here is an example:

HTTP header check is a common way to authorize whether the request is from CDN.

P.S. GCP(Google Cloud Platform)’s HTTP Load balancing service provide an option to set the request headers that GCP CDN nodes should provide while origin servers receiving the data from GCP CDN nodes. This makes the origin server can know the CDN nodes requests from the normal/spiteful clients.

Note: Though GCP load balancing/CDN service only accept GCP VM instances as backends, the mechanism is the same. ↩︎

P.S. In some products, some engineers would like to add some header while requesting the origin server for debug, but not as a feature, which means it won’t appear in the document of their products (such as CDN.net), the customer service staff are not acknowledged also. If you want discover there’s an special header included in the header or not within the CDN product you use, write a simple script to dump all headers you received will be a good choice. This won’t be detailed here.

The configuration is literate, no need to explain:

server {
    listen       80;
    server_name  yourdomain.com;

    if ($http_auth_tag != "here_is_the_credential") {
        return 444;
    }
    location / {
        echo "Hello World!";
    }
}

Configuration if you want to return null

server {
    listen       80;
    server_name  yourdomain.com;

    if ($http_auth_tag != "here_is_the_credential") {
        return @fake;
    }
    location / {
        echo "Hello World!";
    }
    location @fake {
        root /var/www/fakewebsite/; # Highly recommend to build a hand-crafting fake website by yourself
    }
}

Configuration if you want to return fake website/backend

P.S. If you tend to configure these in https/443 port, I recommend you to self-sign the certificate with the unknown domain. Using the real certificate with the exposed domain may let scanner find your origin server easily. Nginx allows you to use the certificate without matching the SNI info with the server_name.

N.B. Some may consider using real certificate with the subdomain of the exposed domain, and most probably use Let’s Encrypt to get free certificates. It would be best if you cared about the Certificate Transparency, which can tell what certificates you have within the specific domain. Especially, Let’s Encrypt submits all certificates it issues to CT logs. (Reference: Original, Archive.ph)
If you want to see whether your certificate is logged into the CT log, you can visit crt.sh.
If you cannot tell whether the CA you want to apply for the certificate submits all certificates it issues to CT logs, you’d better self-sign the certificate.

The self-sign commands are below: (Self-sign the certificate for yeet.com)

cat > csrconfig.txt <<-EOF
[ req ]
default_md = sha256
prompt = no
req_extensions = req_ext
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
commonName = yeet.com
countryName = SG
[ req_ext ]
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=critical,serverAuth,clientAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.0 = yeet.com
EOF

cat > certconfig.txt <<-EOF
[ req ]
default_md = sha256
prompt = no
req_extensions = req_ext
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
commonName = yeet.com
countryName = SG
[ req_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=critical,serverAuth,clientAuth
subjectAltName = @alt_names
[ alt_names ]
DNS.0 = yeet.com
EOF

openssl genpkey -outform PEM -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out cert.key
openssl req -new -nodes -key cert.key -config csrconfig.txt -out cert.csr
openssl req -x509 -nodes -in cert.csr -days 365 -key cert.key -config certconfig.txt -extensions req_ext -out cert.pem

Considering some readers may use the commands I wrote above to generate CSR file, which can be used to apply for the real certificate, I reserve the field countryName (some CA needs this field exists while receiving CSR file). If you don’t need it, you can simply delete it.

N.B. Self-sign the certificate may rise the risk of the MITM (man-in-the-middle attack), unless the underlying facilities are credible, or the CDN provider does support requests with provided client certificate, aka Authenticated Origin Pulls in Cloudflare.

Client Certificates check is also the way to authorize whether the request is from CDN nodes. Only seldom CDN providers support requesting with the client certificate. Whatever which provider has this feature, the configuration on your sever are likely. Here’s the example:

server {
    listen       443;
    ssl_certificate /etc/nginx/certs/cert.crt;
    ssl_certificate_key /etc/nginx/certs/cert.key;

    server_name  yourdomain.com;

    ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
    ssl_verify_client on;

    error_page 495 496 = @444; # For specifying the return instead of giving the default return while the error is related to the client certificate auth error

    location @444 {return 444;}

    location / {
        echo "Hello World!";
    }
}

It will return null while facing the client certificate errors

P.S. Feigning as other websites/backends is also possible, imitate the one in the “HTTP header check” part and you can do it.

N.B. Whatever what method you want to use, do care the default return. Make the default return same as the return if the requests are invalid.

server {
    listen       80  default_server;
    listen       443 ssl default_server;
    ssl_certificate /etc/nginx/certs/cert.crt;
    ssl_certificate_key /etc/nginx/certs/cert.key;

    server_name  localhost;

    location / {
        return 444;
    }
}

Make the default return as null as the return for invalid requests

Result

curl http://127.0.0.1:80
curl: (52) Empty reply from servercurl -k https://127.0.0.1:443   
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

Conclusion

In simple, to protect your origin server IP from detection, you can:

Set IP whitelist if possible
Change the hostname of your website on your origin server if possible/Change the listen port if possible
Set default return for unmatched hostname
Set authorization method for matched hostname
Think if you are the scanner itself, how will you think about the server behavior

The whole process can be roughly drawn like this:

This article and all my original drawing/work within are under CC BY-SA 4.0. Meanwhile, please indicate the post link if you want to quote this article.

Methods to prevent leaking website’s origin server IP behind CDN

Outline

Strategies

IP Whitelist

Change hostname/listen port

Prevent Certificate SNI Leak patch

Configuration of ssl_reject_handshake (Nginx ≥ 1.19.4)

Steps for installing sni-strict patch (Nginx ≤ 1.19.3)

Configuration of sni-strict patch (Nginx ≤ 1.19.3)

Results

Give false information by feigning as other real-existing websites/CDN nodes

Configuration

Result

Prevent unauthorized access by feigning as other self-handcrafting websites/returning null

Result

Conclusion

Written by Sion Kazama

No responses yet