Aanvallers ddos'en website met behulp van honderdduizenden mobieltjes

Kwaadwillenden lijken met behulp van honderdduizenden geïnfecteerde mobiele apparaten een website te hebben aangevallen met een ddos. Waarschijnlijk lieten zij de mobieltjes http-requests versturen door kwaadaardige javascript-code te verstoppen in advertenties.

De ddos werd uitgevoerd op een niet nader genoemde website die wordt gehost door CloudFlare, die de aanval opmerkte en er over rapporteerde op zijn blog. In totaal werden er ongeveer 650.000 unieke ip-adressen gedetecteerd die betrokken waren bij de ddos-aanval, waarbij opvallend genoeg 77 procent afkomstig waren van smartphones en tablets.

Uit onderzoek concludeert CloudFlare dat het aannemelijk is dat de verantwoordelijken voor de ddos malware hebben geïnjecteerd via advertenties, die zijn getoond in apps of in de browser. De webdienst ontdekte namelijk een stuk javascript-code die gemaakt is om http-requests te versturen, en via een advertentienetwerk kunnen aanvallers snel grote aantallen apparaten bereiken.

Waarschijnlijk zijn in Nederland geen smartphones geïnfecteerd met de ddos-malware. Volgens CloudFlare kwamen namelijk bijna alle betrokken ip-adressen uit China. Ook zijn in de javascript-code Chinese tekens gevonden en lijken de aanvallers zich te hebben gericht op het infecteren van browsers die veel in China worden gebruikt. In totaal zijn er ongeveer 4,5 miljard http-requests in een dag tijd verzonden naar de getroffen website. Tijdens de piek kwamen er 275.000 requests per seconde voorbij, aldus CloudFlare.

CloudFlare rapporteert regelmatig over ddos-aanvallen die worden uitgevoerd op zijn servers. Volgens het bedrijf is ddos'en met behulp van geïnfecteerde advertenties die worden weergegeven op mobieltjes een gevaarlijke trend.

Reacties (76)

Misschien een idee om Javascript wat door advertentienetwerken wordt geserveerd niet meer te compressen en langs een strengere QA te halen, ala iOS. Niet dat dat altijd perfect gaat, maar voorlopig is Javascript het enige wat we hebben.

Een beter idee is om van het hele concept van client-side scripting af te stappen en JS gewoon server-side te laten draaien, en de client enkel pure HTML5/CSS laten renderen. Ben je direct van zo ontzettend veel security ellende af, plus je browser wordt een stuk lichter.

Maar goed, server-side rekentijd kost de hoster geld, client-side komt voor rekening van de bezoeker.

[Reactie gewijzigd door Dreamvoid op 28 september 2015 17:27]

Volgens mij heb jij geen verstand van JavaScript want dit gaat dus nooit werken. Het zal client side moeten blijven draaien.

Dat is niet helemaal waar. JS wordt eigenlijk vooral gebruikt om een banner in te kunnen laden omdat het makkelijk te implementeren is, en om eenvoudig tijdens het bezoek te kunnen blijven tracken. Er is geen enkele reden dat real time bidding / algoritmisch banners tonen niet via een server side oplossing kan, behalve dat het druk legt op de interne developmentteams van publishers, en dat het tracking wat moeilijker maakt (iets waar ik zelf niet zo rouwig om zou zijn).

Voor een partij als tweakers, of the verge, is het veel makkelijker gewoon een javascript bestand in te laden dan een eigen oplossing te bouwen. Dit gebeurt echter wel - er zijn partijen (denk aan Sanoma) die hun eigen exchange hebben waarop partijen kunnen inschrijven. Die zouden prima een javascriptvrije oplossing kunnen programmeren. Bovendien gaat een deel van de animaties prima via CSS3/html5, dus daarvoor is JS ook niet nodig.

Uiteindelijk is een deel van het probleem gewoon dat er relatief weinig incentive was voor advertentiepartijen om een minder intrusive manier te verzinnen - tot nu toe was de enige limiet laadsnelheid en devicecompatibiliteit. Dit leidt wel tot fustratie bij gebruikers (en dus adblockers). Bovendien is een extern ingeladen JS een enorme attack vector. De huidige situatie - ongebreideld inladen en tracken - is niet meer houdbaar, iets wat hier weer goed te zien is. Hoe dan ook moeten we gaan denken aan een betere oplossing.

