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

Door , , 91 reacties

Een onderzoeker heeft een nieuwe methode ontdekt om met een enkele computer een succesvolle denial of service-aanval op een server uit te voeren. Normaal gesproken is de bandbreedte van aanzienlijk meer pc's nodig voor een aanval.

De onderzoeker, Sergey Shekyan van Qualsys Security Labs, heeft inmiddels een proof of concept ontwikkeld dat gebruikt zou kunnen worden om vanaf één computer een server plat te leggen. Bovendien, zo stelt de onderzoeker, is de kans om ontdekt te worden tijdens de aanval erg klein.

Shekyan noemt zijn aanvalsmethode de Slow Read-aanval en heeft eerder deze week de werking ervan uit de doeken gedaan. Door misbruik te maken van een eerder ontdekte kwetsbaarheid in het tcp-protocol kan een aanvaller zelf invloed uitoefenen op de snelheid waarmee een server de gegevens probeert af te leveren. Tijdens dit proces controleert de server echter ook continu of het systeem van de ontvanger, in dit geval dus de aanvaller, al klaar is om meer data te ontvangen. Hierdoor loopt het geheugen van de server vol met data die nog verzonden moet worden, waardoor er uiteindelijk geen resources meer beschikbaar zouden kunnen zijn om legitieme bezoekers toegang tot de site te geven.

Om de aanval met succes te kunnen uitvoeren is het volgens Shekyan nodig om de send buffer size van de server te weten omdat tcp deze waarde niet zelf vrijgeeft. Voor de meeste servers staat dit echter ingesteld op een standaardwaarde tussen de 65 en 128kb. Ook moet de response van de server groter zijn dan die send buffer size, wat volgens de onderzoeker met de hedendaagse omvang van webpagina's niet echt een probleem zal zijn.

In potentie kan de ontdekking van de onderzoeker verstrekkende gevolgen hebben. Hoewel er voor zover bekend nog geen tools zijn die deze manier misbruiken om servers aan te vallen, is de kans dat deze ontwikkeld zullen worden groot.

De aanvalsmethode werkt in ieder geval op standaardconfiguraties van Apache, nginx, lighttpd en IIS 7.5. Echt goede verdedigingsmechanismen zijn er volgens Shekyan niet, anders dan niet zomaar persistent connections en http-pipelining toe te staan op de server en de absolute connection lifetime te beperken tot een realistische waarde.

Moderatie-faq Wijzig weergave

Reacties (91)

Er is een eenvoudige oplossing voor dit probleem. Een oplossing welke de grote sites als Twitter, Facebook maar ook Wegener, Telegraaf enzovoort al een poos geleden geïmplementeerd hebben: Varnish.
Dit is over komen waaien vanuit Noorwegen (waar elke webhoster dit inmiddels toepast) en wordt steeds meer over de hele wereld gebruikt. Varnish koppel je aan poort 80, daar komen je requests op binnen. Vervolgens stuurt Varnish de requests door naar bijvoorbeeld Apache, nginx, enzovoort. Varnish is gratis en kun je op https://www.varnish-cache.org/ downloaden.
Eenmaal geïnstalleerd en geconfigureerd, kan Varnish gemakkelijk tot maximum van je netwerkkaart aan requests aan, zonder een zichtbare verhoging van de load.
Dit heb ik diverse malen op mijn eigen serverpark getest: na gelinkt te worden op GeenStijl een paar keer, kon ik gemakkelijk 400 tot 700 unieke bezoekers per seconde aan, met een load van 0.06 tot 0.12, en dat op een enkele server, VPS zelfs.
Varnish beschermt ook tegen dit soort aanvallen: het is me nog niet gelukt om met deze tool mijn eigen websites plat te krijgen.
Mijn config voor Varnish vind je op http://www.hansvaneijsden.nl/conf/default.vcl en dan nog een belangrijke tip: zet ook Varnish voor je Shoutcast server, mocht je die hebben. Die zijn ook extreem kwetsbaar voor deze DoS..!
Er is een eenvoudige oplossing voor dit probleem. Een oplossing welke de grote sites als Twitter, Facebook maar ook Wegener, Telegraaf enzovoort al een poos geleden geïmplementeerd hebben: Varnish.
Het klikt ook als iets wat in elke goed gebouwde load-balancer wel af te vangen valt.

