Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Deel van internet was dinsdag niet bereikbaar door storing bij Cloudflare

Een deel van internet was dinsdagmiddag niet bereikbaar door een storing bij Cloudflare. Benaderde sites gaven een 502 Bad Gateway-melding. Ceo Matthew Prince bevestigde op Twitter dat Cloudflare een netwerkprobleem had. Inmiddels lijken de problemen weer voorbij.

De storing begon halverwege de dinsdagmiddag, Cloudflare meldde op een System Status-pagina 'Network Performance Issues' te hebben. Onder andere Discord was daardoor niet bereikbaar. Om 15:52 uur schreef Cloudflare het euvel te onderzoeken en om 16:15 uur meldde het bedrijf een oplossing te hebben geïmplementeerd en te kijken of het heeft gewerkt. Verdere informatie geeft het bedrijf niet.

De oplossing lijkt te hebben gewerkt. Zo was dinsdagmiddag raspberrypi.org niet bereikbaar, maar op het moment van schrijven is de site weer online. Op Twitter bevestigt Cloudflare-ceo Matthew Prince de problemen te hebben 'verzacht' en dat netwerkverkeer weer werkt. In een update meldt hij dat cpu-pieken de oorzaak waren van de storing bij systemen en back-upsystemen en de resulterende invloed op alle diensten. Volgens hem zijn er geen aanwijzingen dat het om een aanval ging.

De invloed van de storing op internet was zelfs te zien bij de statistieken van internetknooppunt AMS-IX: er was een flinke dip in het verkeer dat het knooppunt verwerkt zichtbaar.

Door Hayte Hugo

Nieuwsposter

02-07-2019 • 16:34

113 Linkedin Google+

Submitter: TrulyUnlucky

Reacties (113)

Wijzig sortering
Inmiddels een "placeholder" post-mortem beschikbaar vanuit Cloudflare, met de hint dat de problemen hoogstwaarschijnlijk door een "slechte" software deploy komen. Ze geven in ieder geval duidelijk aan dat het geen aanval was, zoals wel werd gespeculeerd op o.a. Twitter.

Cloudflare kennende kunnen we een zeer gedetailleerde (en m.i. interessante) post verwachten met een analyse over hoe de storing heeft kunnen ontstaan.

https://blog.cloudflare.com/cloudflare-outage/
Inmiddels heeft CloudFlare een update gepost waarin wordt uitgelegd wat de oorzaak was:
Starting at 1342 UTC today we experienced a global outage across our network that resulted in visitors to Cloudflare-proxied domains being shown 502 errors (“Bad Gateway”). The cause of this outage was deployment of a single misconfigured rule within the Cloudflare Web Application Firewall (WAF) during a routine deployment of new Cloudflare WAF Managed rules.

The intent of these new rules was to improve the blocking of inline JavaScript that is used in attacks. These rules were being deployed in a simulated mode where issues are identified and logged by the new rule but no customer traffic is actually blocked so that we can measure false positive rates and ensure that the new rules do not cause problems when they are deployed into full production.

Unfortunately, one of these rules contained a regular expression that caused CPU to spike to 100% on our machines worldwide. This 100% CPU spike caused the 502 errors that our customers saw. At its worst traffic dropped by 82%.

This chart shows CPU spiking in one of our PoPs:

https://blog.cloudflare.com/content/images/2019/07/cpuspike-1.png

We were seeing an unprecedented CPU exhaustion event, which was novel for us as we had not experienced global CPU exhaustion before.

We make software deployments constantly across the network and have automated systems to run test suites and a procedure for deploying progressively to prevent incidents. Unfortunately, these WAF rules were deployed globally in one go and caused today’s outage.

At 1402 UTC we understood what was happening and decided to issue a ‘global kill’ on the WAF Managed Rulesets, which instantly dropped CPU back to normal and restored traffic. That occurred at 1409 UTC.

We then went on to review the offending pull request, roll back the specific rules, test the change to ensure that we were 100% certain that we had the correct fix, and re-enabled the WAF Managed Rulesets at 1452 UTC.

We recognize that an incident like this is very painful for our customers. Our testing processes were insufficient in this case and we are reviewing and making changes to our testing and deployment process to avoid incidents like this in the future.
Voor degenen die hier niet bekend mee zijn, het gaat hier om een bekend probleem dat kan optreden bij verkeerd geschreven reguliere expressies.

