Russian DDoS completley unmitigated by Cloudflare

Earlier today I was hit by a large-scale DDoS that took my site down after 22 minutes by exhausting all my AWS burst credits. Even when the site went down Cloudflare still didn’t block any of the DDoS connections. Thanks to judicious logging I was able to identify all the sources of the attack, but obviously it is difficult since each IP is sending just one or two requests and they are all coming from a wide variety of IPs. However, almost all the IPs are registered to one of two companies:

  • TrafficTransitSolution LLC.

As far as I can tell, both of these are fake companies who have somehow managed to register literally hundreds of /23 and /24 address ranges. I manually input more than 60 ranges into my firewall but I don’t think it’s even half of them. There were a few other companies besides these two, but a (probably fake) person’s name that was common among all of them was Aleksei Filippenko listed as the registrant.

My question is, why when it’s so clear that these two fake companies are used for nothing but abuse, (even Scamalytics agrees) does Cloudflare do nothing to mitigate access to their sites, including mine, which was on medium security level. I had to subsequently bump it up to “I’m under attack”, of course, but this also negatively impacts real visitors, which should be avoided.

My frustration is in spending literally hours collecting, collating and querying all these IP address ranges to add their CIDRs to my firewall. I could not find a (free) database of all the address ranges registered by these two fraudulent companies, but I imagine a company such as Cloudflare would have access to such a list and would therefore be trivial to block them. Why haven’t they?

Sorry for the troubles, that does not sound good at all. Are you certain the traffic was passing through cloudflare and not hitting your server directly? That is often/sometimes the case when we see posts indicating attacks.

Next, did you activate under attack mode? If so, did you notice any effect?

There is no way it was not passing through Cloudflare. By the time the attack had bought my site down, it showed the Cloudflare interstitial page indicating that my browser is fine, Cloudflare is fine, but the backend server is down (yeah no kidding, because you’re letting the attackers through!).

As I mentioned in my post, I did activate under attack mode, but only several hours later because I forgot the feature existed. I don’t know if it helped or not because I took my site down during that time, so the attackers may have given up at that point. By the time I activated the attack mode, either it worked or the attack had finished, but it’s been fine since and I even backed it off to high mode instead, so it’s less inconvenient for users. I just hope this doesn’t happen again.

I thought the whole point of Cloudflare is that you’re supposed to know who the bad actors are. I don’t know if this is a “new” set of attack vectors, but as I pointed out, Scamalytics is already well aware of them so I guess they’re not that new, if at all.

1 Like

Can you show the statistics from your dashboard?

Sure. You can see the uncharacteristically large traffic spike when the attack occurred.

Looking at the graphs, I would say you were seeing about 10 - 15 requests per second during that three hour period? I think the small HTTP DDOS thresholds start at 150 5xx errors per second from the origin.

Rather than adding individual IP ranges and addresses, you can always just block the whole ASN at the firewall, or using IP Access Rule.


I’m not sure you understand what distributed denial of service means. There were dozens of ASNs and hundreds of CIDRs and thousands of IPs. As I already explained, I spent hours entering and verifying about 63 CIDRs into my (software) firewall rules, but I would estimate that doesn’t even cover half of the attack space. I just ran out of patience to carry on since the attack seems to have stopped for now. The only commonality between the attacks were the registered companies that I listed (and to some degree, the UA headers) but as I stated already, there is no easy way to find all the address spaces they own, at least none available to me, though clearly public WHOIS services have access to such a database and I would expect Cloudflare would have at least one affiliate providing this data as well. The point being, it is non-trivial for you or me to fix it by just dicking around with firewall rules because the lay person does not have access to the necessary data even if we did want to spend the hours necessary to input all the rules to cover the entire attack space, which frankly, I’ve wasted enough time doing already.

Perhaps the traffic volume is not great enough to be classified as a DDoS by some spurious definitions, but the fact of the matter remains that it was sufficient to know the site offline.

I do, it is just that the rate of requests you are showing in the CF dashboard is relatively low, and probably below any threshold to be deemed an attack. If I visit the homepage of my companies website it loads about 100 files in 2 seconds or so, so 50 rps, which is several times the rate of your attack traffic.

The data is all publicly available, but it would be easiest to just block the whole network by its ASN. Say you have one IP address,

A one line command gives you the ASN:

% whois | grep -i origin
origin:         AS46844

Then an IP access list blocks the complete network:

Do you block all access to your Origin server so that only Cloudflare can access it? When you say:

are you saying you were blocking the requests on the Origin, or in CF? Were the requests going through CF at all?


You can go to, enter an IP address and find the AS number for that network. As explained above, if you are dealing with two networks then only two AS numbers are needed to block all their IP addresses.

Also, make sure your firewall only let connections from Cloudflare go through - the IP you allow are here IP Ranges | Cloudflare

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.