Je loopt alleen wel het risico dat je ook legitieme verbindingen op trage uplinks afkapt, of dat je bandbreedte die je aan de clients aanbiedt eronder te lijden krijgt.

Vroeg of laat zul je namelijk nog altijd op het aantal gelijktijdige verbindingen of requests per seconde moeten gaan throttlen.
Legitieme verbindingen op trage uplinks afkappen is juist wat Varnish niet doet, IMHO. Throttlen is ook nergens voor nodig en zelfs niet wenselijk.

Varnish benadert hardware op een heel nieuwe, efficiëntere manier. Requests per seconde is met Varnish niet langer een serieuze beperking. Zie onder andere http://kristianlyng.wordp...ing-varnish-even-further/ voor bevindingen, was nog met een hele oude versie zelfs (dit kan ik ook zelf onderschrijven).

Overigens, ik wil niet betweterig over komen hoor haha, wil gewoon informeren, tips geven en mensen helpen - zodat het wiel niet opnieuw uitgevonden hoeft te worden.

Sowieso heb ik dit in mijn Varnish config staan:
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&
req.request != "OPTIONS" &&
req.request != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
Ik denk dat dat ook al aanzienlijk de overige andere rare requests buiten de deur houdt. ;)

[Reactie gewijzigd door Hans van Eijsden op 8 januari 2012 02:43]

hah, varnish is idd de oplossing die ik hiervoor al een tijdje gebruik ;-). Na de eerste geruchten rond dergelijk tcp-stack issue heb ik toch maar het zeker voor het onzekere genomen en der wat research rond gedaan.
Ondertussen staat het tussen al men klanten en hun web (op enkele uitzonderingen, die wat vreemde headers nodig hebben voor hun blablabla :p ).
Mss kan ik ze eens een live demo geven en hun op die manier overtuigen om juist om te gaan met HTTP headers ;).
Spijtig om te lezen dat Tweakers achter de feiten aanloopt. Dit nieuws was al veel eerder bekend. In ieder geval als je je bezig houdt met informatie beveiliging. Er schijnen ook geruchten te zijn dat er een pakket is ontworpen - Xerxex - waarmee deze exploit ook is toegevoegd en het mogelijk is om diverse kwetsbaarheden in IIS en Apache uit te buiten.

Meer informatie via Sam Bowne op het LayerOne security conference on May 28, 2011.i

Bronnen:
http://www.youtube.com/watch?v=K1tHLgznNDo
http://www.youtube.com/wa...er_embedded&v=OXn-adAWgog
Er zijn allerlei aanvalstypen gebaseerd op slome requests/clients die in diverse varianten soms wel en soms niet geschikt zijn om vanaf 1 host een server compleet onderuit te halen.
Maar dat zegt nog niet dat dit specifieke type aanval uit dit nieuwsitem al langer bekend is. Sowieso als Xerxex specifieke exploits voor Apache misbruikt is het blijkbaar een andere, want de hier genoemde lijkt me meer een tcp of OS-exploit dan een die echt heel specifiek voor een webserver geldt. Het helpt uiteraard niet mee dat Apache een behoorlijk beperkt aantal clients tegelijk kan bedienen.

Het is overigens erg lastig om die typen aanvallen te herkennen en vervolgens te blokkeren. Domweg sloom verkeer blokkeren is een leuk idee, maar het is lastig te onderscheiden of iemand expres of per ongeluk traag is; het is niet erg leuk voor mensen die op de grens van een 3G-gebied met hun mobieltje of vanuit Afrika proberen je site te bekijken om geblokkeerd te worden doordat de ondergrenzen te hoog of timeouts te laag staan...
Onder het genot van een heerlijk rustig muziekje vind u hier een demo:
http://www.youtube.com/watch?v=Jq1nDEuvGjg
Het idee erachter was al langer bekend.