Wat zijn reguliere expressies?
A regular expression, (...) is a sequence of characters that define a search pattern. https://en.wikipedia.org/wiki/Regular_expression
Om een voorbeeld te geven, met de reguliere expressie [0-9] kun je testen of een stuk tekst een cijfer bevat, met ^b kun je testen of een tekst begint met een b, x+ vindt één of meer x-en en de reguliere expressie ^A('|mster)dam$ geeft alleen 'true' terug als de tekst óf A'dam, of Amsterdam is.

Waar ging het fout?


Waar het fout kan gaan bij reguliere expressies is zogeheten catastrophic backtracking. Ik heb nu geen tijd om dit verder uit te werken, maar zie de link.

[Reactie gewijzigd door xrf op 3 juli 2019 08:30]

*katastrofaal terugkrabbelen...
Een typefoutje of een fuckup in een regex doet half het internet neer gaan.
Stemt me gelukkig dat niet alleen ik foutjes maak ;)
En dat waardeer ik enorm daar.
Er blijft maar weinig echt 'classified'
Ook als ze zelfs wat verkeerd doen.
De placeholder is inmiddels dan ook al even geupdatet met wat er daadwerkelijk is gebeurd.
tldr;
Een slechte deploy van firewall rules. Een regex in 1 zo'n rule deed de cpu's spiken.
Er zijn systemen en procedures om dit te voorkomen, maar die hebben nu niet gewerkt. Dit wordt nog onderzocht.
Stel je voor dat je dus een hele procedure afgewerkt hebt, maar ziet dat er toch nog een foutje in geslopen is, in de regex staat "\.gif" ipv "\.jpg". In plaats van een ganse procedure te doorlopen, denk je "ik verander dat wel vlug eens", en je vergeet de backslash en typt ".jpg". Oops, hate to be that guy :+

[Reactie gewijzigd door ? ? op 5 juli 2019 10:19]

Voor de mensen die de grafiek niet direct snappen, die 2 grote dalen zijn in de nacht.
Het dipje rechts achter in de grafiek, dat is toen Cloudflare problemen had.
De as onder is het uur
niemand significant online rond 4 uur snachts? Kan me bijna het patroon niet voorstellen
De nul lijn op de grafiek is 2Tbit

