TCP DDoS mogelijk door non-conforme firewalls/netwerk apparatuur
Reflection/amplification attacks mogelijk via TCP, voorheen werd gedacht dat het alleen via UDP kon. 200 miljoen kwetsbare devices (die dus gebruikt kunnen worden voor deze aanval) gevonden op het internet), gebruikelijke versterking 2 tot 10 met uitschieters tot 100.
De reden dat TCP implementaties tegenwoordig een sterk random sequence nummer gebruiken bij het begin van een
nieuwe connectie (in plaats van een interne variabele te gebruiken die bijvoorbeeld oploopt met de tijd of met het aantal
gemaakte connecties) is juist in verband met dit probleem. Als je niet weet welk sequence nummer de andere kant gaat
gebruiken, en je ontvangt dit niet omdat je het source adres gespoofed hebt, dan kun je ook geen geldige connectie
faken op deze manier.
Wellicht is er hier en daar nog een apparaat van een fabrikant die al 20 jaar niet zit op te letten wat hier gevoelig voor
is, maar veel zal het niet zijn want de meesten gebruiken Linux en daar is het al jaren in gefixed.
Het enige wat werkt is die truuk met SYN waarop de andere kant dan een paar keer SYN+ACK terug gaat sturen, maar
hoe vaak dat kun je zelf tweaken in de sysctl.conf als je je daar zorgen over maakt. Ik zet dat meestal op 2.
Reflection/amplification attacks mogelijk via TCP, voorheen werd gedacht dat het alleen via UDP kon. 200 miljoen kwetsbare devices (die dus gebruikt kunnen worden voor deze aanval) gevonden op het internet), gebruikelijke versterking 2 tot 10 met uitschieters tot 100.
Het feitelijke paper :
https://www.usenix.org/system/files/sec21fall-bock.pdf
Wel een hoop randvoorwaarden - het gaat om firewalls (ze noemen vaak nation states, oftewel great firewall of china e.d.) die een HTTP block injecteren in een sessie *ook als ze maar de halve tcp sessie zien* .
(en de bron als clickable link - mensen, leer die URL tags ... https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/ )
https://therecord.media/firewalls-and-middleboxes-can-be-weaponized-for-gigantic-ddos-attacks/
Waarom doe je die kleine moeite niet even? Je wilt toch dat mensen kennis nemen van dat artikel?
De reden dat TCP implementaties tegenwoordig een sterk random sequence nummer gebruiken bij het begin van een
nieuwe connectie (in plaats van een interne variabele te gebruiken die bijvoorbeeld oploopt met de tijd of met het aantal
gemaakte connecties) is juist in verband met dit probleem. Als je niet weet welk sequence nummer de andere kant gaat
gebruiken, en je ontvangt dit niet omdat je het source adres gespoofed hebt, dan kun je ook geen geldige connectie
faken op deze manier.
Wellicht is er hier en daar nog een apparaat van een fabrikant die al 20 jaar niet zit op te letten wat hier gevoelig voor
is, maar veel zal het niet zijn want de meesten gebruiken Linux en daar is het al jaren in gefixed.
Het enige wat werkt is die truuk met SYN waarop de andere kant dan een paar keer SYN+ACK terug gaat sturen, maar
hoe vaak dat kun je zelf tweaken in de sysctl.conf als je je daar zorgen over maakt. Ik zet dat meestal op 2.
Ik zou zeggen: verdiep je eerst eens in het artikel, en kom dan tot de conclusie dat het iets heel anders is dan jij denkt. Het gaat om een reflection, dus het sequence number is irrelevant voor degene waar het antwoord naar toe wordt gestuurd. Het gaat om network devices die zich NIET aan de standaarden houden, en een antwoord sturen ZONDER de tcp handshake. Voorbeeld: the Great Firewall of China. Prima te misbruiken voor een volumetrische tcp DDoS waarvan jij denkt dat die niet kan vanwege juist die standaard tcp handshaking.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.