Hoofdcategorieën
Device Settings

Nieuwe DoS-aanvalsmethode werkt al met één computer

Door Wilbert de Vries, zaterdag 7 januari 2012 10:45, views: 43.875

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.

Volgende 12:12 Corning toont verbeterde versie Gorilla Glass op CES
Vorige 10:18 Motorola verkoopt meer smartphones en minder mobieltjes
Advertentie

Reacties

«  1  2  3  »

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. :)

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.

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!

Ben erg benieuwd hoe lang het duurt voor de eerste dos aanval plaats vind op basis van deze techniek.

Die zijn waarschijnlijk al wel veel vaker uitgevoerd...

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.


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....

veel succes om je fix om de miljarden toestellen die TCP spreken te deployen

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 zaterdag 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 ced op zondag 8 januari 2012 17:19]


Dat gaat veel.problemen opleveren voor bedrijven,.maar goedkope kansen voor de pestkoppen en loosers onder de pc gebruikers...


Ja, en zo zijn er ook wel eens schietincidenten waarbij zware criminelen het loodje leggen. Dat er ook wel eens iets goed gedaan wordt met zulke exploits is geen reden om ze niet te dichten natuurlijk.

Ja, en zo zijn er ook wel eens schietincidenten waarbij zware criminelen het loodje leggen. Dat er ook wel eens iets goed gedaan wordt met zulke exploits is geen reden om ze niet te dichten natuurlijk.
Maar het bestaan van een tool (wapens) is niet de oorzaak van schietincidenten -- de oorzaak is dat idioten daarmee willekeurige personen aanvallen en ze niet voor een doel gebruiken.

Die wapens worden immers ook gebruikt om Saddam een kogel door zijn hoofd te werken.

Net zo goed als er nuttige toepassingen zullen zijn voor deze hack. Natuurlijk zal niet iedereen het er mee eens zijn als ik zeg dat het een 'nobel, vreedzaam doel' is, maar het kan een aardige bijl zijn in handen van de MPAA als de SOPA-wet er straks doorheen komt.

Zoals je je ongetwijfeld nog zult herinneren, is Saddam opgehangen, er is nooit een kogel door zijn hoofd gewerkt.

_

[Reactie gewijzigd door Youriboy op zondag 8 januari 2012 19:01]


Offtopic: "CEO van me websites"? Noem dat gewoon "eigenaar van mijn websites"...

Ontopic: hoezo zijn er geen verdedigingsmechanismen? Die kwetsbaarheid in het tcp-protocol kan verholpen worden?

CEO's vinden het altijd leuk om met wollige termen te smijten en dingen belangrijker te laten lijken dan ze in werkelijkheid zijn :+

sshhht, zwijg, ik heb hier nu net ontdekt dat ik mij CEO kan noemen.

Is wel leuk als mensen mij vragen wat ik doe in het dagelijks leven.

"Ik? ohhh ik ben helpdeskmedewerker en daarnaast ben ik ook nog CEO van enkele bedrijven"

Klinkt beter als enkel het eerste toch 8-)
Yup, ik heb het gemaakt in het leven. 8-)

Ik zou direct de raad van commissaris bij elkaar roepen! :-)

Ik zou direct de raad van commissaris bij elkaar roepen! :-)
Prima idee! Ik neem het bier mee, zorg jij voor de film, dan doet Pieter de stroom en het netwerk? :+

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 zaterdag 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.

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.

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 zaterdag 7 januari 2012 11:36]


Heb even mijn vps met ubuntu gecheckt, die staat default op 15 seconde en 100 connections.

Wie gaat er nu testen of tweakers.net veilig is? :)

Tweakers gebruikt load balancers zover ik weet =D

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 zaterdag 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 :(

kijk, dit is nou vooruitgang. :+

Door het aantal gelijktijdige verbindingen per IP-adres te beperken en een redelijk korte verbindingstime-out in te stellen lijkt me dat de impact van deze vulnerability al enigszins wordt ingeperkt. Je kunt dan nog steeds met een botnet een server omver trekken, maar met één systeem wordt dat al moeilijker. Misschien zelfs onmogelijk.

Door het aantal gelijktijdige verbindingen per IP-adres te beperken en een redelijk korte verbindingstime-out in te stellen lijkt me dat de impact van deze vulnerability al enigszins wordt ingeperkt
Het kan. De kans dat je hier hele volkstammen dan uitsluit op je website moet je dan voor lief nemen. Azie staat nou niet direct bekend om snelle lijnen.
Je kunt dan nog steeds met een botnet een server omver trekken, maar met één systeem wordt dat al moeilijker. Misschien zelfs onmogelijk.
Met een botnet lukt 't je praktisch sowieso al wel. Daar heb je deze techniek niet direct voor nodig.

Met een korte verbindingstimeout gaan applicaties continue connectie verliezen, terug moeten connecteren en zo voor héél veel overhead zorgen. Ook kunnen véél applicaties daar niet meer overweg die een continue verbinding nodig hebben. Denk maar aan storage protocols (SAN storage: iscsi luns, FCoE connecties, NFS mounts bv voor vmware datastores). Stel je voor dat je op het interne netwerk een geïnfecteerde PC hebt...
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 12:12 Corning toont verbeterde versie Gorilla Glass op CES
Vorige 10:18 Motorola verkoopt meer smartphones en minder mobieltjes
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011