Dus wel degelijk iets. De onderste lijn is dus niet 0
Zijn anders bar weinig mensen wakker doordeweeks om 4 uur :P
Zijn anders bar weinig mensen wakker doordeweeks om 4 uur :P
Over welke tijdzone heb jij het dan ?
Want wat hier 04:00 AM is, is in Chicago 21:00PM
Lijkt mij dat het om 21u lokale tijd aldaar best 'spits' is op diverse online diensten
Het gaat nog steeds over de grafiek van AMS-IX, oftewel Amsterdam, dat valt in CET ;)
Dus kunnen inwoners van andere continenten niet op een Europese website, dit een goede kans heeft om via AMS-IX gerouteerd te worden? Dat is natuurlijk van den zotte :)
Gebruikers kónden niet op websites, over heel de wereld. Het had weinig te maken met AMS-IX of specifieke locaties van gebruikers. CloudFlare heeft 155 datacenters over de hele wereld en zoals ik het lees op de gelinkte pagina hadden ze er allemaal last van:
This incident affected: Europe (Amsterdam, Netherlands - (AMS), Athens, Greece - (ATH), Barcelona, Spain - (BCN), Belgrade, Serbia - (BEG), Berlin, Germany - (TXL), Brussels, Belgium - (BRU), Bucharest, Romania - (OTP), Budapest, Hungary - (BUD), Chișinău, Moldova - (KIV), Copenhagen, Denmark - (CPH), Dublin, Ireland - (DUB), Düsseldorf, Germany - (DUS), Edinburgh, United Kingdom - (EDI), Frankfurt, Germany - (FRA), Geneva, Switzerland - (GVA), Gothenburg, Sweden - (GOT), Hamburg, Germany - (HAM), Helsinki, Finland - (HEL), Istanbul, Turkey - (IST), Kyiv, Ukraine - (KBP), Lisbon, Portugal - (LIS), London, United Kingdom - (LHR), Luxembourg City, Luxembourg - (LUX), Madrid, Spain - (MAD), Manchester, United Kingdom - (MAN), Marseille, France - (MRS), Milan, Italy - (MXP), Moscow, Russia - (DME), Munich, Germany - (MUC), Nicosia, Cyprus - (LCA), Oslo, Norway - (OSL), Paris, France - (CDG), Prague, Czech Republic - (PRG), Reykjavík, Iceland - (KEF), Riga, Latvia - (RIX), Rome, Italy - (FCO), Saint Petersburg, Russia - (LED), Sofia, Bulgaria - (SOF), Stockholm, Sweden - (ARN), Tallinn, Estonia - (TLL), Thessaloniki, Greece - (SKG), Vienna, Austria - (VIE), Vilnius, Lithuania - (VNO), Warsaw, Poland - (WAW), Zagreb, Croatia - (ZAG), Zürich, Switzerland - (ZRH)), Middle East (Amman, Jordan - (AMM), Baghdad, Iraq - (BGW), Baku, Azerbaijan - (GYD), Beirut, Lebanon - (BEY), Doha, Qatar - (DOH), Dubai, United Arab Emirates - (DXB), Kuwait City, Kuwait - (KWI), Manama, Bahrain - (BAH), Muscat, Oman - (MCT), Ramallah - (ZDM), Riyadh, Saudi Arabia - (RUH), Tel Aviv, Israel - (TLV)), Asia (Bangkok, Thailand - (BKK), Cebu, Philippines - (CEB), Chengdu, China - (CTU), Chennai, India - (MAA), Colombo, Sri Lanka - (CMB), Dongguan, China - (SZX), Foshan, China - (FUO), Fuzhou, China - (FOC), Guangzhou, China - (CAN), Hangzhou, China - (HGH), Hanoi, Vietnam - (HAN), Hengyang, China - (HNY), Ho Chi Minh City, Vietnam - (SGN), Hong Kong - (HKG), Hyderabad, India - (HYD), Islamabad, Pakistan - (ISB), Jinan, China - (TNA), Karachi, Pakistan - (KHI), Kathmandu, Nepal - (KTM), Kuala Lumpur, Malaysia - (KUL), Lahore, Pakistan - (LHE), Langfang, China - (NAY), Luoyang, China - (LYA), Macau - (MFM), Manila, Philippines - (MNL), Mumbai, India - (BOM), Nanning, China - (NNG), New Delhi, India - (DEL), Osaka, Japan - (KIX), Phnom Penh, Cambodia - (PNH), Qingdao, China - (TAO), Seoul, South Korea - (ICN), Shanghai, China - (SHA), Shenyang, China - (SHE), Shijiazhuang, China - (SJW), Singapore, Singapore - (SIN), Suzhou, China - (SZV), Taipei - (TPE), Tianjin, China - (TSN), Tokyo, Japan - (NRT), Ulaanbaatar, Mongolia - (ULN), Wuhan, China - (WUH), Wuxi, China - (WUX), Xi'an, China - (XIY), Yerevan, Armenia - (EVN), Zhengzhou, China - (CGO), Zuzhou, China - (CSX)), Oceania (Auckland, New Zealand - (AKL), Brisbane, QLD, Australia - (BNE), Melbourne, VIC, Australia - (MEL), Perth, WA, Australia - (PER), Sydney, NSW, Australia - (SYD)), North America (Ashburn, VA, United States - (IAD), Atlanta, GA, United States - (ATL), Boston, MA, United States - (BOS), Buffalo, NY, United States - (BUF), Calgary, AB, Canada - (YYC), Charlotte, NC, United States - (CLT), Chicago, IL, United States - (ORD), Columbus, OH, United States - (CMH), Dallas, TX, United States - (DFW), Denver, CO, United States - (DEN), Detroit, MI, United States - (DTW), Houston, TX, United States - (IAH), Indianapolis, IN, United States - (IND), Jacksonville, FL, United States - (JAX), Kansas City, MO, United States - (MCI), Las Vegas, NV, United States - (LAS), Los Angeles, CA, United States - (LAX), McAllen, TX, United States - (MFE), Memphis, TN, United States - (MEM), Miami, FL, United States - (MIA), Minneapolis, MN, United States - (MSP), Montgomery, AL, United States - (MGM), Montréal, QC, Canada - (YUL), Nashville, TN, United States - (BNA), Newark, NJ, United States - (EWR), Norfolk, VA, United States - (ORF), Omaha, NE, United States - (OMA), Phoenix, AZ, United States - (PHX), Pittsburgh, PA, United States - (PIT), Portland, OR, United States - (PDX), Queretaro, MX, Mexico - (QRO), Richmond, Virginia - (RIC), Sacramento, CA, United States - (SMF), Salt Lake City, UT, United States - (SLC), San Diego, CA, United States - (SAN), San Jose, CA, United States - (SJC), Saskatoon, SK, Canada - (YXE), Seattle, WA, United States - (SEA), St. Louis, MO, United States - (STL), Tampa, FL, United States - (TPA), Toronto, ON, Canada - (YYZ), Vancouver, BC, Canada - (YVR), Tallahassee, FL, United States - (TLH), Winnipeg, MB, Canada - (YWG)), Latin America & the Caribbean (Asunción, Paraguay - (ASU), Bogotá, Colombia - (BOG), Buenos Aires, Argentina - (EZE), Curitiba, Brazil - (CWB), Fortaleza, Brazil - (FOR), Lima, Peru - (LIM), Medellín, Colombia - (MDE), Mexico City, Mexico - (MEX), Panama City, Panama - (PTY), Porto Alegre, Brazil - (POA), Quito, Ecuador - (UIO), Rio de Janeiro, Brazil - (GIG), São Paulo, Brazil - (GRU), Santiago, Chile - (SCL), Willemstad, Curaçao - (CUR)), and Africa (Cairo, Egypt - (CAI), Casablanca, Morocco - (CMN), Cape Town, South Africa - (CPT), Dar Es Salaam, Tanzania - (DAR), Djibouti City, Djibouti - (JIB), Durban, South Africa - (DUR), Johannesburg, South Africa - (JNB), Lagos, Nigeria - (LOS), Luanda, Angola - (LAD), Maputo, MZ - (MPM), Mombasa, Kenya - (MBA), Port Louis, Mauritius - (MRU), Réunion, France - (RUN), Kigali, Rwanda - (KGL)).
Ik zat net bij klanten in cPanel webmail pakket te upgraden die door HTTPS Proxy van CF lopen.
Maar Ctrl F5 ramen om 4u in de nacht WANT, dan zit er zeker geen klanten op hun mail servers.
De update repository gaat over een CloudFlare proxy? Het kan wel enorm vervelend zijn als je van een derde afhankelijk bent voor dit soort infrastructuur. Indien het een door cPanel geleverde webmail applicatie (Roundcube, Horde) is zal 'ie het vannacht automatisch weer proberen door de automatische updates. Dus hoef je om 4 uur je bed niet uit te rollen ;)
Webmail Pro op PHP, denk dat er een Auth of CaptchaV3 update was.
Effe in de avond doen dan heb ik in de ochtend minder emails dat er niks werkt bij klant X.
Volledig offtopic, ik heb zelf wel goede ervaring met Rainloop. Integreert niet met cPanel zelf, maar je kunt het binnen een account installeren, bijvoorbeeld webmail.mijnhostingbedrijf.tld.

Afterlogic en Rainloop lijken qua interface redelijk op elkaar. Wat de voordelen of nadelen zijn van elk durf ik niet te zeggen, behalve dat Afterlogic ook support voor bestanden heeft (prefeeeer zelf dan NextCloud).
De CEO op twitter: Cpu spikes zorgde dat de primaire en backup systemen niet meer werkte. Service die zorgde voor de spikes uitgezet, vervolgens werkte het weer: https://twitter.com/eastdakota/status/1146065231270907907

Zijn nog opzoek naar de root cause.
Dit klinkt bijna hetzelfde als een bekend KPN-probleempje van vorige week ;)
Als dit zo is, dan wordt het tijd dat niet alleen KPN, maar ook CloudFlare eens orde op zaken moet stellen en wat redundante verbindingen moet leggen.
Persoonlijk hoop ik een beetje dat deze incidenten (zijn er meer geweest de afgelopen twee/drie weken), aan het nadenken zetten of het nu eigenlijk wel zo'n slim idee is om CloudFlare te gebruiken - en of er wellicht ook een ander middel is om het beoogde doel te bereiken.

