Terrible flooding - Panic can't make it stop

dash-dns
#1

Going to give this a try here. I have had flooding issues on my cloud server so many times now that my provider is going to terminate me if this doesn’t get fixed. This has happened at least 10 times in 3 months and it is SO FRUSTRATING. I am panicking because my host will terminate me if this does not get fixed already. Here I will attach a log for the latest issue:

Please help, advise…


same issue is causing the whole day
3005 5/23/24999 K 9.80 4 1608 12720733 17.6 0.17 579.56 108.162.219.60 http/1.1 my.domain: GET /gallery/addpic.php?pic_file=VGVsZXZpc2lvbiBTaG93cy8yMDE4IF
1-4 1105 0/5/25117 W 1.70 9 0 11958455 0.0 0.03 500.81 213.162.73.81 http/1.1 my.domain: GET /content/style/verycavallari.jpg HTTP/1.1
2-4 3655 0/11/24266 _ 0.02 3 11765 11279927 0.0 0.10 530.16 213.162.73.81 http/1.1 my.domain: GET /gallery/albums/Collections/Chinese%20Laundry/2017%20Spring
3-4 3663 0/2/23018 _ 0.06 0 5576 13437201 0.0 0.06 508.78 213.162.73.81 http/1.1 my.domain: GET /content/elite01.jpg HTTP/1.1
4-4 3310 0/22/23617 _ 6.43 1 5258 11607721 0.0 0.22 777.31 213.162.73.81 http/1.1 my.domain: GET /content/trueroots.jpg HTTP/1.1
5-4 3669 0/1/21338 W 0.00 5 0 11134819 0.0 0.01 462.10 162.158.78.30 http/1.1 prc23fa10ic7td.min.owncube.com: GET /gallery/login.php?referer=displayimage.php%3Falbum%3D46%26
6-4 3315 0/5/20644 W 1.83 4 0 9828906 0.0 0.04 455.45 213.162.73.81 http/1.1 my.domain: GET /content/elite02.jpg HTTP/1.1
7-4 3670 2/3/19704 K 1.51 1 1775 9875864 9.0 0.07 463.50 108.162.219.60 http/1.1 my.domain: GET /gallery/addpic.php?pic_file=VGVsZXZpc2lvbiBTaG93cy8yMDE4IF
8-4 3680 1/3/19294 C 2.07 0 1 11168375 4.9 0.07 446.92 46.229.168.134 http/1.1 kcav51cukry87n-1.min.owncube.co GET /gallery/login.php?referer=displayimage.php%3Falbum%3Dtopn%
9-4 3681 0/2/17539 _ 0.00 2 4872 8406958 0.0 0.06 391.93 213.162.73.81 http/1.1 my.domain: GET /content/giftcardgiveaway.jpg HTTP/1.1
10-4 4148 0/1/17459 _ 0.00 13 101 7006567 0.0 0.16 385.91 162.158.63.24 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
11-4 4149 0/1/15193 _ 0.00 12 100 7560886 0.0 0.16 324.72 162.158.63.120 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
12-4 2222 0/38/14414 _ 9.71 13 206 7915598 0.0 0.67 316.75 162.158.62.17 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
13-4 4150 0/1/11141 _ 0.00 12 200 6321700 0.0 0.16 274.43 162.158.62.71 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
14-4 4151 0/1/8841 _ 0.00 11 103 6213017 0.0 0.16 222.99 108.162.219.186 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
15-4 4152 0/1/8551 _ 0.00 11 106 6075014 0.0 0.16 214.88 162.158.62.167 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
16-4 4153 0/1/8365 _ 0.00 11 105 4102894 0.0 0.17 202.36 108.162.219.150 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
17-4 4154 0/1/5756 _ 0.00 11 102 3191150 0.0 0.16 183.51 162.158.62.11 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
18-4 4155 0/1/5098 _ 0.00 10 205 2779145 0.0 0.17 155.59 162.158.63.84 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
19-4 4156 0/1/4572 _ 0.00 10 100 2491759 0.0 0.16 142.70 108.162.219.54 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
20-4 4157 0/1/3525 _ 0.00 10 207 2048286 0.0 0.16 119.28 108.162.219.210 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
21-4 4158 0/1/3603 _ 0.00 10 106 1884311 0.0 0.16 126.07 108.162.219.18 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
22-4 4159 0/1/3748 _ 0.00 10 104 2389181 0.0 0.17 120.80 162.158.63.24 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
23-4 4160 0/1/2950 _ 0.00 10 206 1905877 0.0 0.16 126.18 108.162.219.204 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
24-4 4161 0/1/3022 _ 0.00 10 100 1880700 0.0 0.15 107.18 173.245.52.183 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
25-4 4162 0/1/2748 _ 0.00 10 101 1728789 0.0 0.16 110.03 162.158.62.63 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
26-4 4163 0/1/2372 _ 0.00 9 106 2493369 0.0 0.16 88.91 162.158.62.161 http/1.1 my.domain: GET /gallery/albums/Television%20Shows/2018%20Very%20Cavallari/
#2

