”Historiens största DDOS-attack” stoppad på minuter av Cloudflare, Google, Microsoft och Amazon

Märkte inte ens av det, rätt skönt att dom här stora blockar åt en

Edit: attacken är nu alltså säkrad vad jag förstått, och det är därför som de här stora bolagen kan släppa sina blogginlägg. Attackerna skedde i augusti.

Sånt här är kul att läsa om, mer sånt

Ah, så sant. Smart tänkt där. Ddos används väl primärt för att påbörja andra attacker?
Sitter med OWASP just nu o sett sammanfattningen för det kapitlet men inte läst det än

Jag förstår inte riktigt varför det inte går att sätta två enkla spär?
1) Alla anrop behandlas i turordningen. Verifieras inte anrop (avbryts den omedelbart), så går servern vidare till nästa anrop utan att slösa resurser på föregående.
2) Man ska sätta gränsen för hur många anrop per tidsenhet servern får ta och behandla. Överskrids gränsen, kastas alla extra anrop i en kö, som behandlas enligt punkt 1.

Och blir det enormt många anrop, kan man ordna en redirect till en enkel sida där det ska stå typ:
Det verkar som att vi är väldigt populära idag och har för stor tryck på våra servrar. Var god och försök lite senare.

Precis, heter ju denial of service av en anledning.

Jag menar inte att man ska sätta gränsen på 1 förfrågan per en sekund. Min tanke var att om blir det för högt tryck, skulle servern själv känna av det och vidta åtgärder för att inte krasha. För i vissa fall servrar förlorar mycket information som är viktigt.

Så man kan lägga till flera alternativ till det jag har redan skrivit. T.ex minska maksimala antal förfrågningar till 75-80%, tillfälligt spärra parallella förfrågningar som kan öppnas för den enskilda "förfrågare" igen efter verifiering/validering. Eventuellt tillfälligt spärra några "förfrågare" om de inte har passerat verifiering. Dubbla köer, en för verifierade användare och en för okänd.

Som sagt, det finns massor med lösningar. Som jag kom på bara så här, och jag är inte ens it tekniker...

Låter egentligen som en lätt grej att fixa. 1. Hålla reda på öppna connections/clienter och ge dem max N streams.
2. Se om nån client efterfrågar onormalt många streams = block

Nog bättre man håller tyst om man inte kan tillhandahålla en konstruktiv kritik eller ett bra exempel som kan förklara problematiken, istället för man skriver en taskig kommentar

Ibland en icke standard lösning kan hålla skurkar på ett bra avstånd.

1) Jag tänkte bara att undvika värsta scenariot, då serveromstart kan medföra oanade konsekvenser typ information förlust eller information stöld, självklart att informationen är inte tillräckligt kan också vara kritisk, beroende på informationen.
Det var en gång en chef på en stor varuhuskedja som en vacker dag "märkte" att alla datorer i hans butik hade blivit för slöa, så han gick in serverrummet och restartade servern i slutet på arbetsdagen... Jo men så gör man med datorer hemma.... Två IT-tekniker höll på en hel arbetsdag för att få igång den.

2) Men det bör finnas något sätt att urskilja "falska" anrop, och knyta fast dem till en specifik ip-adress och spärra den (åtminstonde tillfälligt) så att servern inte ens slöser beräknings resurser för att svara på förfrågningar med detta specifika ip-adress?

3) Så att en av dem enklaste (men också dyraste) lösningar mot sådana attacker är "system överdimitionering" som kan hantera abnorma överbelastningar.
Jo som sagt Brute force mot brute force det funkar, men det är kanske inte den bästa lösningen.

Ps: tack för ett erforderlig förklaring av problematiken.

Jag ber om ursäkt. Jag är faktiskt exakt likadan. Vid en första anblick verkar många problem väldigt enkla när man inte förstår dem. Jag tycker dessutom det är ett ganska givande sätt att få bättre förståelse om man har någon kunnig men tålmodig att diskutera med, dvs man föreslår en lösning, får förklarat varför den inte fungerar, föreslår en mer komplicerad modifierad variant och får återigen en förklaring på varför den inte heller fungerar, osv.

Men beror mycket på hur man lägger fram det också. Om det låter som att man tror att man faktiskt löst någonting, eller om det låter som att man försöker förstå varför en lösning inte fungerar eller vad det är som gör problemet svårare än man tror.

Iaf har du ju fått förklaringar i tråden från folk som säkert kan mer om det hela än mig.

Ursäkten tagen, inget surt minne.
Min vision är bara att det bör finnas lösningar för alla problem. Att lösningen inte finns vid den specifika tidpunkten betyder endast att ingen kom på denna lösning ännu. Det finns inget omöjligt.

Ett bra exempel är en historia om en student som kom till en matte lektion för sent, typ precis en minut det tog slut. Har tittade på tavlan och upptäckte 2 matematiska ekvationer som han tog för givet var hemläxan som skulle lösas. Han skrev ner dem och gick hem. Under helgen satte han sig och började greja med formler, men de kluriga ekvationer såg ut som att inte ville bli lösta. Men killen ville ge upp och till slut knäckte han båda ekvationer. Måndag där på kom han i tid till mattelektion för att diskutera med läraren denna hemläxan. Läraren blev förvånad då de två ekvationer på tavlan som killen skrev ner inte var en hemläxa utan "två icke lösbara problem" som matematiker runt hela världen försöker att lösa för runt 160 år (kan vara 180, kommer inte ihåg exakt). Så läraren trodde att studenten hade gjort något fel och fick ett svar som såg rimligt ut. Men efter att allt blivit kontrollerat (och troligen inte bara en gång) visade det sig att killen hade rätt. Den killen hette George Bernard Dantzig och blev en väldig känd matematiker.

