Attacks from CloudFlare IP ranges


I have created a script, which collects FAILED LOGINS and BRUTE FORCE attacks all over our hosting facilities. Website owners must agree to participate with their Wordpress and Joomla websites, then we agree to create some non-common usernames (instead of admin) and watch for hackers to try to login.

But I have A LOT of problems, because on the list of BRUTE FORCERS and LOGIN attacks are quite some CloudFlare IP addresses. There’s a pattern most of the time the same - 1 try from 1 IP address, then they wait for few hours, then repeat. And they cycle IP addresses. But they use CloudFlare a lot.

What is there to be done?
I could write abuse report t CF, but sometimes there are hundreds of attacks per day, who would follow all them?
Is there maybe some API that I can submit attack report, as soon as CF IP gets on my list? I would then first need to compare found IP with a list of CF IPs, and if matches, run some API to report issue.
But in the end there’s a question, whether those reports will do any good.

Couldn’t it be that someone left either the IP of the server on a record even though they aren’t using it?

Also logins via HTTP or other ports? Maybe some of your customers use Cloudflare themselves? Check for the cf-connecting-ip header which shows the user IP, behind Cloudflare.

I was just reading the article, and I ask: do the IP’s have a track of xxx or If those IP’s have that range, they probably originate in Cloudflare’s warp network. Right now, I’m connected on my phone to WARP+, to the Cloudflare Lisbon datacenter, and I have an IP range of

Nope, “mine” CF IPs are in segment.

Can you post one or a sample of the IPs here?

@matteo: I doubt very much, there is some error in IP retrieving mechanism. My script looks for CF-CONNECTING-IP first, and if not exists, resolves IP via other variables.
Beside that, those IP’s are using my TRAP usernames as login, for example, on each Wordpress website I always create few “trap” posts or pages, which are not part of menu navigation, and are created as username “admin123”, for example.Then I delete this username, and in configuration I set to immediately block any login attempt, which uses “admin123” as username.

So no, it’s not a mistake, login attempts are coming from CloudFlare without any doubt.

I guess the possibility is there, obviously, but I believe that it’s an extremely unlikely scenario.

I also believe it’s impossible to receive a request, that tries to login, with a cf-connecting-ip header under normal circumstances. Are you sure you are not searching it in uppercase or something that may force a false negative? Post one of these requests, with full headers if you have them.

Example IPs from today:
…and some dozens more

Example of nginx logs: - - [24/May/2020:00:09:35 +0200] “GET /wp-login.php HTTP/1.1” 200 2461 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0” - - [24/May/2020:00:09:36 +0200] “POST /wp-login.php HTTP/1.1” 200 2599 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0” - - [24/May/2020:00:09:37 +0200] “POST /xmlrpc.php HTTP/1.1” 200 257 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0” - - [24/May/2020:00:11:26 +0200] “GET /administrator/index.php?option=com_login HTTP/1.1” 404 868 “-” “Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36” - - [24/May/2020:00:13:32 +0200] “GET /wp-login.php HTTP/1.1” 200 2461 “-” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0”

Any idea, guyz? I usually put all those attacking IPs on blacklist on my firewall, so none of my customers can communicate with blacklisted IP in any way, not even send or receive an e-mail from that IP for 2 days.
But in this case I will block a lot of CF and many other proxy providers IPs. Does not CF and others have some cross-linked intelligence, which would recognize brute force even if attackers are changing IP for every subsequent login attempt? Or maybe exactly due to such behaviour?

The problem you have here is that they are not necessarily attackers but rather more likely zombies (infected machines) being used as a proxy by a botnet, which is possibly proxied again.

You could create a CloudFlare firewall rule, say to block “X11” in the user agent, and then you can see the real IP Addresses in the firewall logs.

Another option you have is to edit the PHP files for your relevant installation (Wordpress for example) and intercept the requests at the time they are first executed. There, you include some PHP code which will update a log or database with those connections and instead of grabbing the CloudFlare IP (equal to $_SERVER[‘REMOTE_ADDR’]), you use $_SERVER[‘HTTP_X_FORWARDED_FOR’] to get the genuine IP. You can further this by automatically blacklisting IP’s based on heuristics.

But neither option will solve anything if the IP’s are constantly changing, so all you can do in that case is create firewall rules to block the patterns.

This topic was automatically closed after 30 days. New replies are no longer allowed.