Ik heb persoonlijk de mening dat dit soort extreme centralisatie niet goed, noch wenselijk is, omwille van privacy, de macht die deze partijen krijgen en de afnemende mogelijkheden om er iets tegen te doen, mochten deze partijen zich misdragen.
CloudFlare heeft de capaciteit om een dDdos op te vangen. Wat zouden andere goedkope/gratis middelen zijn voor een simpele site om dit op te vangen zonder CloudFlare?
Verschilt mijn inziens per usecase. Wellicht dat het een hele fijne, (vrijwel) kosteloze oplossing is voor gameservers, als je als wat groter bedrijf CloudFlare "nodig hebt" zou ik mijzelf toch eens achter de oren krabben. Maar wellicht is dat mijn attitude als voorvechter voor privacy, decentralisatie en ethiek.
Sorry hoor, maar Cloudlfare heeft eens in de 4 jaar misschien een kwartiertje downtime? Kan gebeuren, wat maakt dat nu uit het is overigens zelfs gratis als je de free plan gebruikt.

Het is gewoon een prima oplossing om je site te beschermen.
Cloudflare kan je ook als backup van je sitegebruiken, pas als je eigen server down is wordt Couldflare dan gebruikt.
De kans dat je site én cloudflare tegelijkertijd down zijn is erg klein.
Zo heb ik het op min server ook ingesteld, als ik ge Ddos'd wordt dan is mijn site gewoon nog bereikbaar.
En toen Cloudflare vanmiddag down was heeft ook niemand op mijn site iets van gemerkt.
Ik zou het bijna hetzelfde hebben genoemd als de KPN-storing slechts 23 minuten had geduurd en het niet om 112 ging. Trump zal hier geen twittervragen over stellen lijkt me.
maandag hadden ze ook problemen. Ik kon gisteren een tijdje transferwise.com niet gebruiken door cloudflare problemen.
Maandag was het alleen niet een probleem specifiek bij Cloudflare en was de oorzaak bij Verizon.