2007
http://www.securityfocus.com/archive/1/456339/30/0/threaded

Het is ook beschreven in: "Programming Model Attacks" in de Apache security sectie uit 2005.
Tijdens dit proces controleert de server echter ook continue of het systeem van de ontvanger, in dit geval dus de aanvaller, al klaar is om meer data te ontvangen.
Dat is dus een hele gemene, want je kunt, mochten ze je traceren, gewoon zeggen dat je problemen had met de computer?
Een kleine windowsize duidt op:
A. Een dun lijntje tussen jou en de server
B. Een instabiel lijntje tussen jou en de server

Dus zou ik eerder zeggen dat je ISP knudde is, en dat jij er ook weinig aan kan doen.

Overigens, volgens mij zijn HTTP-servers niet de enige servers die hier gevoelig voor zijn. Als je het achterliggende document leest, is het meer een exploit op tcp, en zijn andere op tcp-gebaseerde applicaties er vatbaar voor :P
Het gaat om de combinatie van heel traag lezen, grote antwoorden en een connection pool.
Ik kan me zo voorstellen dat allerlei DBMS'en hier ook last van hebben, al staan die meestal niet naar buiten open :P

Edit: voorbeeldjes enzo.

[Reactie gewijzigd door Hadron op 7 januari 2012 11:29]

Inderdaad, alle TCP-gebaseerde diensten zijn hier vatbaar voor.

In feite ben ik verbaasd dat het nog zo lang heeft geduurd voor dit probleem "ontdekt" is: de Linux firewall, iptables, heeft al jaren een target die exact dit doet. De TARPIT target accepteert een inkomende verbinding, zet de window op 0 bytes en sluit de verbinding stilletjes aan één kant. De client blijft de verbinding open houden tot deze tegen een tcp timeout aanloopt, wat volgens de docu 12-24 minuten zou duren.

Iptables doet dit echter niet als aanval, maar als verdediging.
Die functie in iptables werkt de andere kant op. Bij iptables is het de server die de client bezig houdt, op poorten waar het niet hoort te zijn, en deze aanval is een client die een server bezig houdt.
Totdat er gecontroleerd wordt hoe snel je computer daadwerkelijk internetdata kan ontvangen. Dan kom je er niet zo makkelijk van af. Zekers niet als het een "schuldig tenzij onschuld bewezen" zaak wordt.
Niet echt Je kan namelijk vrijwel niet bewijzen dat alle computers tussen jou en de aangevallen server precies hetzelfde waren tijdens de problematische request en de "snelle" data. En TCP is robuust maar garandeert geen correcte bezorging van pakketjes.

Dus een reactie als "Huh, nu doet ie het wel??????" is moeilijk onderuit te halen.
En TCP is robuust maar garandeert geen correcte bezorging van pakketjes.
Dat garandeert TCP dus juist wél (en is één van de oorzaken van deze kwetsbaarheid): Door aan de client-kant te controleren of alle pakketjes in volgorde en correct aangekomen zijn, en dan pas nieuwe data vragen.

TCP garandeert alleen niet dat pakketjes op tijd aankomen. Als je lijn dus overbezet is of er is aan de server- of client-kant een opstopping, dan wordt er geen data meer verzonden en is dat 0-byte window niet alleen nuttig, maar juist nodig om ervoor te zorgen dat de server je niet met data blijft doodgooien.
Standaard KeepAlive timeout van Apache staat op 100 seconden. Tijd zat om alle (doorgaans 100 threads) aan je toe te eigenen en bezet te houden.
Dan zou je hopen dat er weinig productieservers op de standaard configuratie draaien, maar helaas.
Standaard KeepAlive timeout van Apache staat op 100 seconden.
Dat is niet wat ik in de handleiding zie: http://httpd.apache.org/d...ore.html#keepalivetimeout

Volgens de handleiding staat hij standaard op 5 seconden.

Die 100 seconden zal je *NIX distri dan wellicht gedaan hebben. Of je haalt het door de war met: http://httpd.apache.org/d...html#maxkeepaliverequests welke standaard wel op 100 staat (maar niet dezelfde impact heeft als keep alive time out).