Alleen extern ingeladen javascript weren werkt ook niet lang genoeg - kwestie van tijd voor de grote publishers externe JS via hun eigen domein pipen en je alsnog tegen 'first party javascript' zit aan te kijken.

[Reactie gewijzigd door Roytoch op 28 september 2015 17:49]

Wat maakt het nou uit -waar- iets draait? Je slaat de plank mis vanwege het -feit- dat je de client -iets- moet serveren waar deze gene iets mee kan. Of dit nu plain text is, of javascript.. dat maakt niet uit. Of wil je nu ook tekst server-side gaan serveren? Dat klinkt heel stom (en dus wat makkelijker) omdat ik 'tekst' als voorbeeld gebruik maar je kunt dit invullen door wat dan ook.
Je draait iets serverside om bijv. een berekening te doen zonder dat dit clientside direct te beïnvloeden is (indirect dus wel).

Verder noem je html5 , maar daar kun je net zo goed exploits op verzinnen.

Het afschaffen van een bepaalde taal is niet -de- oplossing, dat iets wat maar tijdelijks is. Op het moment dat je domweg iets binnen krijgt van een 3e partij ben je per definitie kwetsbaar, of dit nu JS, html5 of wat dan ook is.

Denk dat we elkaar niet helemaal begrijpen. Ik bedoel eigenlijk vooral:

• Met serverside bedoel ik dat door bijvoorbeeld het ophalen van een banner en het uitserveren ervan via whatever welke programmeertaal gebruikt wordt voor de website (php bijvoorbeeld), je een kant en klare, niet continue onder het surfen wijzigende en trackende pagina aan je bezoekers uitserveert. Dit is toch een stukje sneller en je voorkomt 'vieze' doorlopende tracking. Niet helemaal het juiste termgebruik van mijn kant waarschijnlijk - ik bedoel meer JS tov PHP.
• Extern is vooral omdat je dan een extra afhankelijkheid hebt en omdat je als publisher een derde partij grip geeft op wat jij als publisher aan je klanten serveert. Dit is goed te zien als je ghostery gebruikt - er worden 5-6 externe bestanden ingeladen die zelf ook weer een aantal trackers naar binnen fietsen, en uiteindelijk krijg je 50-60 trackers op een site als voetbalzone. Je geeft gewoon heel veel controle en macht over wat je bezoekers zien, maar kan er zelf geen controle op draaien.

Kijkende naar je zin:

Op het moment dat je domweg iets binnen krijgt van een 3e partij ben je per definitie kwetsbaar, of dit nu JS, html5 of wat dan ook is.

Denk ik dat we het wel met elkaar eens zijn.

[Reactie gewijzigd door Roytoch op 29 september 2015 14:00]

Prima verhaal, en wat je nog vergeet, is dat ik nu iedere keer tegen een treurig bannertje van tweakers aan zit te kijken "dat ik 'hun' advertenties block" omdat ik een blocker draai.... Dat wíl ik niet per sé, maar dergelijke enorme veiligheidsgaten maken dat het eigenlijk wel móet (als je een beetje security conscious bent). En zolang dáár geen goed alternatief voor is (of sterker wat je al aangeeft als ze JS via het Eigen domein gaan pipen) is de enige oplossing als het niet per sé hoeft beginnen met álle JS te blocken...

Hangt er volledig van af hoe je je site ontwerpt. Je kan prima websites maken zonder clientside JS.

Dan krijg je wel hele saaie websites.

Kijk maar eens naar Amazon, dat is een mooi voorbeeld van een site die perfect werkt zonder JS.

Ik bedoel, natuurlijk kan je met JavaScript (en Flash, Silverlight, Java) heel mooie dingetjes knutselen - het is alleen een groter security risico en met een complete JS runtime wordt de browser er ook niet lichter op.

[Reactie gewijzigd door Dreamvoid op 28 september 2015 17:41]

Als je kijkt in de source van Amazon dan zie je dat het begint met JS.
Wellicht bedoel jij een andere Amazon?

Uiteraard is het wel mogelijk maar zeker niet best practice

Je snapt best wat ik bedoel - als je JS uitzet serveert Amazon een volledig functionele website. Als iedereen dit netjes zou doen kan JS op termijn langzaam afsterven, en als we van client-side scripting af zijn zal het web er een stuk veiliger op worden.

Maar goed, dat gaat rechtstreeks tegen de ambities van Google in, dus veel kans heeft dit niet.

[Reactie gewijzigd door Dreamvoid op 28 september 2015 17:47]

