Microsoft: Azure-storing werd veroorzaakt door ddos-aanval

De storing die Azure en andere Microsoft-diensten dinsdag trof, werd veroorzaakt door een ddos-aanval. Dat zegt Microsoft. Het bedrijf meldt daarnaast dat zijn eigen ddos-bescherming de aanval mogelijk verergerde.

Microsoft deelt verder nog geen informatie over de grootte van de ddos-aanval of wie er mogelijk achter zat, maar zegt dat klanten rond 13.45 uur Nederlandse tijd voor het eerst last kregen van de aanval. Door de ddos werkten de Azure Front Door- en Azure Content Delivery Network-diensten niet meer naar behoren, waardoor klanten foutmeldingen, time-outs en latency spikes kregen. Verschillende Azure-diensten 'en een deel van de Microsoft 365- en Purview-diensten' werden door de aanval getroffen, schrijft het bedrijf.

Na de ddos-aanval werd Microsofts ddos-bescherming geactiveerd, maar 'een eerste onderzoek suggereert dat een fout in het implementeren van die bescherming de impact van de aanval verergerde in plaats van deze te verminderen'. Daarom duurde het tot 21.43 uur Nederlandse tijd voordat Microsofts storingscijfers weer normaal werden. Een uur later meldde het bedrijf dat de storing voorbij was. Microsoft belooft in de komende dagen en weken meer informatie te delen over de wereldwijde storing.

Reacties (145)

[djwice]

Wow, dat is heftig een CDN plat krijgen.

Op AWS kan ik per account (een tenant in Microsoft termen) 3.75 TBps en 50 miljoen requests per seconden krijgen, zonder enige vooraankondiging of service request.
Dit is een normaal standaard AWS account.

Hoe groot moet de attack wel niet zijn geweest op de hele Microsoft CDN te kunnen beïnvloeden?

Of is de capaciteit van Microsoft zo veel kleiner dan die van AWS?
Opgezocht Een Microsoft tenant kan maximaal 234GBps en 2.5 miljoen request per seconde aan. Dat is een factor 16 tot 40 kleiner dan AWS per tenant.

[Reactie gewijzigd door djwice op 31 juli 2024 20:11]

[JackBol]

Meeste attacks zijn tegenwoordig niet meer volumetisch maar misbruiken een zwakte in het protocol. Ik heb geen flauw idee hoe ze Azure plat hebben gekregen, maar ik heb ergens gelezen dat de HTTP/2 rapid reset aanval op meerdere cloud providers met slechts 30k hosts uitgevoerd was.

[renecl]

Waarom zou iemand dat willen doen?

Stoerdoenerij?

[Yolo]

Rusland, China, n-Korea zijn er alles aan gelegen om partijen als Microsoft op haar zwakke plek te raken.
Kwestie van tijd voordat dit erger wordt. Indrukwekkend dat het zo lang heeft mogen duren tot dit gebeurde.

[Krommetenen]

Zou maar een fractie kunnen zijn geweest en 1000x verergerd zijn door de foute implementatie van de ddos beveiliging.

Of dat die beveiliging diensten uitzette inplaats van te beschermen. We kunnen enkel speculeren.

[McNutters]

Microsoft geeft aan dat de maatregelen die een DDoS moeten mitigeren mogelijk voor een versterking van de aanval hebben gezorgd:

While the initial trigger event was a Distributed Denial-of-Service (DDoS) attack, which activated our DDoS protection mechanisms, initial investigations suggest that an error in the implementation of our defenses amplified the impact of the attack rather than mitigating it.

Het blijft desalniettemin indrukwekkend.

[mobrockers]

Welke dienst heb je hiervoor bekeken? Ik kan de service limits die jij noemt niet vinden.

[djwice]

AWS CloudFront (som per account)
https://docs.aws.amazon.c...imits.html#limits-general
en
https://docs.aws.amazon.c...#limits-web-distributions

Azure CDN (som per tenant)
https://learn.microsoft.c...t-delivery-network-limits

[Reactie gewijzigd door djwice op 1 augustus 2024 18:26]

[mobrockers]

De limits bij azure zijn per subscription niet per tenant. Er is geen limiet aan het aantal subscriptions per tenant dus volgens jou berekening zou de cdn limiet bij azure infinite zijn.

Het lijkt me logischer om naar de specifieke cdn limits te kijken en dan levert 1 azure cdn max 75gbps en 1 Amazon cdn max 150gbps throughput. Amazon doet het hier nogsteeds goed maar niet de 20x die jij noemt. De som is imo niet zo nuttig want het is allemaal saas dus het is niet alsof de cdn specifiek voor jouw tenant of azure account is en de limieten zijn dus ook niet gebaseerd op wat Amazon noch Azure qua load aankunnen.

[djwice]

Dan heb ik tenant en subscription door elkaar gehaald qua naam. Ik dacht dat tenant op Azure het zelfde was als account bij AWS, maar blijkbaar is dat subscription. En is een tenant bij was een organisatie. Ik kan mijn post helaas niet meer updaten met een strike trough.


Azure accepteert maximaal 100k requests per seconde op 1 cdn instance, AWS 250.000 per seconde per instance.
Azure accepteert 25 CDN instances per subscription, AWS 200 per account.

Bij AWS kun je een onbeperkt aantal accounts hebben in een organisatie, maar kijken we naar AWS Shield (DDoS protectie) dan is er een limiet van 1000 CDN instances default, deze limiet kan op verzoek worden verhoogd (15 minuten afhandeltijd).
Azure heeft een limiet van 100 IP-adressen per tenant., dat is minder dan de 192 beschikbare Edge locaties, zelfs minder dan de 109 metro cities op Azure.

Het leek mij logisch om limieten per subscription/account te bekijken.
Kijken we naar de limiet per DDoS protectie per tenant / organisatie, dan worden de verschillen (helaas) nog groter dan die factor 40, Azure lijkt (volgens eigen specificaties) niet eens alle metro cities van 1 CDN in je subscription te beschermen binnen je de Azure DDoS instance (op tenant niveau). Waar AWS standaard een equivalent van 40 subscriptions afdekt en dat makkelijk is uit te breiden.

Bij AWS wordt de normale gebruiker bij gebruik van Amazon Route 53 (DNS) automatisch geleidt naar de best beschikbare Edge locatie, dat update binnen 1 seconde. Tijdens aanvallen wordt het normale verkeer dus heel snel dynamisch omgeleid. Als Azure dat ook doet, maar slechts 52% van hun Edge locaties beschermd met 1 DDoS mechanisme en de andere 48% met een andere , en beide willen het traffic naar de ander offloaden kom je in een oneindige loop.


Let op, ook de netwerk limieten op Azure zijn gelijk aan die van de CDN. Bij AWS is dat niet het geval.

[Reactie gewijzigd door djwice op 3 augustus 2024 22:49]

[mobrockers]

Ik denk dat je hier te veel probeert om wat je van aws weet te plotten op hoe Azure werkt. In azure hebben alle resources ddos protection. Je kan daarnaast additionele ddos protection aanschaffen voor public ip's voor je meer iaas resources wanneer je bijvoorbeeld gebruik maakt van virtual machines of loadbalancers. Per ddos protection plan kan je 100 ip's opnemen in hetzelfde plan, maar je kan meerdere plans aanschaffen. Als je meer ip's wil beschermen.