Here’s a recent support page with detailed instructions on many Cloudflare tools you can use to mitigate an attack:

#3

Could you go back to your original post, edit it and mark the log section as code? Just highlight the log part and click on the </> icon. This will make it easier to read.

First, apply a “I’m Under Attack” setting to the whole site.

Then you should try to find patterns and block visitors accordingly. Try to figure if there’s a country or a few countries where the hits are originating from. Create a Firewall Rule to block Challenge (Captcha) visitors from those countries. Or you may prefer to Challenge all visitors NOT coming from the countries most of your legit visitors come from.

Then try identifying User Agents and IPs that are being used. Firewall > Tools > IP Access Rules / User Agent Block.

I hope these actions help you mitigate this attack. Good luck!

#4

I’m so scared to request reactivation now because they will terminate 10 years of work. I just asked them to provide me with a new server IP… I hope they agree to. And I had my web site all set up on the attack part and all these features, somehow it keeps flooding anyway and I cannot fix this on my own.

#5

You should try to keep calm, avoid giving in to panic.

If you provide more details on your setup, other people in this community with similar config can perhaps help you with tips from their past experience or expertise.

Is your site running in Apache? Nginx?

What’s the CMS?

What rules do you have in place already, both in Cloudflare and on your origin server? Though you said you’ve tried “all these features”, perhaps if you provide some details others may help you fine tune your rules to more effective results.

2 Likes
#6

Is your site running in Apache? Nginx?

How do I know? I believe Apache…

What’s the CMS?

Wordpress on start page, and then Coppermine for /gallery.

I have had “Im under Attack” all this time.


I just put these rules in just now (for when the site comes back active)

In addition, I added a couple of Asian countries to the firewall setting for Captcha. If the JS one is better in my case, please let me know.

Then try identifying User Agents and IPs that are being used. Firewall > Tools > IP Access Rules / User Agent Block.

I have a bunch of IP ranges denied in .htaccess. Is that not good enough?

#7

ask your host, they will know

It would be good if you posted the actual Firewall Rule. Challenge Captcha is better then JS Challenge here, and you may even elevate it to Block until the attack is controlled.

Add more to the list as you identify more IPs. Don’t worry about the list getting big, the performance impact should be negligible.

Ideally, you should get help from your host to only allow connections from Cloudflare servers. You can try adding something like this to your htaccess, to check for a CF header before allowing anyone in.

Also, make sure the WordPress block on .htaccess is at the bottom of the .htaccess file.

1 Like
#8

My server is under suspension, and yet the attacks keeps going on. See:

#9

That means they are being blocked by Cloudflare before they reach your origin server. It also means these hits are not bypassing Cloudflare as you feared.

So with the proper set of rules in place you should be able to ask your hosting to reactivate your site. If you are afraid this may cause them to permanently close your account, you should try talking to them to reestablish your site for, say, half an hour, then check the logs and see if the attack was in fact completely blocked by Cloudflare.

Also, the page rule you posted above, these settings should be set at the different tabs of the Dashboard. Only one page rule is triggered by a URL, so if you have another page rule placed above it, it may render that one ineffective.

1 Like
#10

I changed Challenge now to Block - as you said, until it gets under control. However, how do I know by looking at this chart that these functions are actually working? Is there any way to measure before/now GETs?

#11

These hits were blocked. Whether or not there are other hits getting to your website needs to be checked at your origin server logs, like the one in the original post. That’s why I suggested you reenable it for a short period, look at the logs, then hopefully put the site back on.

Also, you may want to check Analytics on the Cloudflare Dashboard.

1 Like
#12

This flooding is still going on. I will let the block be active for entire CN for now and forward.