Ja joh, lekker allemaal page refreshes overal de god ganse tijd. Ga ff terug naar pre 2000 era.
Js heeft wel meer mogelijkheden dan dingen met advertenties. Json/ajax bv kan een fikse hoeveelheid data besparen door enkel wat data te serveren ipv een complete pagina...
En dat is maar een voorbeeld, je kan ook denken aan zaken als webgl en nog veel meer...

[Reactie gewijzigd door jozuf op 28 september 2015 18:10]

Kijk FF naar spdy push, zit ook in http/2 en quic. Je kunt serverside orkestreren dat slechts een deel van de pagina vervangen wordt. Bocendien zijn de browser render engines zijn er op geoptimaliseerd om gelijke delen tussen pagina's te cachen. Dus hergebruik bij preload.

Ik zie genoeg angularjs sites die ondanks alleen json updates of zelfs uit localStorage langzamer tabellen renderen tot interactie ready dan server push html5/css3 sites.

Hmn interesting, thx. Wel beetje bekend met spdy (toevallig net opgezet op thuisserver) maar deze mogelijkheid kende ik niet.

Ja joh, lekker allemaal page refreshes overal de god ganse tijd.

Ach, zo werkt Tweakers.net nu ook. Als je nieuwe reacties wilt zien op dit artikel moet je ook refreshen. Is dat zo'n ramp? Het zijn in mijn ervaring vooral de webdevelopers die een site vol met dynamisch inladende elementen supergaaf en flashy vinden, maar ik zie bitter weinig websites waar dat daadwerkelijk nut heeft.

Hier op de voorpagina wel inderdaad, maar op het forum kan je de tab gewoon open laten staan binnen een topic, en verschijnt er een melding wanneer er nieuwe posts in het topic geplaatst zijn. Bij het klikken op die melding worden ze er bij geplaatst, zonder refresh.

Ook het plaatsen van een reactie hier, gaat met JS en zonder refresh.

En niet te vergeten ... Die moderatie op jullie opmerkingen :-)

Nou ik heb voor mijn mobiel toch liever dat er een beetje kostbaar word omgegaan met hoeveelheden data...

Het zijn in mijn ervaring vooral de webdevelopers die een site vol met dynamisch inladende elementen supergaaf en flashy vinden, maar ik zie bitter weinig websites waar dat daadwerkelijk nut heeft.

Op zich een begrijpelijke reactie.

Mijn ervaring is echter dat Javascript (of ECMAscript voor de puristen onder u) juist een super handige cross-OS browser programmeertaal is. Je kan er een kruising tussen een website / app mee maken die toegang heeft (leesrechten) tot het lokale bestandssysteem.

Aan de hand daarvan kan je bijvoorbeeld data-visualisaties van csv-bestanden maken, zonder besturingssysteem / platformafhankelijk te hoeven programmeren, gewoon helemaal zonder internet en zonder servers. En zonder het in mijn ogen "bloated" Java, wat ook boordevol beveiligingsgaten zit, ik denk nog erger dan Javascript.

En ja, de toegang tot een lokaal csv-bestand doe je nou eenmaal met een XMLHttpRequest; dezelfde technologie die hier misbruikt wordt.

Ik zou het superdom vinden om het maken van client-side apps met toegang tot het lokale bestandssysteem in een cross-platform programmeertaal onmogelijk te maken door "servers" verplicht te stellen. In het bedrijfsleven lijkt me dat vaak ook mega-ondhandig, omdat je dan een server met 13 beveiligingslagen moet optuigen waarvan alles super sloom wordt. Mijn ervaring is dat alles organisatorisch ca. 10-100x zo snel gaat als je geen 'server' nodig hebt. Die servers zelf namelijk, zij vaak ook weer vatbaar voor allerlei aanvallen en misbruik, kunnen 100x zoveel DDOS-aanvallen versturen per seconde als een smartphone, dus wat schiet je er in 's hemelsnaam mee op?

Op sites als dit is het ook een enorme toevoeging, Zeker als een artikel net geplaatst is, zijn er altijd meerdere reacties die exact hetzelfde zijn qua inhoud. Erg vervelend als je dit handmatig moet refreshen (terwijl de meuk tracker links alles keurig om de zoveel minuten ververst ). Waarom kan dat dan bij de artikelen niet?

[...]

