05/05/2016 22:31:51
Hey mensen,
Een DDoS-aanval is die eigenlijk gericht op willekeurige poorten op je server? Of zoeken ze eerst een open poort die ze vervolgens gaan aanvallen?
En stel je zet bijv. je ftp-poort (21) in je firewall op blokkeren (deny). Kan die poort dan nog aangevallen worden via DDoS?
10/05/2024 04:59:23
05/05/2016 22:53:30
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.
Gewijzigd op 05/05/2016 22:53:55 door
Aad B
Beheerder05/05/2016 22:56:59
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.
Gewijzigd op 05/05/2016 22:57:53 door
- Ariën -
05/05/2016 23:15:50
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?
05/05/2016 23:19:57
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).
Toevoeging op 05/05/2016 23:20:52:
En nee, een poort zal niet vanzelf open gaan, het gebeurt veel eerder dat alle verbindingen uiteindelijk geweigerd worden.
Toevoeging op 05/05/2016 23:23:14:
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.
05/05/2016 23:55:41
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 :-)
06/05/2016 00:04:57
Om bij de basis te beginnen (wikipedia heeft in dit geval gelijk):
https://en.wikipedia.org/wiki/Slowloris_(computer_security)
https://en.wikipedia.org/wiki/Smurf_attack
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.
06/05/2016 00:36:55
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! ;-)
06/05/2016 15:20:39
Het doel van een DDOS-aanval lijkt mij ook lamleggen, niet inbreken.
Dus in plaats van dat je inbreekt in de kluis van de bank blaas je gewoon het hele gebouw op :).
06/05/2016 17:14:44
Of nog liever: de infrastructuur voor het gebouw, zodat niemand meer bij het gebouw kan komen ;)
06/05/2016 21:05:01
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? :-)
06/05/2016 21:21:11
Het is nu de tweede keer dat je die vraag stelt. Wat leidt je tot de conclusie dat zoiets mogelijk zou zijn?
06/05/2016 21:25:39
Geen idee ... dat is waarom ik het vraag :-)
Mijn vraag is simpelweg of iptables solide genoeg is om een poort dicht te (blijven) houden, of dat het wellicht mogelijk is door heel hard aan die poort te rammelen dat alsnog de poort opengaat.
06/05/2016 21:30:14
Het zou wel ontzettend vreemd zijn als een poort opeens open vliegt, gezien er juist werk verricht moet worden om verkeer door te laten, zowel op filter niveau als op routing niveau. Simpel gezegd: nee, iptables is niet op die manier te overbelasten. Als dat wel zo was zou het al erg lang niet meer gebruikt worden. Een firewall is iets anders dan een mens, je kunt niet door lang genoeg zeuren opeens een poort openen. Zo werkt het gewoon niet.
06/05/2016 21:32:02
Oké ... gelukkig maar. Ik ben weer een beetje gerustgesteld ;-)
06/05/2016 21:37:27
Uiteraard beveilig je wel verder dan alleen met een firewall, vooral voor het geval je zelf een fout maakt of je specifiekere beveiliging nodig hebt. Je zet immers geen niet authenticerende mailserver op, "want hij is alleen van localhost te benaderen". Kan wel door de server zelf op de lo adapter te laten luisteren, maar dan wordt ontvangen van mail weer zo lastig. En een open relay wil je ook niet. Een simpel voorbeeld, maar het belangrijk om alles van voor tot achter goed geregeld te hebben.
06/05/2016 21:40:26
Ik begrijp wat je bedoelt. Ik ben 'van huis uit' geen systeembeheerder, maar ik krijg wel steeds beter door hoe dingen werken, ook mede dankzij o.a. jouw hulp. Ik gebruik Plesk waarin veel zaken standaard al zijn beveiligd, maar ik wil me ook buiten die standaardzaken goed beveiligen. Vergt wat inspanning en motivatie, maar met kleine stapjes komen we er wel :-)