[Reactie gewijzigd door JUDGExKTF op 7 januari 2012 11:36]

Heb even mijn vps met ubuntu gecheckt, die staat default op 15 seconde en 100 connections.
Dat is dan ook een volstrekt belachelijke waarde voor een beetje server. Ergens in de orde van 1-3 seconden is al een stuk beter.
Volgens mij ligt het niet zozeer aan Apache, maar aan de TCP stack zelf. Het is een exploit in het TCP protocol. Dat is veel erger, want dat betekent dat mogelijk de firmware in routers vulnerable is, en die patch je niet zo makkelijk even overal.
Systems Affected

Generally, any system or product that implements or uses TCP could be affected by this vulnerability, depending on how the product handles resource exhaustion and TCP connections in persist. By design, TCP does not inherently defend against denial-of-service attacks based on resource exhaustion. Decisions about how to detect and respond to such attacks are the responsibility of individual systems or products.
Ja die tools die komen er nu dus wel...
Dit kon vroeger toch ook al op/tegen een ouwe win95/98 machine?

De truc was toen om een tcp/ip pakketje een stuk meer data mee te geven dan in de header vermeld werd, waardoor je netwerkverbinding onderuitging.
Ja, bugs zijn van alle tijden. Wat jij omschrijft is echter een ontwerpfout van een specifiek software pakket, en daardoor 'niet zo erg'. Destijds was dat zelfs waarschijnlijk redelijk te filteren door een niet-windows firewall, en/of te patchen door MS.

Deze nieuwe kwetsbaarheid zit in het ontwerp van het netwerkprotocol, en is daardoor toepasbaar op allerlei configuraties. Daardoor is de mogelijke impact van deze bug echt enorm.
Die nieuwe kwetsbaarheid zit toch helemaal niet in het netwerkprotocol? Vele IRC servers hebben beperkte send en recv queue. Ga je er over wordt je connection gesloten. Waardoor deze methode van aanvallen niet werkt lijkt mij.

En is trouwens een DoS aanval niet altijd afkomstig van 1 PC?
Anders spreek je toch over een DDoS aanval?
Die nieuwe kwetsbaarheid zit toch helemaal niet in het netwerkprotocol? Vele IRC servers hebben beperkte send en recv queue. Ga je er over wordt je connection gesloten. Waardoor deze methode van aanvallen niet werkt lijkt mij.
Dus wel. Als je receive queue die je naar de server aanbiedt nul is (ofwel: je vertelt de sever: "mijn verbinding is op het moment even vol, wacht even met zenden!") terwijl je wel ACKs terugstuurt (pakketjes die zeggen: "Ik heb de vorige data prima verwerkt, zet maar nieuwe klaar!"), dan gaat die server op zijn gemakje het geheugen vullen met gegevens omdat het protocol het voorschrijft.

Er is geen functie in TCP die aan de zendkant throttling implementeert, dus een pakketje waar de server kan zeggen: "Ho even met vragen, ik kan geen data meer voor je klaarzetten."). TCP gaat er namelijk braaf van uit dat het onderliggende besturingssysteem zoiets wel af zal handelen als het geheugen vol is -- maar dan is het natuurlijk al te laat.

Je verbinding afkappen bij een volle send/receive queue werkt misschien wel voor IRC servers omdat daar de hoeveelheid data erg klein is in verhouding met webservers, die makkelijk MB's per seconde moeten kunnen zenden. Als er dan een (legitieme) verbinding onverhoopt wordt afgekapt omdat er te veel data in het geheugen wordt geladen, is dat natuurlijk niet de bedoeling.

Bovendien is het aanbieden van een 0-byte receive window een perfect legitieme actie. Het wordt vaak gedaan als een client in de toekomst nog data nodig heeft maar geen tijd heeft om een verbinding af te breken en weer op te bouwen. Dan wordt er om de zoveel tijd een ACK gestuurd van 1 byte (hee, ik heb 1 byte verwerkt, ik ben er nog!) zodat de server de verbinding niet onverhoopt dropt.