Ach, zo werkt Tweakers.net nu ook. Als je nieuwe reacties wilt zien op dit artikel moet je ook refreshen. Is dat zo'n ramp? Het zijn in mijn ervaring vooral de webdevelopers die een site vol met dynamisch inladende elementen supergaaf en flashy vinden, maar ik zie bitter weinig websites waar dat daadwerkelijk nut heeft.

In mijn ervaring zijn het vooral mensen die totaal geen kaas gegeten hebben van hoe een moderne website in elkaar steekt, die idiote opmerkingen gaan rondslingeren als 'zet JS maar uit'.

JS is niet een bittere noodzakelijkheid vanuit functioneel oogpunt, maar vanuit functioneel oogpunt heb ik aan DOS + edit.exe ook voldoende om een brief te tikken. Wel wat vreemd dan dat we tegenwoordig allemaal veel zwaardere OSen met grafische shells gebruiken en veel grotere gespecialiseerde tekstverwerkings-programma's met allerlei hulpmiddelen bij de hand nemen.

Oh ja; dat komt omdat die voor de gemiddelde gebruiker gewoon simpelweg een veel betere gebruikservaring opleveren. Denk daar maar eens even over na.

[Reactie gewijzigd door R4gnax op 28 september 2015 21:02]

Ik kan me aan de ene kant wel in je punt vinden, maar het is totaal niet handig en omslachtig (JS bestaat niet voor niets). Je zal dan meer server side moeten gaan doen wat dus een stuk duurder is (stroom/bandwith is niet gratis) en ook weer omslachtiger (zal uiteindelijk toch op een manier bij de client moeten komen).

Oja, en er zullen dan een hele hoop leuke/mooie/handige dingen niet meer bruikbaar zijn. Kijk bijvoorbeeld naar https://keybase.io/ gebruik client-side JS om met je PGP key te werken, of je facebook feed die automagisch nieuwe dingen op haalt zodat we nog minder hoeven te bewegen achter onze pc.. En zo kan ik nog wel even door gaan.

Ik denk wel dat JS in sommige gevallen wordt "misbruikt", want het is inderdaad niet nodig om de simpele website van de buurvereniging 20 verschillende JS frameworks te gebruiken, maar dit is voornamelijk te danken aan bepaalde CMSsen die ze helemaal voor proppen met frameworks voor het "gemak van de eindgebruiker"

Ik ben geen expert, maar JS wordt toch voor een groot deel gebruikt voor visuele UI interactie? CSS kan dit tegenwoordig ook een beetje, maar JS aan de client-side lijkt me ook hiervoor nog onmisbaar?

Het is toch grappig dat flash in het bijzonder en silverlight worden afgeserveerd mbt exploits en iedereen over html5 +js blijven roepen terwijl de laatste tijd steeds naar voren komt dat js net zo onveilig is en zelf nog erger kan worden misbruikt. Bijv. Sileverlight was zo slecht nog niet...

Ik ben het wel deels met je eens. Vooral voor wat betreft Flash. Toen dat nog voor websites (en niet voor ads) gebruikt werd, konden daar dingen mee die je nu amper meer ziet in html5 (of die zelfs onmogelijk zijn). Extreem kleine vector files, super gebruiksvriendelijke teken en animatie software, standaard inladen van complete websites en alle GUI interacties (van een paar kb) zodat er geen gekke AJAX achtige delays of page-load-tijden in websites zitten, extreem mooie fullscreen Swift3D vector graphics die in een paar kb passen. Ok, het kan met html5 ook allemaal, maar het is voor de designer 100x omslachtiger om het te implementeren... Sterker nog, een designer kan dat helemaal niet meer zelf en heeft er een programmeur bij nodig...

Bij bedrijven als Google is alles dat oud is meteen slecht en onveilig. Dat het nieuwe alternatief nog niet helemaal klaar is houden ze geen rekening mee. Blokkeren is lekker makkelijk.

CSS heeft aardig veel van de animaties vanaf versie 3 op zich genomen. JavaScript als geheel wegnemen gaat hem inderdaad niet worden. Maar een middenweg is de ads aan de server side doen allicht?

[Reactie gewijzigd door thomasv op 28 september 2015 17:44]

Probleem is dat zoiets afhangt van hoe netjes de website zich daaraan houdt, als client heb je vrijwel geen enkele controle wat JS nou precies doet binnen je browser.

Sanbox erom en alleen http Traffic naar de source toelaten. Dan kunnen ze alleen de adserver dossen en dat vinden de andere gebruikers wel fijn