Man skall inte sätta gränserna för tidigt

1) Jo jag förstår tanken, dock är moderna webb-system (och här pratar vi om webbservrar) väldigt ofta byggda på så sätt att de kan startas om utan problem. Inte sagt att det alltid kan vara problemlöst utan mest att det finns fler scenarier i en denial of service än just en serverkrash.

2) Inte alltid, om vi pratar om en kvalificerat skapad DDoS så ska de se ut och agera exakt som vilken annan request som helst. I just det här fallet dock så handlade det om att utnyttja ett hål i http/2 så där går det ju att filtrera men då ska vi utanpå allt detta också behöva en filtermekanism som klarar av den enorma trafiken (så risk finns att filtret blir en sak till som kan leda till denial of service). Matcha mot specifik ip går inte då detta är en DDoS och inte DoS (dvs det extra D:et innebär att attacken är distribuerad, dvs vi pratar om miljoner med zombie-maskiner på nätet som gör dessa requests, inte några enskilda maskiner (det hade varit en vanlig DoS attack, inte en DDoS)).

Dvs du ensam stå i kassan till ICA och hålla den upptagen för att hindra andra från att köpa är en DoS. Men om du får 10M med människor att fylla hela ICA inkl parkeringen utanför är en DDoS, och storleken på just denna DDoS var i graden av att du lyckas fylla hela motorvägen och alla avfarter med "ditt folk" också som bara står still och hindrar människor från att besöka detta ICA. Att filtrera lokalt är ju då som att försöka lösa detta genom att inne i detta ICA kolla om det ser ut som att folk handlar på riktigt eller inte och kasta ut de som inte gör det.

3) Det är ofta den enda lösningen. Tänk dig själv att du har 2x10Gbps anslutningar till den serverhall men att attacken är 200Gbps i omfattning. Då kvittar det ju vad du än gör på din sida för det finns inte en enda riktig användare som kommer att ha en chans att komma in förbi eftersom det står 10ggr så många och vill in. Tänk det lite som att försöka lösa kö-problemet långt inne i affären vid en black-friday i USA när det står 10k folk i kö utanför din affär. Google mfl kan hantera detta för de har långt mer än 200Gbps så _de_ kan applicera filter mm på datan innan de skyfflar den vidare in till de bolag som hyr plats i deras moln, men vi andra dödliga kan ju inte göra sådana enorma investeringar precis som du skriver, men det skiter ju angriparen stort i, eller rättare sagt det är ju vad de räknar med.

ett exempel på att man kan få DDoS-verkan är tex inloggning via SSH med password. Där har man keystreching någonstans i kedjan, inte nödvändigt just SSH-daemonen utan i linux/unix passwordshantering med en bunt hundra tusen olika re-hashes för var inloggningsförsök för att en läckt shadow-fil skall vara svår att attackera och få ut passworden i klartext genom att prova sig fram.

en sådan re-hashes cykel kan belägga en CPU med bara att göra hashvärden i kanske någon eller ett par sekunder innan den säger att inloggningen lyckas eller misslyckas per försök - och liknande har man på TLC/SSL för inloggning hos Webbservrar.

med andra ord en fientlig inloggningsförsök efter varandra hela tiden som ligger på SSH-porten eller port 80 för webbservrar och sedan förhandla om en https: (även om det avbryts lite senare avsiktligt) kan käka upp alla resurser på en serven väldigt fort och den valida användaren ligger i kö med kanske 1000 fientliga anrop före som håller porten upptagen hela tiden och det upplevs som dålig respons på server eller att det inte går att logga in alls innan någon timeout kastar ut dig igen och det hela tiden fylls på med nya fientliga anrop.

För tex SSH kan man stänga av inloggning via användare/password och bara acceptera inloggning med SSH-nycklar.

SSH-nycklar är utformade på sådan sätt att medans kodsträngen matas in (istället för password) så har det ett antal checkpunkter - säg liknande checksummor - som kontrollerar att det som matas in hänger ihop och stämmer med användarkontons publika SSH-nycklar innan det går nästa steg i förhandlingen och gör det inte detta så stängs porten för användaren och kickas ut (och kanske tom IP-bannas om det försöker mer än 3-5 ggr om man har sådan demon som sköter detta)[1]. Med en sådan lösning så kan det beta ha många hundra fler anrop i sekunden, ja kanske tusentals gånger fler anrop på samma tid än när man har en passwordsbaserad inloggning med 1-2 sekunders re-hasning per inloggningförsök med password.

[1] men det fungerar inte på en dagens DDoS-attack då det kan komma ifrån miljoner av olika kidnappade datorer från hela världen som duggar in och bara gör en enda försök precis som en användare just för att det inte skall bli IP-bannade eller väcker intresse från en eller flera stora nätaktörer som cloudflare mfl.