Dit is niet van toepassing op Azure cdn of Azure front door want dat zijn volledig saas diensten waar Azure zelf de ip's en routing aanlevert. Ddos protection voor deze resources valt dus ook niet onder de ddos protection plan. Deze resources routeren automatisch ook idd naar de dichtstbijzijnde edge locatie.

Het klopt dan natuurlijk nogsteeds wel dat aws 2-3x veel max throughput en connections levert per cdn instance, maar buiten dat gaat de vergelijking die je probeert te maken mij echt te scheef, omdat de diensten te verschillend aangeboden worden.

[Reactie gewijzigd door mobrockers op 4 augustus 2024 00:01]

[djwice]

Ik verwacht dat de services een reflectie zijn van de inrichting. Als je een plan niet kunt uitbreiden naar meer dan 100, maar een 2e plan moet configureren, zegt dat iets over de inrichting van de onderliggende laag.

[HetisRick]

Fijn om dat ze het in ieder geval communiceren, velen van onze klanten konden simpelweg mensen naar huis sturen vanwege het niet kunnen bereiken van hen ERP-pakket. (Dynamics 365). Hopen dat 't niet snel opnieuw gebeurd.

[Erwin1967]

Dat is ook zo fijn om je primaire systemen in de cloud af te nemen. Bij dit soort problemen kun je je bedrijf gewoon sluiten en hebben de medewerkers een dagje vrij.

[supersnathan94]

Tsja. Als je het on-prem doet kun je je vaker je medewerkers vrij geven in veel gevallen.

Hybrid zou een oplossing kunnen zijn, maar dan nog zijn er vaak veel meer bedrijven getroffen aan leverancierszijde of afname kant. Dus of je producten worden ook niet gebruikt of je leveranciers zijn niet bereikbaar. Bij dit soort globale storingen is het enige wat nog telt je SLA cijfertje voor het contract. Dat er niet gewerkt kan worden is dan jammer.

[jurroen]

Tsja. Als je het on-prem doet kun je je vaker je medewerkers vrij geven in veel gevallen.

Waar baseer je dat op? Wij draaien alles on-prem en geen werk door een technische storing is de afgelopen 12 jaar maar liefst nul minuten voorgekomen.

[Argantonis]

Da’s leuk maar als je wél een doelwit bent dan kan je het natuurlijk vergeten. Voor bedrijven die totaal geen aandacht trekken is een eigen serverparkje misschien nog wel interessant. Maar qua beveiliging en schaalbaarheid bij een eventuele ddos leg je het natuurlijk wel altijd af tegenover een grote cloud dienst. Wel het voordeel dat je idd niet geraakt wordt bij dit soort hele grote aanvallen.

[SuperDre]

Dan is dat bij jullie misschien heel goed geregeld, maar ik verwacht dat het vooral meer ook een kwestie van geluk is.

[jurroen]

Het scheelt misschien dat het geen groot bedrijf is met honderden medewerkers - maar het is ook volledig redundant en KISS opgezet, uitgebreide monitoring (logs, hardware). Er is een vrij zware UPS, de uplink is redundant (fysiek gescheiden/ander pad plus twee verschillende providers/netwerken), er zijn wat hot én cold spares en if need be kan er omgeschakeld worden naar een fallback in een datacenter. Zelfs dat is in die 12 jaar niet nodig geweest.

De andere kant heb ik overigens ook onlangs meegemaakt, bij een bedrijf waar ik geen link mee heb: goed uitgevoerd (hybride) netwerk - ineens alles op z'n gat. Was niemand op kantoor op dat moment. Mannetje naar toe gestuurd... bleek dat er een waterleiding IN het serverhok liep die gesprongen was. Ouch

[Reactie gewijzigd door jurroen op 31 juli 2024 20:27]

[supersnathan94]

bleek dat er een waterleiding IN het serverhok liep die gesprongen was.

Autsch. Maar dat soort dingen kunnen dus ook een probleem zijn.

Of laatst wat er in frankrijk is gebeurd, sabotage door meerdere defecte internet kabels. Dan kun je wel twee gescheiden kabels hebben, maar als ze allebei moedwillig stuk worden gemaakt heb je gewoon een probleem.

Een glasvezel lassen kan vaak nog wel binnen een dag, maar een hele berg defecte hardware vervangen (want waterschade) kan weken duren. Levertijd van serverproducten loopt hard op. Zit nu bij een project waar men 6 maanden uitstel nodig heeft doordat een hardware boer niet voldoende capaciteit kan leveren.

On-prem kan prima heel goed gaan, maar is dan vaak stukken duurder door de extra overcapaciteit en operationeel houden van de hardware en als puntje bij paaltje komt is volledige reparatie in geval van catastrofaal falen vaak iets wat enkele uren tot weken kan duren.

Dan moet je dus uitwijk locaties inregelen inclusief data sync heen en weer en dat kost ook allemaal geld.

De meeste bedrijven zijn in de cloud beter en goedkoper af, maar dan moet je wel je software er voor maken.

[Scriptkid]

Of een beetje overdreven, ik ken geen wnkel bedrijf waar het 10 jaar lang foutloos draait.

Dat zou een uptime van 100 zijn. Bijna geen enkel bedrijf krijgt 5×9 of 4×9 klaar.

[SuperDre]

Tja, en hoe denk je dat het zal zijn als je de servers intern hebt staan en er een groot probleem zich voor doet? Dan kun je dus ook je personeel naar huis sturen. Juist cloudbased geeft een hogere kans op uptime dan zelf beheren.

[klakkie.57th]

Alles is niet zo zwart wit natuurlijk ..
On prem , kan prima in verschillende datacenters, met volledig synchronisatie.
Je doet nu net of we in 2015 alles in de cloud hadden staan.
Het aantal storingen van onze onprem infrastructuur van verschillende uren kan ik werkelijk op 1 hand tellen en dan hebben we het meestal over 1 applicatie niet "ALLES".

[Reactie gewijzigd door klakkie.57th op 31 juli 2024 22:00]

[Scriptkid]

Als je in de cloud gewoon multi region draai het je ook weinig tot geen issues en hogere security en vaak ook hogere uptime.

[Marve79]

Bij deze storing had dat niets uitgemaakt. En Azure is al gillend duur en dan ook nog multiregion mag je nog weer langs de kassa.

Azure e.a. cloud diensten zijn gewoon heel erg kwetsbaar. Het zijn ook gewoon data centra maar zeer groot en extreem complex en daardoor ook een zeer geliefd doelwit onder hackers.

Ik zie heel de voordelen van dat cloud gewoon niet meer. Kijk sommige diensten zoals email, teams, SharePoint kan ik nog inkomen. Maar je ERP systeem, je crown jewels zou ik lekker on-prem blijven draaien.

[ibmpc]

Alleen is het on-prem onbetaalbaar om dezelfde mate van beveiliging en uptime te krijgen. Vandaar dat mensen kiezen voor SaaS, omdat de TCO daarvan veel lager is en je de beveiliging veel verder kunt opschroeven.

[Marve79]

