Live data from Hacker News

Cloudflare API Down

cloudflarestatus.com

201–210 of 211 posts

Re: Cloudflare API Down

#201
post #113
post #26

Earlier quoted context omitted.

Why not just access it normally over the proper internet, instead of chancing it with Cloud Flare's janky wiring system?

WARP is much more than a VPN under the surface, it does device attestation and all kinds of integration with their Access product.

How does that help with GitHub though? I understand using this service as a proxy to access internal resources (which wouldn't be available on the public internet), but what good does it do to access a public service like GitHub? Does GH understand/rely on the (presumed) HTTP headers that this product sets on the proxied traffic?

Re: Cloudflare API Down

#202

IMHO edge servers are a waste of time that expose conceptual flaws in the internet's design. We should have had free public proxy servers that relayed any publicly-accessible (public domain) static files automagically like Coral CDN, which is difficult to even find information about anymore: https://en-academic.com/dic.nsf/enwiki/495553 And that caching should have happened in the ISP's backbone or user's devices so…

I think your point boils down to "vendor's edge cache are too far away and should be at the city level", right? If so, major cities already have local Netflix caches in many ISPs, for example. Same is done for Google, Facebook and others. It takes peering contracts, colocation, etc, but it exists extensively. Maybe you're arguing for government-sponsored caching infrastructure?

It annoys me to no end that the idea of metro-ISPs never took off. If somebody in the same city as me wants to connect to any services I host at home they first have to round-trip to my ISPs core-routers and then back to me.

Now this all happens very quickly within 5-6 ms but it could be 1ms or less in an ideal world. I understand why we cannot have nice things though (cost mainly).

Re: Cloudflare API Down

#203
post #37

I dunno. Cloudflare gives me the creeps. I have no idea why so many folks think large swaths of the Internet should be reliant on a single company.

No idea?

They came along, out of nowhere and started offering their infrastructure, their global distribution network for free as a reverse proxy. This allowed people to scale their single-server-services out for nothing, it insulated servers from DDoS and single-government action. For the people that needed it, it took 10 minutes and revolutionised a lot of slow websites.

But then they started offering actual services. A formal CDN, largely for free but after that, pennies on the dollar of what major players were asking. And 6 years ago they started building your stuff for you, allowing you to host it near your users. They sell domains at cost, host DNS for nothing, and handle inbound email for you.

As a webdev, they're making my life very simple. Things that took me a day to bash out and bootstrap for a new client, I've done with CloudFlare while the client is on the phone.

If they vanished tomorrow, it'd be a wrench. But that's true of so much online infrastructure. Where would you be without Github, NPM, PyPI, dockerhub, etc? Enjoy it while we can.

Re: Cloudflare API Down

#204

Earlier quoted context omitted.

good luck with all those strawman replies... It only takes one trivial event to make you a cloudflare zealot, most ISPs (web hosts) don't provide attack mitigation nor prevention. If you didn't know that you could ban IPs programtically you'd have been screwed* and would have loved how quickly cloudflare would protect your site. It's not a difficulty thing, it's an ignorance thing. cloudflare isn't better,or magic, i…

What's the correct way to do things if I don't want to use Cloudflare for attack mitigation?

I'm not an expert in network security, so I can only give you an idea. The correct way to do things depends on so many factors, but the TLDR n probably use multiple ways to identify malicious traffic, and then block it as early as possible. Dropping all traffic from abusive IP addresses with netfilter is where you start because it's easy/simple. Then you can move on to grouping by ASN, and dropping closer to a load balancer.

The problem (as far as I know) that cloudflare actually provides, is being able to identify abusive networks, and making them prove they're not bots before they reach your server. If you can't even identify the abusive traffic, you don't have many options other than cloudflare.

Re: Cloudflare API Down

#205

Earlier quoted context omitted.

> Just consider how IP address spoofing is still possible today and you'll begin to realize how broken the internet has always been long before you even get into dirt cheap residential smart toaster botnets. I know I'm going to regret asking but, ok, I'll bite... why does IP address spoofing prove the Internet is broken? Especially considering that a) the point of internet routing is to route packets whenever possibl…

With spoofed src addr: * you can do all sorts of udp amplification attacks (e.g. dns - send a zone transfer request in a single packet with a spoofed IP, and the IP you spoofed to gets a lot of traffic in response.) * you can do tcp syn or ack floods with a spoofed IP, these eat resources on the target machine. syn floods cause the os to allocate a new connection and timers waiting for the third ack. * you can send l…

I'm not terribly impressed... this reads like a response from an LLM. Yeah I know what kind of packets you can send with a spoofed source IP... But the question was, given these are all decades old, how does that prove the Internet is broken?

Re: Cloudflare API Down

#206

Earlier quoted context omitted.

With spoofed src addr: * you can do all sorts of udp amplification attacks (e.g. dns - send a zone transfer request in a single packet with a spoofed IP, and the IP you spoofed to gets a lot of traffic in response.) * you can do tcp syn or ack floods with a spoofed IP, these eat resources on the target machine. syn floods cause the os to allocate a new connection and timers waiting for the third ack. * you can send l…

I'm not terribly impressed... this reads like a response from an LLM. Yeah I know what kind of packets you can send with a spoofed source IP... But the question was, given these are all decades old, how does that prove the Internet is broken?

The point of the internet is to provide a robust communictions platform. If fundamental infrastructure of that communcations platform can be abused to deny communications, and further that the abuse can continue with the root cause unaddressed for decades, then the platform is broken.

The fact that routing is designed to go around damage is orthoganal to this, and has not bearing on the fact that the communications platform can be used against itself to prevent communications (via spoofed IPs).

For literal decades partial solutions to the spoofing problem have been known - rp filtering would eliminate a lot of problems yet still isn't close to universal.

BGP has been vulnerable to all sorts of simple human mistakes for decades and decade old solutions like IRR are only slowly being adopted because many of the people that run the internet are too busy pretending they are important and good at building systems to actually make the systems good. When those same simple mistakes are intentional, all sorts of IP traffic can be spoofed including full TCP connections.

The fact that there isn't a widely supported way for the consequences of spoofing to be mitigated without paying out the nose for a 3rd party service is pretty broken too. Allowing destinations be overwhelmed without any sort of backpressure or load shedding is a fundamental flaw in "get packets to destination no matter what". An AS should be able to say "I no longer want packets from this subnet", and have it honored along the entire path. This should be a core feature, not an add-on from some providers.

The internet does work as designed, however it's folly to think that the first attempt at building something so different to anything that came before it is the best way to do it and reusing to address design decisions is fundamentally broken.

Re: Cloudflare API Down

#207
post #46

When I worked there (3+ years ago), if PDX were out then "the brain" was out... things like DDoS protection was already being done within each PoP (so that will be just fine, even for L3 and L7 floods, even for new and novel attacks), but nearly everything else was done with the compute in PDX and then shipped to each PoP as configuration data. The lifecycle is: PoPs generate/gather data > send to PDX > compute in PD…

DNS updates were also down during a good chuck of the outage. Most likely due to degraded API access since I'm guessing the dashboard UI relies on the API to make updates. But even when DNS updates managed to update in the UI, they still weren't propagating. I had to delete entire domains and recreate them after the outage in Cloudflare dashboard in order for SSL and DNS propagation to work again.

Re: Cloudflare API Down

#208

IMHO edge servers are a waste of time that expose conceptual flaws in the internet's design. We should have had free public proxy servers that relayed any publicly-accessible (public domain) static files automagically like Coral CDN, which is difficult to even find information about anymore: https://en-academic.com/dic.nsf/enwiki/495553 And that caching should have happened in the ISP's backbone or user's devices so…

I think your point boils down to "vendor's edge cache are too far away and should be at the city level", right? If so, major cities already have local Netflix caches in many ISPs, for example. Same is done for Google, Facebook and others. It takes peering contracts, colocation, etc, but it exists extensively. Maybe you're arguing for government-sponsored caching infrastructure?

Well, sort of. I feel that something like Interplanetary File System (IPFS) should have been the original web. Or at least, after BitTorrent arrived, we should have all moved to content-addressable memories because they automatically handle caching and scaling. That would have required solving circles of trust with potential improvements to SSL certificates so that they don't require a central authority, like a distributed version of letsencrypt.org. It also would have needed improvements to DNS for making domain-data pairs instead of domain-IP. And at the very least, IPv6 should have improved UDP so that it "just works" everywhere and doesn't have to deal with NAT hole punching. That stuff represents the real work of rolling out a true P2P internet.

Since we did none of that, we cemented the centralized web we have today, full of walled gardens funding the copyright nanny state. So that people are so aghast at seeing the real internet running on stuff like TikTok that their first instinct is to ban it.

To me, it feels like we're living under a bizarro version of the internet, so far removed from its academic/declarative/data-driven roots that it's almost unrecognizable. Javascript is just distributed async desktop programming now, reminiscent of the C++ days of the late 1980s, complete with all of the nondeterminism that we worked so hard to get away from. Paid services like Cloudflare and 5G are a symptom of that inside-the-box thinking. If we had real distributed P2P through our routers and cell phones, we probably wouldn't need ISPs today, because we'd be accustomed to gigabit download speeds and would only perceive long distance as slow and worth paying for. In which case, maybe the government should pay to maintain the backbone and perhaps satellite internet like Starlink. Which would be a good thing IMHO, because at least there would be oversight and we wouldn't have to worry about billionaire narcissists making the satellites highly reflective and visible to the naked eye, like carving a McDonalds sign on the moon.

Re: Cloudflare API Down

#209

Earlier quoted context omitted.

I'm not terribly impressed... this reads like a response from an LLM. Yeah I know what kind of packets you can send with a spoofed source IP... But the question was, given these are all decades old, how does that prove the Internet is broken?

The point of the internet is to provide a robust communictions platform. If fundamental infrastructure of that communcations platform can be abused to deny communications, and further that the abuse can continue with the root cause unaddressed for decades, then the platform is broken. The fact that routing is designed to go around damage is orthoganal to this, and has not bearing on the fact that the communications p…

First, I want to say thanks for the interesting reply! it's refreshing to read good arguments on HN again :)

> The fact that routing is designed to go around damage is orthoganal to this, and has not bearing on the fact that the communications platform can be used against itself to prevent communications (via spoofed IPs).

> For literal decades partial solutions to the spoofing problem have been known - rp filtering would eliminate a lot of problems yet still isn't close to universal.

It's orthogonal, and yet of the places where it would actually matter or have the strongest effect, it's not used? I wonder why... 'cept not really. The Internet seems to still be functioning pretty well for something fundamental broken. For the vast majority of internet routers it's entirely reasonable for them to accept any source IP from any peer. because it is impossible to prove that peer can't reach somebody else. The exception is a huge number of endpoint ISPs who shouldn't be sending these packets and it's on them to filter them. I would love a way to identify and punish these actors for their malfeasance, but I'm not willing to add a bunch of complexity to do so.

> because many of the people that run the internet are too busy pretending they are important and good at building systems to actually make the systems good.

wow, that's a super toxic comment... and I'm an asshole saying that.

> Allowing destinations be overwhelmed without any sort of backpressure or load shedding is a fundamental flaw in "get packets to destination no matter what".

one mans fundemntal flaw is another's design trade off... every single system that has ever seen widespread adoption has defaulted to open and permissive. every. single. one. it's only after seeing widespread adoption does anything ever add in restrictions and rules and most often when it does it's seen as the enshittification of something. (most often then because exerting control allows you to vampiriclly extract more value). but dropping packets one system is overloaded is exactly what the internet does do, what you're describing sounds more like TCP working around it. (poorly admittedly)

> An AS should be able to say "I no longer want packets from this subnet", and have it honored along the entire path. This should be a core feature, not an add-on from some providers.

I could not agree more. but this is a missing feature not a fundamental flaw. the internet still works for the vast, vast majority of users and as I've said in a different thread the use or dependency on cloudflare is often a skill issue not a requirement.

You're 100% correct, core internet routing has many fixable defects. and many ISPs are moving slower than could be reasonably considered ethical or competent. But for something this core of infrastructure I would actually prefer slow and careful over the break everything on a whim because of the "move fast" mind virus that has overtaken CS.

> The internet does work as designed, however it's folly to think that the first attempt at building something so different to anything that came before it is the best way to do it and reusing to address design decisions is fundamentally broken.

It's also needless absolutist to say every defect is a fundamental design decision. The Internet was built to support trusted peering relationships. Where if someone was being abusive, you'd call your buddy and say "fix your broken script". The core need the internet is now supporting is wildly different, and this "fundamental design flaw", is actually just user error. If you strap a rocket engine on a budget sedan, it's not a design flaw when the whole thing explodes. If you're going to add untrustworthy peers to your network you also have to add a way to deal with them. that's a missing feature not a design flaw.

Re: Cloudflare API Down

#210
post #176

Earlier quoted context omitted.

You summed up quite well how these things happen. All of these parts make for an increasingly complex system with a large number of failure points. Our DC was a very living entity -- servers were being changed out/rack configuration altered very regularly. Large operations were carefully planned. You wouldn't overlook the power requirements of a few racks being added -- there'd -- literally[0] -- be no place to plug…

We had an outage a few years ago on Black Friday; we had been getting our DC to purchase and rack servers for us for years, and the data centre had IIRC four separate circuits that our servers were on depending on which rack they were in. Unfortunately, we hadn't provided them input into which servers were which purpose, and we occasionally repurposed hardware from one service to another. This resulted in one of our…

Thanks for sharing, that was a very entertaining read and gave me fond memories of the decade or so I worked in a phone switch.

My office was in a space that was shared by a large legacy phone switch, SONET node, and part of our regional data center but I worked in infrastructure doing software development. My proximity[0] meant I ended up being used to support larger infrastructure efforts at times, but it usually just meant I got a lot of good ... stories.

I wonder if there's a collection of Data Center centric "Daily WTF" stories or something similar.

For me, I think my favorite is when we had multiple unexplained power failures very late at night in our test/management DC[0]. It turned out "the big red kill switch" button behind the plexiglass thing designed to make sure someone doesn't accidentally "lean into it and shut everything off" was mistaken for the "master light switch" by the late night cleaning crew. Nobody thought about "the cleaning crew" because none of the other DCs allowed cleaning crew anywhere near them but this was a test switch (someone forgot about the other little detail). If memory serves, it took a few outages before they figured it out. The facilities manager actually hung around one night trying to witness it only to have the problem not happen (because the cleaning lady didn't turn the lights off when people were there, duh!). I'd like to say that it was almost a "maybe bugs/animals/ghosts are doing it" impulse that caused them to check the cameras but it was probably also the pattern being recognized as "days coinciding with times that the late night cleaning crew does their work."

Outside of that, the guy who made off with something like 4 of these legacy switch cards because some fool put a door stop on the door while moving some equipment in was probably really excited when he found out they were valued at "more than a car" but really disappointed when he put them on eBay for something like $20,000 (which was, I wanna say at least a 50% markdown), was quickly noticed by the supplier[2] was arrested and we were awaiting the return of our hardware.

[0] Among many other things due to a diverse 17-year career, there, but mostly just because I was cooperative/generally A-OK with doing things that "were far from my job" when I could help out my broader organization.

[1] When that went down, we couldn't connect to the management interfaces of any of the devices "in the network". It's bad.

[2] Alarms went off somewhere -- these guys know if you are using their crap, you're stuck with their crap and they really want you stuck paying them for their crap. I'm fairly certain the devices we used wouldn't even function outside of our network but I don't remember the specifics. AFAIK, there's no "pre-owned/liquidation-related market" except for stripping for parts/metals. When these things show up in unofficial channels, they're almost certainly hot.

Post reply on HN