How to Restrict Direct Access to Server’s Real IP When Using Cloudflare (OpenLiteSpeed)

[krlabs]

Every day, dozens of bots, crawlers, and other attackers make requests to xttp://SERVER_IP. So the question arises - how to restrict access to the server by its IP address.

One of the options that immediately came to mind is to use the Accces/Denied List at the Server Settings level in the WebAdmin panel.

Knowing that I have Cloudflare, I first set the mode to Trusted IP and then marked all Cloudflare-trusted IP addresses with a T. In the Access List, I had the following:

173.245.48.0/20T, 103.21.244.0/22T, 103.22.200.0/22T, 103.31.4.0/22T, 141.101.64.0/18T, 108.162.192.0/18T, 190.93.240.0/20T.. (all IPs CF here: https://www.cloudflare.com/ips/)

And in the Denied List, I added ALL, hoping to block all IP addresses that are making access to xhttp://SERVER_IP.

As a result, Cloudflare returning a 520 error (Obviously, their IP address pool is much wider... ). I had to disable the full blocking and create the Denied List manually, adding each address separately...

So the question is still relevant: what is the best practice to completely restrict public HTTP access to a server IP address?

A similar topic was discussed here, but I didn't find an answer there: https://forum.openlitespeed.org/thr...lare-ip-for-connection-limit.5870/#post-17285

Are there any administrators here who care about the security of their servers and have come up with a complete solution?

 

[krlabs]

Another solution that came to mind was to redirect from the server IP address to the domain. But I didn't like it. Because there are a lot of resources on the server and I don't want to associate the server IP address with any of them.
https://forum.openlitespeed.org/thr...cess-redirect-from-ip-address-to-domain.4420/

 

[LiteCache]

Every day, dozens of bots, crawlers, and other attackers make requests to xttp://SERVER_IP. So the question arises - how to restrict access to the server by its IP address.

The problem you describe is a well-known problem that many experts have already racked their brains over. There is a solution to this problem, but it is not an OLS problem because OLS is just a web server. That is why you cannot expect a web server to solve a problem that requires other solutions.

A classic solution such as a firewall or a WAF can only solve this problem to a limited extent. Especially since firewalls or a WAF are only smart to a limited extent. In order to block unwanted traffic, you must first identify the unwanted traffic. The IP address may be an identification feature, but blocking unwanted traffic by IP address is like fighting windmills, which means you always lose this battle. The same applies to the user agent, by the way. CloudFlare's standard filters are therefore not useful. Especially since CloudFlare does not know what is important for intelligent blocking.

What am I trying to tell you? There are solutions to block unwanted traffic efficiently and without much effort or cost, but don't expect to get such solutions for free in a forum.

I have been working on such solutions since 1998, so you can expect that I know what I'm talking about and I know what works. If you are willing to invest money, then I am happy to help you.

 

[krlabs]

The problem you describe is a well-known problem that many experts have already racked their brains over. There is a solution to this problem, but it is not an OLS problem because OLS is just a web server. That is why you cannot expect a web server to solve a problem that requires other solutions.

A classic solution such as a firewall or a WAF can only solve this problem to a limited extent. Especially since firewalls or a WAF are only smart to a limited extent. In order to block unwanted traffic, you must first identify the unwanted traffic. The IP address may be an identification feature, but blocking unwanted traffic by IP address is like fighting windmills, which means you always lose this battle. The same applies to the user agent, by the way. CloudFlare's standard filters are therefore not useful. Especially since CloudFlare does not know what is important for intelligent blocking.

What am I trying to tell you? There are solutions to block unwanted traffic efficiently and without much effort or cost, but don't expect to get such solutions for free in a forum.

I have been working on such solutions since 1998, so you can expect that I know what I'm talking about and I know what works. If you are willing to invest money, then I am happy to help you.

Thank you for your feedback. I understand exactly what you mean. Of course, there are solutions like fail2ban and others. Of course, Cloudflare is not a panacea at all. In this case, I'm just trying to use the standard functionality. But if it doesn't provide for this, if there are no standard solutions already in place, then we will use or create other ways).

 