[Reactie gewijzigd door clx_ op 2 juli 2019 18:14]

Maandag was verizon (Amerikaanse isp) de oorzaak dat een deel van het internet het niet deed
Er was niets mis met "het internet".
Verbindingen waren gewoon mogelijk.

Er lag (een deel van) één hosting/caching provider plat, waardoor vele websites niet meer toegankelijk waren, en dat is nogal een verschil met "internet is stuk".
Toch bizar dat het internet/www (web van decentrale machines) toch grotendeels om kan vallen. Hele wereld is er van afhankelijk en het is toch oh zo kwetsbaar blijkt maar weer...
Al die sites kunnen ook met weinig moeite overstappen naar de concurrent of het gewoon even zonder CDN doen. Dat is met een dagje geregeld. Maar gewoon wachten tot de bestaande leverancier het in 20 minuten repareert gaat sneller.
Deze bedrijven zitten niet bij cloudflare voor alleen de CDN.

De voornaamste reden om cloudflare te gebruiken is zodat je bij een DDOS-aanval genoeg capaciteit hebt om de aanval af te weren, namelijk het netwerk van Cloudflare.

Zo is bijvoorbeeld het IP-adres van de servers van de bedrijven vaak privé, en gaat alles via cloudflare. Op deze manier weten aanvallers niet de echte ip adressen van het bedrijf. Het fungeert als proxy. Een CDN richt zich voornamelijk op het serveren van statische bestanden. Dat is bij een groot deel van deze bedrijven niet alleen aan de orde, hun non-cahchable requests moeten ook nog afgehandeld worden.

Het even weghalen van deze proxy kan niet zomaar. Dan weet de hele wereld je IP adressen en deze aanpassen is geen makkelijke taak.

[Reactie gewijzigd door Stemis op 2 juli 2019 19:55]

CloudFlare heeft een gigantische backbone waardoor ze in de positie zijn om gigantische DDoS aanvallen af te slaan, dat is een feit. Indien dat de enige reden is om voor CloudFlare te kiezen, zijn er meer manieren om zoiets te bewerkstelligen.

Je kunt bijvoorbeeld ook in een ander datacenter een proxy opstelling implementeren, met bijvoorbeeld NaWas en een partij die ervaring heeft met het afslaan van DDoS aanvallen. Op Nederlandse bodem bijvoorbeeld met Leaseweb, hun DDoS (ofja, beter anti DDoS) dienstverlening. Wil niet zeggen dat de primaire servers daar ook dienen te staan.

