lgeek

Cloudflare Warp has been more of an issue for a small webapp I run than residential proxies. Because it's a mix of legitimate users whom I guess installed the 1.1.1.1 app and have no idea they're tunnelling all their traffic through Cloudflare, and abusive users. I've never seen an actual CGNAT IP addresses from a consumer ISPs being shared by a legitimate user and a persistent abusive one.

CF seems to end up in the business of making problems worse, and selling the fix way too often. Before this, I had someone try to DDoS a webapp by setting up their own domain to proxy to my backend and running their attack traffic through CF. But that was easy, I could just block CF's IP range entirely as I don't use their reverse proxies.

If you do run an NTP server, please make sure it's not vulnerable to DDoS amplification (monlist, readvar, etc need to be disabled) and apply some rate limiting to make it less useful for reflection attacks. And be proactive about monitoring its traffic volume.

If you see high packet rate from a specific IP address or prefix, it's very likely not them abusing your service, but rather you attacking them by responding to spoofed requests.

I hate it when I can't get in touch with the right engineers at a large company. This (especially the highly targeted ad mentioned on the page) is a very creative way to try to solve that problem.

Not associated with Meta, but this piqued my interest. That being said, I found some parts confusing and hard to follow. For example what does URPF (Unicast Reverse Path Forwarding) in the title of this submission have to do with the contents?

And is the packet loss supposedly happening at specific times only? It's not mentioned anywhere, but one screenshot highlights the time. I couldn't reproduce the packet loss using any of the looking glasses and dest IP addresses in the screenshots. At this point, if this was a report I had received about one of my services, I would have probably bumped down the priority to low and asked for a reproducible test, because in my experience even issues that affect a single path in an ECMP group are not this hard to reproduce. I think it's way more important to give the engineer who will process the report an easy way to check that there is indeed a problem than to start to teach how traceroute works.

TBF, there does seem to be an issue somewhere, because sticking 129.134.80.234, one of the Meta IP addresses from a screenshot, on ping.pe does definitely show significant packet loss from more locations than you'd expect to see for an address with no connectivity issues.

I'm only familiar with this as a user and not a developer, but I've had multiple Android phone where not all camera features available in the Camera app were available to other apps via the APIs:

* not all cameras being available

* stabilisation not working

* 60 FPS unavailable

BunnyCDN don't run their own network, most of their servers are hosted at DataPacket(.com), but they use some other hosting companies too.

DataPacket has a very large network though and is kind of, sort of EU-based. AFAIK most operations are in Czechia, but the company is registered in UK. And there's also the Luxembourg-based Gcore.

If you're buying transit, you'll have a hard time getting away with less than 10% commit, i.e. you'll have to pay for 10 Gbps of transit to have a 100 Gbps port, which will typically run into 4 digits USD / month. You'll need a few hundred Gbps of network and scrubbing capacity to handle common DDoS attacks using amplification from script kids with a 10 Gbps uplink server that allow spoofing, and probably on the order of 50+ Tbps to handle Aisuru.

If you're just renting servers instead, you have a few options that are effectively closer to a 1% commit, but better have a plan B for when your upstreams drop you if the incoming attack traffic starts disrupting other customers - see Neoprotect having to shut down their service last month.

From having worked on DDoS mitigation, there's pretty much no difference between CGNAT and IPv6. Block or rate limit an IPv4 address and you might block some legitimate traffic if it's a NAT address. Block a single IPv6 address... And you might discover that the user controls an entire /64 or whatever prefix. So if you're in a situation where you can't filter out attack trafic by stateless signature (which is pretty bad already), you'll probably err on the side of blocking larger prefixes anyway, which potentially affect other users, the same as with CGNAT.

Insofar as it makes a difference for DDoS mitigation, the scarcity of IPv4 is more of a feature than a bug.

This is very challenging, in about one year the biggest recorded DDoS attack has increased from 5 Tbps to almost 30.

Almost all of the DDoS mitigation providers have been struggling for a few weeks because they just don't have enough edge capacity.

And normal hosting companies that are not focused on DDoS mitigation also seem to have had issues, but with less impact to other customers as they'll just blackhole addresses under larger attacks. For example, I've seen all connections to / from some of my services at Hetzner time out way more frequently than usual, and some at OVH too. Then one of my smaller hosting providers got hit with an attack of at least 1 Tbps which saturated a bunch of their transit links.

Cloudflare and maybe a couple of the other enterprise providers (Gcore?) operate at a large enough scale to handle these attacks, but all the smaller ones (who tend to have more affordable rates and more application-specific filters for sensitive applications that can't deal with much leakage) seem to be in quite a bad spot right now. Cloudflare Magic Transit pricing supposedly starts at around $4k / month, and it would really suck if that became the floor for being able to run a non-HTTP service online.

Something like Team Cymru's UTRS service (with Flowspec support) could potentially help to mitigate attacks at the source, but residential ISPs and maybe the T1s would need to join it, and I don't see that happening anytime soon.

It was taught in a first year software ethics class on my Computer Science programme. Back in 2010. I'm wondering if they still do

Update: it's finally up again after around 25.5 hrs of downtime

Over 22 hours of downtime for the one VPS I have in that region.

My infrastructure is redundant and spread out among hosting providers and DCs so there's no real impact, but I'm pretty sure this is the longest outage I've ever had with any provider. And the communication level has been so dissapointing. 4 hrs to say it's a power / HVAC issue? Updates that basically just say we're still working on it since then.

On Firefox on Android on my pretty old phone, a blurry preview rendered in about 10 seconds, and it was fully rendered in 20 something seconds. Smooth panning and zooming the entire time

> One crawler downloaded 73 TB of zipped HTML files in May 2024 [...] This cost us over $5,000 in bandwidth charges

I had to do a double take here. I run (mostly using dedicated servers) infrastructure that handles a few hundred TB of traffic per month, and my traffic costs are on the order of $0.50 to $3 per TB (mostly depending on the geographical location). AWS egress costs are just nuts.