Een bekend voorbeeld is een FTP-server waar je client-side door de bestandslijst aan het bladeren bent, maar je alleen nieuwe data wil hebben als je een andere directory op wil vragen.

Daarom is het ook zo moeilijk om je tegen deze aanval te verdedigen, omdat je veel te veel risico hebt op collateral damage als je 'zo maar even' verbindingen af gaat hakken omdat je een DoS attack vermoedt. Het kan bijvoorbeeld ook resultaat zijn van netwerk-verstopping (congestion), net zoals een file op de weg spontaan kan ontstaan of een resultaat is van een protest-actie van vrachtwagenchauffeurs.
De "Ping of Death"... Daar hebben we vroeger een boel lol mee gehad zeg...
Ping 192.168.0.x 65500 -t -l

Ook inderdaad een DOS aanval..
http://insecure.org/sploits/ping-o-death.html
http://en.wikipedia.org/wiki/Ping_of_death

Good times! }:O
En dat dan in een bat bestandje, 1000x tegelijk. :)
Echt bizar hoe goed en makkelijk die tool werkt. Zojuist uitgetest bij mn eigen website en hij lag al na 5 seconden plat. Ik hoop dat er goed verweer komt tegen deze kwetsbaarheid, anders vrees ik het ergste.
Ik hoop ook bij je eigen server!
Ik heb dit tooltje maar eens geprobeerd, dit werkt echt heel erg goed. Ik deed dit vanaf mijn laptop naar mijn veel sterkere desktop en een paar pogingen kon ik op mijn desktop zijn locale server niet eens meer bereiken.
Die tool is door Shekyan zelf ontwikkeld en bestond al voor de nu door hem beschreven methode. Hij heeft zijn tool er al wel mee uitgebreid.
Bij zo'n DOS aanval kun je toch ook gewoon automatisch het IP nummer laten blokkeren van degene die de aanval pleegt, of zie ik iets over het hoofd?
Maar totdat je beseft dat het een aanval is, en je het IP moet blokkeren, ben je meestal al te laat. De website heb je al neergehaald voor een bepaald periode, waarna je het IP gaat blokkeren.

En dat is meer symptoombestrijding, want de hacker kan dan via een ander IP-adres het aanval toch door laten gaan.
Valt wel mee toch?

Laat je firewall controleren op http requests met onrealistisch lage buffer waarden, en meteen daarop al een ban op ip-adres voor 5 minuten.

Volgens mij moet dit zelfs in fail2ban wel te scripten zijn? Is alweer iets te lang geleden dat ik me daarin verdiept heb...
Valt wel mee toch?

Laat je firewall controleren op http requests met onrealistisch lage buffer waarden, en meteen daarop al een ban op ip-adres voor 5 minuten.
En wat doe je dan met een client die even geen data meer wil hebben, bijvoorbeeld omdat ie een bestand aan het downloaden is van 600MB en het proces even weg moet schrijven naar de harddisk? Dan vraagt zo'n client namelijk ook voor een bepaalde tijd (een fractie van een seconde) een window van 0 bytes aan, anders gaat de data onderweg verloren omdat 'de emmer overloopt'.
Ja, want in het artikel zeggen ze nog dat het moeilijk is om een aanvaller te herkennen dus als je niet precies weet wanneer je wordt aangevallen door één specifiek ip-adres van de duizenden die je site bezoeken dan wordt het lastig om zomaar wat te gaan blokkeren.
Een TCP stack zou eigenlijk gewoon gebruikte resources per destination ip moeten bijhouden en als die te hoog komt gooi je al die connecties dicht en blacklist je het ip voor een poosje. Wat voor exploit je dan ook verder vindt, je kan nooit iets platleggen. Nadeel is dat het extra resources kost om dit te checken, maar dat is volgens mij vrij minimaal.

Aan de andere kant wil je misschien soms dat een connectie alle bandbreedte en resources krijgt... dus misschien toch geen algemene oplossing. Hmm..

[Reactie gewijzigd door Zoijar op 7 januari 2012 11:44]