Als het kritische infrastructuur is kun je ook een draaiboek maken met een tweede provider, dat als het nodig is, er binnen no-time kan worden omgeschakeld.
Zomaar even je CDN veranderen omdat er een storing is, is niet echt mogelijk. Zelfs al had je de servercapaciteit (waarom huur je dan in hemelsnaam bij een dienst als CF?) dan nog heb je tijd nodig om DNS records te laten aanpassen en propageren over het internet.
Bij Cloudflare kan je gewoon de beveiligingsmuur/CDN ook tijdelijk pauzeren. OP dat moment gaat alles weer direct naar je Cloudflare. In de gunstige gevallen zou dit ook moeten helpen als CF weer eens problemen heeft. Maar dan moet het Dashboard wel bereikbaar zijn. Vanmiddag was dit niet het geval, las ik.... :/
Het tijdelijk stoppen van Cloudflare zal als gevolg hebben dat het origin IP-adres in de DNS wordt opgenomen. Hackers weten dat IP-adres dan ook meteen en kunnen ook nadat je de beveiliging weer hebt aangezet een rechtstreekse aanval plegen.
Er zijn genoeg sites waarop je vroegere dns records kan achterhalen. Zeker handig wanneer je CF niet gelijk hebt ingevoerd, maar pas later :).
Toch bizar dat het internet/www (web van decentrale machines) toch grotendeels om kan vallen. Hele wereld is er van afhankelijk en het is toch oh zo kwetsbaar blijkt maar weer...
Omdat men gebruik maakt van die handige verzameldiensten, die alles op een (paar) lokaties centreren.
Als jij niet langs 15K-kanten wil gebombardeerd worden met een DDOS zet je een dienst in als CloudFlare.
En als die gateway nu juist wegvalt, sla je je eigen deur dicht.

Het blijft een keuze tussen veiligheid en zekerheid .. of een compromis van beiden met een dunne scheidslijn
Nou ja, 'oh zo kwetsbaar'.. Hoe vaak ligt CF er nou uit en dan ook nog globaal?

De stroom valt ook wel eens uit, 112 is ook wel eens niet bereikbaar, je hebt ook wel eens even geen mobiel internet. In Nederland gebeurt het zelden, maar 'nooit' haal je niet.

Het kan altijd nog beter en mooier geregeld, maar er komt ook altijd een punt waarop je het niet meer terugverdient. Het is ook maar gewoon een commercieel bedrijf met klanten die zich tegen DDOS willen beschermen. Klanten voor wie geld geen rol speelt, kunnen dat ook zonder CF oplossen. De CF-klanten zijn niet per se de klanten met de diepste zakken, zal ik maar zeggen.
Ik surf blijkbaar aan de verkeerde kant van het internet :)

Niets gemerkt. vraag me af welke websites dan last hadden.
Discord
Allestoringen
MMO-Champion

en nog wat andere dingen van wat ik merkte :)
Wel grappig ja ik wilde kijken bij allestoringen en downdetector maar die waren beide ook down :')
Discord
Allestoringen
MMO-Champion

