Onduidelijkheid over DDoS-aanval op politie.nl
Zondagmiddag was de website van de politie enige uren slecht bereikbaar, het is echter onduidelijk of het om een DDoS-aanval ging, zo laat de politie zelf weten. Vanaf het eind van de middag waren er problemen bij het bereiken van politie.nl. Of dit het gevolg was van een DDoS-aanval staat niet vast.
"Het was in ieder geval ook druk op de site. Een bericht met een foto van een dode vrouw die in de Maas was gevonden, werd veel bezocht en gedeeld. Dit trok vele duizenden bezoekers tegelijk. Ook dat kan de problemen mede hebben veroorzaakt", aldus een verklaring van de politie. De komende dagen wordt nader uitgezocht wat de exacte oorzaak is geweest. De NOS meldt dat de oorzaak mogelijk lag in de resolutie van de foto die op de website was geplaatst. Door een kleinere vervangende foto te plaatsen werd de website weer bereikbaar.
Reacties (13)
Tja het is nou eenmaal mode om camera's zoveel mogelijk megapixels te geven (dat is waarop ze verkocht worden, zelfs
als de kwaliteit van de optiek helemaal niet in lijn is met het aantal megapixels), gevolg is dat fotobestanden alsmaar
groter worden. Combineer dat met het steeds verder afschermen van de techniek van de gebruiker (wie weet er nog
wat "de grootte van een bestand in bytes" is en hoe zich dit verhoudt tot typische lijnsnelheden?) en je krijgt dit soort
dingen. Ik zag op het werk dat iemand een paar kiekjes gemaakt had van het pand ivm een verbouwing, de directory
waar hij ze in gezet had is 20GB. Zo krijg je vanzelf problemen...
Achteraf natuurlijk makkelijk roepen "het CMS had een limiet aan de grootte van de bestanden moeten stellen", als je zo
iets hebt dan krijg je veelal weer klachten van de gebruikers "ik kan me foto nie uploade!" en moet dat weer hoger gezet
worden...
als de kwaliteit van de optiek helemaal niet in lijn is met het aantal megapixels), gevolg is dat fotobestanden alsmaar
groter worden. Combineer dat met het steeds verder afschermen van de techniek van de gebruiker (wie weet er nog
wat "de grootte van een bestand in bytes" is en hoe zich dit verhoudt tot typische lijnsnelheden?) en je krijgt dit soort
dingen. Ik zag op het werk dat iemand een paar kiekjes gemaakt had van het pand ivm een verbouwing, de directory
waar hij ze in gezet had is 20GB. Zo krijg je vanzelf problemen...
Achteraf natuurlijk makkelijk roepen "het CMS had een limiet aan de grootte van de bestanden moeten stellen", als je zo
iets hebt dan krijg je veelal weer klachten van de gebruikers "ik kan me foto nie uploade!" en moet dat weer hoger gezet
worden...
31-08-2015, 11:00 door
Mozes.Kriebel
Wat een enorm sneu bericht. Zoveelste bevestiging IT + Overheid = drama....
31-08-2015, 11:21 door
Hans van Eijsden
Die website draait nog steeds op... Apache. En ook nog steeds direct aan internet, en dus niet achter Varnish of via NGINX.
Wanneer ik op een bekabelde Mac via een snelle verbinding met lage ping de website opvraag met Safari, en CMD-R (vernieuwen) ingedrukt houd, lijkt de hele server te crashen.
Als ze gewoon het stokoude niet-schaalbare Apache zouden vervangen voor NGINX, zou het gewoon goed gaan. Meer informatie over het probleem: https://en.wikipedia.org/wiki/C10k_problem en https://anturis.com/blog/nginx-vs-apache/
$ curl -I https://www.politie.nl
HTTP/1.1 200 OK
Expires: Mon, 31 Aug 2015 09:27:59 GMT
X-UA-Compatible: IE=edge,chrome=1
Cache-Control: max-age=600, public
Content-Type: text/html;charset=UTF-8
Vary: Accept-Encoding
Date: Mon, 31 Aug 2015 09:18:40 GMT
Connection: keep-alive
Server: Apache
Wanneer ik op een bekabelde Mac via een snelle verbinding met lage ping de website opvraag met Safari, en CMD-R (vernieuwen) ingedrukt houd, lijkt de hele server te crashen.
Als ze gewoon het stokoude niet-schaalbare Apache zouden vervangen voor NGINX, zou het gewoon goed gaan. Meer informatie over het probleem: https://en.wikipedia.org/wiki/C10k_problem en https://anturis.com/blog/nginx-vs-apache/
$ curl -I https://www.politie.nl
HTTP/1.1 200 OK
Expires: Mon, 31 Aug 2015 09:27:59 GMT
X-UA-Compatible: IE=edge,chrome=1
Cache-Control: max-age=600, public
Content-Type: text/html;charset=UTF-8
Vary: Accept-Encoding
Date: Mon, 31 Aug 2015 09:18:40 GMT
Connection: keep-alive
Server: Apache
Er zijn meer load balancers dan NGINX, ik gebruik Brocade ADX met SSL offloading en die voegt automatisch geen Via of Server toe aan het verkeer.
Een te groot plaatje kan iedereen overkomen, waarschijnlijk had caching dan wel geholpen.
Een te groot plaatje kan iedereen overkomen, waarschijnlijk had caching dan wel geholpen.
Het Parool citeerde gister een woordvoerder van de politie die zei:
Een foto van veel megabytes, duizenden mensen tegelijk, ze verkleinen de foto en de site is stabiel. Ik heb niet de indruk dat er dan nog een aanwijzing voor een DDOS-aanval overblijft.
'Het was een grote foto, veel megabytes. Het verhaal werd bovendien door duizenden mensen tegelijk bekeken. We hebben de foto verkleind en dat lijkt te werken. De site is stabiel'
http://www.parool.nl/parool/nl/4/AMSTERDAM/article/detail/4132146/2015/08/30/Website-politie-onbereikbaar-door-te-grote-foto.dhtmlEen foto van veel megabytes, duizenden mensen tegelijk, ze verkleinen de foto en de site is stabiel. Ik heb niet de indruk dat er dan nog een aanwijzing voor een DDOS-aanval overblijft.
Dus het is de politie die een DOS aanval op zijn gebruikers heeft uitgevoerd. :P
Het is ook nooit een DDOS het is DOS zijn verschillende soorten aanvallen
Het is ook nooit een DDOS het is DOS zijn verschillende soorten aanvallen
Door Anoniem: Dus het is de politie die een DOS aanval op zijn gebruikers heeft uitgevoerd. :P
Het is ook nooit een DDOS het is DOS zijn verschillende soorten aanvallen
Van een beetje hosting is te verwachten dat ze een dikke lijn hebben, die je onder normale omstandigheden niet om kan gooien met een simpele DSL lijn (of zelfs met een glasvezel; je pc loopt eerder vast). Om dat te omzeilen moet je meerdere connecties gebruiken om de connectie plat te leggen.Het is ook nooit een DDOS het is DOS zijn verschillende soorten aanvallen
Zelfde geldt voor server resources, dat kan je niet in je eentje volmaken. Je hebt toch echt meerdere clients nodig die constant requests doen.
All in all, het was een DDoS. In dit geval eentje die ze zelf veroorzaakt hebben.
Iemand de EXIF data van de foto bekeken?? Zou me niks verbazen als ze het vergeten zijn te verwijderen.
Door Anoniem: Dus het is de politie die een DOS aanval op zijn gebruikers heeft uitgevoerd. :P
Het is ook nooit een DDOS het is DOS zijn verschillende soorten aanvallen
Het is ook nooit een DDOS het is DOS zijn verschillende soorten aanvallen
Ho stop, Als er veel traffic is door laten we zeggen 100 computers die 1 foto op willen halen is eigenlijk al een ddos aanval ( layer 7 DoS per computer) elke computer vraagt de webpagina met de foto erop en die foto is zo groot dat de server het niet aan kan om het te verwerken dus word het een layer 7 http-get aanval die de politie zelf gemaakt heeft.
Het is dus niet een opzettelijke aanval maar gewoon een fout van de webadmin.
Eens beginnen met access.log (of equivalent)?
"Het is ze echter onduidelijk hoe ze zoiets moeten achterhalen" lijkt me eerder :P
"Het is ze echter onduidelijk hoe ze zoiets moeten achterhalen" lijkt me eerder :P
Is een bekend verschijnsel dat mensen vergeten te letten op de resolutie van een afbeelding,
en dat hierdoor vervolgens capaciteitsproblemen kunnen ontstaan.
Professionele fototoestellen werken tegenwoordig al snel met 20MB "raw" per plaatje.
Stel het betreffende plaatje was inderdaad 20MB en 1000 mensen halen bijna tegelijk dit plaatje op.
Dan verwerkt de server 20MB x 1000 = 20GB
Behalve van serververwerkingssnelheid, hangt de snelheid ook van de netwerkbandbreedte af.
Gebruikelijke netwerkbandbreedte van een beetje website is zelden meer dan 5Gbit/sec.
Plaatje is 20MB, omgerekend ca. 200Mbits (incl. overhead) die per download getransporteerd moet worden.
Voor 1000 mensen is er dan 5Gbit/s : 1000 = 5Mbit/sec/persoon aan netwerkbandbreedte beschikbaar.
Downloadsnelheid duurt in dit geval minstens ca. 200.000 Mbit : 5Mbit = ruim 11 minuten.
(mogelijk zelfs langer, omdat ik misschien nog ben uitgegaan van te riante waarden, er vast ook nog andere activiteiten op de server plaatsvinden die enige netwerkbandbreedte en servercapaciteit in beslag nemen, en nog geen rekening is gehouden met vertragingen vanwege verwerkingstijd in de server)
Maar binnen deze downloadtijd van meer dan 11 minuten kunnen er weer heel wat mensen bijkomen die óók het plaatje willen downloaden, waardoor alles trager en trager en trager gaat verlopen, het downloaden nog langer duurt, etc.
Sommige mensen zijn dan geneigd om de dowload af te breken en maar eens opnieuw te starten omdat het zo langzaam gaat, waardoor het nóg erger kan worden.
Werkt zo ongeveer als een DDoS van 1000 externe IP-adressen op de webserver van politie.nl die gemakkelijk oploopt
naar duizenden externe IP-adressen, hoewel er in dit geval waarschijnlijk weinig of geen sprake van een opzettelijke aanval is geweest, maar gewoon een capaciteitsprobleem vanwege de hoge resolutie (= groot bestand) van de foto.
en dat hierdoor vervolgens capaciteitsproblemen kunnen ontstaan.
Professionele fototoestellen werken tegenwoordig al snel met 20MB "raw" per plaatje.
Stel het betreffende plaatje was inderdaad 20MB en 1000 mensen halen bijna tegelijk dit plaatje op.
Dan verwerkt de server 20MB x 1000 = 20GB
Behalve van serververwerkingssnelheid, hangt de snelheid ook van de netwerkbandbreedte af.
Gebruikelijke netwerkbandbreedte van een beetje website is zelden meer dan 5Gbit/sec.
Plaatje is 20MB, omgerekend ca. 200Mbits (incl. overhead) die per download getransporteerd moet worden.
Voor 1000 mensen is er dan 5Gbit/s : 1000 = 5Mbit/sec/persoon aan netwerkbandbreedte beschikbaar.
Downloadsnelheid duurt in dit geval minstens ca. 200.000 Mbit : 5Mbit = ruim 11 minuten.
(mogelijk zelfs langer, omdat ik misschien nog ben uitgegaan van te riante waarden, er vast ook nog andere activiteiten op de server plaatsvinden die enige netwerkbandbreedte en servercapaciteit in beslag nemen, en nog geen rekening is gehouden met vertragingen vanwege verwerkingstijd in de server)
Maar binnen deze downloadtijd van meer dan 11 minuten kunnen er weer heel wat mensen bijkomen die óók het plaatje willen downloaden, waardoor alles trager en trager en trager gaat verlopen, het downloaden nog langer duurt, etc.
Sommige mensen zijn dan geneigd om de dowload af te breken en maar eens opnieuw te starten omdat het zo langzaam gaat, waardoor het nóg erger kan worden.
Werkt zo ongeveer als een DDoS van 1000 externe IP-adressen op de webserver van politie.nl die gemakkelijk oploopt
naar duizenden externe IP-adressen, hoewel er in dit geval waarschijnlijk weinig of geen sprake van een opzettelijke aanval is geweest, maar gewoon een capaciteitsprobleem vanwege de hoge resolutie (= groot bestand) van de foto.
Door Anoniem: Is een bekend verschijnsel dat mensen vergeten te letten op de resolutie van een afbeelding,
en dat hierdoor vervolgens capaciteitsproblemen kunnen ontstaan.
Professionele fototoestellen werken tegenwoordig al snel met 20MB "raw" per plaatje.
Stel het betreffende plaatje was inderdaad 20MB en 1000 mensen halen bijna tegelijk dit plaatje op.
Dan verwerkt de server 20MB x 1000 = 20GB
Behalve van serververwerkingssnelheid, hangt de snelheid ook van de netwerkbandbreedte af.
Gebruikelijke netwerkbandbreedte van een beetje website is zelden meer dan 5Gbit/sec.
Plaatje is 20MB, omgerekend ca. 200Mbits (incl. overhead) die per download getransporteerd moet worden.
Voor 1000 mensen is er dan 5Gbit/s : 1000 = 5Mbit/sec/persoon aan netwerkbandbreedte beschikbaar.
Downloadsnelheid duurt in dit geval minstens ca. 200.000 Mbit : 5Mbit = ruim 11 minuten.
(mogelijk zelfs langer, omdat ik misschien nog ben uitgegaan van te riante waarden, er vast ook nog andere activiteiten op de server plaatsvinden die enige netwerkbandbreedte en servercapaciteit in beslag nemen, en nog geen rekening is gehouden met vertragingen vanwege verwerkingstijd in de server)
Maar binnen deze downloadtijd van meer dan 11 minuten kunnen er weer heel wat mensen bijkomen die óók het plaatje willen downloaden, waardoor alles trager en trager en trager gaat verlopen, het downloaden nog langer duurt, etc.
Sommige mensen zijn dan geneigd om de dowload af te breken en maar eens opnieuw te starten omdat het zo langzaam gaat, waardoor het nóg erger kan worden.
Werkt zo ongeveer als een DDoS van 1000 externe IP-adressen op de webserver van politie.nl die gemakkelijk oploopt
naar duizenden externe IP-adressen, hoewel er in dit geval waarschijnlijk weinig of geen sprake van een opzettelijke aanval is geweest, maar gewoon een capaciteitsprobleem vanwege de hoge resolutie (= groot bestand) van de foto.
Niet alles is waar wat hier staat, met een 5mbit per seconde download je ookwel op 640kb per seconden en om daarmee een 20MB file te downloaden duurt geen 11minuten het duurt minder dan een minuut om een 20mb file te downloaden met 5mbit snelheid.en dat hierdoor vervolgens capaciteitsproblemen kunnen ontstaan.
Professionele fototoestellen werken tegenwoordig al snel met 20MB "raw" per plaatje.
Stel het betreffende plaatje was inderdaad 20MB en 1000 mensen halen bijna tegelijk dit plaatje op.
Dan verwerkt de server 20MB x 1000 = 20GB
Behalve van serververwerkingssnelheid, hangt de snelheid ook van de netwerkbandbreedte af.
Gebruikelijke netwerkbandbreedte van een beetje website is zelden meer dan 5Gbit/sec.
Plaatje is 20MB, omgerekend ca. 200Mbits (incl. overhead) die per download getransporteerd moet worden.
Voor 1000 mensen is er dan 5Gbit/s : 1000 = 5Mbit/sec/persoon aan netwerkbandbreedte beschikbaar.
Downloadsnelheid duurt in dit geval minstens ca. 200.000 Mbit : 5Mbit = ruim 11 minuten.
(mogelijk zelfs langer, omdat ik misschien nog ben uitgegaan van te riante waarden, er vast ook nog andere activiteiten op de server plaatsvinden die enige netwerkbandbreedte en servercapaciteit in beslag nemen, en nog geen rekening is gehouden met vertragingen vanwege verwerkingstijd in de server)
Maar binnen deze downloadtijd van meer dan 11 minuten kunnen er weer heel wat mensen bijkomen die óók het plaatje willen downloaden, waardoor alles trager en trager en trager gaat verlopen, het downloaden nog langer duurt, etc.
Sommige mensen zijn dan geneigd om de dowload af te breken en maar eens opnieuw te starten omdat het zo langzaam gaat, waardoor het nóg erger kan worden.
Werkt zo ongeveer als een DDoS van 1000 externe IP-adressen op de webserver van politie.nl die gemakkelijk oploopt
naar duizenden externe IP-adressen, hoewel er in dit geval waarschijnlijk weinig of geen sprake van een opzettelijke aanval is geweest, maar gewoon een capaciteitsprobleem vanwege de hoge resolutie (= groot bestand) van de foto.
20MB staat niet gelijk aan 200mbits zijn 2 verschillende dingen.
200mbits staat gelijk aan 25MB per seconden in internet snelheid.
Niet alles is waar wat hier staat, met een 5mbit per seconde download je ookwel op 640kb per seconden en om daarmee een 20MB file te downloaden duurt geen 11minuten het duurt minder dan een minuut om een 20mb file te downloaden met 5mbit snelheid.
20MB staat niet gelijk aan 200mbits zijn 2 verschillende dingen.
200mbits staat gelijk aan 25MB per seconden in internet snelheid.
Nee hoor, het meeste klopte best redelijk. Eén byte is 8 bits.20MB staat niet gelijk aan 200mbits zijn 2 verschillende dingen.
200mbits staat gelijk aan 25MB per seconden in internet snelheid.
"Bit" wordt meestal aangegeven met een kleine letter "b". "Byte" wordt aangegeven met hoofdletter "B"
Voor het gemak en omdat er wat extra netwerkverkeer nodig is ("overhead"), heb ik bij het omrekenen van bytes naar bits een factor 10 gebruikt in plaats van 8.
Maar ik zie dat ik wel één ernstige fout heb gemaakt. Het gaat om deze regel:
Downloadsnelheid duurt in dit geval minstens ca. 200.000 Mbit : 5Mbit = ruim 11 minuten.
Dat klopt niet. Eén plaatje van 20MByte is namelijk ca. 200Mbit wat over de lijn moet. Niet 200.000 MbitDe rekensom wordt dan: 200Mbit : 5Mbit = 40 seconden.
(alle duizend plaatjes gedeeld door totale netwerkbanbreedte = 200Gbit : 5Gbit, was ook OK geweest)
Inderdaad is dit minder dan een minuut als alle andere uitgangspunten zouden kloppen (doen ze vast niet)
en er geen rekening wordt gehouden met de verwerkingssnelheid van de server. (zou eigenlijk wel moeten)
Maar hé, het ging me ook niet om een precisie berekening te showen, maar om het principe.
De werkelijke netwerkbandbreedte zou bijv. best vele malen lager kunnen zijn dan geschat, en het bezoekersaantal vele malen groter. En dan nog een overbelaste server erbij, en je bent zo weer ver over de tien minuten downloadtijd. ;)
Evengoed bedankt voor uw oplettendheid. (en de mijne ook natuurlijk) :))
Reageren
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.