Voor SaaS zeker, maar als je bijv VM's in Azure draat is dat niet veel (on)veiliger als on-prem. Daarom zeg ik ook bijv zoiets als Exchange en Sharepoint zou ik lekker in de cloud draaien. Dat is on-prem een draak om te beheren zeker qua security. Maar VM's zou ik dan weer on-prem draaien. Minder latency, vaak snellere hardware, goedkoper.

Hybride blijft toch de toekomst.

[ibmpc]

Waarom zou je dingen als VM in Azure draaien, dat is hartstikke duur
Azure Virtual Desktop is in Azure wel by far goedkoper dan RDP on-prem, maar dat is denk ik een van de weinige uitzonderingen.

[Marve79]

Tot iedereen AVD draait dan gooien ze de prijs ook omhoog.

[ibmpc]

Dat zou niet heel ernstig moeten zijn. Veel bedrijven zien AVD als een interim om nog legacy applicaties aan te bieden. Dat zal steeds minder worden. Er zijn wel use cases om volledig in AVD te draaien met al je SaaS webapps, maar ook dat is een beetje een niche aan het worden.

[yatogami28]

We moeten niet doen alsof azure wekelijks een storing heeft. Een aanslag op deze grote komt nauwelijks voor. Stel je voor als dit wel op je on premise systeem gebeurde😭 .

[klakkie.57th]

Je hele AD infrastructuur , sql servers, sharepoint , fileservers … zullen netjes blijven draaien.
Verkeer routeren naar “emergency” firewall via andere provider ….
Sms uitsturen naar personeel dat ze het emergency profiel moeten selecteren in de vpnclient …. En we zijn weer online 🤷🏻‍♂️

Laat de ddos maar lekker doorgaan op je oorspronkelijke firewall, ze stoppen vanzelf wel eens en in de tussentijd kun je de hulp van je provider inschakelen.

[Reactie gewijzigd door klakkie.57th op 1 augustus 2024 02:44]

[SuperDre]

Zodra je iets in verschillende datacenters hebt, dan hebben we het dus al over cloud.

[GeroldM]

En jij, als getroffen bedrijf zijnde, hebt een boel verloren inkomsten en vooral 'Nee' verkocht aan je klanten. Klanten die daardoor wel gaan nadenken of jouw bedrijf nog wel in hun plannen past. Of bij het verkopen van diensten en/of goederen klanten zien weglopen naar je concurrent.

Zoals je misschien al hebt gemerkt met 'alles naar de cloud en abonnementjes'-gedoe van tegenwoordig, terugkerende klanten leveren veel meer op.En als je 'Nee' verkoopt, dan ben je wel degelijk (een deel van) die terugkerende klanten kwijt. Of nog erger, verloren aan je (directe) concurrent.

Veel bedrijven kijken vaak teveel naar de kosten van zelf IT draaien en niet genoeg naar de risico's/consequenties van onderbrekingen in die IT.

[Argantonis]

Ze kijken ook naar het risico van wél alles zelf hosten en alle mogelijke problemen die daarbij komen kijken.

[HetisRick]

Ja dat is een feit, echter hosten wij ook voor sommige klanten nog steeds on-prem. Ik kan je bevestigen dat de uptime van Microsoft hoger is. Ze doen het gewoon echt heel netjes. Dat mag stiekem ook wel gezien de hogere kosten.

[cariolive23]

Wow, dat is wel een totaal gebrek aan flexibiliteit. Wij hadden er ook last van, zijn gewoon andere dingen gaan doen. Ik geloof niet dat de productiviteit er onder heeft geleden. Of we nou eerst A doen en dan B, of eerst B en dan A, dat maakt onderaan de streep niet zoveel uit.

Wanneer de service er meerdere dagen uit ligt, dan verwacht ik wel problemen. Maar dat is iets wat ik nou net niet verwacht bij oa Azure.

[MeanGreen]

De tijd van 15.45 die Microsoft noemt klopt niet, wij hadden er voor 14:30 al last van.

[Blokker_1999]

Correct, dat is ook niet de tijd in de communicatie van MS zelf. Zij geven 11:45UTC aan als beginpunt oftewel 13:45 bij ons.

[Bark_At_The_Cat]

Wat Microsoft beweert strookt niet met mijn ervaring. Ik heb mijn zoekgeschiedenis er even bij teruggepakt. Ik ben 13:08 gaan kijken op de Power Apps Community of anderen ook issues ervaren (en dat liep meteen al niet lekker), en heb ik een minuut later gezocht op "reddit sysadmin". Ik kom nooit op die subreddit, tenzij ik zelf begin te vermoeden dat er storingen zijn.

Op dat moment had ik al zeker een paar minuutjes wat issues.

[Reactie gewijzigd door Bark_At_The_Cat op 31 juli 2024 16:50]

[Keypunchie]

Wat ik denk is dat de issues met Front Door / Azure Portal om dat tijdstip begonnen zijn, omdat ze toen waarschijnlijk hun "mitigation" voor die DDoS hebben aangezet.

Ben heel benieuwd naar de PIR.

[Blokker_1999]

Uiteraard geen idee waar MS zich zelf op basseert, maar met een DDOS is het niet verwonderlijk dat er al issues zijn voordat alles echt begint neer te gaan. Heb zelf ook het gevoel dat de problemen er al vroeger waren, al was toen voor mij nog niet alles onbereikbaar.

[localhost]

Bij ons intern begonnen de klachten al rond 13:20 of zo. Verdere interne acties uitgezet vanaf 13:38.
Maar na 14:00 uur begon het pas echt erg te worden.

[Arnout]

Allestoringen begon vlak na 13.05 al op te lopen, wij keken ook vanaf 13.10 en toen was het voor verschillende bedrijven op downdetector al bal.

[GeroldM]

Maandagavond was ik bezig met het her-installeren van een laptop voor een collega en had de grootste moeite om Teams te downloaden van de Microsoft website, welke enigszins trager was dan normaal. Meerdere browsers (met en zonder extensies) geprobeerd op meerdere computers, waaronder zelfs een Linux computer, het mocht niet baten.

Dat speelde toen al in Zuid-Amerika.

[eric.1]

In de bron spreken ze over "11:45 UTC", wat 13:45 CEST is.

[Keypunchie]

Denk een tijdszone-foutje van Tweakers cc. @Hayte

[Hayte]

Dank voor de mention, is aangepast

[Andreplusplus]

13.45 CET

[DJanmaat]

DDoS op wat; intern was via admin.microsoft.com alles te benaderen. Vermoed een DDoS op trafficmanager.net

[DJanmaat]

En logisch op trafficmanager.net. Frontend. Verkeer wordt vanuit dit punt verdeeld. Iedere service hierachter krijgt verdeeld een sht load aan verkeer te verduren. Gevolg; meerdere services aan frontend niet te benaderen; afhankelijk hoe MS de load verdeeld. Kloppend met de reactie dat MS aangeeft hun techniek het heeft verergerd. Was bij trafficmanager.net de DDoS geweerd had dit niet gebeurd. Ze zullen hun techniek hier zeer wss op aanpassen. Kun je ook zien, check hoe verkeer nu via trafficmanager wordt begeleid en kijk eens naar hoe het gaat als MS een nieuwe statement heeft gegeven dat ze het hebben opgelost.

[as400]

