ddos
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?
Gewijzigd op 05/05/2016 22:53:55 door Aad B
Gewijzigd op 05/05/2016 22:57:53 door - Ariën -
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?
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.
Gewijzigd op 05/05/2016 23:28:39 door Ben van Velzen
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 :-)
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.
Gewijzigd op 06/05/2016 00:21:57 door Ben van Velzen
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! ;-)
Dus in plaats van dat je inbreekt in de kluis van de bank blaas je gewoon het hele gebouw op :).
Of nog liever: de infrastructuur voor het gebouw, zodat niemand meer bij het gebouw kan komen ;)
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? :-)
Het is nu de tweede keer dat je die vraag stelt. Wat leidt je tot de conclusie dat zoiets mogelijk zou zijn?
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.
Gewijzigd op 06/05/2016 21:30:54 door Ben van Velzen
Oké ... gelukkig maar. Ik ben weer een beetje gerustgesteld ;-)
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.
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 :-)