Een TCP stack zou eigenlijk gewoon gebruikte resources per destination ip moeten bijhouden
Daarmee maak je het al een moeilijke oplossing: Hoe laat je je tcp-stack controleren hoeveel resources een thread in apache verbruikt?
[...]


Daarmee maak je het al een moeilijke oplossing: Hoe laat je je tcp-stack controleren hoeveel resources een thread in apache verbruikt?
Niet. De TCP-stack hoort oblivious te zijn over wat er binnen Apache gebeurt, en andersom al helemaal.
die honderden miljoenen botnet zombies over héél de wereld... Die lijst met geblokkeerde adressen wil ik wel eens zien.

Bovendien hebben consumenten IPs uit een DHCP range dus een geblokkeerd IP kan morgen niet meer dat van de geïnfecteerde pc van de buurman zijn maar aan jouw router hangen. Je moet dus voorzichtig zijn met blokkages.

+ NAT...
1 pc binnen jouw netwerk die geïnfecteerd is een externe server aanvalt en geblokkeerd wordt => het IP van jouw firewall geblokkeerd => niemand kan nog naar die site.

"Gewoon" blokkeren bestaat niet, spijtig genoeg :(
Ben erg benieuwd hoe lang het duurt voor de eerste dos aanval plaats vind op basis van deze techniek.
Dit lijkt me toch een andere exploit, dan diegene die in het artikel erboven vermeld staat.
Jouw artikel verwijst naar een kwetsbaarheid in de meeste web programmeertalen.

De exploit uit het artikel hierboven, verwijst naar een kwetsbaarheid in het TCP protocol zelf, en kan dus ook op niet-webservers uitgevoerd worden.

Lijkt me echter niet zo moeilijk om te fixen. Ik denk niet dat er veel software is die gebruik maakt van 0-byte tcp windows....
Lijkt me echter niet zo moeilijk om te fixen. Ik denk niet dat er veel software is die gebruik maakt van 0-byte tcp windows....
Think again: Elk programma wat 'persistent connections' gebruikt heeft zo'n 0-byte TCP window nodig om de verbinding open te houden.

Verwar niet het 'window' met de hoeveelheid data die er per seconde door een pijp heen gaat. Op een gegeven moment een window van 0 bytes aan de server aanbieden is vaak nuttig als je als client-programma niet meer data kan verwerken, om de server zo ver te krijgen om op te houden met zenden. Als dat niet gebeurt, dan kan je als client compleet gebombardeerd worden met data en kan er dus data verloren gaan.

Het probleem zit hem er alleen in dat elke keer als je zo'n ACK stuurt (dat is een pakketje wat zegt: "Ik heb nu alle infomatie verwerkt, stuur me nog maar eens x bytes aan nieuwe data"), er aan de server-kant geheugen wordt gereserveerd en data wordt klaargezet. En die hoeveelheid hoeft niet gelijk te zijn aan de hoeveelheid data die door de client aangevraagd wordt (namelijk 0 bytes), maar kan per OS verschillen. Dat gebeurt namelijk in de TCP stack en niet in het server-programma.

Wat je dan ook nog kan doen is een hele batterij aan losse verbindingen opbouwen en die allemaal 0 bytes aan data laten vragen. Dan wordt er wel geheugen gereserveerd voor alle server-processen die daaruit volgen, maar die doen uiteindellijk niets en houden het systeem bezet.

Als een aanvaller dus een hele batterij aan aanvragen doet voor 0 bytes aan data, kan het geheugen compleet vol lopen en loopt de server vast. Uiteindelijk kapt het OS dan wel de TCP-verbinding af als er geen geheugen meer over is, of draait ie het server-proces de nek om, maar dan heb je natuurlijk als aanvaller al je doel bereikt.
Ik ben geen netwerk expert, maar is het niet te ondervangen door een programma te schrijven die controleert hoeveel ruimte iemand reserveert en bij teveel geheugen reservering, de buffer dropt en gewoon de connectie afsluit? Misschien in de vorm van een hardwarematige linux-achtige box voor de server die dat checkt?

Misschien lul ik nu maar wat, maar is het niet mogelijk om dit te doen? Ik weet dat het TCP protocol zich op de netwerklaag bevindt, maar is het niet mogelijk om de connectie constant te monitoren d.m.v. een applicatie (op die laag?)
Misschien lul ik nu maar wat, maar is het niet mogelijk om dit te doen? Ik weet dat het TCP protocol zich op de netwerklaag bevindt, maar is het niet mogelijk om de connectie constant te monitoren d.m.v. een applicatie (op die laag?)
Het is juist een eigenschap van OSI dat dat niet mogelijk is: De applicatie hoort zich niet te bemoeien met wat zich op de netwerklaag (of strikter, transportlaag) afspeelt. It's not a bug, it's a (very important) feature, want dat zorgt er juist voor dat applicaties onafhankelijk van het onderliggend OS en netwerkdrivers kunnen worden geprogrammeerd. :Y)