This particular domain is one of many domains that I operate. Should I set the setting for the “head” domain as well even though I don’t use it?

#13
  1. You should make sure you have a backup (multiples preferably) of your content stored offsite. This is true regardless of your current situation with the provider. Accidents/ disasters/ bad things happen.

  2. If this content is mostly static you could also consider turning on a cache everything page rule. This would cache the HTML content as well and reduce requests to origin.

1 Like
#14

Sounds good. Got it.

What should be set under - Browser Cache Expiration. the default seems to be 4 hours.

#15

Depending on the requirements of your site, most traffic use GET and POST if you have forms. You could use a Cloudflare Firewall Rules to temporarily block all requests that are not GET

Not sure if you have mod_cloudflare installed or you are getting direct hits on the origin but your logs above show the actual IP’s.

A Firewall Rule like this would block traffic from reaching the origin that isn’t from your country and methods that are not GET or POST(if you have forms)
(ip.geoip.country ne "YOUR_COUNTRY") or (http.request.method ne "GET") or (http.request.method ne "POST")

The following would help with direct traffic by blocking unwanted methods and require visitors to arrive with Cloudflare’s headers.

#REQUEST METHODS (some methods may break website functionality)
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK|PUT|OPTIONS|CONNECT|DELETE|HEAD)
RewriteRule .*$ - [F,L]

#REQUIRE CLOUDFLARE CF-RAY HEADER
RewriteCond %{HTTP:CF-Ray} =""
RewriteRule .* - [F,L]

#REQUIRE Cloudflare IP Geolocation
RewriteCond %{HTTP:CF-IPCountry} ^$
RewriteRule ^ - [F,L]

If you know you don’t have mod_cloudflare you can also add this

#REQUIRE Cloudflare IPs
order deny,allow
deny from all
#(IPv4)
Allow from 173.245.48.0/20
Allow from 103.21.244.0/22
Allow from 103.22.200.0/22
Allow from 103.31.4.0/22
Allow from 141.101.64.0/18
Allow from 108.162.192.0/18
Allow from 190.93.240.0/20
Allow from 188.114.96.0/20
Allow from 197.234.240.0/22
Allow from 198.41.128.0/17
Allow from 162.158.0.0/15
Allow from 104.16.0.0/12
Allow from 172.64.0.0/13
#(IPv6)
Allow from 2400:cb00::/32
Allow from 2405:8100::/32
Allow from 2405:b500::/32
Allow from 2606:4700::/32
Allow from 2803:f800::/32
Allow from 2c0f:f248::/32
Allow from 2a06:98c0::/29

Lastly, IMO, maybe they are now, but the Hosting company should have been a lot more helpful with this matter.

3 Likes
#16

:+1::+1::+1::+1::+1:
I couldn’t agree more!

1 Like
#17

This won’t affect bots in any way, as they won’t cache anything from your site no matter what setting you have here.

You should have this setting at the smaller value available to your plan, smaller relative to the normal cycle of your site dynamic content generation. If your pages have no dynamic content, you can safely set this to 1 day. If you add content every hour, set the smaller amount possible, or Respect Origin Headers.

You should have a Edge Cache TTL, which is the amount of time the cached file stays at a CF datacenter, set at a much larger period if your content is not dynamic. You can always purge this cache when you update your content. This setting must be included in the same page rule that sets “cache everything” for many WordPress installations.

1 Like
#18

Guys - the problem is still there. Now I am starting to think that this is a ROOT issue. I don’t use it for any purpuses but it seems the attack goes up that far. The subdomains automatically started getting flooding as soon as they unsuspended my account just now.

What am I missing? Is the flooding focused on my root (and going from there into the subdomains) or?

BUT I CAN’T add “my” root because it is a subdomain to my hosting provider.

#19

Hi,

That really shouldn’t matter AFAIK. As long as your domain and subdomain DNS records are being proxied by Cloudflare (:orange: in their DNS records on Cloudflare Dashboard > DNS), all rules you created should apply to them as well.

After blocking CN, have you identified any other countries? Also, is there any pattern such as the same URLs being requested over and over? You can try a Firewall Rule to block requests to non existing URI paths, to avoid the origin server having to process these 404s.

In a WorldPress site, the server won’t know it is a 404 until WP returns a 404, which is un unnecessary burden you can avoid by identifying and blocking such requests before they even hit your origin.

closed #20

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