"L'home que va crear el nostre lloc web ja va configurar la protecció DDoS".
"Tenim protecció DDoS, per què es va caure el lloc?"
"Quants milers vol Qrator?"
Per respondre correctament aquestes preguntes del client/cap, seria bo saber què s'amaga darrere del nom "protecció DDoS". Escollir serveis de seguretat és més com triar un medicament d'un metge que escollir una taula a IKEA.
He estat donant suport a llocs web durant 11 anys, he sobreviscut a centenars d'atacs als serveis als quals suporto, i ara us parlaré una mica sobre el funcionament intern de la protecció.
Atacs regulars. 350k requeriments totals, 52k requeriments legítims
Els primers atacs van aparèixer gairebé simultàniament amb Internet. DDoS com a fenomen s'ha estès des de finals dels anys 2000 (consulta ).
Des del 2015-2016 aproximadament, gairebé tots els proveïdors d'allotjament estan protegits dels atacs DDoS, igual que els llocs més destacats en àrees competitives (feu whois per IP dels llocs eldorado.ru, leroymerlin.ru, tilda.ws, veureu les xarxes). dels operadors de protecció).
Si fa 10-20 anys la majoria dels atacs es poguessin repel·lir al propi servidor (avalueu les recomanacions de l'administrador del sistema Lenta.ru Maxim Moshkov dels anys 90: ), però ara les tasques de protecció s'han tornat més difícils.
Tipus d'atacs DDoS des del punt de vista de l'elecció d'un operador de protecció
Atacs a nivell L3/L4 (segons model OSI)
— Inondació UDP des d'una botnet (moltes peticions s'envien directament des dels dispositius infectats al servei atacat, els servidors estan bloquejats amb el canal);
— Amplificació DNS/NTP/etc (des de dispositius infectats s'envien moltes peticions a DNS/NTP/etc vulnerables, l'adreça del remitent es falsifica, un núvol de paquets que responen a les peticions inunda el canal de la persona atacada; així és com més es duen a terme atacs massius a Internet moderna);
— SYN / ACK flood (moltes peticions per establir una connexió s'envien als servidors atacats, la cua de connexió es desborda);
— atacs amb fragmentació de paquets, ping of death, ping flood (Google si us plau);
- etcètera.
Aquests atacs tenen com a objectiu "obstruir" el canal del servidor o "matar" la seva capacitat d'acceptar trànsit nou.
Tot i que les inundacions i l'amplificació SYN/ACK són molt diferents, moltes empreses les combaten igualment bé. Els problemes sorgeixen amb els atacs del grup següent.
Atacs a L7 (capa d'aplicació)
— http flood (si s'ataca un lloc web o alguna API http);
— un atac a zones vulnerables del lloc (aquelles que no tenen memòria cau, que carreguen molt el lloc, etc.).
L'objectiu és que el servidor "treballi dur", processi moltes "sol·licituds aparentment reals" i es quedi sense recursos per a peticions reals.
Encara que hi ha altres atacs, aquests són els més habituals.
Els atacs greus al nivell L7 es creen d'una manera única per a cada projecte atacat.
Per què 2 grups?
Perquè hi ha molts que saben com repel·lir bé els atacs a nivell L3 / L4, però o bé no ocupen gens de protecció a nivell d'aplicació (L7) o encara són més febles que les alternatives per fer-hi front.
Qui és qui al mercat de protecció DDoS
(la meva opinió personal)
Protecció a nivell L3/L4
Per repel·lir els atacs amb amplificació ("bloqueig" del canal del servidor), hi ha canals prou amplis (molts dels serveis de protecció es connecten a la majoria dels grans proveïdors de backbone a Rússia i tenen canals amb una capacitat teòrica de més d'1 Tbit). No oblideu que els atacs d'amplificació molt rars duren més d'una hora. Si sou Spamhaus i no us agraden a tothom, sí, poden intentar tancar els vostres canals durant uns quants dies, fins i tot amb el risc que s'utilitzi més la supervivència de la botnet global. Si només teniu una botiga en línia, encara que sigui mvideo.ru, no veureu 1 Tbit en pocs dies molt aviat (espero).
Per repel·lir atacs amb inundació SYN/ACK, fragmentació de paquets, etc., necessiteu equips o sistemes de programari per detectar i aturar aquests atacs.
Molta gent produeix aquest tipus d'equips (Arbor, hi ha solucions de Cisco, Huawei, implementacions de programari de Wanguard, etc.), molts operadors de backbone ja l'han instal·lat i venen serveis de protecció DDoS (conec instal·lacions de Rostelecom, Megafon, TTK, MTS). , de fet, tots els principals proveïdors fan el mateix amb hosters amb la seva pròpia protecció a-la OVH.com, Hetzner.de, jo mateix he trobat protecció a ihor.ru). Algunes empreses estan desenvolupant les seves pròpies solucions de programari (tecnologies com DPDK permeten processar desenes de gigabits de trànsit en una màquina física x86).
Dels jugadors coneguts, tothom pot lluitar contra DDoS L3/L4 amb més o menys eficàcia. Ara no diré qui té la capacitat màxima de canal més gran (això és informació privilegiada), però normalment això no és tan important, i l'única diferència és la rapidesa amb què s'activa la protecció (a l'instant o després d'uns minuts d'inactivitat del projecte, com en Hetzner).
La qüestió és com de bé es fa: un atac d'amplificació es pot repel·lir bloquejant el trànsit dels països amb la major quantitat de trànsit nociu, o només es pot descartar el trànsit realment innecessari.
Però al mateix temps, segons la meva experiència, tots els actors seriosos del mercat ho fan sense problemes: Qrator, DDoS-Guard, Kaspersky, G-Core Labs (abans SkyParkCDN), ServicePipe, Stormwall, Voxility, etc.
No he trobat la protecció d'operadors com Rostelecom, Megafon, TTK, Beeline; segons els comentaris dels companys, ofereixen aquests serveis força bé, però fins ara la falta d'experiència està afectant periòdicament: de vegades cal modificar alguna cosa a través del suport. de l'operador de protecció.
Alguns operadors tenen un servei separat de "protecció contra atacs a nivell L3/L4" o "protecció del canal"; costa molt menys que la protecció a tots els nivells.
Per què el proveïdor de backbone no repel·leix atacs de centenars de Gbits, ja que no té els seus propis canals?L'operador de protecció pot connectar-se a qualsevol dels principals proveïdors i repel·lir els atacs "al seu càrrec". Haureu de pagar pel canal, però tots aquests centenars de Gbits no sempre s'utilitzaran; hi ha opcions per reduir significativament el cost dels canals en aquest cas, de manera que l'esquema segueix sent viable.
Aquests són els informes que rebo regularment de la protecció L3/L4 de nivell superior mentre donava suport als sistemes del proveïdor d'allotjament.
Protecció a nivell L7 (nivell d'aplicació)
Els atacs al nivell L7 (nivell d'aplicació) són capaços de repel·lir les unitats de manera coherent i eficient.
Tinc molta experiència real amb
— Qrator.net;
- DDoS-Guard;
- G-Core Labs;
- Kaspersky.
Es cobren per cada megabit de trànsit pur, un megabit costa uns milers de rubles. Si teniu almenys 100 Mbps de trànsit pur, oh. La protecció serà molt cara. Us puc explicar en els següents articles com dissenyar aplicacions per tal d'estalviar molt en la capacitat dels canals de seguretat.
L'autèntic "rei del turó" és Qrator.net, la resta queda enrere. Fins ara, els Qrator són els únics de la meva experiència que donen un percentatge de falsos positius propers a zero, però al mateix temps són diverses vegades més cars que altres actors del mercat.
Altres operadors també proporcionen una protecció estable i d'alta qualitat. Molts serveis que donem suport (inclosos els molt coneguts al país!) estan protegits de DDoS-Guard, G-Core Labs i estan bastant satisfets amb els resultats obtinguts.
Atacs repel·lits per Qrator
També tinc experiència amb petits operadors de seguretat com cloud-shield.ru, ddosa.net, milers d'ells. Definitivament no el recomanaré, perquè... No tinc molta experiència, però us explicaré els principis del seu treball. El seu cost de protecció és sovint 1-2 ordres de magnitud inferior al dels principals actors. Com a regla general, compren un servei de protecció parcial (L3/L4) d'un dels jugadors més grans + fan la seva pròpia protecció contra atacs a nivells superiors. Això pot ser bastant efectiu + podeu obtenir un bon servei per menys diners, però encara són petites empreses amb un petit personal, tingueu-ho en compte.
Quina és la dificultat de repel·lir atacs al nivell L7?
Totes les aplicacions són úniques i cal permetre el trànsit que els sigui útil i bloquejar-ne els nocius. No sempre és possible eliminar de manera inequívoca els bots, de manera que heu d'utilitzar molts, realment MOLTS graus de purificació del trànsit.
Hi havia una vegada, el mòdul nginx-testcookie era suficient (), i encara n'hi ha prou per repel·lir un gran nombre d'atacs. Quan treballava a la indústria de l'allotjament, la protecció L7 es basava en nginx-testcookie.
Malauradament, els atacs s'han tornat més difícils. testcookie utilitza comprovacions de bot basades en JS, i molts robots moderns poden passar-les amb èxit.
Les botnets d'atac també són úniques i s'han de tenir en compte les característiques de cada botnet gran.
Amplificació, inundació directa des d'una xarxa de bots, filtratge de trànsit de diferents països (filtrat diferent per a diferents països), inundació SYN/ACK, fragmentació de paquets, ICMP, inundació http, mentre que a nivell d'aplicació/http podeu trobar un nombre il·limitat de diferents atacs.
En total, a nivell de protecció del canal, equips especialitzats per netejar el trànsit, programari especial, configuracions de filtratge addicionals per a cada client, hi pot haver desenes i centenars de nivells de filtratge.
Per gestionar-ho correctament i ajustar correctament la configuració de filtratge per a diferents usuaris, necessiteu molta experiència i personal qualificat. Fins i tot un gran operador que ha decidit oferir serveis de protecció no pot “llenar diners estúpidament al problema”: s'haurà d'aconseguir experiència amb llocs mentiders i falsos positius sobre trànsit legítim.
No hi ha cap botó de "repel·lir DDoS" per a l'operador de seguretat; hi ha un gran nombre d'eines i cal saber com utilitzar-les.
I un bon exemple més.
Un servidor sense protecció va ser bloquejat per l'hoster durant un atac amb una capacitat de 600 Mbit
("La pèrdua" de trànsit no es nota, perquè només s'ha atacat un lloc, es va eliminar temporalment del servidor i el bloqueig es va aixecar en una hora).
El mateix servidor està protegit. Els atacants "es van rendir" després d'un dia d'atacs rebutjats. L'atac en si no va ser el més fort.
L'atac i la defensa de L3/L4 són més trivials; depenen principalment del gruix dels canals, dels algorismes de detecció i filtrat per als atacs.
Els atacs L7 són més complexos i originals; depenen de l'aplicació atacada, les capacitats i la imaginació dels atacants. La protecció contra ells requereix molts coneixements i experiència, i el resultat pot no ser immediat ni cent per cent. Fins que Google va crear una altra xarxa neuronal per protegir-se.
Font: www.habr.com