en nog wat andere dingen van wat ik merkte :)
Steam bijv.
Extra zuur tijdens de zomer uitverkoop.
Wij merkten het ook aan topdesk. Verder nergens last van gehad. Werd eerst traag en toen ineens de 502.
Even een flashback naar mijn mbo hier! Eeeh topdesk :(
onze topdesk SaaS oplossing ook ....
Je bedoelt zeker “de verkeerde kant van internet”.

Ik weet niet waar tweakers tegenwoordig z’n style guide vandaan haalt, maar “de helft van internet was niet bereikbaar”, rly?
Inderdaad, dit keer geen mail van wordpress-jetpack gekregen over 'offline'
Vorige week bij de storing was het direct raak, 90 minuten 'offline' geweest
Buckaroo lag bijvoorbeeld plat.
onder andere Dumpert en Geenstijl, de Dumpert app werkte wel op miraculeuze wijze.
Cloudflare is wel een single point of failure wanneer de meesten cloudflare gebruiken als hun DNS.
Ook als je het niet als DNS gebruikt worden veel sites via Cloudflare geserveerd, heb je wel leuk het IP adres van die website maar als Cloudflare eruit ligt kan je er nog niets mee...
Kan je als je meerdere sites beheerd (elk met eigen IP adres) eentje gebruik laten maken van CloudFlare CDN, de andere via een andere CDN.

Vraag me af wat er zal gebeuren als Let's Encrypt een storing heeft. Dat is net zoals CloudFlare ook al zo'n single point of failure aan het worden.

Maak je het makkelijk voor websites, dan komen de klanten vanzelf naar je toe. Klanten die maar al te graag al hun eieren in hetzelfde mandje willen stoppen.
Als LetsEncrypt een storing heeft dan vervang je je certificaten een dag later. In dat proces zit zo'n enorme marge. Certificaten zijn 3 maanden geldig, worden standaard na een maand vervangen en als het goed is loopt dat proces 1 of meerdere keren per dag.

Het is niet zo dat jouw browser voor iedere SSL cert check een server van LetsEncrypt raadpleegt. Die CAs zijn allemaal gecached in je systeem/browser.

Als LetsEncrypt er langere tijd uitligt dan heb je ~2 maanden de tijd om een andere te regelen.
Twee CDNs zoals Cloudflare voor je site gebruiken is technisch echter nogal lastig, vooral door hoe diensten als Cloudflare werken.
Verdelen per IP adres is leuk maar beperkt je ook gigantisch aangezien de helft van je sites dan wel bereikbaar zijn en de rest niet bij een storing, daarnaast is het administratief een stuk meer gedoe, grote kans dat het alleen maar meer storingen veroorzaakt omdat het fouten in de hand werkt.

Een storing van LetsEncrypt tot zelfs een paar weken lang heeft geen effect op het internet, de default configuratie (welke de meeste sites zullen gebruiken) checkt dagelijks of de certificaten die maand verlopen en als dat het geval is worden ze direct verlengd voor zo'n 3 maanden.
Ook als die storing bij LetsEncrypt langer zou duren kan je alsnog ruim op tijd een alternatief certificaat installeren zonder dat er downtime van komt.
Hetzelfde geldt voor GoogleDNS, OpenDNS, je provider's DNS etc......
In dit geval was er niks fout met Cloudflare zijn DNS. De problemen lagen bij de HTTP proxy die gebruikt wordt om jouw website te cachen en te serveren door deze proxies.

Het probleem kon je voor je eigen website in dit geval tijdelijk fixen door de HTTP proxy uit te zetten, hierna laadde hij je website zonder Cloudflare zijn caching en had je geen problemen.
Jep, maar het dashboard van Cloudflare gaat ook via.. Cloudflare. (Dus lag er ook uit)

Meer isolatie daarin zou wel mooi zijn.
Ik heb zelf ook de DNS van cloudflare en nergens last van gehad. Terwijl sites van klanten van ons die via Cloudflare draaien wel down waren.

Ik denk dat hun nameservers los staan van hun CDN.
Cloudflare is wel een single point of failure wanneer de meesten cloudflare gebruiken als hun DNS.
In mijn router staan 4 DNSservers, 1.1.1.1 - 8.8.8.8 - 208.67.222.123 - 9.9.9.9

Als de eerste niet reageert, komen de andere aan de beurt.
Alleen niet pro-actief, pas na een reboot van de router gaat men weer vooraan beginnen.

Dus de SPOF is mijn router in dit geval
En voor alle mensen op KPN als dat down gaat. Kan je niet bellen, niet bij 112 enzo.
NPM was zelfs down, dat heeft een aantal javascript developers vast laten zweten :P
Misschien was dat wel het probleem, met die gigabytes aan node_modules die ze binnen trekken 😜
Dit is dus waarom ik nou geen gebruik maak van cloudflare...
Je hebt niet zoveel keuze. Of je moet het halve internet vermijden.
waarom is er niet ''zoveel keuzen'' zeg mij dat is. ik gebruik op geen ene site van mij cloudflare en heb nooit dit soort problemen
Je hoeft je eigen sites niet via Cloudflare laten lopen maar een boel externe zaken die je vroeg of laat nodig hebt gebruiken Cloudflare. Denk aan REST API's of boekingsmodules.
Je hebt niet zoveel keuze. Of je moet het halve internet vermijden.
Hangt af van welke diensten je bij CloudFlare afneemt.

Als het om DDoS Protection gaat, heb je al een paar dozijn alternatieven. Voor DNS services ook. Load balancing en CDN idem.

Het zijn geen producten die compleet wallet garden zijn, iedere toko zou het aan kunnen bieden.

Het verschil is dat bij CloudFlare je alles onder één dak hebt, wat handig is omdat die services naar elkaar geconfigureerd zijn. Dus is er minder handmatige configuratie nodig. Maar dat is alles qua voordeel van CloudFlare gebruiken.

[Reactie gewijzigd door RoestVrijStaal op 2 juli 2019 18:45]

Dit is dus waarom ik nou geen gebruik maak van cloudflare...
Wat een oplossing, omdat er een storing is "daarom doe ik het niet"

Providers liggen er ook regelmatig even/langer uit
Zelfs datacenters kunnen downtime krijgen.

"daarom gebruik ik product XX niet" is zo'n vage opmerking..
Ik gebruik CF dus wél, het bespaart me een hoop nutteloos dataverkeer en 'beschermt' aardig tegen scriptkiddies, die mijn services willen schoppen.
Daarom gebruik ik Cloudflare .... ( en omdat het gratis is ;) )
Wat noem jij onder “scriptkiddies”?
Wat noem jij onder “scriptkiddies”?
Van die grapjassen die met een 'kant&klaar' scan-hack pakketje IP-reeksen afstruinen om te proberen of er een port / service open staat