[krlabs]

Another option is to create a separate virtual host with an IP address and deny access:
https://forum.openlitespeed.org/threads/hide-server-ip.5612/

At this moment this solution works.

 

[krlabs]

How to protect access to Server IP?
-----------------------------------

1. Create a new Virtual Host with any name, for example, “serverhost”.
2. Add new host "serverhost" in Listeners 80/443 (HTTP/HTTPS) and assign them the server IP address.
3. Activate "Enable Rewrite" on the Rewrite tab in Vhost Settings and add RewriteRule (.*) - [F,L] in the Rewrite Rules tab
OR
Add Context -> Static with access denied. In Location, specify the vhost location, for example /usr/local/lsws/your-vhost
4. View logs tail -n 50 /usr/local/lsws/logs/access.log. Now the "bombers" are getting 403s.

PROFIT
...and nothing money invest.

 

[LiteCache]

4. View logs tail -n 50 /usr/local/lsws/logs/error.log. Now the "bombers" are getting 403s.

...but causes higher load to prevent blocking requests in that way... OLS is a web server and not a firewall and every block causes extra load.

 

[krlabs]

...but causes higher load to prevent blocking requests in that way... OLS is a web server and not a firewall and every block causes extra load.

If you think that a lot 404 errors, which the server processed before and returned for thousands of non-existent spam HTTP-requests, not caused HIGHER LOAD, then you are mistaken, sir. For example, these ones:

8.222.226.153 - - [30/Nov/2024:14:27:23 +0200] “GET /yii/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”
8.222.226.153 - - [30/Nov/2024:14:27:25 +0200] “GET /zend/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”
8.222.226.153 - - [30/Nov/2024:14:27:26 +0200] “GET /ws/ec/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”
8.222.226.153 - - [30/Nov/2024:14:27:27 +0200] “GET /V2/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”
8.222.226.153 - - [30/Nov/2024:14:27:28 +0200] “GET /tests/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”
8.222.226.153 - - [30/Nov/2024:14:27:29 +0200] “GET /test/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”
8.222.226.153 - - [30/Nov/2024:14:27:30 +0200] “GET /testing/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1” 404 1249 “-” “Custom-AsyncHttpClient”

Now, if attacker see 403, he quickly understand that access denied and attack stopped! I know this logic very well because I conduct such attacks myself in penetration testing.

BUT. You have reason, that LS is not WAF. And its not complete solution for everything.For a huge IT infrastructure, more global approaches in the form of IPS/IDS are required. And free OLS won't work for such projects either, so you need to look at LiteSpeed Enterprise.

Unlike other web servers, such as the outdated Apache, LS has good anti-DDoS protection.
The problem of unprofitable loads is also being solved. See here: https://www.litespeedtech.com/docs/webserver/config/security

 

[LiteCache]

Now, if attacker see 403, he quickly understand that access denied and attack stopped!

Open your mind...

There are hundreds or thousands of machine driven attacks globally and there is no single user that wants to attack your site only. It is machine driven script and the result of every request matters only if the result code is not 40*. It is just about of the status code is 200, because with status code 200 a certain CMS can be determined. If I am a attacker and if I know which CMS is running I can use well-known security leaks of such CMS to run certain attacks.

If you want to block such requests you must identify such requests first. Blocking such requests by IP address is no good idea since spammers or spambots doesn't use fixed IP addresss. OLS or any other web server blocks requests to non existing sources, but blocking such requests can be expensive if a CMS like WordPress catches all requests and forces high database load. So it is better to use any WAF like CloudFlare WAF to block such requests, but such requests must be identified by typically parameters. We at cachecrawler.com are working for such solutions since 1998 and we know how to block unwanted traffic smart without causing load.

 

[Cold-Egg]

FEI, here are the WAF setup, Throttling Setup, and reCAPTCHA Setup guides that could help to mitigate DDoS attacks from the web server side.