NCSC: ddos-aanvallen op internetproviders uitzonderlijk groot
De recente ddos-aanvallen op internetproviders, waaronder Delta, Online.nl, Tweak en Freedom Internet, zijn voor Nederlandse maatstaven uitzonderlijk groot, zo laat het Nationaal Cyber Security Centrum (NCSC) vandaag weten. Het NCSC ontving meldingen van aanvallen die oplopen tot 250 Gbps.
Vorig jaar werden in totaal elf aanvallen van boven de 40 Gbps in Nederland waargenomen, waarvan de grootste 124 Gbp was. De aanvallers hebben het voorzien op de dns-infrastructuur van organisaties en proberen die via UDP-floods plat te leggen. Bij een UDP-flood wordt een grote hoeveelheid UDP-pakketjes naar de server van de aangevallen organisatie gestuurd, met het doel om die te overbelasten.
Bij een UDP-flood wordt er met name misbruik gemaakt van de stappen die een server uitvoert wanneer die reageert op een UDP-pakket dat naar een serverpoort is gestuurd. Wanneer een server een UDP-pakket op een bepaalde poort ontvangt vinden er twee stappen plaats. De server kijkt eerst of er programma's draaien die naar verzoeken op de betreffende poort luisteren.
Wanneer er geen programma's zijn die pakketjes op die poort ontvangen verstuurt de server een ICMP-pakket naar de afzender dat de bestemming onbereikbaar was. Elk nieuw UDP-pakket dat de server ontvangt wordt op deze manier verwerkt, waarbij in het geval van een grote hoeveelheid UDP-pakketten uiteindelijk alle resources van de server worden gebruikt, waardoor de server niet meer op normaal verkeer kan reageren.
Motieven
In het verleden zijn bedrijven afgeperst met ddos-aanvallen, waarbij er werd gedreigd om websites plat te leggen als er niet zou worden betaald. Het NCSC heeft meldingen ontvangen van partijen die afpersingsmails hebben ontvangen uit naam van een statelijke actor waarin gedreigd wordt met een ddos-aanval. Er zijn ook meldingen bij de overheidsinstantie binnengekomen van partijen die slachtoffer van ddos-aanvallen zijn geworden.
"Er is geen indicatie dat deze afpersingsmails en de hierboven genoemde ddos-aanvallen verband houden met elkaar", aldus het NCSC. "Het motief van de ddos-aanvallen in Nederland is nog onbekend." De overheidsinstantie houdt contact met de aangevallen organisaties en politie en is bezig met een technisch onderzoek naar de aanvallen.
Reacties (14)
waarbij in het geval van een grote hoeveelheid UDP-pakketjes uiteindelijk alle resources van de server worden gebruikt, waardoor de server niet meer op normaal verkeer kan reageren.
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, maar dat het netwerkpad naar de server niet voldoende bandbreedte heeft om dit verkeer te verwerken, waardoor er heel veel verkeer gedropt wordt, waaronder het verkeer van de legitieme gebruikers. Die ervaren dan dat de server bijna niet reageert.Of je al of niet een "ICMP port unreachable" terugstuurt dat is meestal geen issue, wat wel een probleem kan zijn is dat je een UDP reply terug stuurt op het request dat veel groter is dan het binnenkomende request, waardoor je de attack nog eens versterkt op je eigen netwerk. Bijvoorbeeld aanvalles sturen een DNS request met een grote resultaatset, zoals de TXT records van je domein waar vaak behoorlijke lappen tekst in kunnen staan voor allerlei DNS-based autorisatiemechanismen.
Wat ik er van in de pers gelezen heb is dat de betrokken providers inderdaad het probleem ondervinden dat de DNS resolvers van hun klanten niet werken (die klanten kunnen dat dan omzeilen door andere DNS resolvers in te stellen, zoals 8.8.8.8 of 1.1.1.1)
Het mag duidelijk zijn dat het niet slim is om je klant DNS resolvers op dezelfde machines te draaien als je DNS servers voor de domeinen die je host, en al helemaal niet op dezelfde adressen. Maar dat soort situaties is soms in een grijs verleden ontstaan.
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.Door Anoniem:
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Hahaha al die bedrijven zijn zo afhankelijk geworden van Interslet in het kader van meer digitaal, samenwerken, efficienter, sneller bla bla.... zonder ook maar geen flauw benul van de gevaren.
Wen er maar aan want dit soort praktijken word alleen maar erger...
Voor overheden / landen natuurlijk ook zeer interessant want je kan nogal makkelijk heel wat zaken lam leggen.
Wen er maar aan want dit soort praktijken word alleen maar erger...
Voor overheden / landen natuurlijk ook zeer interessant want je kan nogal makkelijk heel wat zaken lam leggen.
Door Anoniem:
WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Door Anoniem:
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
DNS amplify is ook meestal udp/53 ... en idd queues vol is droppen maar... dus met 250Gb/s lopen er heel wat queues vol...
Wel gek dat men niet goed kan rate-limiten dan want dat is wat ik voor ons bedrijf doe bij DDOS aanvallen en dat werkt op zich goed.... nooit complete uitval iig.
Door Anoniem:
Of je al of niet een "ICMP port unreachable" terugstuurt dat is meestal geen issue, wat wel een probleem kan zijn is dat je een UDP reply terug stuurt op het request dat veel groter is dan het binnenkomende request, waardoor je de attack nog eens versterkt op je eigen netwerk. Bijvoorbeeld aanvalles sturen een DNS request met een grote resultaatset, zoals de TXT records van je domein waar vaak behoorlijke lappen tekst in kunnen staan voor allerlei DNS-based autorisatiemechanismen.
Wat ik er van in de pers gelezen heb is dat de betrokken providers inderdaad het probleem ondervinden dat de DNS resolvers van hun klanten niet werken (die klanten kunnen dat dan omzeilen door andere DNS resolvers in te stellen, zoals 8.8.8.8 of 1.1.1.1)
Het mag duidelijk zijn dat het niet slim is om je klant DNS resolvers op dezelfde machines te draaien als je DNS servers voor de domeinen die je host, en al helemaal niet op dezelfde adressen. Maar dat soort situaties is soms in een grijs verleden ontstaan.
Keurig en correct verwoord!waarbij in het geval van een grote hoeveelheid UDP-pakketjes uiteindelijk alle resources van de server worden gebruikt, waardoor de server niet meer op normaal verkeer kan reageren.
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, maar dat het netwerkpad naar de server niet voldoende bandbreedte heeft om dit verkeer te verwerken, waardoor er heel veel verkeer gedropt wordt, waaronder het verkeer van de legitieme gebruikers. Die ervaren dan dat de server bijna niet reageert.Of je al of niet een "ICMP port unreachable" terugstuurt dat is meestal geen issue, wat wel een probleem kan zijn is dat je een UDP reply terug stuurt op het request dat veel groter is dan het binnenkomende request, waardoor je de attack nog eens versterkt op je eigen netwerk. Bijvoorbeeld aanvalles sturen een DNS request met een grote resultaatset, zoals de TXT records van je domein waar vaak behoorlijke lappen tekst in kunnen staan voor allerlei DNS-based autorisatiemechanismen.
Wat ik er van in de pers gelezen heb is dat de betrokken providers inderdaad het probleem ondervinden dat de DNS resolvers van hun klanten niet werken (die klanten kunnen dat dan omzeilen door andere DNS resolvers in te stellen, zoals 8.8.8.8 of 1.1.1.1)
Het mag duidelijk zijn dat het niet slim is om je klant DNS resolvers op dezelfde machines te draaien als je DNS servers voor de domeinen die je host, en al helemaal niet op dezelfde adressen. Maar dat soort situaties is soms in een grijs verleden ontstaan.
Door Anoniem:
DNS amplify is ook meestal udp/53 ... en idd queues vol is droppen maar... dus met 250Gb/s lopen er heel wat queues vol...
Wel gek dat men niet goed kan rate-limiten dan want dat is wat ik voor ons bedrijf doe bij DDOS aanvallen en dat werkt op zich goed.... nooit complete uitval iig.
DNS amplify is ook meestal udp/53 ... en idd queues vol is droppen maar... dus met 250Gb/s lopen er heel wat queues vol...
Wel gek dat men niet goed kan rate-limiten dan want dat is wat ik voor ons bedrijf doe bij DDOS aanvallen en dat werkt op zich goed.... nooit complete uitval iig.
Of rate limit effectief is, hangt samen met je doel. In beginsel ben je met een rate limit gevoeliger voor een (d)DOS aanval dan zonder rate limiter. Immers, een rate limit leg je onder de maximale capaciteit en je verlaagt feitelijk de capaciteit van je dienst. Als je server een capaciteit heeft van 1.000 parallelle sessies en jij zet een rate limit op 800 sessies, dan zal de server sneller stoppen met het reageren op verzoeken. En dat is dus precies de primaire intentie van een (d)DOS.
Daarmee zeg ik niet dat rate limits onverstandig zijn. Met het aanbrengen van een rate limit zorg je dat de CPU nog ruimte over heeft om andere processen te draaien. Daarmee kan je met een rate limit wel beschermen tegen ongewenst crashen van systemen en services, maar niet tegen de (d)DOS zelf.
Sterker, tegen een DDOS beschermen kan eigenlijk alleen in het wereldwijde netwerk. Als je een filter op het eindpunt zet, dan lopen de lijnen aan de voorkant van je filter (het datacenter) vol en hapert de dienstverlening met de buitenwereld alsnog. Door in het wereldwijde netwerk ongewenste datapakketjes al te droppen, voorkom je dat het eindpunt volloopt. De afvoerputjes voor (d)DOS verkeer moeten zo dicht mogelijk bij de bron zitten, niet bij het eindpunt.
Door Anoniem:
WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Door Anoniem:
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Een poort kan maar door één programma gebruikt worden. Een webserver draait op poort 80 of 443 en redirect vervolgens naar een poort boven 1024. Wanneer een flood aan connecties verschijnen kan je alle beschikbare poorten snel vullen. En meestal is een server geconfigureerd dat deze 'maar' een x-aantal simultane connecties accepteert.
Lemma: zelfs met een smalle bandbreedte kun je veel poorten vullen zolang je de connecties maar druppelsgewijs blijft voeden zodat de server de connectie niet out-timed.
De bronnen van deze staats-gestuurde ellende zijn gekend - dus moeten we daar via interpol maar wat mee doen. Afsluiten van toegangen - ongeacht de gevolgen.
Door Anoniem:
Een poort kan maar door één programma gebruikt worden. Een webserver draait op poort 80 of 443 en redirect vervolgens naar een poort boven 1024. Wanneer een flood aan connecties verschijnen kan je alle beschikbare poorten snel vullen. En meestal is een server geconfigureerd dat deze 'maar' een x-aantal simultane connecties accepteert.
Door Anoniem:
WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Door Anoniem:
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Een poort kan maar door één programma gebruikt worden. Een webserver draait op poort 80 of 443 en redirect vervolgens naar een poort boven 1024. Wanneer een flood aan connecties verschijnen kan je alle beschikbare poorten snel vullen. En meestal is een server geconfigureerd dat deze 'maar' een x-aantal simultane connecties accepteert.
Dat is een klok en klepel verhaal - met een paar totaal onjuiste uitspraken.
Inderdaad draait er maar één programma op een poort, maar dat programma 'redirect' helemaal niet naar een andere poort.
Het tupel (sourceip , source poort, destination ip, destination poort) moet uniek zijn.
Op een webserver staan gewoon alle connecties met poort 80 of poort 443 - niks 'redirect naar andere poort' .
*Draai* een webserver, en kijk (netstat , ss ) naar staande sessies.
Er zijn verschillende programmeerstijlen om te werken met veel connecties - klassiek is dat de ontvanger zichzelf fork()'ed en in het child-proces werkt met de zojuist binnengemomen connectie.
Maar binnen het proces met meerdere threads werken kan ook, of gewoon één proces dat alle sessies afhandelt.
(Lees over Apache Prefork, Worker MPM en Event MPM voor de drie stijlen die de Apache webserver in de loop van de tijd gekregen heeft ).
Of lees wat serieuze boeken over socket programming . [zoek met termen als socket, select(), en epoll_wait() ]
Het is natuurlijk wel zo dat een staande connecties resources kost op een server : een stukje kernel geheugen voor de socket, en stuk resources van het webserver proces, of een child proces . Daar zijn, afhankelijk van de specs van de server en configuratie maxima voor ingesteld . Of absolute maxima - geheugen vol is vol .
Dus veel staande (of half-open) connecties kan het aantal _sockets_ dan wel het aantal processen claimen.
Alleen dat heeft _niets_ te maken met tcp _poorten_ .
Een *socket* is geen *tcp/udp poort* . Ik hoop dat het je eigen misverstand is, en niet dat je een boek of leraar hebt die socket met poort vertaalt .
Lemma: zelfs met een smalle bandbreedte kun je veel poorten vullen zolang je de connecties maar druppelsgewijs blijft voeden zodat de server de connectie niet out-timed.
Dat is bijna juist - maar je vult geen *poorten* , maar claimt sockets/processen/filedescriptors .
Het nadeel, vanuit DoS perspectief - je hebt hier een staande tcp sessie voor nodig . Je kunt het dus niet effectief spoofen, of met reflectie ampliceren zoals de udp ldap e.d. floods .
Dat maakt filtering aan de verdedigende kant een heel stuk makkelijker.
05-09-2020, 15:52 door
didrix
Door Anoniem:Een poort kan maar door één programma gebruikt worden. Een webserver draait op poort 80 of 443 en redirect vervolgens naar een poort boven 1024. Wanneer een flood aan connecties verschijnen kan je alle beschikbare poorten snel vullen. En meestal is een server geconfigureerd dat deze 'maar' een x-aantal simultane connecties accepteert.
Een verbinding is uniek op basis van ip+poort van bron en ip+poort van bestemming. Een service draait op een bepaald server ip+poort, dus je kunt (iig in theorie*) ongeveer 65k verbindingen per client ip bouwen. Normaal gesproken geen probleem dus, tenzij er geproxied wordt aan de serverkant, waarbij in het geval van tcp door de aanvallers volledige verbindingen moeten worden opgebouwd. Echter is afslaan van een aanval in deze situatie kinderspel, omdat je kunt rate/connection limiten obv ip. Dit is in feite wat CloudFlare doet.
*In de praktijk ben je niet gelimiteerd door het tcp-protocol. Je bent nog wel gelimiteerd door geheugen, cpu, bandbreedte, kernel limieten etc.
Door Anoniem:
Dat is een klok en klepel verhaal - met een paar totaal onjuiste uitspraken.
Inderdaad draait er maar één programma op een poort, maar dat programma 'redirect' helemaal niet naar een andere poort.
Het tupel (sourceip , source poort, destination ip, destination poort) moet uniek zijn.
Op een webserver staan gewoon alle connecties met poort 80 of poort 443 - niks 'redirect naar andere poort' .
Dat is een klok en klepel verhaal - met een paar totaal onjuiste uitspraken.
Inderdaad draait er maar één programma op een poort, maar dat programma 'redirect' helemaal niet naar een andere poort.
Het tupel (sourceip , source poort, destination ip, destination poort) moet uniek zijn.
Op een webserver staan gewoon alle connecties met poort 80 of poort 443 - niks 'redirect naar andere poort' .
Er klopt inderdaad voor een echte webserver niks van dat verhaal.
Maar misschien heeft hij een reverse proxy of een SSL accellerator voor een website (zien) zitten.
Dan loop je wel tegen dat soort problemen aan als die zelf vanaf 1 IP adres de connecties gaat maken naar de achterliggende webserver.
Zo'n ding moet dus meerdere adressen gebruiken als ie heel veel connecties moet openzetten.
Door Anoniem:
DNS amplify is ook meestal udp/53 ... en idd queues vol is droppen maar... dus met 250Gb/s lopen er heel wat queues vol...
Wel gek dat men niet goed kan rate-limiten dan want dat is wat ik voor ons bedrijf doe bij DDOS aanvallen en dat werkt op zich goed.... nooit complete uitval iig.
Door Anoniem:
WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Door Anoniem:
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
DNS amplify is ook meestal udp/53 ... en idd queues vol is droppen maar... dus met 250Gb/s lopen er heel wat queues vol...
Wel gek dat men niet goed kan rate-limiten dan want dat is wat ik voor ons bedrijf doe bij DDOS aanvallen en dat werkt op zich goed.... nooit complete uitval iig.
Inderdaad, alle verkeer gaat naar en van poort 53 (udp, mag ook tcp zijn). De server houdt orde door het serienummer van het pakket te gebruiken. Het aantal beschikbare uitgaande poorten voor ander verkeer kan wel problematisch worden, want dat gaat via poorten 1024 t/m 5000 (of 65535). Oude versies van Windows Server bijvoorbeeld konden in default setting last krijgen in een normale omgeving van de beperking van het aantal poorten. De grap daarbij was dat Unix mensen dachten dat zij de RFC's volgden, maar het was juist Microsoft die zich daar strikter aan hield (de 5000 grens). Daarbij zijn er ook nog wait times van poorten, ze zijn niet zomaar na gebruik beschikbaar. Daarvoor moet je low level tcp/ip instellingen wijzigen.
Heel erg ruim voordat 250 Gbps verkeer wordt gehaald zijn alle queues al gevuld, zelfs met een cluster of een load balancer. Voor een functionele DDoS heb je niet zoveel verkeer nodig.
Door Anoniem:
Dat is een klok en klepel verhaal - met een paar totaal onjuiste uitspraken.
Inderdaad draait er maar één programma op een poort, maar dat programma 'redirect' helemaal niet naar een andere poort.
Het tupel (sourceip , source poort, destination ip, destination poort) moet uniek zijn.
Op een webserver staan gewoon alle connecties met poort 80 of poort 443 - niks 'redirect naar andere poort' .
*Draai* een webserver, en kijk (netstat , ss ) naar staande sessies.
Er zijn verschillende programmeerstijlen om te werken met veel connecties - klassiek is dat de ontvanger zichzelf fork()'ed en in het child-proces werkt met de zojuist binnengemomen connectie.
Maar binnen het proces met meerdere threads werken kan ook, of gewoon één proces dat alle sessies afhandelt.
(Lees over Apache Prefork, Worker MPM en Event MPM voor de drie stijlen die de Apache webserver in de loop van de tijd gekregen heeft ).
Of lees wat serieuze boeken over socket programming . [zoek met termen als socket, select(), en epoll_wait() ]
Door Anoniem:
Een poort kan maar door één programma gebruikt worden. Een webserver draait op poort 80 of 443 en redirect vervolgens naar een poort boven 1024. Wanneer een flood aan connecties verschijnen kan je alle beschikbare poorten snel vullen. En meestal is een server geconfigureerd dat deze 'maar' een x-aantal simultane connecties accepteert.
Door Anoniem:
WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Door Anoniem:
Bij een DDoS van 250 Gbps zal het probleem normaal gesproken niet zijn dat de resources van de server worden gebruikt, ...
Een TCP-IP stack heeft maar 65536 poorten beschikbaar, met deze bandbreedte zijn alle poorten snel gevuld.WTF ?
Je snapt echt het concept poorten (noch TCP/IP) niet - je schrijft alsof er een gereserveerde bandbreedte per poort bestaat .
En alsof het een 'tcp poort' is die gevuld wordt.
Een pakket is een pakket. In de header staat wat nummers die er udp of tcp of icmp van maken, en bij sommige protocollen zoals tcp en udp ook nog wat nummers die 'poorten' genoemd worden.
Wat er overvuld wordt zijn interfaces en queues. En wat niet past wordt gedropt - en wat er gedropt wordt zijn dan ook heel hoge percentages van 'normaal' verkeer want dat past ook niet.
Een poort kan maar door één programma gebruikt worden. Een webserver draait op poort 80 of 443 en redirect vervolgens naar een poort boven 1024. Wanneer een flood aan connecties verschijnen kan je alle beschikbare poorten snel vullen. En meestal is een server geconfigureerd dat deze 'maar' een x-aantal simultane connecties accepteert.
Dat is een klok en klepel verhaal - met een paar totaal onjuiste uitspraken.
Inderdaad draait er maar één programma op een poort, maar dat programma 'redirect' helemaal niet naar een andere poort.
Het tupel (sourceip , source poort, destination ip, destination poort) moet uniek zijn.
Op een webserver staan gewoon alle connecties met poort 80 of poort 443 - niks 'redirect naar andere poort' .
*Draai* een webserver, en kijk (netstat , ss ) naar staande sessies.
Er zijn verschillende programmeerstijlen om te werken met veel connecties - klassiek is dat de ontvanger zichzelf fork()'ed en in het child-proces werkt met de zojuist binnengemomen connectie.
Maar binnen het proces met meerdere threads werken kan ook, of gewoon één proces dat alle sessies afhandelt.
(Lees over Apache Prefork, Worker MPM en Event MPM voor de drie stijlen die de Apache webserver in de loop van de tijd gekregen heeft ).
Of lees wat serieuze boeken over socket programming . [zoek met termen als socket, select(), en epoll_wait() ]
Er is geen fork of multithreading nodig om op netwerkniveau antwoord te geven op pakketten van diverse IP's op netwerkniveau. Dat is een keuze van de programmeur om taken af te handelen, op netwerkniveau kun je prima op een poort meerdere clients afhandelen. Ook vanuit één proces of thread.
Op netwerkniveau gaat het om de netwerkhardware en de kernel die voldoende buffers (voor de wachtrij/queueu) moet hebben om netwerkverkeer af te handelen. Bij een DDoS van meer dan 1 (of 10/40) Gbps per server is de kans groot dat die buffers voortdurend vol zitten en er dus pakketten worden gedropt.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?