Banned IPs continue to be able to access my site

I posted before about how people were able to post spam comments to the forms on my website, despite their IP addresses being blocked by Cloudflare’s Firewall Tools.

People told me that they might be accessing my site directly using the IP address and suggested denying all traffic that didn’t originate from Cloudflare’s IP addresses. So, I did that. I updated the nginx server blocks to allow traffic from Cloudflare’s IP addresses and denying all other traffic. However, I continue to get the spam form entries.

  1. How can I test whether my website can be accessed directly using my IP address, and
  2. What is going on that people are still able to submit spam comments?

Hi,

You could use curl:
curl -svo /dev/null https://yourwebsiteaddress --connect-to ::ip.of.your.origin

You could also just add an entry to your hosts file (/etc/hosts or c:\Windows\System32\Drivers\etc\hosts) and access the website normally using the browser. Example of entry:
ip.of.your.origin yourwebsiteaddress

If you are able to access the website, then it is allowing traffic from any IP, not only Cloudflare and you would need to check your firewall rules in the origin.

It depends a lot, you would really need to check the logs and see exactly which IP are they coming from, what url are they using to send it, which user agent are they using. Personally I would try to create a firewall rule issuing a challenge or captcha for the contact page rather than blocking the IPs (unless it was being heavily targetted by a specific ip). This way I wouldn’t risk blocking legitimate traffic.

I hope I was able to help a bit.

2 Likes

That was very helpful. I assume that ip.of.your.origin refers to my website server’s IP address rather than my own IP address.

When I did that, I got the following output (domain and IP address obscured intentionally), which suggests to me that I was correctly given a 403 error code, is that right?:

    Computer:.ssh Dave$ curl -svo /dev/null https://mysite.com --connect-to ::0.0.0.0
* Connecting to hostname: 0.0.0.0
*   Trying 0.0.0.0...
* TCP_NODELAY set
* Connected to 0.0.0.0 (0.0.0.0) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [230 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [102 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2814 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=www.mysite.com
*  start date: Sep  2 23:27:06 2020 GMT
*  expire date: Dec  1 23:27:06 2020 GMT
*  subjectAltName: host “me.mysite.com” matched cert's "me.mysite.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  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 0x7fd57580f600)
> GET / HTTP/2
> Host: me.mysite.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 403
< server: nginx
< date: Tue, 13 Oct 2020 04:39:07 GMT
< content-type: text/html
< content-length: 146
<
{ [146 bytes data]
* Connection #0 to host 0.0.0.0 left intact
* Closing connection 0

Hi,

Yes. 403, when connecting to your origin means your request was blocked (or have some permission issue) by your origin web server (nginx, in this case). In my option you would be better off blocking it in a firewall level (if possible) so that the request doesn’t even reach your web server.

1 Like