Het volgende artikel is deel 2 van een driedelige serie over het oplossen van DDoS-aanvallen en is een gastartikel van Matt Conran van Network Insight . In dit artikel bespreekt Matt de uitdagingen van de handmatige aanpak voor het oplossen van DDoS-aanvallen.
Een DDoS-aanval (Distributed Denial of Service) is een aanval die erop gericht is online diensten plat te leggen door een enorme hoeveelheid verkeer vanuit verschillende bronnen. Bij deze cyberaanval gebruikt de aanvaller meerdere unieke IP-adressen. Wanneer we aan DDoS denken, denken we in de eerste plaats aan detectie en mitigatie. Immers, daar wordt het meeste geld in geïnvesteerd en worden de nieuwste, geavanceerde functies geïntroduceerd. Het is echter de effectiviteit van de complete end-to-end oplossing die de DDoS-aanval tijdig stopt.
Het ontbrekende puzzelstukje is het oplossen van problemen. Velen denken dat het in kaart brengen van een netwerk en het oplossen van problemen een technische taak is die alleen door een engineer kan worden uitgevoerd. Maar er is een compleet bedrijfsproces dat moet worden geïntegreerd, wat uiteindelijk leidt tot de daadwerkelijke configuratie en het stoppen van de DDoS-aanval.
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.
Remotely-Triggered Black Hole (RTBH) is een van de meest gebruikte methoden om een aanval af te weren. Het maakt gebruik van het Border Gateway Protocol (BGP) binnen het netwerk en installeert regels in de doorstuurlocatie om de bestemming te blokkeren en zo de DDoS-aanval te neutraliseren. In feite voert het de DDoS-aanval uit namens de aanvaller. RTHB is in het verleden nuttig gebleken, maar een van de nadelen is dat het zowel de missiemodus-routering 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 effectieve DDoS-bescherming is het essentieel om alle lagen van de Open Systems Interconnection-architectuur (OSI) te onderzoeken. Het gaat niet meer om slechts één laag; cybercriminelen gebruiken meerdere lagen om een netwerk binnen te dringen. Vaak worden parallelle aanvallen gebruikt, waarbij volumetrische aanvallen op laag 4 worden gecombineerd met applicatieaanvallen op laag 7. Kortom, we hebben twee lagen van de architectuur die aandacht 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 traceren en commando's zoals "Netstat" uitvoeren om te bepalen welke verbindingen openstaan op die server of dat apparaat. Weer een andere beheerder moet controleren of de machinebelasting hoog is of het aantal actieve HTTP-processen vaststellen . Een Linux- of firewallbeheerder moet aangepaste scripts maken en deze uitvoeren op IP-tabellen om andere soorten beveiligingsinformatie te achterhalen.
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 meer ervaren engineer worden ingeschakeld om de HTTP-hostheaders of sessietabellen op een load balancer te bekijken en te bepalen of het om een geavanceerdere aanval gaat. Aanvallen op laag 7 overschrijden de pakketsnelheid per seconde niet, dus we moeten verder kijken dan de standaard 5-tuple en intermitterende problemen opsporen.
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.
Uiteindelijk is een handmatige aanpak voor het oplossen van problemen noodzakelijk. Alle diagnostische informatie moet vervolgens op een of andere manier worden samengebracht om een beslissing te kunnen nemen over de te volgen procedure. Het herhalen van deze stappen met dezelfde mensen zonder automatisering is geen manier om een soepele werking te garanderen. Er zijn veel verschillende stappen bij betrokken die de inzet van diverse teams en verschillende technologische expertise vereisen.
Sommige van de apparaten die nodig zijn voor het oplossen van problemen bevinden zich mogelijk zelfs op verschillende netwerken met verschillende inloggegevens. Het kan voorkomen dat u een ticket moet aanmaken om toegang te krijgen tot het apparaat en met de probleemoplossing te beginnen. We zitten al met de handen gebonden en de DDoS-aanval heeft al een grote voorsprong. Deze manier van probleemoplossing is nadelig, vooral omdat we al in een kat-en-muisspel verwikkeld zijn. Het samenbrengen van teams, technische expertise en vaardigheden is een lastige opgave en vereist goed team- en projectmanagement. In plaats van alles aan het lot over te laten, is het beter om een oplossing paraat te hebben die voor u werkt. Zo bent u, wanneer een DDoS-aanval plaatsvindt – en dat zal zeker gebeuren – met één druk op de knop klaar om deze te neutraliseren.
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.