Je kan dus ook geen 'applicatie' schrijven die de internals van de TCP-stack monitort en ermee gaat rommelen, en al helemaal niet de TCP-sessies van een ander programma. Dat is namelijk de taak van de kernel. Als je het over beveiligingsrisico's hebt.... :+

Alleen als er wat echt fout gaat (zoals de TCP-stack die zonder geheugen komt te zitten), dan wordt er naar de applicatie geklaagd en zal die geen data meer aanbieden. Dat er nu een bug zit in het TCP-protocol (dus in de formele definitie, niet de implementatie ervan) hoort voor een applicatie geen barst uit te maken.

Strikt genomen is het protocol ook niet bugged, maar is het een client die er doelbewust en structureel misbruik van maakt. Het sturen van een 0-byte ACK is namelijk juist ontzettend handig om de verbinding tijdelijk te stallen zodat een client zijn data kan wegwerken en de buffers leeg kan maken voor nieuwe data.

[Reactie gewijzigd door Stoney3K op 7 januari 2012 22:20]

Klopt

de TCP stack begint volgens mij reeds in layer 2 van het OSI-model, terwijl bv OS'en slechts in layer 3 beginnen (althans Windows, die heeft een layer 3 netwerkstack en die kan géén layer 2 functionaliteit zoals VLAN'ing).

Ik vermoed dat de beschreven mechanismes echter wél in een hogere laag zitten (boven laag 2) en er dus eventueel in het OS een mogelijkheid zou zijn om de aanval te detecteren. Echter zou het controleren van elke SYN/ACK voor héél véél overhead zorgen en de uiteindelijke toepassing zéér zwaar impacteren qua performance.

Applicaties zitten zeker te hoog in het OSI model; daar moet je dit dus niet gaan oplossen.
Dan doe je dat toch op kernel niveau?
Is in elk geval een optie om dit lek te sluiten, lekker makkelijk ook, een beveiligingsupdate en je hele server is er tegen beveiligd.
Nadeel is wel dat in sommige situaties legitiem TCP verkeer word tegengehouden. Maar dat is vast ook wel weer tweakbaar te maken.

edit: Overigens is het ook mogelijk dit te fixen met een IPS/IDS of geavanceerde firewall regel.

[Reactie gewijzigd door Alex_dragon op 8 januari 2012 17:19]

veel succes om je fix om de miljarden toestellen die TCP spreken te deployen
Ik vrees dat deze techniek al gebruikt wordt. Waar 1 het openbaar bekent maakt, zijn er minstens 10 die het weten en niet openbaar maken, maar juist gebruiken.
Die zijn waarschijnlijk al wel veel vaker uitgevoerd...
Kan er niet heel makkelijk cap op ondermaatse snelheden?
Moet kunnen. Of een patch op je serversoftware tegen die kwetsbaarheid, dus instructies om die aflever-snelheid aan te passen negeren/overriden met admin permissies.
Kan er niet heel makkelijk cap op ondermaatse snelheden?
Dan heb ik erg veel medelijden met je als je veel clients hebt op een onbetrouwbare verbinding zoals 3G. Ben je aan het surfen, ga je onder een tunnel door en word je door de server voor 'hacker' uitgemaakt en je verbinding verbroken.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True