Een poort met een service, voornamelijk http, wordt doorgaans belast met honderdduizenden calls. Het kan uiteraard ook op een ftp poort, als de service (firewall) moet "nadenken" over een deny kost dat ook tijd en dus overbelast dat wellicht het systeem bij duizenden aanvragen.
Ja, maar de druk zal dan op het ervoorliggende netwerk liggen. Zie het als een winkel van de V&D waar 1.000 mensen op elkaar staan te dringen voor een kleine ingang. De straat zal dan niet makkelijk begaanbaar zijn voor anderen. Als je de deur dan sluit (firewall) dan blijft de mensenmassa voor de deur staan.
Maar het kan dus niet zo zijn dat mijn firewall een poort (ftp of ssh) netjes blokkeert, en dat door die 'druk' de firewall bezwijkt waardoor er ineens een poort opengaat?
Daarbij worden veel aanvallen gedaan op basis van het onderliggende protocol: geen HTTP of FTP of wat dan ook, maar bijvoorbeeld packet sequences binnen TCP (denk aan SYN flooding etc). Ook UDP is een veelgebruikte vector, omdat in tegenstelling tot TCP er geen congestion control aanwezig is. Een kwestie van afvuren, en omdat het stateless is heb je ook geen antwoord om rekening mee te houden. Kort gezegd heb je dus een aantal vectoren. Onder andere de volgende: de applicatielaag (overbelast een server applicatie, bijvoorbeeld http), de netwerkstack (overbelast de packet queues van je OS of voorliggende routers), of iets exotischer: overbelast een service waar je gebruik van maakt (denk hierbij aan DNS of mogelijk zaken als BGP, RIP etc).
[size=xsmall]Toevoeging op 05/05/2016 23:20:52:[/size]
En nee, een poort zal niet vanzelf open gaan, het gebeurt veel eerder dat alle verbindingen uiteindelijk geweigerd worden.
[size=xsmall]Toevoeging op 05/05/2016 23:23:14:[/size]
Misschien is het leuk om je eens in te lezen op een basale HTTP aanval als slowloris, of een broadcast aanval als smurf. Gekoppeld met kennis van in het eerste geval het HTTP protocol, en in het tweede geval netwerkbeginselen als broadcast kun je heel duidelijk zien waar je mee te maken hebt. Slowloris en smurf zijn geen echte DDOS, maar gewoon DOS, maar smurf is in effect wel DDOS, omdat er onbedoeld een hoop antwoorden komen vanaf een complete ip range. Uiteraard is dit niet een aanval die nog langer werkt, maar het laat zien dat de netwerklaag veelzijdiger is dan alleen een doorgeefluik. Het is op verschillende manieren te misbruiken.
Ben, dank je voor je uitleg, maar het klinkt allemaal nogal technisch. Ik wil je niet vragen om het allemaal stapje voor stapje uit te leggen (veel te veel werk), maar kun je mij verwijzen naar een simpele online uitleg waarin wordt uitgelegd waar jij het nu over hebt? Ik kan het zelf wel gaan zoeken ... maar aangezien ik niet echt een idee heb waar je het over hebt, ga ik het waarschijnlijk ook niet vinden :-)
Voor het overige denk ik dat je gewoon naar SYNFLOOD moet kijken (iets dat met syncookies een mitigatie kent). Uiteraard heeft TCP een hoop verschillende opties, en anti congestion methodes. Ook hier kan ik je verwijzen naar wikipedia (liefst in het Engels, omdat dit uitgebreider is).
Verder weet ik zo snel geen online leesvoor, maar ik ga er voor het gemak van uit dat je de definitie van denial of service kent, waarna vanzelf distributed denial of service volgt (denial of service op grotere schaal).
Volg vooral het pad van de lokale machine naar het internet (ARP,BGP/RIP etc). Uit deze zaken kun je allerlei zaken pikken die van invloed zijn op de betrouwbaarheid van een connectie, of met denkwerk zijn te overbelasten.
Het belangrijkste bij mitigatie is dat je weet wat er op welke laag mis kan gaan. Wanneer je dit begrip hebt zul je ook zien dat (vaak duurbetaalde) appliances uitkomst kunnen bieden. Denk hierbij aan patroonherkennende firewalls etc.
Oké, thanks. Ik heb me nooit echt beziggehouden met serverbeheer, maar ik vind het wel leuk om er wat meer over te leren (en dus ook over wat er mis kan gaan). Ik zal je linkjes eens gaan lezen. Thanks! ;-)
Oké, helder. Maar het kan dus niet zo zijn dat als ik met mijn firewall bijv. de SSH-poort dicht heb gezet, dat die onder de druk van een DDoS-aanval ineens bezwijkt en spontaan open knalt? :-)
