Yes, it has all of the pitfalls of other kinds of NAT.
However, in 2021, blocking all traffic from entire subnets or NATted IPs is an extremely blunt defense and doesn't even work for certain kinds of attacks like UDP floods. "Websites" do not typically do their own traffic filtering or attack mitigation for this reason and many others. They leave that up to their upstream provider. And any provider worth their salt is paying big bucks for a system that can recognize and mitigate attacks based on traffic patterns and deep packet inspection while letting most of the "good" traffic through.
Source: I work for a company that makes these products.
You're basically saying it's magic and trust me because I work on this stuff. That's fair, but how can you tell if I send you 1MM curl commands to download large_ugly_cow{i}.bmp from your server or if it's my neighbor doing that if we both share the same IP address?
> your server or if it's my neighbor doing that if we both share the same IP address?
It depends on how sloppy you are running your attack. Most of the time the attacker will be sloppy and hit the system using the same useragent with the same cookies. Or maybe they'll go the other way and every single request will have some random BS for a useragent and random cookies. Plus they will only hit that exact single URL and won't bother loading the rest of the page.
So if you look at your logs, you'll see a million requests for "large_ugly_cow.bmp" coming from the same IP with a useragent that doesn't bother loading anything else.
In short, to a human such an attack usually stands out like a sore thumb. Writing the filter rules to block them... that is a different beast. With the right tools and a smart tech, it is totally possible though.
Good question! The fact you've got a thousand users on the same IP doesn't really change much honestly. Like I said, when you see this kind of attack happening it usually stands out in your monitoring. The trick is writing the filter rules to target it.
Using IP addresses as filter / block criteria isn't very effective so most don't do it. Any attacker even a slight clue is hopping all over IP blocks to route around IP blocks so effective filtering rules use things other than IP addresses.
In short, the fact that your "signal" (attacker) is using the exact same IP address as the "noise" (everybody else using the IP address) shouldn't be a problem.
Commonly on CGNAT your connection will be assigned a range of source ports. The web server can see that all your connections have a source port number between 10,000 and 20,000, for instance, so they block new connections in that range. This would not directly target you (unless there's only 6 customers per NATted IP) but it does reduce the blast radius.
However, in 2021, blocking all traffic from entire subnets or NATted IPs is an extremely blunt defense and doesn't even work for certain kinds of attacks like UDP floods. "Websites" do not typically do their own traffic filtering or attack mitigation for this reason and many others. They leave that up to their upstream provider. And any provider worth their salt is paying big bucks for a system that can recognize and mitigate attacks based on traffic patterns and deep packet inspection while letting most of the "good" traffic through.
Source: I work for a company that makes these products.