If I use CSF to block an IP address, why can I still see MySQL queries being generated by that IP?

C

cmyden

Verified User
Joined
Oct 8, 2020
Messages
60
My server was sending out high usage alerts. Upon investigation I could see that an SEO company is crawling through blog posts at a high rate.

The blog post URLs have a structure like: /tag/keyword/

The requests were all coming from 99.888.777.X (I've replaced the real IP address)

So here's what I did:

# csf -d 99.888.777.0/24

# nano /etc/csf/csf.deny

Added - Do not delete -
to the comments beside the IP address

# csf -r
# lfd -r
Click to expand...

# csf -g 99.888.777.0/24

^^ shows:

Table Chain num pkts bytes target prot opt in out source destination

filter DENYIN 989 0 0 DROP all -- !lo * 99.888.777.0/24 0.0.0.0/0

filter DENYOUT 989 0 0 LOGDROPOUT all -- * !lo 0.0.0.0/0 99.888.777.0/24
Click to expand...

# nano /etc/csf/csf.deny

^^ shows:

99.888.777.0/24 # - Do not delete - Manually denied: 99.888.777.0/24 (SG/Singapore/-) - Mon Jan 6 15:40:44 2025
Click to expand...


Now, I understand that requests from these IP addresses can still show up in my httpd logs.

The request is still made, and the traffic is allegedly being blocked thereafter.

But what I'm having trouble understanding is why can I still see MySQL queries that are undoubtedly being triggered by requests from 99.888.777.X ?

Should that be possible?


I know the MySQL queries are coming from this IP address because...

a) I watch for all of the live MySQL queries being made, and when I see a query being generated for a very obscure keyword...

b) I then immediately launch the following command:

tail -n 1000 /var/log/httpd/domains/domain.com.log | awk '{print $4, $1, $7}' | sort -r | head -n 50


c) And I can see the request for the URL with the same obscure keyword being made by 99.888.777.X within the last 10 seconds

[08/Jan/2025:13:28:24 99.888.777.19 /tag/kurumon-ichiba-market


I do use Cloudflare.

Thanks for any insight anyone can provide.
 
Hello,

Firewall locally installed on a server can not block an IP of a remote client if a connection is proxied over CloudFlare. It does not matter however you try to block an IP in CSF, it will still reach HTTP/HTTPs on the server.

When checking MySQL monitor do you see the IP in Host column? Example:

Bash: 
[root@server ~]# mysqladmin processlist
+-------+----------+-----------+----+---------+------+----------+------------------+----------+
| Id    | User     | Host      | db | Command | Time | State    | Info             | Progress |
+-------+----------+-----------+----+---------+------+----------+------------------+----------+
| 15390 | da_admin | localhost |    | Query   | 0    | starting | show processlist | 0.000    |
+-------+----------+-----------+----+---------+------+----------+------------------+----------+
[root@server ~]#

If you don't the see IP, then they do not have an access to SQL port, but it is your website generating SQL queries from localhost.

cmyden said:
I do use Cloudflare.
Click to expand...
 
Awesome, thanks guys! I will look into adding the IP range to Cloudflare. I was just under the assumption that blocked at the server level would be enough. Guess I was wrong.

If you don't the see IP, then they do not have an access to SQL port, but it is your website generating SQL queries from localhost
Click to expand...

I do have the SQL port disabled, but I will check the MySQL monitor to be sure.

Thanks!
 
Just to confirm, blocking the IP address through Cloudflare seems to have done the trick.


For anyone reading this that might be unfamiliar, here's how:

# Go to Cloudflare -> Domain -> Security -> WAF -> Tools

IP:

Action: Block

Zone: All websites in account <-- makes life a lot easier if you have multiple websites


It can also be done through Rules. But there might be a limit to the number of rules. The method above seems better.

# Go to Cloudflare -> Domain -> Security -> WAF -> Rule name ->

Field: IP Source Address

Equals: IP Address

Choose Action: Block
 
zEitEr said:
Hello,

Firewall locally installed on a server can not block an IP of a remote client if a connection is proxied over CloudFlare. It does not matter however you try to block an IP in CSF, it will still reach HTTP/HTTPs on the server.
Click to expand...

This is my main argument against using CloudFlare in a shared hosting (multi-tenant) environment.

The administrator of the server (me, fellow DirectAdmin server owners) are not the same ones managing a website (our clients). For that reason, website managers (clients) are generally oblivious to the various attacks going on to their website, WordPress login brute forcing being one of the major players. But server administrators are aware of this.

But a website that is using CloudFlare is nullifying any protections we have against WordPress brute force attempts (mod_security + csf or iptables) because of the very reasons outlined here. All requests to a website behind CloudFlare's proxy are going to show IP connections from Cloudflare's IPs. If you are using mod_remote or some means to tie hits to the CF-Connecting-IP header, then your log files are going to show a different IP than the CloudFlare's IP that is actually connecting to the server. So if you block that IP address in CSF or iptables, it's not going to do a thing to stop them from connecting.

If you're using CloudFlare, you have to stop all of that traffic at CloudFlare and not at your individual server. And from a server administrator's point of view, that is very hard to do - because every website is going to be a different CloudFlare account. Not to mention that we don't have access to your CloudFlare account to institute the blocks.

This is why I don't believe CloudFlare should have any special treatment. I don't use mod_remoteip to rewrite the visitors IP address for logging. When a CloudFlare IP floods our server with WordPress login attempts or various other attacks, CSF will eventually block the offending CloudFlare IP. And eventually all of the CloudFlare IPs may get blocked at the server level. This means any account that's using CloudFlare may have trouble accessing their website on the server - regardless if they were a target of the attack or not. But that's the price you pay for using nameservers other than the ones we designated for you.

CloudFlare can certainly be useful in a single-tenant environment. Where you run your website on a server... that you also have root access to. Because then you can see the attacks coming into your server and make the required changes at CloudFlare to block the attack.

But in a multi-tenant environment, especially one where those tenants are oblivious to attacks and server security (I'm not blaming those tenants for being oblivious, they just want their website to work, and this guide they found on the Internet told them to use CloudFlare) using CloudFlare can really hinder what a server administrator can do.
 
Another point, that most of administrators and users do not take into a consideration. Whenever CloudFlare is used, it reads ALL TRAFFIC, the servers of CloudFlare become a kind of MITM.

In cryptography and computer security, a man-in-the-middle[a] (MITM) attack, or on-path attack, is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, where in actuality the attacker has inserted themselves between the two user parties.

That's a security flaw.
 
Also Free version of CloudFlare doesn't useful for protect ddos attack if not in " I'm under ddos attack" mode.

The attacker will search the slow script on the website and ddos on these script and fillup the PHP-FPM process, then it's stop receipt new connection until old process have been processing.
 
You must log in or register to reply here.
Back
Top