Variti desenvolupa protecció contra els bots i atacs DDoS, i també realitza proves d'estrès i càrrega. A la conferència HighLoad++ 2018 vam parlar sobre com protegir els recursos de diversos tipus d'atacs. En resum: aïlleu parts del sistema, utilitzeu serveis al núvol i CDN i actualitzeu regularment. Però encara no podreu gestionar la protecció sense empreses especialitzades :)
Abans de llegir el text, podeu llegir els resums breus .
I si no us agrada llegir o simplement voleu veure el vídeo, la gravació del nostre reportatge es troba a sota de l'spoiler.
Enregistrament en vídeo de l'informe
Moltes empreses ja saben com fer proves de càrrega, però no totes fan proves d'estrès. Alguns dels nostres clients pensen que el seu lloc és invulnerable perquè tenen un sistema de càrrega alta i protegeix bé dels atacs. Mostrem que això no és del tot cert.
Per descomptat, abans de realitzar proves, obtenim el permís del client, signat i segellat, i amb la nostra ajuda no es pot dur a terme un atac DDoS a ningú. Les proves es realitzen en un moment escollit pel client, quan el trànsit al seu recurs és mínim i els problemes d'accés no afectaran els clients. A més, com que alguna cosa sempre pot sortir malament durant el procés de prova, tenim un contacte constant amb el client. Això us permet no només informar dels resultats aconseguits, sinó també canviar alguna cosa durant les proves. Un cop finalitzades les proves, sempre elaborem un informe en el qual assenyalem les deficiències detectades i donem recomanacions per eliminar les debilitats del lloc.
Com estem treballant
Quan fem proves, emulem una botnet. Com que treballem amb clients que no es troben a les nostres xarxes, per tal d'assegurar que la prova no s'acabi en el primer minut a causa de límits o protecció activada, subministrem la càrrega no des d'una IP, sinó des de la nostra pròpia subxarxa. A més, per crear una càrrega important, tenim el nostre propi servidor de proves força potent.
Postulats
Massa no vol dir bo
Com menys càrrega puguem portar un recurs al fracàs, millor. Si podeu fer que el lloc deixi de funcionar amb una sol·licitud per segon, o fins i tot una sol·licitud per minut, això és genial. Perquè segons la llei de la mesquinesa, els usuaris o atacants cauran accidentalment en aquesta vulnerabilitat particular.
El fracàs parcial és millor que el fracàs total
Sempre aconsellem fer sistemes heterogenis. A més, val la pena separar-los a nivell físic, i no només per containerització. En el cas de la separació física, fins i tot si alguna cosa falla al lloc, hi ha una alta probabilitat que no deixi de funcionar completament i els usuaris continuaran tenint accés almenys a una part de la funcionalitat.
Una bona arquitectura és la base de la sostenibilitat
La tolerància a fallades d'un recurs i la seva capacitat de suportar atacs i càrregues s'haurien d'establir en l'etapa de disseny, de fet, en l'etapa de dibuix dels primers diagrames de flux en un quadern. Perquè si hi ha errors fatals, és possible corregir-los en el futur, però és molt difícil.
No només el codi hauria de ser bo, sinó també la configuració
Molta gent pensa que un bon equip de desenvolupament és una garantia d'un servei tolerant a errors. Un bon equip de desenvolupament és realment necessari, però també hi ha d'haver bones operacions, bons DevOps. És a dir, necessitem especialistes que configuren correctament Linux i la xarxa, escriguin les configuracions correctament a nginx, estableixin límits, etc. En cas contrari, el recurs només funcionarà bé a les proves i, en algun moment, tot es trencarà en producció.
Diferències entre proves de càrrega i proves d'esforç
Les proves de càrrega us permeten identificar els límits del funcionament del sistema. Les proves d'estrès estan destinades a trobar debilitats en un sistema i s'utilitzen per trencar aquest sistema i veure com es comportarà en el procés de fallada de determinades peces. En aquest cas, la naturalesa de la càrrega normalment roman desconeguda pel client abans que comencin les proves d'estrès.
Característiques distintives dels atacs L7
Normalment dividim els tipus de càrrega en càrregues als nivells L7 i L3 i 4. L7 és una càrrega a nivell d'aplicació, la majoria de vegades només significa HTTP, però ens referim a qualsevol càrrega a nivell de protocol TCP.
Els atacs L7 tenen certes característiques distintives. En primer lloc, arriben directament a l'aplicació, és a dir, és poc probable que es reflecteixin a través de mitjans de xarxa. Aquests atacs utilitzen la lògica i, per això, consumeixen CPU, memòria, disc, base de dades i altres recursos de manera molt eficient i amb poc trànsit.
HTTP Flood
En el cas de qualsevol atac, la càrrega és més fàcil de crear que de manejar, i en el cas de L7 això també és cert. No sempre és fàcil distingir el trànsit d'atac del trànsit legítim, i la majoria de les vegades això es pot fer per freqüència, però si tot està planificat correctament, és impossible entendre dels registres on es troba l'atac i on són les sol·licituds legítimes.
Com a primer exemple, considereu un atac HTTP Flood. El gràfic mostra que aquests atacs solen ser molt potents; a l'exemple següent, el nombre màxim de sol·licituds va superar els 600 mil per minut.
HTTP Flood és la manera més senzilla de crear càrrega. Normalment, es necessita algun tipus d'eina de prova de càrrega, com ApacheBench, i estableix una sol·licitud i un objectiu. Amb un enfocament tan senzill, hi ha una gran probabilitat de trobar-se amb la memòria cau del servidor, però és fàcil evitar-lo. Per exemple, afegir cadenes aleatòries a la sol·licitud, cosa que obligarà el servidor a publicar constantment una pàgina nova.
A més, no us oblideu de l'agent d'usuari en el procés de creació d'una càrrega. Molts agents d'usuari de les eines de prova populars són filtrats pels administradors del sistema i, en aquest cas, és possible que la càrrega simplement no arribi al backend. Podeu millorar significativament el resultat inserint una capçalera més o menys vàlida del navegador a la sol·licitud.
Per senzills que siguin els atacs HTTP Flood, també tenen els seus inconvenients. En primer lloc, es necessiten grans quantitats d'energia per crear la càrrega. En segon lloc, aquests atacs són molt fàcils de detectar, sobretot si provenen d'una adreça. Com a resultat, les sol·licituds comencen a filtrar-se immediatament per part dels administradors del sistema o fins i tot a nivell de proveïdor.
Què buscar?
Per reduir el nombre de sol·licituds per segon sense perdre eficiència, heu de mostrar una mica d'imaginació i explorar el lloc. Així, podeu carregar no només el canal o el servidor, sinó també parts individuals de l'aplicació, per exemple, bases de dades o sistemes de fitxers. També podeu buscar llocs al lloc que fan càlculs grans: calculadores, pàgines de selecció de productes, etc. Finalment, sovint passa que el lloc té algun tipus d'script PHP que genera una pàgina de diversos centenars de milers de línies. Aquest script també carrega significativament el servidor i pot convertir-se en un objectiu per a un atac.
On buscar
Quan analitzem un recurs abans de provar, primer mirem, per descomptat, el mateix lloc. Busquem tot tipus de camps d'entrada, fitxers pesats, en general, tot allò que pot crear problemes per al recurs i frenar-ne el funcionament. Les eines de desenvolupament banals de Google Chrome i Firefox ajuden aquí, que mostren els temps de resposta de la pàgina.
També analitzem subdominis. Per exemple, hi ha una determinada botiga en línia, abc.com, i té un subdomini admin.abc.com. El més probable és que aquest sigui un tauler d'administració amb autorització, però si hi poseu una càrrega, pot crear problemes per al recurs principal.
El lloc pot tenir un subdomini api.abc.com. El més probable és que aquest sigui un recurs per a aplicacions mòbils. L'aplicació es pot trobar a l'App Store o Google Play, instal·lar un punt d'accés especial, disseccionar l'API i registrar comptes de prova. El problema és que la gent sovint pensa que qualsevol cosa que estigui protegida per autorització és immune als atacs de denegació de servei. Se suposa que l'autorització és el millor CAPTCHA, però no ho és. És fàcil crear entre 10 i 20 comptes de prova, però en crear-los, tenim accés a una funcionalitat complexa i no dissimulada.
Naturalment, mirem la història, a robots.txt i WebArchive, ViewDNS, i busquem versions antigues del recurs. De vegades passa que els desenvolupadors han llançat, per exemple, mail2.yandex.net, però la versió antiga, mail.yandex.net, es manté. Aquest mail.yandex.net ja no és compatible, no s'hi assignen recursos de desenvolupament, però continua consumint la base de dades. En conseqüència, amb la versió antiga, podeu utilitzar efectivament els recursos del backend i tot el que hi ha darrere del disseny. Per descomptat, això no sempre passa, però encara ens trobem amb això força sovint.
Naturalment, analitzem tots els paràmetres de la sol·licitud i l'estructura de la cookie. Podeu, per exemple, abocar algun valor a una matriu JSON dins d'una galeta, crear molts nidificacions i fer que el recurs funcioni durant un temps excessivament llarg.
Càrrega de cerca
El primer que em ve al cap a l'hora d'investigar un lloc és carregar la base de dades, ja que gairebé tothom té una cerca, i per a gairebé tothom, malauradament, està mal protegida. Per alguna raó, els desenvolupadors no presten prou atenció a la cerca. Però aquí hi ha una recomanació: no hauríeu de fer sol·licituds del mateix tipus, perquè és possible que us trobeu amb la memòria cau, com és el cas amb HTTP flood.
Fer consultes aleatòries a la base de dades tampoc no sempre és efectiu. És molt millor crear una llista de paraules clau que siguin rellevants per a la cerca. Si tornem a l'exemple d'una botiga en línia: posem per cas que el lloc ven pneumàtics per a cotxes i permet configurar el radi dels pneumàtics, el tipus de cotxe i altres paràmetres. En conseqüència, les combinacions de paraules rellevants obligaran la base de dades a funcionar en condicions molt més complexes.
A més, val la pena utilitzar la paginació: és molt més difícil que una cerca torni la penúltima pàgina dels resultats de la cerca que la primera. És a dir, amb l'ajuda de la paginació podeu diversificar lleugerament la càrrega.
L'exemple següent mostra la càrrega de cerca. Es pot veure que des del primer segon de la prova a una velocitat de deu peticions per segon, el lloc va caure i no va respondre.
Si no hi ha cap cerca?
Si no hi ha cap cerca, això no vol dir que el lloc no conté altres camps d'entrada vulnerables. Aquest camp pot ser autorització. Avui en dia, als desenvolupadors els agrada fer hash complexos per protegir la base de dades d'inici de sessió d'un atac de taula de l'arc de Sant Martí. Això és bo, però aquests hash consumeixen molts recursos de CPU. Un gran flux d'autoritzacions falses provoca un error del processador i, com a resultat, el lloc deixa de funcionar.
La presència al lloc de tot tipus de formularis per a comentaris i comentaris és un motiu per enviar-hi textos molt grans o simplement crear una inundació massiva. De vegades, els llocs accepten fitxers adjunts, fins i tot en format gzip. En aquest cas, agafem un fitxer d'1 TB, el comprimim a diversos bytes o kilobytes mitjançant gzip i l'enviem al lloc. Després es descomprimeix i s'obté un efecte molt interessant.
API Rest
M'agradaria prestar una mica d'atenció a serveis tan populars com l'API Rest. Assegurar una API Rest és molt més difícil que un lloc web normal. Fins i tot els mètodes trivials de protecció contra la força bruta de contrasenyes i altres activitats il·legítimes no funcionen per a l'API Rest.
L'API Rest és molt fàcil de trencar perquè accedeix directament a la base de dades. Al mateix temps, el fracàs d'aquest servei comporta conseqüències força greus per a les empreses. El cas és que l'API Rest s'utilitza normalment no només per al lloc web principal, sinó també per a l'aplicació mòbil i alguns recursos empresarials interns. I si tot això cau, l'efecte és molt més fort que en el cas d'una simple fallada del lloc web.
S'està carregant contingut pesat
Si se'ns ofereix provar alguna aplicació d'una sola pàgina, pàgina de destinació o lloc web de targetes de visita que no tingui una funcionalitat complexa, busquem contingut pesat. Per exemple, imatges grans que envia el servidor, fitxers binaris, documentació en pdf, intentem descarregar tot això. Aquestes proves carreguen bé el sistema de fitxers i obstrueixen els canals i, per tant, són efectives. És a dir, fins i tot si no deixis el servidor, baixant un fitxer gran a baixa velocitat, simplement obstruiràs el canal del servidor objectiu i llavors es produirà una denegació de servei.
Un exemple d'aquesta prova mostra que a una velocitat de 30 RPS el lloc va deixar de respondre o va produir errors del servidor número 500.
No us oblideu de configurar servidors. Sovint podeu trobar que una persona ha comprat una màquina virtual, hi ha instal·lat Apache, ho ha configurat tot per defecte, ha instal·lat una aplicació PHP i a continuació podeu veure el resultat.
Aquí la càrrega va anar a l'arrel i només va ascendir a 10 RPS. Vam esperar 5 minuts i el servidor es va estavellar. És cert que no se sap del tot per què va caure, però es suposa que simplement tenia massa memòria i, per tant, va deixar de respondre.
Basat en ones
En l'últim any o dos, els atacs d'onades s'han tornat força populars. Això es deu al fet que moltes organitzacions compren determinades peces de maquinari per a la protecció DDoS, que requereixen una certa quantitat de temps per acumular estadístiques per començar a filtrar l'atac. És a dir, no filtren l'atac en els primers 30-40 segons, perquè acumulen dades i aprenen. En conseqüència, en aquests 30-40 segons podeu llançar tant al lloc que el recurs romandrà durant molt de temps fins que s'aclareixin totes les sol·licituds.
En el cas de l'atac a continuació, hi va haver un interval de 10 minuts, després del qual va arribar una nova part modificada de l'atac.
És a dir, la defensa va aprendre, va començar a filtrar-se, però va arribar una part nova, completament diferent de l'atac, i la defensa va començar a aprendre de nou. De fet, el filtratge deixa de funcionar, la protecció es torna ineficaç i el lloc no està disponible.
Els atacs d'onades es caracteritzen per valors molt alts al pic, poden arribar a les cent mil o un milió de peticions per segon, en el cas de L7. Si parlem de L3&4, aleshores hi pot haver centenars de gigabits de trànsit, o, en conseqüència, centenars de mpps, si es compta en paquets.
El problema d'aquests atacs és la sincronització. Els atacs provenen d'una xarxa de bots i requereixen un alt grau de sincronització per crear un pic puntual molt gran. I aquesta coordinació no sempre funciona: de vegades la sortida és una mena de pic parabòlic, que sembla més aviat patètic.
No només HTTP
A més de l'HTTP a L7, ens agrada explotar altres protocols. Per regla general, un lloc web normal, especialment un allotjament habitual, té protocols de correu i MySQL sobresortint. Els protocols de correu estan subjectes a menys càrrega que les bases de dades, però també es poden carregar de manera bastant eficient i acabar amb una CPU sobrecarregada al servidor.
Vam tenir molt èxit amb la vulnerabilitat SSH de 2016. Ara aquesta vulnerabilitat s'ha solucionat per a gairebé tothom, però això no vol dir que la càrrega no es pugui enviar a SSH. Llauna. Simplement hi ha una gran quantitat d'autoritzacions, SSH consumeix gairebé tota la CPU del servidor i, a continuació, el lloc web es col·lapsa d'una o dues sol·licituds per segon. En conseqüència, aquestes una o dues sol·licituds basades en els registres no es poden distingir d'una càrrega legítima.
Moltes connexions que obrim als servidors també segueixen sent rellevants. Abans, Apache era culpable d'això, ara nginx és realment culpable d'això, ja que sovint es configura per defecte. El nombre de connexions que nginx pot mantenir obertes és limitat, de manera que obrim aquest nombre de connexions, nginx ja no accepta una connexió nova i, com a resultat, el lloc no funciona.
El nostre clúster de prova té prou CPU per atacar l'enllaç SSL. En principi, com mostra la pràctica, a les botnets també els agrada fer això. D'una banda, està clar que no es pot prescindir de SSL, perquè els resultats de Google, el rànquing, la seguretat. D'altra banda, SSL malauradament té un problema de CPU.
L3 i 4
Quan parlem d'un atac als nivells L3 i 4, normalment estem parlant d'un atac a nivell d'enllaç. Aquesta càrrega gairebé sempre es pot distingir d'una de legítima, tret que es tracti d'un atac SYN-flood. El problema dels atacs SYN-flood per a eines de seguretat és el seu gran volum. El valor màxim de L3&4 era d'1,5-2 Tbit/s. Aquest tipus de trànsit és molt difícil de processar fins i tot per a grans empreses, com ara Oracle i Google.
SYN i SYN-ACK són paquets que s'utilitzen en establir una connexió. Per tant, SYN-flood és difícil de distingir d'una càrrega legítima: no està clar si es tracta d'un SYN que va arribar a establir una connexió o part d'una inundació.
UDP-inundació
Normalment, els atacants no tenen les capacitats que tenim, de manera que l'amplificació es pot utilitzar per organitzar atacs. És a dir, l'atacant explora Internet i troba servidors vulnerables o configurats incorrectament que, per exemple, en resposta a un paquet SYN, responen amb tres SYN-ACK. Mitjançant la falsificació de l'adreça d'origen des de l'adreça del servidor de destinació, és possible augmentar la potència, per exemple, tres vegades amb un sol paquet i redirigir el trànsit a la víctima.
El problema de les amplificacions és que són difícils de detectar. Alguns exemples recents inclouen el cas sensacional dels vulnerables memcached. A més, ara hi ha molts dispositius IoT, càmeres IP, que també es configuren majoritàriament de manera predeterminada, i per defecte estan configurats incorrectament, per això els atacants sovint fan atacs a través d'aquests dispositius.
SYN-inundació difícil
SYN-flood és probablement el tipus d'atac més interessant des del punt de vista d'un desenvolupador. El problema és que els administradors del sistema solen utilitzar el bloqueig d'IP per protegir-se. A més, el bloqueig d'IP no només afecta els administradors de sistemes que actuen mitjançant scripts, sinó també, malauradament, alguns sistemes de seguretat que es compren per molts diners.
Aquest mètode pot convertir-se en un desastre, perquè si els atacants substitueixen les adreces IP, l'empresa bloquejarà la seva pròpia subxarxa. Quan el tallafoc bloqueja el seu propi clúster, la sortida fallarà en les interaccions externes i el recurs fallarà.
A més, no és difícil bloquejar la vostra pròpia xarxa. Si l'oficina del client disposa d'una xarxa Wi-Fi, o si el rendiment dels recursos es mesura mitjançant diversos sistemes de monitorització, prenem l'adreça IP d'aquest sistema de monitorització o la Wi-Fi de l'oficina del client i l'utilitzem com a font. Al final, sembla que el recurs està disponible, però les adreces IP de destinació estan bloquejades. Així, la xarxa Wi-Fi de la conferència HighLoad, on s'està presentant el nou producte de l'empresa, pot quedar bloquejada, i això comporta certs costos empresarials i econòmics.
Durant les proves, no podem utilitzar l'amplificació mitjançant memcached amb cap recurs extern, perquè hi ha acords per enviar trànsit només a adreces IP permeses. En conseqüència, utilitzem l'amplificació mitjançant SYN i SYN-ACK, quan el sistema respon a l'enviament d'un SYN amb dos o tres SYN-ACK, i a la sortida l'atac es multiplica per dues o tres vegades.
Instruments
Una de les eines principals que fem servir per a la càrrega de treball L7 és Yandex-tank. En particular, un fantasma s'utilitza com a pistola, a més hi ha diversos scripts per generar cartutxos i per analitzar els resultats.
Tcpdump s'utilitza per analitzar el trànsit de xarxa i Nmap s'utilitza per analitzar el servidor. Per crear la càrrega al nivell L3 i 4, s'utilitzen OpenSSL i una mica de la nostra pròpia màgia amb la biblioteca DPDK. DPDK és una biblioteca d'Intel que us permet treballar amb la interfície de xarxa sense passar per la pila de Linux, augmentant així l'eficiència. Naturalment, utilitzem DPDK no només al nivell L3 i 4, sinó també al nivell L7, perquè ens permet crear un flux de càrrega molt elevat, dins del rang de diversos milions de peticions per segon d'una màquina.
També fem servir determinats generadors de trànsit i eines especials que escrivim per a proves específiques. Si recordem la vulnerabilitat sota SSH, el conjunt anterior no es pot explotar. Si atacem el protocol de correu, agafem utilitats de correu o simplement escrivim scripts sobre ells.
Troballes
Com a conclusió m'agradaria dir:
- A més de les proves de càrrega clàssiques, és necessari realitzar proves d'estrès. Tenim un exemple real on el subcontractista d'un soci només va realitzar proves de càrrega. Va demostrar que el recurs pot suportar la càrrega normal. Però aleshores va aparèixer una càrrega anormal, els visitants del lloc van començar a utilitzar el recurs una mica diferent i, com a resultat, el subcontractista es va estirar. Per tant, val la pena buscar vulnerabilitats encara que ja esteu protegits dels atacs DDoS.
- Cal aïllar algunes parts del sistema d'altres. Si teniu una cerca, heu de moure-la a màquines separades, és a dir, ni tan sols a Docker. Perquè si falla la cerca o l'autorització, almenys alguna cosa continuarà funcionant. En el cas d'una botiga online, els usuaris continuaran trobant productes al catàleg, passaran des de l'agregador, compraran si ja estan autoritzats o autoritzaran a través d'OAuth2.
- No descuideu tot tipus de serveis al núvol.
- Utilitzeu CDN no només per optimitzar els retards de la xarxa, sinó també com a mitjà de protecció contra atacs a l'esgotament del canal i simplement inundar el trànsit estàtic.
- Cal utilitzar serveis de protecció especialitzats. No us podeu protegir dels atacs L3 i 4 a nivell de canal, perquè el més probable és que simplement no tingueu un canal suficient. També és poc probable que combatis els atacs L7, ja que poden ser molt grans. A més, la recerca de petits atacs segueix sent prerrogativa de serveis especials, algorismes especials.
- Actualitzeu regularment. Això s'aplica no només al nucli, sinó també al dimoni SSH, especialment si els teniu oberts a l'exterior. En principi, tot s'ha d'actualitzar, perquè és poc probable que pugueu fer un seguiment de determinades vulnerabilitats pel vostre compte.
Font: www.habr.com