Ja en dan wil je naar de website van de advertentie? Moet ik die dan maar handmatig gaan googelen? Sure dan kan je daar weer een escape voor in bouwen, maar wie zegt dat dit geen redirect is? Hoe moeilijk is het om een domeinnaam op een IP-adres neer te zetten wat al in gebruik is? Volgens mij is dit heel eenvoudig mogelijk en ga je al weer direct de mist in.

Ik bedoel JS alleen laten connecten naar de source server en scripts in html ook alleen laden als ze van dezelfde server komen (en css etc.). M.a.w. als ik intik www.tweakers.net/index.html alleen de content laden die vanaf deze naam komt. Geen kruisbestuiving toegestaan. Is er alleen nog een probleem als tweakers gehacked zou zijn.

Ja dat weet ik, maar dit gaat allerlei problemen opleveren met Ad servers (die dus niet op die link staat) en storage doublering doordat je dus alle ads moet dubbelen naar je eigen server. Dit wordt een groot drama want adsense werkt dan ook niet meer.

Ik vraag me alleen af hoe de browser dan omgaat met een Javascript rederict naar de website van de adverteerder.

Dat is mijn probleem niet. Ik denk echter niet dat Chrome/Chromium en Firefox dit zullen doen omdat dan de inkomstenbron opdroogt. Als gebruiker vind ik het wel een goed idee. En de storage doublering: die paar jqueries extra downloaden ipv. een cdn: don't care (zolang ik niet mobiel zit). Weegt mooi op tegen de wegbezuinigde ad downloads ;-) Ik zeg niet dat het gaat gebeuren, maar ik denk dat er weinig gebruikers zijn die echt blij zijn met ads.

Dat is jouw probleem wel. Javascript wordt niet alleen gebruikt om ads te serveren. Heel veel grafische elementen of GUI interacties met AJAX maken gebruik van cross origin redirects. Dat gaat dan dus in een keer stuk en ik denk dat je hiermee direct het halve internet dan breekt.

met html5 is dat vrijwel overbodig geworden zeker met css3.

Echt niet. Succes met een async rest call die een JSON teruggeeft en daar fancy netwerken mee moet maken on-the-fly. Je weet wel, van die prachtige hairballs of live plots. Gaat em niet worden. En als het wel kan hoor ik dat graag, want dan ben ik eindelijk van dat hele JS af.

Server-side JS suggereren als alternatief voor client-side is natuurlijk gewoon ridicuul. Los daarvan, zo'n DDOS aanval kun je natuurlijk ook gewoon in pure HTML bouwen.

Same origin policy op alle content? Gaat helaas niet werken omdat ad-netwerken als die van google dan geen views meer krijgen maar afgezien daarvan zou de internet experience er flink op vooruit gaan.

Het is niet duidelijk hoe het gebruikte advertentie-systeem in elkaar steekt, maar inderdaad: Nu is JS het probleem omdat het gebruikt kan worden voor een DDOS? Waarom ligt het niet aan de mobieltjes het ad-netwerk? Zwakste schakel is in dit geval in de eerste plaats het advertentie-netwerk. Lijkt me dat de opdrachtgever hiervan makkelijk te vinden moet zijn trouwens.

Je kan niet alles server-side draaien... je doet net alsof rekenwerk de enige kosten zijn. Wat dacht je van de bandbreedte die nodig is om bij iedere update een complete change van HTML/CSS te sturen?

Zal leuke gebruiksvriendelijke websites geven om per visuele update een HTTP requests te doen en weer het HTML document te versturen. Op je mobieltje mag je dan een seconde per klik wachten.

Super idee

[Reactie gewijzigd door Gamebuster op 28 september 2015 18:33]

Ben het met je eens dat niet alles in serverside nodejs (bijvoorbeeld) kan wat je wilt, bijvoorbeeld local cache uitlezen.

Maar performance van aantal request, zoals jij als argument geeft is niet het probleem, denk aan http/2 of zelfs quic als oplossing (incl. push).

Maar even terug naar het topic, ads worden meestal als 1 file geserveerd. Je zou dus kunnen eisen dat ads dat alleen doen en alleen een html link naar een target bevatten op de hele body, waar geen events aan mogen hangen. En vervolgens geen hover of click events toestaan.

Los daarvan merk in dat de veilig browse plugins die ik op de desktop heb om dit te voorkomen, ik mobiel niet beschikbaar heb tenzij ik een proxy installeer. Samengevat, mobiel is vatbaarder, snel plugins mogelijk maken is een must, de meeste cores zijn toch idle op m'n mobiel.