Vreemd, het duurt een dag voordat ze doorhebben dat de oorzaak een ddos zou zijn? En de eigen protectie maakt het erger?

[mobrockers]

Waar maak je uit op dat ze dat vandaag pas weten? Ze delen die informatie vandaag, dat zegt niks over wat ze wanneer al wisten.

[Mosterd]

Het feit dat ze het pas vandaag mededelen misschien? Idee van cloud diensten is dat je meer betaald maar je het service deel uitbesteed, onder service verwacht ik niet 100% SLA maar wel communicatie over eventuele issues, feit dat dit zo lang geduurd heeft voor wat gewoon enorme hoeveelheden traffic is (want dat is DDoS in feite) is heel vreemd.

[Andreplusplus]

Wel degelijk geïnformeerd (per mail en via https://azure.status.microsoft/nl-nl/status

[Mosterd]

De status page gaf idd aan dat er een storing was, maar niet de oorzaak. Daar gaat deze thread en post over, er was gisteren al een post die ging over dat er uberhaupt een storing was FYI: nieuws: Azure en andere Microsoft-diensten wereldwijd getroffen door storing ...

[eettjjuuhh]

Misschien was er een reden om er pas vandaag mee naar buiten te treden? Dat zou een goede verklaring zijn imo.

[oltk]

Ik lees toch echt dat ze enige tijd na start van de DDOS aanval begonnen met beschermende maatregelen. Die maatregelen pakten niet goed uit door een fout in de configuratie.

Feiten op een rij: je gaat geen anti-DDOS bescherming doen als je niet weet dat er een DDOS aanval is. Kortom: dat wisten ze al snel.

Maar ze kregen de bescherming niet snel goed! Dat is IMHO veel interessanter dan proberen spijkers op laag water te zoeken over het moment van communicatie en of ze wisten of het een DDOS aanval was. Het verbaast me dat hier op tweakers niet ingegaan wordt op welke bescherming ze zouden kunnen hebben gehad en wat misgeconfigureerd zou kunnen zijn. Uit interesse kwam ik juist daarvoor .

[mobrockers]

Mijn eerste gok zou zijn een probleem in bgp (routing) waardoor verkeer niet goed terug kwam vanuit dedicated ddos infrastructuur, of dns. Reden? Het is altijd dns, en anders is het wel bgp.

[Krommetenen]

MS dealt dagelijks met DDOS.

Wellicht duurde het nu even, omdat de oorzaak waardoor de services onbereikbaar waren. Niet te verklaren was, nu blijkt een implementatie van de DDOS beveiliging, dan wel nagenoeg een verlate of ongewenste rol speelde

[mobrockers]

Pas vandaag? Wat heb jij aan de informatie tijdens het incident dat het om een ddos aanval gaat? Ze hebben het binnen 24u, na het oplossen van het incident, gemeld. Beetje ongeduldig niet

[Mosterd]

Als je als Microsoft zijnde geen goede DDoS bescherming hebt en/of de traffic niet kan rerouten, helemaal voor de bedragen die zij rekenen, dan gaat er iets goed mis en is snellere communicatie wel gepast.

Feit dat ze dat niet direct konden communiceren - ook al wisten ze het wel - geeft aan dat er ook wat schaamte heerst, je moet dan als techreus die hoge bedragen rekent toegeven dat je in ruil voor die hoge bedragen geen adequate DDoS bescherming kan regelen, dan maar wachten tot de oplossing er is en wanneer de storm gesust is stilletjes naar buiten brengen dat dat de oorzaak is geweest.

Ongeduldig is leuk maar feit is dat Azure niet zo vaak gebruikt wordt voor de site van de plaatselijke honkbal vereniging.

[CPV]

Het valt me wel vaker op, maar hier wel erg: iemand krijgt een -1 en zijn post is niet meer leesbaar.
Echter, de reacties wel en de reacties daarop ook. Dan krijg je een soort verhaal, waarvan de helft van de tekst is weggelaten.

Als het een onzin-post is, zijn de reacties ook niet meer nuttig. Verwijder die dan ook!

[MennoE]

Ja dat ziet er rommelig uit inderdaad. Misschien moeten ze überhaupt de mogelijkheid schrappen om te reageren op posts met een -1.

[jmvdkolk]

Kan het niet zo zijn dat er eerst gereageerd wordt op die post, en dat de post daarna pas een -1 kreeg?

[Andreplusplus]

Gewoon openklikken? Sommige posters verwijderen de tekst in hun bericht als -1 ontvangen, maar helemaal verwijderen kan niet.

[Buitenaerts]

Beter gewoon instelbaar maken, of je dit bij default wel of niet wil zien.

[thegve]

https://tweakers.net/instellingen/layout/

Onder reacties -> niveau. Ik heb het ook op 'ongewenst' staan.

[Buitenaerts]

Ooo wist ik niet top, dankjewel

[CPV]

Openklappen? Ik wist niet dat dat kon. Waarom wordt hij dan dichtgeklapt?

Inderdaad lijkt schrappen van die -1 het beste. Eén -1 post suggereerde: overstappen naar Linux.
Ik zou niet weten wat daar zo grensoverschrijdend aan was dat hij gecancelled moest worden

[Djeepman]

Wie bepaalt dat dan? Heel vaak wordt er een min gegeven omdat iemand de reactie niet aanstaat. Terwijl het toch echt ontopic is. Gewoon dat hele min verhaal schrappen 😉

[r2504]

... over te zetten naar terug on-premise zal je bedoelen.

We maken ons veel te veel afhankelijk van de cloud tegenwoordig.

[wildhagen]

Ook een onpremise omgeving kan een DDoS attack over zich heen krijgen. En de kans is vrij aannemelijk dat die dan net zo goed plat gaat. En ook daar kan een DDoS-protector (bijv Ckoudflare of soortgelijke dienst) verkeerd geconfigureerd zijn, waardoor hetzelfde probleem ontstaat als bij deze Azure-storing.

Daarnaast kost het hosten van alles onpremise ook behoorlijk wat geld, want je zult het datacenter helemaal zelf moeten onderhouden, incl alle benodigde personeel (duur), danwel huren bij een commercieel datacenter (ook duur). En dan nog kan je een DDoS-attack krijgen.

Over het algemeen is een cloud prima betrouwbaar, dit soort situaties en storingen van deze omvang zijn relatief zeldzaam. Om dit nu als argument tegen clouddiensten te gebruiken lijkt me, gezien bovenstaande alinea, een beetje overdreven, zeker als je de flinke (financiele en technische) nadelen van onpremise niet meeneemt in die vergelijking.

[r2504]

Ook een onpremise omgeving kan een DDoS attack over zich heen krijgen. En de kans is vrij aannemelijk dat die dan net zo goed plat gaat.

Ik zie niet in waarom een on-premise omgeving plat zou gaan bij een DDOS aanval. In het ergst geval gaat je firewall op z'n knieen maar de rest bljift netjes draaien (tenzij je alsnog externe services aanspreekt).

Daarnaast kost het hosten van alles onpremise ook behoorlijk wat geld

Ik dacht dat de mythe dat de cloud goedkoop was ondertussen toch stilaan voorbij was. Toegegeven, hoe complexer je loads hoe meer het belang van persooneel(skost) toeneemt.

Over het algemeen is een cloud prima betrouwbaar, dit soort situaties en storingen van deze omvang zijn relatief zeldzaam.

Ook weer grotendeels afhankelijk van de complexiteit van je omgeving... menig bedrijf heeft al meer downtime gehad met de cloud dan on-premise (toegegeven vaak ook minder onderhouden).

[hermanbrood]

Ik zie niet in waarom een on-premise omgeving plat zou gaan bij een DDOS aanval. In het ergst geval gaat je firewall op z'n knieen maar de rest bljift netjes draaien (tenzij je alsnog externe services aanspreekt).

Dit is niet helemaal waar. Laag-7 DDoS attacks kunnen je lokale, on-prem infrastructuur wel degelijk onderuit schoffelen. Been there, seen that.

Ik dacht dat de mythe dat de cloud goedkoop was ondertussen toch stilaan voorbij was. Toegegeven, hoe complexer je loads hoe meer het belang van persooneel(skost) toeneemt.

De cloud is goedkoop. Maar niet als die wordt ingezet zoals een on-premise omgeving. Dan is hij een stuk duurder. Dat is waar de culprit ligt. Bedrijven denken rucktsichtlos even een lift&shift te doen van hun virtuele machines die vervolgens lekker 24/7 staan te torren in Azure. Ka-chinggg!

Veel mensen maken deze denkfout ook nog steeds: De cloud zien als een datacenter. De cloud is geen datacenter, maar de cloud is een principe, een verandering van je organisatiecultuur, proces en technologie.

Het cloud principe moet een organisatie goed snappen om echt waarde en kostenbesparing uit de cloud te halen. Als een organisatie dat principe niet door heeft, is de cloud veel en veel duurder en is de organisatie er ook nog helemaal niet klaar voor om die stap te gaan maken.

[Reactie gewijzigd door hermanbrood op 31 juli 2024 17:02]

[klakkie.57th]

Ik ben het 100% met je eens dat je de cloud niet moet willen inzetten als een gewoon datacenter, alleen vraagt dat erg veel inspanningen van het bedrijf zelf en dat is dan weer iets dat niet meegerekend wordt in de IT-kost van de migratie want dit zijn werkuren van personeelsleden van andere afdelingen , die dan weer geen tijd hebben of "belangrijkere" taken hebben... gevolg hiervan is dus "LIFT & SHIFT"

[sapphire]

Nee de cloud is niet goedkoop maar als je geen personeel kunt vinden wel een oplossing

Ik werk in de zorg, ga eens opzoek naar ICT personeel die in een zorg CAO willen werken, succes

Ik heb hetzelfde bij meerdere instellingen gezien en als de keuze is tussen gekwalificeerde mensen extern inhuren of meer in de cloud gooien is die laatste vaak de minste slechte optie.

[david-v]

Nee de cloud is niet goedkoop maar als je geen personeel kunt vinden wel een oplossing

Kan je mij een on-premise sql server regelen voor 12 euro per maand?

Cloud of on-prem is niet goedkoop vs duur of beter vs slechter. Ze hebben beide, aanvankelijk van het gebruik en je wensen een bestaansrecht. Geen personeel kunnen vinden om systeembeheer te kunnen doen vind ik dan een betere reden. Of het goedkoper of duurder is staat redelijk los en is afhankelijk van je keuzes en je voorwaarden.

[Dennisb1]

Ik werk in de zorg, ga eens opzoek naar ICT personeel die in een zorg CAO willen werken, succes

Ik heb hetzelfde bij meerdere instellingen gezien en als de keuze is tussen gekwalificeerde mensen extern inhuren of meer in de cloud gooien is die laatste vaak de minste slechte optie.

Wel, ik werk in de zorg als systeembeheerder, heerlijke CAO (zorg en welzijn) wat dat betreft.

Tevens huren wij niet externen in en ook qua cloud alleen het noodzakelijke waar je niet onderuit kan komen.

[david-v]

Ik zie niet in waarom een on-premise omgeving plat zou gaan bij een DDOS aanval. In het ergst geval gaat je firewall op z'n knieen maar de rest bljift netjes draaien (tenzij je alsnog externe services aanspreekt).

Het ging hier om een DDOS aanval op CDN. Ik weet niet hoe vaak jij een wereldwijde CDN hebt opgezet on-prem maar ik wens je veel succes bij het opzetten van een on-prem wereldwijde CDN die bestand is tegen een DDOS aanval.

Overigens als je firewall uitvalt door de DDOS dan heb je niks aan de systemen erachter. Bedoel je niet dat interne systemen die niet via een firewall benaderbaar zijn het alsnog blijven doen?

[D11]

Wel als je die diensten zelf (intern) gebruikt. Niet als daarbij ook een internet verbinding nodig is (communicatie software bijvoorbeeld).

[david-v]

Er zijn maar weinig software pakketten die werken zonder dat je iets op internet kan doen. Je kan een mailserver intern hebben, maar als communicatie onmogelijk is dan heb je er ook niet zoveel aan, tenzij je met interne collega's gaat mailen

[jurroen]

Misschien heel flauw, maar afhankelijk van het bedrijf, de situatie en ook de positie: mails kun je alsnog behandelen. Wellicht wat achterstanf inlopen. De reacties kun je (afhankelijk van de mailserver en diens configuratie) verzenden waarbij de MTA het opnieuw probeert als de verbinding weer online is óf de reactie opslaan als concept en zelf verzenden als de boel weer up en running is.

[david-v]

Ook heel flauw, maar meer lokale Outlook cliënt en odfice365 werkt dat ook prima. De mails binnen in je outbox staan totdat er weer verbinding is met Office 365

Alleen systemen die volledig offline werken gaan vrijuit, denk aan besturing van machines of fabrieksprocessen. Maar zelfs dat is tegenwoordig al vaak gekoppeld omdat het veel makkelijker is om iemand remote te laten kijken als er problemen zijn dan dat ze moeten overvliegen of de auto in moeten stappen om na te gaan wat het probleem is.

[klakkie.57th]

O365 connectie maak je gewoon via een andere DC , via andere Provider die je enkel hebt voor dit soort noodsitutaties gebruikt. Het lijkt me sterk dat ze kunnen DDOSSen op de verbindingen tussen je datacenters die gebruik maken van verschillende operatoren op een gesloten netwerk

[kodak]

Argumenten als betrouwbaarheid van 'oplossingen' worden vaak gegeven op basis van het niet merken van onacceptabele gevolgen. Dat soort argument op basis van resultaten uit het verleden geven echter niet zomaar de werkelijkheid weer. Eerder juist niet, zeker als een bedrijf als Microsoft nauwelijks tot geen verantwoording af legt over de maatregelen die zo ondertussen wel/niet genomen hebben. Aan de andere kant heb je er als eigenaar van een eigen 'oplossing' juist wel heel veel inzicht in wat er dan allemaal niet zou voldoen, dus gaat het vergelijken al heel snel om problemen bij een leverancier pas proberen op te lossen als ze zich wel voor doen. En ondertussen kan je dan makkelijk gaan doen alsof het goedkoper is. Tot het een keer heel erg mis gaat door het te veel hebben gehoopt alsof je goed aan besparen doet om onwetend te zijn.

Niet voor niets moet tegenwoordig verpicht door financiële bedrijven aan klanten duidelijk gemaakt worden dat resultaten uit het verleden geen garanties geven. Is het al jaren in de medische wereld gebruikelijk te wijzen op risico's en niet slechts de mooie voordelen ingrepen kunnen geven. Het doen alsof prima vooral (of alleen) naar resultaten uit het verleden gewezen kan worden om liever een belangrijk product of service te (ver)kopen is geen redelijke handel. Er is transparantie nodig om te kunnen vergelijken en problemen te voorkomen. Niet het vooral doen alsof je goede bescherming krijgt als je niets merkt of dat het besparing lijkt te geven door verantwoordelijkheid af te schuiven.

[Reactie gewijzigd door kodak op 31 juli 2024 17:19]

[Andreplusplus]

Wat zoek je?
https://learn.microsoft.c...ure/compliance/offerings/

[kodak]

Je lijkt te bedoelen dat microsoft aan compliance doet en voor klanten extra wil doen als klanten daar gebruik van willen maken.

Het punt is dat wat Microsoft doet niet zomaar voor klanten genoeg is (hun disclaimer dat klanten zelf verantwoordelijk zijn staat daar niet voor niets bovenaan). En de klanten eisen zelf ook niet zomaar even goede of betere bescherming dan wanneer
men zichzelf regels oplegde. Die zelfde of extra eisen kost immers geld, wat men juist probeert te besparen. Hoeveel klanten van Microsoft gaan denk je nu eisen dat het bedrijf gedetailleerde uitleg geeft waarom de beveiliging tegen deze aanval niet werkte en in discussie of men dat al had moeten voorzien ?

Als je kan tonen dat Microsoft alleen maar gelijke of betere bescherming geeft dan wanneer klanten het zelf zouden regelen dan heb je een punt. Maar dat toont je verwijzing niet aan.

[Reactie gewijzigd door kodak op 1 augustus 2024 09:08]

[well0549]

Heb jij wel eens een rekening van Azure gezien.
Het is gewoon behoorlijk duur.

Helemaal als je hun leuke features gaat gebruiken, dan loop je behoorlijk leeg...

Ik werk bij een bedrijf waar je iedere maand een volledig opgetuigde hypervisor kunt aftikken bij ms.

Maar goed het verkoop praatje werkt....

Zelfs ik heb al prive meer aan ms over gemaakt dan dat een dikke laptop kost.

[Erwin1967]

Eenmaal gemigreerd naar de Cloud ben je volledig overgeleverd en afhankelijk. Dat weet Microsoft en een ding is zeker, de tarieven gaan alleen maar omhoog.

[david-v]

Heb jij wel eens een rekening van Azure gezien.
Het is gewoon behoorlijk duur.

Ja. Wat is duur? Is €600 per maand voor een sql server veel als je daarmee 50k gebruikers per dag kan bedienen?

Het is net zo duur als je het zelf maakt. Als ontwikkelaar kan je ook een 12 euro per maand kostende sql server hebben in de cloud. Traag, kan niet veel verbindingen tegelijk aan, maar voldoet voor ontwikkel werkzaamheden.

Het voornaamste probleem wat ik ervaarde met traditionele hosting is dat je voorbereid moest zijn op de pieken die je had. Dus als je pieken te verwerken kreeg gedurende het jaar moest je wel de hardware paraat hebben. Virtualisatie heeft daar wel enorm in geholpen maar die had ook grenzen aan wat je erbij kon schalen.

Ik moet ook toegeven dat je als DevOps team wel bewust moet zijn van de kosten die je maakt. Tijdens mijn eerste jaar bij een project heb ik de kosten met 2/3 kunnen terug brengen door de juiste dimensionering toe te passen en niet alleen gaan voor het duurste omdat dat het "beste" is.

Cloud is niet duurder (of goedkoper) dan self hosted. Het zijn de keuzes die je maakt die de prijs bepalen. Als je de elasticiteit van cloud goed kan inzetten dan denk k dat je een stuk goedkoper bent in de cloud, maar alles is afhankelijk van de keuzes die je maakt.

[well0549]

Ja Ja, een jij hebt zeker niet gehoord van de capaciteits problemen bij Azure West Europa...

Als je in het laatste kwartaal even resources bij wilt schalen is er grote kans dat dat niet gaat lukken.

En een stukje van je sql server in Noord Europa draaien gaat niet zo makkelijk.

Wij zijn door ms op de hoogte gesteld om hier in de toekomst voorlopig rekening mee te houden....

[david-v]

Ja Ja, een jij hebt zeker niet gehoord van de capaciteits problemen bij Azure West Europa...

Nee, nergens last van. Ook geen indicatie of mail van Microsoft gehad dat het voor ons een probleem zou zijn. Geen idee of er voor nieuwe klanten wel beperkingen zijn.

[well0549]

Nee ook bestaande klanten, sommige resources kunnen gewoon niet meer aangemaakt worden.

EU-West is one of the busiest Datacenters of Microsoft, they are currently expanding the capacity by building a new set of data centers next to the others. So on this moment they indeed might have problems with their current setup, I did not hear recently how they doing but I worked close together with one of the sales reps who was working for them during Covid and than they had huge problems as you described now.

En

this. Our MSFT rep told us the same thing... basicaly for new customers, not to recommend WestEurope because of capacity problems.

En
https://technology.amis.n...-well-this-region-anyway/

[Yzord]

Ook een onpremise omgeving kan een DDoS attack over zich heen krijgen.

Mijn oma dr pc ook. De vraag is, is dat wel interessant? Dus ja, een centralised cloudhub aanvallen is interessant. Want veel klanten.

Dus een onpremise omgeving kan zeker wel vele voordelen geven tegenwoordig. In een tijd van cyberwar is centralisatie het domste wat men kan doen.

[david-v]

Dus een onpremise omgeving kan zeker wel vele voordelen geven tegenwoordig. In een tijd van cyberwar is centralisatie het domste wat men kan doen.

Dus je denkt dat als alle gemeentes, provincies, universiteiten, scholen enz voor hun eigen security zorgen beter af zouden zijn bij ddos aanvallen dan een gezamenlijke aanpak?

Volgens experts is dat niet het geval

De NaWas is een mooi voorbeeld van centralisatie waarbij je juist weerbaarder bent als kleine organisatie tegen dit soort criminaliteit.

Dus nee, in een cyberwar is decentralisatie eigenlijk het domste wat je kan doen. Kop in het zand steken en hopen dat je niet aangevallen wordt is geen goeie strategie.

[GeroldM]

Heb jij ooit eens als soldaat in een actief slagveld rondgewandeld? Een machinegeweer springt niet zuinig om met kogels. En er is wel degelijk een limiet aan de hoeveelheid kogels je tegenstanders meezeulen om op jou groepje soldaten te gaan schieten.

Drie keer raden wat soldaten dus doen: schieten op de meest belangrijke doelen. Of schieten op de doelen die het meest "pijn" doen aan je tegenstander(s).

Deze analogie is 1-op-1 overzetbaar in het geval van een cyber-war. DDOS is het wapen en de kogels. En je richt deze op de plekken waar je het meeste schade aan je tegenstander doet.

De soldaten die de schermutseling overleven waren diegenen die er het minst belangrijk uitzagen. Maar die zien de resultaten van de schietpartij en verliezen daardoor moraal.

Decentralisatie levert veel kleine doelen op die zeer zeker niet allemaal even belangrijk zijn. Dus richten je tegenstanders hun DDOS aanval liever op een centrale plek waar je in 1 keer heel veel diensten onderuit kan halen.

Jij mag dan wel een andere mening daarover hebben, maar besef 1 ding: ga jij het veld in met jouw mening, sta er dan niet versteld van als jij door een gedemoraliseerde mede-soldaat in de baan van de kogelregens wordt geduwd. Jouw vervanging kan niet slechter zijn dan jij. Mocht dat wel het geval zijn...tijd voor nieuwe vervanging.

Veel doelen vereisen veel verschillende (kleinere) DDOS aanvallen, 1 centraal doel vergt 1 grote DDOS aanval. Daarnaast kunnen de personen achter een grote DDOS aanval zich op de borst kloppen, want zij hebben het voor elkaar gekregen dat ze een dienst als Microsoft onderuit hebben kunnen halen. Maar als zij een DDOS aanval uitvoeren op de website/service van bijvoorbeeld de kruidenier op de hoek, dan is slechts hoon hun deel.

Ach ja, jij gaat mij niet overtuigen en ik jou ook niet.

[Fr0zenFlame]

Inderdaad, de risico's liggen niet alleen op het vlak van regelgeving en juridische kwesties waarbij zaken kunnen worden afgedwongen, waardoor je volledig afhankelijk wordt.

Technisch gezien kan men het ook beschouwen als een "single point of failure (SPOF)." Ik begrijp dat on-premises omgevingen ook plat kunnen gaan door een DDoS-aanval, mede vanwege het feit dat dit over het algemeen kleinere omgevingen zijn met minder capaciteit of minder goede bescherming (vanwege kostenafwegingen). Een clouddienst zoals Azure beschikt over alle middelen, maar door (hypothetisch gezien) alle grote omgevingen in de cloud te draaien, wordt de IMPACT wel significant groter als het misgaat. In potentie kan je daarmee een groot deel van de infrastructuur of economie platleggen. Als je spreekt over een gerichte on-premises omgeving, is dat heel vervelend, maar worden slechts één, twee of misschien een paar bedrijven geraakt. Dergelijke grote cloudproviders zijn interessante doelwitten, zeker in het huidige klimaat.

[Reactie gewijzigd door Fr0zenFlame op 31 juli 2024 16:45]

[cariolive23]

Dat heeft als voordeel dat je mogelijk minder interessant bent om te worden aangevallen. Het nadeel is dat je waarschijnlijk niet de kennis en/of resources hebt om je te beschermen tegen aanvallen. En daar komt het dagelijks beheer dan nog bij. Alleen al de 24x7 bezetting met 2 man kost je minstens 10 medewerkers, vakantie en ziekte vereisen nog meer medewerkers. En of je nou veel of weinig werk hebt voor deze mensen, je moet ze wel betalen.

Tevens wil een eigen DC niet zeggen dat jouw uptime beter wordt. Grootste verschil is nog dat vrijwel alle downtime jouw eigen schuld is.

[Erwin1967]

Het beheer kun je ook afnemen van gespecialiseerde bedrijven. Het afnemen van 7x24 beheer is gewoon mogelijk en kost veel minder dan mensen in dienst nemen.

[cariolive23]

En dan heb je weer hetzelfde issue als dat je hebt met een cloud omgeving: 100% afhankelijk van anderen.

[mobrockers]

24x7 bezetting kost je niet per se 10 medewerkers. Een medewerker mag 14 dagen per maand standby draaien dus aan 4 man heb je in ieder geval volgens de wet genoeg.

[cariolive23]

Ik heb het over de fysieke aanwezigheid. Alle DCs die ik ken, zijn 24x7 mensen aanwezig.

[mobrockers]

Ah op die manier! Dat klopt, maar je hoeft natuurlijk ook niet meteen zelf een heel fysiek datacenter in te richten. Dat kan ook colocated waarbij je wel je eigen netwerk voorzieningen hebt bijvoorbeeld. Dan heb je de fysieke aanwezigheid vanuit de colo en voor je eigen 'virtual datacenter' standby.

[cariolive23]

En dan heb je weer een vergelijkbare afhankelijkheid als wat je met de cloud hebt: anderen beheren (een deel van) jouw IT infra

[mobrockers]

Ja, zeker mee eens.

[mmvs]

Eens. Al ben ik meer fan van hybride setups. Mocht er dan een stroom of Internet storing zijn op de locatie waar je servers staan, heb je de cloud om het over te nemen tot alles weer terug is.
en als er een storing is bij de cloud provider dan heb je eigen hardware waar je de data hebt draaien. Dus eigenlijk blijf je altijd operationeel

[david-v]

Je kan ook multicloud gaan, maar dat vergt nogal een investering en architectuur keuzes (lees een flinke hoeveelheid geld) voor storingen die eens in de zoveel jaar voorkomen gedurende x uur op één dag.

[mmvs]

Is ook een optie. Uiteindelijk moet je alles wegen naar kosten en baten. Maar voor sommige sector en is mutlicloud of hybride cloud zeker het overwegen waard.

Bijvoorbeeld: Alle ziekenhuizen gaan AWS gebruiken, en die valt uit (oorzaak onbelangrijk). In een mutlicloud of hybride setup blijft alles werken, maar met alleen AWS kunnen er letterlijk doden vallen omdat er geen terugval is.

Een terugval systeem is in sommige gevallen beter dan afhankelijk zijn van 1 cloud provider, in mijn opinie

[well0549]

Je blijft altijd een probleem houden, stel je gebruikt okta...

En dan lekker multi cloud en...

En dan krijgt okta een ddos...

[klakkie.57th]

Alleen is multicloud enkel mogelijk met “standaard” oplossingen. Microsoft doet zijn uiterste best om hun eigen sausje te verkopen en zodoende kun je geen kant op met je multicloud strategie.

[michelr]

In den beginne maakten organisaties spanden organisaties zich hiervoor nog in met contingency plannen, uitwerken offboarding scenarios, etc. Dat lijkt compleet afwezig, en gezien de gemiddelde hersteltijd is dat voor te stellen omdat zo'n uitwijkoperatie ook geen simpele operatie zonder consequenties is.

[david-v]

Ik weet niet hoe het bij jouw organisaties werkt, maar wij werken nog steeds met allerlei contingency, failover en offboarding scenarios. In veel sectoren is dat zelfs verplicht. Kijk naar de eisen van DNB bij financiële instellingen. Het maakt dan niet uit of je on-premise of in de cloud draait.

[GeroldM]

Maar is het dan niet vaak zo dat een organisatie SLA-contract bij een cloud-provider als contingency aanduiden? Bij een cloud-provider ben je echt niet de enige klant met een soortgelijk SLA-contract. En dan kun je er zeker van zijn dat er altijd een grotere klant voorrang krijgt met het vervullen van de SLA vereisten.

Want als puntje bij paaltje komt, is het simpelweg goedkoper voor de cloud-provider om jou te betalen/korting te geven op de dienst die je van hen afneemt, dan aan jouw contract te voldoen. Dus zit jij langer zonder infrastructuur om je inkomsten mee te genereren.

Of, als je diensten/producten levert aan klanten, een 'Nee' aan hen moet verkopen. Die gaan dan kijken naar jouw (directe) concurrent en als het daar net zo goed is als bij jou (met normale gang van zaken), dan gaat het je meer tijd en moeite en vaak ook geld kosten om die klanten weer terug te winnen. Als dat zowiezo al lukt, want jij hebt ze tenslotte een 'Nee' verkocht op het moment dat zij jouw 'Ja' hard nodig hadden.

Zit je in een business waar je met gemak 10 nieuwe klanten voor elke verloren klant kan krijgen, dan is een 'Nee' verkopen niet zo van belang. Is dat echter niet het geval, dan heb je gelijk een groot probleem en met een beetje pech zelfs een faillesement-aanvraag. En dat allemaal omdat je cloud-provider een keer zijn dag niet heeft.

[well0549]

Wat ga je dan voor authenticatie gebruiken, niets iets van die cloud vendors, dus kies je een andere authenticatie provider, een wat nou als zie die aanvallen met een ddos

[marcmiddendorp]

Ja man. Lekker terug naar de jaren 70.... Good old days .

[well0549]

Precies, alleen om Prem accès via het toetsenbord, nix netwerk

[jacobkap]

Ik werk niet bij Microsoft, maar ik weet toch vrijwel zeker dat dit soort services op een aangepaste versie van BSD of Linux draaien.

Bij Google Cloud draait de boel ook op een sterk aangepaste en geoptimaliseerde versie van Linux. Dat zal bij Microsoft niet veel anders zijn. Of dacht je echt dat een CDN als Frontdoor op een cluster Windows Server draaide met alle overhead die daarbij komt kijken?

[david-v]

Azure Front Door is gebaseerd op Windows-based proxy dus in die zin klopt het dat het op Windows draait. Echter, de nieuwe generatie Azure Front Door zal wel op linux gebaseerd zijn

[wildhagen]

Het OS heeft hier letterlijk niks mee te maken. Een DDoS attack kan elk systeem effectief platleggen, ongeacht welk OS het draait.

De verbinding wordt simpelweg overspoeld met packets. Of dat nu een Linux of Windows systeem is, de facto onbereikbaar wordt het toch wel.

[Justin0017]

Ik kan het mis hebben maar volgens mij draait een groot gedeelte van Azure al op Linux.

Geen enkel systeem is 100% storingsvrij. Helaas hebben we hiermee te maken in ons vak.

[Visgek82]

Nergens voor nodig.

Niets is immers immuun voor een DDOS aanval.

[hermanbrood]

Azure Frontdoor wordt al tijden geleverd vanaf een Linux Platform. Wat is dan nu je advies? Terug naar de aloude Windows proxy waar Frontdoor mee begon?

[Reactie gewijzigd door hermanbrood op 31 juli 2024 16:53]

[PageFault]

Jammer dat die spullen nooit op Linux draaien

[Japie api]

Reactie op verkeerde persoon

[Reactie gewijzigd door Japie api op 31 juli 2024 18:50]

[Japie api]

CrowdStrike heeft een paar maanden , ik dacht in april, geleden ook Linux versies plat gekregen, kernel panics , dus het heeft niet alleen voordelen.

[SuperDre]

Voor het geval je het nog niet wist, veel Azure backend is al linux.

[SilentDecode]

En jij denkt dat Linux niet kwetsbaar is? En jij denkt dat Azure niet deels op Linux draait?
Droom lekker verder.

Ik ben een Linux fan, draai het op m'n desktop, m'n laptop en bijna al m'n servers, maar ook ik weet dat Linux kwetsbaar is.

[ShadLink]

99% van Azure draait op Linux

[david-v]

je wordt gedownmod maar er zit wel een kern van waarheid in je statement, al weet ik niet of je dat zelf beseft of niet

Azure Front Door, originally built upon a Windows-based proxy, has been a critical component in serving and protecting traffic for Microsoft’s core internet services. As the commercial offering of Azure Front Door expanded, and with the ever-evolving landscape of security and application delivery, we recognized the need for a new platform. This new platform would address the growing demands of scale, performance, cost-effectiveness, and innovation, ensuring we are able to meet the challenging scale and security demands from our largest enterprise customers. For our next-generation Azure Front Door platform, we opted to build it on Linux and embrace the open-source software community.

en

Why Linux and Open Source?
A key choice that we made during the development of the new proxy platform was to use Linux as the operating system for the proxy. Linux offers a mature and stable platform for running high-performance network applications and it has a rich ecosystem of tools and libraries for network programming which allows us to leverage the expertise and experience of the open-source community.

bron

[Rinzwind]

En Windows heeft dat niet zonder het expliciet te noemen? Rare keuze van Microsoft.

[PowerToTheUsers]

Linux offers a mature and stable platform for running high-performance network applications

Hoewel er Microsoft proxy servers waren, en hoewel de Windows servers uiteraard ook wel een network stack hebben, zullen ze de specifieke services die nodig zijn in network appliances beter/performanter/stabieler/matuurder zijn in Linux dan in Windows.

[cariolive23]

Hoezo logisch? Sinds jaar en dag draaien zij honderdduizenden Linux servers en leveren zij bijdragen aan vele open source projecten.

Wat ik logisch zou vinden, is dat je eerst gaat uitzoeken op welk OS een dienst draait of dat je die vraag gaat stellen. Maar zomaar wat roepen zonder enige onderbouwing, dat is nou net niet logisch.

[Blokker_1999]

Omdat het niets bijdraagt aan heel de discussie. Het OS staat grotendeels los van dit probleem. Het komt over alsof je gewoon wenst te zeggen: Windows is slecht, Linux is goed, alles moet naar Linux. Je geeft geen enkele onderbouwing voor waarom dat een verbetering zou zijn.

[michelr]

Vermoed het ook; inhoudsloos bashen van leveranciers/producten is misschien wel leuk voor enkelen, maar Tweakers kunnen beter.

[ArcticWolf]

Misschien eerst even inlezen hoe zaken wel werken voordat je gaat wijzen?

[SED]

Dus nu je weet dat het op linux draait gaat je stelling ineens niet meer op?
Fanbois gedrag oast niet in een serieuze discussie.

[PageFault]

Azure draait geen Windows

[Blokker_1999]

En nu maak je dezelfde fout opnieuw. Opnieuw zeg je, zonder enige onderbouwing, dat het de schuld is van Windows en dat, had men Linux gebruikt, dit absoluut niet zou gebeurd zijn. En dan zeg ik opnieuw: onderbouw het eens in plaats van met een eenvoudige oneliner af te komen. Toon eens aan dat bijv. hun DDOS mitigatie op Windows draait. Want ik acht die kans bijna 0. Zo een verkeer mag nooit tot in de buurt van een server komen, dat wil je zo vroeg mogelijk in je netwerk stoppen, liefst al bij de firewall. En tenzij MS zijn eigen edge firewalls bouwt met Windows, wat ik ten sterkste betwijfel, gaat Windows hier niets mee te maken hebben.