Via CF wordt dat in veel gevallen geblokkeerd
Hmmm heb daar niet bepaald last van..
Dit is niet specifiek iets dat Cloudflare kan overkomen. Soortgelijke storingen zijn ook bij bijvoorbeeld AWS voorgekomen, daar kun je niet echt iets aan doen.
Dus jouw infrastructuur doet het altijd? Ik ben wel benieuwd hoe je dat voor elkaar krijgt.
Dat is niet super moeilijk hoor.. alles uptodate houden en onderhouden en bij een host gaan die mogelijk ddos kan afweren wanneer nodig is :)
Maak je dan ook geen gebruik van de grote single point of failures als KPN en Ziggo? Of AMS-IX?
Ah, jij zit op je eigen internet. Cool.
2 providers hebben is voldoende. En het kan, in een paar stukjes Nederland, dat dit niet via KPN of Ziggo's netwerken gaat, maar TweakDSL, Caiway, T-Mobile en volgens mij heeft Solcon her en der stukjes glas zelf in beheer. Buiten de netwerken van de providers, zijn er maar weinig single points of failure. De meeste Nederlandse providers gaan via minimaal 2 -van onze- exchanges het internet op.
Tsja, maar helpt dat als de site die je wil bezoeken alleen op KPN gehost wordt? Bijv. in een van hun datacenters? En wat als je twee providers hebt, maar de stroom valt uit. Je kan dan een UPS nemen. Maar wat als je huis onder water staat? Tweede huis?

Alles kan, maar hoe ver moeten we gaan...
Yep, enige downtime op mijn eigen internet is als de stroom er af gaat :+
Host je dan ook je eigen google? :+ Ik wel, en ik sta altijd boven aan in de resultaten, super goede SEO 8-)

[Reactie gewijzigd door johnkeates op 2 juli 2019 20:58]

Je rijdt ook geen auto of fiets neem ik aan? Dat gaat ook wel eens mis tenslotte.
Het is iets anders, maar de logica is hetzelfde. Je kiest een provider niet omdat er iets mis gaat, maar dat kan net zo goed bij de andere gebeuren, alleen is dat nu niet zo en zie jij dat als argument om het niet te kiezen.
Dat is dus hetzelfde als dat je een volkswagen aan de kant ziet staan en zegt, daarom koop ik geen volkswagen. n=1 met compleet missende logica.
Hier was er even paniek - wereldwijd waren onze sites niet toegankelijk.

Verder ging betalingsverkeer moeizaam (Adyen) en hadden we geen toegang meer tot tools als Zendesk. End-users overspoelden ons gelijk met een internetstoring.

De foutmelding gaf gelukkig wel netjes "Cloudflare" weer onderaan elke 502, dus de oorzaak was nogal snel gevonden en een algemene mailing naar onze 3 kantoren en melding op de chatkanalen was genoeg om gelijk iedereen gerust te stellen dat "het halve internet" eruit lag en dat we bitterweinig meer konden doen dan afwachten.

We waren wel gelijk een "plan B" aan het bedenken mocht de storing te lang duren, maar alles waar we op konden komen duurden helaas langer dan wachten totdat Cloudflare met een oplossing kwam.

[Reactie gewijzigd door bramvandeperre op 2 juli 2019 16:45]


Om te kunnen reageren moet je ingelogd zijn


OnePlus 7 Pro (8GB intern) Nintendo Switch Lite LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Smartphones

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True