Het volgende artikel is deel 2 in een driedelige serie over het oplossen van DDoS-aanvallen, en het is een gastpost van Matt Conran van Netwerk inzicht. In dit artikel behandelt Matt de uitdagingen voor de handmatige aanpak van DDoS-probleemoplossing.
Een DDoS-aanval (Distributed Denial of Service) is een hinderlaag om de online diensten van zich te vervreemden door enorm verkeer van talloze bronnen. Bij deze cyberaanval gebruikt de beul meer dan één uniek IP-adres. Dus, als we aan DDoS denken, zijn de belangrijkste elementen die in ons opkomen de componenten voor detectie en beperking. Dit is tenslotte waar het geld wordt gepusht en waar de nieuwe mooie functies worden geïntroduceerd. Het is echter de volledige end-to-end oplossingseffectiviteit die de DDoS op tijd stopt.
Het ontbrekende stukje van de puzzel is het oplossen van problemen. Dat merken velen een netwerk in kaart brengen en het oplossen van problemen is een technische taak die alleen de handen van een technicus vereist. Maar er is een heel bedrijfsproces dat moet worden geïntegreerd, wat leidt tot het laatste hands-on configuratiewerk, waardoor de DDoS wordt gestopt.
De procedure omvat de coördinatie van mensen van verschillende teams en technische achtergronden om efficiënt samen te werken en een oplossing te vormen. Dit is niet iets dat automatisch of toevallig gebeurt. Het moet worden geoefend en nauwkeurig worden gecontroleerd. Een van de grootste problemen met DDoS-aanvallen is het gebrek aan voorbereiding. Gebrek aan voorbereiding leidt tot paniek en als dat gebeurt, wordt er niets opgelost.
Alle technische ervaring in de wereld zal je niet helpen, tenzij de culturen tussen de teams efficiënt functioneren. En bij een DDoS-evenement heb je zeker meerdere teams nodig die samenwerken.
De kunst van het netwerken heeft geleid tot duizenden verschillende netwerkontwerpen die vaak unieke sneeuwvlokken worden genoemd. In een SP-netwerk biedt het vaak dezelfde connectiviteitsvereiste voor het einddoel, zoals een L2VPN en L3PVPN. Het type netwerkontwerp verschilt echter aanzienlijk van provider tot provider.
Veel ontwerpen blijven op het hoofd van de ontwerper staan, terwijl het in een centrale repository zou moeten staan, bijgehouden met wijzigingen. Het oplossen van problemen met verschillende netwerkontwerpen en -configuraties wordt moeilijk wanneer u wordt aangevallen door DDoS met volumes die de Terabyte-schaal bereiken.
Op afstand geactiveerd zwart gat (RTBH) is een van de meest voorkomende manieren om een aanval af te slaan. Het gebruikt Border Gateway Protocol (BGP) binnen het netwerk en installeert regels in de doorstuurplaats om de bestemming te blokkeren om de DDoS-aanval te beperken. Het voltooit in wezen de DDoS-aanval namens de aanvaller. RTHB is in het verleden nuttig geweest, maar een van de tekortkomingen is dat het zowel de routering in de missiemodus als de beveiligingsfuncties op hetzelfde apparaat combineert.
Firewallregels die worden gebruikt om een aanval te blokkeren, worden in het netwerkapparaat geplaatst dat de kernrol vervult bij het routeren van verkeer van punt A naar punt B. Technisch gezien hebben we dus al uitdagingen. Om dit nog erger te maken, moeten we meer dan vaak twee teams combineren om op hetzelfde apparaat te werken, zowel beveiliging als netwerk. Vanuit operationeel oogpunt is de meest gebruikelijke benadering van DDoS-mitigatie het combineren van twee technische hoeden op hetzelfde apparaat.
Op het hoogtepunt van een DDoS-aanval is teamsamenwerking van cruciaal belang en de bestaande DDoS-mitigatie zoals RTBH kan teamcoördinatieproblemen opleveren. Om efficiënt tegen DDoS te beschermen, kan een oplossing nooit alleen vanuit technisch gezichtspunt worden gezien. Het is het hele probleemoplossingsproces en de samenwerking van teams die de race met succes wint.
Voor efficiënte DDoS-bescherming moet u alle lagen van de Open Systems Interconnection-model (OSI)-stack onderzoeken. Het gaat niet meer om slechts één laag; de cybercriminelen gebruiken meerdere lagen om in een netwerk binnen te dringen. Parallelle aanvallen worden vaak gebruikt door beide te combineren, de volumetrische Layer 4 met de Layer 7 applicatie-aanval. Dus in wezen hebben we twee lagen van de stapel die probleemoplossing vereisen: Laag 4 en Laag 7.
Dit kan mogelijk ook twee afzonderlijke teams omvatten: netwerkteam voor laag 4 en een toepassingsteam voor laag 7. Combineer een paar firewalls en load balancers en we hebben een mooie mix van verspreide teaminteractie. Dit soort samenwerking moet efficiënt worden gestroomlijnd en gecoördineerd.
De handmatige aanpak van DDoS bevat een aantal stappen voordat je daadwerkelijk bij de bron van het probleem komt. Al deze moeten mogelijk worden uitgevoerd door verschillende mensen, teams, plaatsen en tijden. De betrokken personen zullen hoogstwaarschijnlijk niet naast elkaar zitten. Afhankelijk van de aanval en hoe deze werd gesignaleerd, is wat telt. Als het een aanval op applicatieniveau betreft, moet een beheerder mogelijk de logboeken van afzonderlijke servers bekijken door handmatig in te loggen of via een centrale Log Analyser.
Een andere beheerder moet mogelijk een groep machines volgen en opdrachten geven zoals "Netstat" om te bepalen welke verbindingen open zijn op die server of dat apparaat. Een andere beheerder moet controleren of de machinebelasting hoog is of het aantal bepalen HTTP-processen rennen. Een Linux- of firewallbeheerder moet aangepaste scripts maken en deze uitvoeren tegen IP-tabellen om andere soorten beveiligingsinformatie te bepalen.
Aangepaste scripts die door individuele ingenieurs zijn gemaakt, zijn geweldig voor een van de taken, maar als u wilt dat het tussen teams wordt geautomatiseerd, wordt het lastiger. De persoon die het script maakt, is meestal degene die het script beheert. Wat gebeurt er als deze persoon weggaat of als er bugs of wijzigingen zijn die nodig zijn?
Het extra werk dat buiten het domein van die ingenieur valt, wordt samengevoegd met zijn normale dagelijkse werkzaamheden en zal uiteindelijk aan de kant worden gelaten. Het is veel beter om al uw scripting op te slaan in een centraal beheerde database waar niemand de leiding over heeft. DDoS-aanvallen evolueren snel. Het type vereiste willekeurige wijzigingen ( TCP -> UDP ) zou een eenvoudige opdracht op de C2-server zijn. Dit alles proberen bij te houden met aangepaste scripts is een slechte dienst voor u en uw bedrijf.
Mogelijk moet een geavanceerdere technicus worden gebeld om naar de HTTP-hostheaders of sessietabellen te kijken op een load balancer om te bepalen of het een meer geavanceerde aanval is. Laag 7-aanvallen overschrijden het pakket per seconde niet, dus we moeten dieper gaan dan de standaard 5-tuple en intermitterende problemen vaststellen.
Soms moeten we extra moeite doen om congestietellingen, congestievensters, TCP RTT of andere geavanceerde functies te onderzoeken. Op een webserver moeten we mogelijk zoeken naar specifieke headers om naar Null0 te schrijven.
BGP-gemeenschappen zijn vaak geschikt voor DDoS-mitigaties. BGP-community is ingesteld op een route en vervolgens wordt die route geblokkeerd aan de WAN-edge. Indien verkeerd ingesteld, zou het veel handmatig werk vergen om erachter te komen waar de oorzaak van het probleem ligt.
De handmatige benadering van het oplossen van problemen moet uiteindelijk worden uitgevoerd en vervolgens moet alle diagnostische informatie op de een of andere manier op één plaats worden samengevoegd om een beslissing te nemen over wat te doen. Proberen deze stappen zonder automatisering met dezelfde mensen te herhalen, is niet de manier voor een soepele bedrijfsvoering. Er zijn veel verschillende stappen bij betrokken waarvoor veel verschillende teams nodig zijn, die veel verschillende technologiehoeden combineren.
Sommige van deze apparaten die nodig zijn voor het oplossen van problemen, bevinden zich mogelijk zelfs op verschillende netwerken met verschillende logins. Het kan zijn dat u een probleemoplossingsticket moet indienen, zelfs om op het apparaat te komen om de probleemoplossing te starten. We hebben onze handen al gebonden en DDoS wint al met een lange mijl. Dit soort probleemoplossing bewijst u een slechte dienst, vooral wanneer we al in een kat-en-muisspel zitten. Het combineren van teams, technische hoeden en vaardigheden is een zware taak en vereist een goed team- en projectmanagement. In plaats van het vertrouwen aan de goden over te laten, is het beter om een oplossing te hebben om dingen voor je te laten werken. Dus als er een DDoS gebeurt en het zal zeker gebeuren, ben je met een klik op de knop klaar om het te beperken.
NetBrain biedt een unieke benadering van netwerkautomatisering waardoor de kloof tussen DDoS-detectie en -beperking wordt overbrugd. Het vermogen voor NetBrain de integratie met zowel detectie- als mitigatiesystemen maakt het ontbrekende stukje van de Denial of Service (DDoS)-puzzel compleet. Het is niet het kaartbedrijf maar het automatiseringsbedrijf dat profiteert Dynamische netwerktoewijzing, uitvoerbaar Runbooks en rijk integratieframework van API's en werkstromen om elk type DDoS op te lossen.