“De man die onze website heeft gemaakt, heeft DDoS-beveiliging al ingesteld.”
“We hebben DDoS-bescherming, waarom is de site offline gegaan?”
“Hoeveel duizenden wil Qrator?”
Om dergelijke vragen van de klant/baas goed te kunnen beantwoorden, zou het fijn zijn om te weten wat er achter de naam ‘DDoS-bescherming’ schuilgaat. Het kiezen van veiligheidsdiensten lijkt meer op het kiezen van een medicijn van een dokter dan op het kiezen van een tafel bij IKEA.
Ik ondersteun al elf jaar websites, heb honderden aanvallen overleefd op de diensten die ik ondersteun, en nu zal ik je iets vertellen over de innerlijke werking van bescherming.
Regelmatige aanvallen. Totaal 350 aanvragen, legitieme 52 aanvragen
De eerste aanvallen verschenen vrijwel gelijktijdig met internet. DDoS is als fenomeen wijdverspreid sinds eind jaren 2000 ).
Sinds ongeveer 2015-2016 zijn bijna alle hostingproviders beschermd tegen DDoS-aanvallen, evenals de meeste prominente sites in concurrerende gebieden (doe whois via IP van de sites eldorado.ru, leroymerlin.ru, tilda.ws, je zult de netwerken zien van beveiligingsoperatoren).
Als 10-20 jaar geleden de meeste aanvallen op de server zelf zouden kunnen worden afgeweerd (bekijk de aanbevelingen van Lenta.ru-systeembeheerder Maxim Moshkov uit de jaren 90: ), maar nu zijn beveiligingstaken moeilijker geworden.
Soorten DDoS-aanvallen vanuit het oogpunt van het kiezen van een beveiligingsoperator
Aanvallen op L3/L4-niveau (volgens OSI-model)
— UDP-overstroming vanaf een botnet (veel verzoeken worden rechtstreeks vanaf geïnfecteerde apparaten naar de aangevallen dienst verzonden, de servers worden geblokkeerd met het kanaal);
— DNS/NTP/etc-versterking (veel verzoeken worden verzonden van geïnfecteerde apparaten naar kwetsbare DNS/NTP/etc, het adres van de afzender wordt vervalst, een wolk van pakketten die reageren op verzoeken overspoelt het kanaal van de persoon die wordt aangevallen; dit is hoe het meest er worden massale aanvallen uitgevoerd op het moderne internet);
— SYN / ACK flood (veel verzoeken om een verbinding tot stand te brengen worden naar de aangevallen servers gestuurd, de verbindingswachtrij loopt over);
— aanvallen met pakketfragmentatie, ping of death, ping flood (Google maar);
- enzovoort.
Deze aanvallen zijn bedoeld om het kanaal van de server te ‘verstoppen’ of het vermogen om nieuw verkeer te accepteren te ‘doden’.
Hoewel SYN/ACK-flooding en -versterking heel verschillend zijn, bestrijden veel bedrijven ze even goed. Er ontstaan problemen bij aanvallen van de volgende groep.
Aanvallen op L7 (applicatielaag)
— http flood (als een website of een http-api wordt aangevallen);
— een aanval op kwetsbare delen van de site (degenen die geen cache hebben, die de site erg zwaar belasten, enz.).
Het doel is om de server "hard te laten werken", veel "schijnbaar echte verzoeken" te verwerken en geen middelen meer te hebben voor echte verzoeken.
Hoewel er nog meer aanvallen zijn, zijn dit de meest voorkomende.
Ernstige aanvallen op L7-niveau worden op een unieke manier gecreëerd voor elk project dat wordt aangevallen.
Waarom 2 groepen?
Omdat er velen zijn die aanvallen goed weten af te weren op L3/L4-niveau, maar ofwel helemaal geen bescherming op applicatieniveau (L7) opnemen, ofwel nog steeds zwakker zijn dan alternatieven in het omgaan ermee.
Wie is wie op de markt voor DDoS-bescherming
(mijn persoonlijke mening)
Bescherming op L3/L4-niveau
Om aanvallen met versterking (“blokkering” van het serverkanaal) af te weren, zijn er voldoende brede kanalen (veel van de beveiligingsdiensten zijn verbonden met de meeste grote backbone-providers in Rusland en hebben kanalen met een theoretische capaciteit van meer dan 1 Tbit). Vergeet niet dat zeer zeldzame versterkingsaanvallen langer dan een uur duren. Als je Spamhaus bent en iedereen vindt je niet leuk, ja, dan kunnen ze proberen je kanalen een aantal dagen stil te leggen, zelfs met het risico dat het mondiale botnet verder voortbestaat. Als je alleen maar een online winkel hebt, ook al is het mvideo.ru, zul je niet binnen een paar dagen 1 Tbit zien (hoop ik).
Om aanvallen met SYN/ACK-flooding, pakketfragmentatie, enz. af te weren, hebt u apparatuur of softwaresystemen nodig om dergelijke aanvallen te detecteren en te stoppen.
Veel mensen produceren dergelijke apparatuur (Arbor, er zijn oplossingen van Cisco, Huawei, software-implementaties van Wanguard, enz.), veel backbone-operators hebben het al geïnstalleerd en verkopen DDoS-beveiligingsdiensten (ik ken installaties van Rostelecom, Megafon, TTK, MTS (in feite doen alle grote providers hetzelfde met hosters met hun eigen bescherming a-la OVH.com, Hetzner.de, ik kwam zelf bescherming tegen bij ihor.ru). Sommige bedrijven ontwikkelen hun eigen softwareoplossingen (met technologieën als DPDK kun je tientallen gigabits aan verkeer verwerken op één fysieke x86-machine).
Van de bekende spelers kan iedereen min of meer effectief L3/L4 DDoS bestrijden. Nu zal ik niet zeggen wie de grootste maximale kanaalcapaciteit heeft (dit is voorkennis), maar meestal is dit niet zo belangrijk, en het enige verschil is hoe snel de bescherming wordt geactiveerd (onmiddellijk of na een paar minuten projectonderbreking, zoals in Hetzner).
De vraag is hoe goed dit wordt gedaan: een versterkingsaanval kan worden afgeweerd door verkeer uit landen met de grootste hoeveelheid schadelijk verkeer te blokkeren, of alleen echt onnodig verkeer kan worden weggegooid.
Maar tegelijkertijd kunnen, op basis van mijn ervaring, alle serieuze marktspelers hier zonder problemen mee omgaan: Qrator, DDoS-Guard, Kaspersky, G-Core Labs (voorheen SkyParkCDN), ServicePipe, Stormwall, Voxility, etc.
Ik ben geen bescherming tegengekomen van operators zoals Rostelecom, Megafon, TTK, Beeline; volgens beoordelingen van collega's bieden ze deze diensten vrij goed, maar tot nu toe heeft het gebrek aan ervaring periodiek invloed: soms moet je iets aanpassen via de ondersteuning van de beschermingsoperator.
Sommige operators hebben een aparte dienst “bescherming tegen aanvallen op L3/L4-niveau”, of “kanaalbescherming”; deze kost veel minder dan bescherming op alle niveaus.
Waarom weert de backbone-provider aanvallen van honderden Gbits niet af, omdat hij niet over eigen kanalen beschikt?De beveiligingsoperator kan verbinding maken met een van de grote providers en aanvallen ‘op eigen kosten’ afweren. Je zult voor het kanaal moeten betalen, maar al deze honderden Gbits zullen niet altijd worden benut; er zijn mogelijkheden om in dit geval de kosten van kanalen aanzienlijk te verlagen, zodat het schema werkbaar blijft.
Dit zijn de rapporten die ik regelmatig ontving van L3/L4-bescherming op een hoger niveau terwijl ik de systemen van de hostingprovider ondersteunde.
Beveiliging op L7-niveau (applicatieniveau)
Aanvallen op L7-niveau (toepassingsniveau) zijn in staat eenheden consistent en efficiënt af te weren.
Ik heb er heel veel echte ervaring mee
— Qrator.net;
— DDoS-Guard;
- G-Core Labs;
— Kasperski.
Ze brengen kosten in rekening voor elke megabit puur verkeer, een megabit kost ongeveer enkele duizenden roebel. Als je minimaal 100 Mbps puur verkeer hebt - oh. Bescherming zal erg duur zijn. Ik kan je in de volgende artikelen vertellen hoe je applicaties ontwerpt om veel te besparen op de capaciteit van beveiligingskanalen.
De echte “koning van de heuvel” is Qrator.net, de rest blijft achter. Qrator is naar mijn ervaring tot nu toe de enige die een percentage false positives dicht bij nul geeft, maar tegelijkertijd meerdere keren duurder is dan andere marktspelers.
Andere operators bieden ook hoogwaardige en stabiele bescherming. Veel door ons ondersteunde diensten (waaronder zeer bekende in het land!) Zijn beschermd tegen DDoS-Guard, G-Core Labs en zijn redelijk tevreden met de verkregen resultaten.
Aanvallen afgeslagen door Qrator
Ik heb ook ervaring met kleine beveiligingsoperatoren zoals cloud-shield.ru, ddosa.net, duizenden daarvan. Ik zal het zeker niet aanbevelen, omdat... Ik heb niet veel ervaring, maar ik zal je vertellen over de principes van hun werk. Hun beschermingskosten zijn vaak één tot twee ordes van grootte lager dan die van grote spelers. In de regel kopen ze een gedeeltelijke beschermingsdienst (L1/L2) van een van de grotere spelers + doen ze hun eigen bescherming tegen aanvallen op hogere niveaus. Dit kan behoorlijk effectief zijn + je kunt voor minder geld een goede service krijgen, maar dit zijn nog steeds kleine bedrijven met een klein personeelsbestand, houd daar alsjeblieft rekening mee.
Wat is de moeilijkheid bij het afweren van aanvallen op L7-niveau?
Alle applicaties zijn uniek en u moet verkeer toestaan dat nuttig voor hen is en schadelijk verkeer blokkeren. Het is niet altijd mogelijk om bots ondubbelzinnig uit te roeien, dus je moet heel veel graden van verkeerszuivering gebruiken.
Ooit was de nginx-testcookie-module voldoende (), en het is nog steeds voldoende om een groot aantal aanvallen af te weren. Toen ik in de hostingbranche werkte, was L7-bescherming gebaseerd op nginx-testcookie.
Helaas zijn aanvallen moeilijker geworden. testcookie maakt gebruik van op JS gebaseerde botcontroles, en veel moderne bots kunnen deze met succes doorstaan.
Aanvalsbotnets zijn ook uniek en er moet rekening worden gehouden met de kenmerken van elk groot botnet.
Versterking, directe flooding vanuit een botnet, filteren van verkeer uit verschillende landen (verschillende filtering voor verschillende landen), SYN/ACK flooding, pakketfragmentatie, ICMP, http flooding, terwijl je op applicatie/http-niveau een onbeperkt aantal kunt bedenken verschillende aanvallen.
In totaal kunnen er op het niveau van kanaalbescherming, gespecialiseerde apparatuur voor het opruimen van verkeer, speciale software en extra filterinstellingen voor elke client tientallen en honderden filterniveaus zijn.
Om dit goed te kunnen beheren en de filterinstellingen voor verschillende gebruikers correct af te stemmen, heb je veel ervaring en gekwalificeerd personeel nodig. Zelfs een grote operator die heeft besloten beschermingsdiensten aan te bieden, kan niet “dom geld naar het probleem gooien”: er zal ervaring moeten worden opgedaan met liegende sites en valse positieven over legitiem verkeer.
Er is geen knop “DDoS afweren” voor de beveiligingsoperator; er zijn een groot aantal tools en u moet weten hoe u ze moet gebruiken.
En nog een bonusvoorbeeld.
Tijdens een aanval werd door de host een onbeveiligde server geblokkeerd met een capaciteit van 600 Mbit
(“Het verlies” aan verkeer is niet merkbaar, omdat slechts 1 site werd aangevallen, deze tijdelijk van de server werd verwijderd en de blokkering binnen een uur werd opgeheven).
Dezelfde server is beveiligd. De aanvallers ‘gaven zich over’ na een dag van afgeslagen aanvallen. De aanval zelf was niet de sterkste.
Aanval en verdediging van L3/L4 zijn trivialer; ze zijn voornamelijk afhankelijk van de dikte van de kanalen en detectie- en filteralgoritmen voor aanvallen.
L7-aanvallen zijn complexer en origineler; ze zijn afhankelijk van de applicatie die wordt aangevallen, de mogelijkheden en verbeeldingskracht van de aanvallers. Bescherming hiertegen vereist veel kennis en ervaring, en het resultaat is mogelijk niet onmiddellijk en niet honderd procent. Tot Google met een ander neuraal netwerk ter bescherming kwam.
Bron: www.habr.com