Dat is dan een taak aan de eigenaar van het medium waar op wordt geadverteerd lijkt mij. Dus Tweakers.net zou dit dan in de regels op moeten nemen voor adverteerders.

Denk je in dat geval eens een wereld zonder AJAX in. Dit concept bestaat nog niet direct in html of css. Om maar een voorbeeld te noemen. Voor wat betreft advertenties is Javascript beter dan flash in ieder geval.

Je kan met html ook http requests sturen?

Wat een fantastisch idee, weer naar het jaar 1995 gaan.

Yeah old school

Browsers moeten gewoon cross domain javascript calls blokkeren.
Of deze alleen toestaan als hij statisch geïnclude wordt in de html.

Er zijn browser-plugins die dat kunnen. Ik gebruik NoScript en RequestPolicy. Met RequestPolicy geef (of onthou) ik toestemming voor cross-domain links. Met NoScript schakel ik JavaScript selectief aan of uit.

Ook op mobiel? 70% van het Traffic was mobiel (20% is normaal).

Cross domain requests zijn ook echt niet zomaar toegestaan

Is dit nu echt malware? Bedoel, neem aan dat je gewoon in je app reclameblokje kan meenemen die een time(0) refresh blijft doen op een IP adres, wat ze ook nog wel eens doen op websites (maar die blokkeren nu vrijwel direct als er een script iets fout doet).

Desnoods laad je de app gewoon 'ads' ophalen van een server (ter controle oogt het legitiem), maar pas je daarna de servering van de server gewoon aan?

De code doet iets op/met jouw systeem waar jij geen toestemming voor hebt gegeven, en iemand heeft er last van.

Klinkt toch echt we als malware.

Die beschrijving is anders ook van toepassing op die stomme reclame meuk.

De code doet iets op/met mijn systeem waar ik geen toestemming voor heb gegeven en ik heb er last van..

Klinkt toch echt als Reclame.

Precies, veel reclame geeft jouw IP en unieke cookie (akka persoonsgegevens) door aan de adverteerder zonder jouw toestemming.

Dus maleware, spyware.
Dus veel sites zijn ook adware.

Leve het internet of things.

Nu het aantal mobiele en tablet devices steeds groter word, is het een target geworden voor kwaadwillenden die grote groepen devices nodig hebben voor hun acties. Al is het maar om andere hackpogingen te verbergen door de aandacht af te leiden naar een grote ddos aanval. We zullen waarschijnlijk steeds meer gaan horen van malware gericht op de mobiele besturingssystemen (android, ios).

Plus dat de mobieltjes steeds meer op pc's gaan lijken, ze (bijna) altijd beschikken over een snelle verbinding met internet en niet te vergeten.. weinig tot geen bescherming.

at de verantwoordelijken voor de ddos malware hebben geïnjecteerd via advertenties, die zijn getoond in apps of in de browser.

Dus toch gewoon de adblocker om dit soort malware buiten de deur te houden. Maar ja dan beginnen er weer mensen te zeuren dat dat voor sommige sites niet eerlijk is en ze inkomsten verliezen.

Ik mis nog iets in het artikel, is de betreffende site beschikbaar gebleven of niet?

Jup, dat staat in de blog.

Daarom gebruik ik dus adblock en adfree(root). Dat adverteerders inkomstenbron mislopen interesseert me geen biet.

Word dan op zijn minst abonnee: https://secure.tweakers.net/aboshop/

Tweakers.net staat op de whitelist.

Soortgelijk probleem, Imgur liet een weekje terug via (externe?) javascript een grote hoeveelheid aanvragen naar 8chan gaan.

https://www.reddit.com/r/...create_a_botnet_and_ddos/

[Reactie gewijzigd door Henk Poley op 28 september 2015 18:08]

Ik ken iemand die had zijn smartphone in zijn netwerk en die had een ping van 400 en hoger en regelmatig packets drops. Na het resetten van zijn telefoon functioneerde de ping normaal. Het kan geen kwaad om eens in de zoveel tijd je IP adres van je smartphone te pingen voor vreemde taferelen.

Daarom gebruik ik altijd adblockers meer dan een tegelijk!

En weer advertenties, hoezo een adblocker nodig.

[Reactie gewijzigd door codebeat op 28 september 2015 22:50]