Variti sviluppa a prutezzione contra i bots è l'attacchi DDoS, è ancu cunduce teste di stress è di carica. À a cunferenza HighLoad++ 2018 avemu parlatu di cumu assicurà e risorse da parechji tipi di attacchi. In breve: isolate parti di u sistema, utilizate servizii cloud è CDN, è aghjurnà regularmente. Ma ùn sarete ancu capaci di trattà a prutezzione senza cumpagnie specializate :)
Prima di leghje u testu, pudete leghje i brevi abstracts .
È s'ellu ùn ti piace micca leghje o solu vulete vede u video, a registrazione di u nostru rapportu hè sottu sottu u spoiler.
Registrazione video di u rapportu
Parechje cumpagnie sanu digià cumu fà a prova di carica, ma micca tutte e teste di stress. Qualchidunu di i nostri clienti pensanu chì u so situ hè invulnerable perchè anu un sistema highload, è pruteghja bè da attacchi. Dimustremu chì questu ùn hè micca cumplettamente veru.
Di sicuru, prima di fà e teste, avemu ottene u permessu di u cliente, firmatu è stampatu, è cù u nostru aiutu un attaccu DDoS ùn pò esse realizatu à nimu. A prova hè realizata in un tempu sceltu da u cliente, quandu u trafficu à a so risorsa hè minimu, è i prublemi d'accessu ùn affettanu micca i clienti. Inoltre, postu chì qualcosa pò sempre sbaglià durante u prucessu di prova, avemu un cuntattu constante cù u cliente. Questu permette micca solu di rapportà i risultati ottenuti, ma ancu di cambià qualcosa durante a prova. Dopu à a fine di a prova, avemu sempre un rapportu in quale indichemu i difetti rilevati è dà cunsiglii per eliminà e debule di u situ.
Cumu travagliamu
Quandu testemu, emulemu una botnet. Siccomu travagliendu cù i clienti chì ùn sò micca situati nantu à e nostre rete, per assicurà chì a prova ùn finisce micca in u primu minutu per via di limiti o prutezzione attivata, furnimu a carica micca da una IP, ma da a nostra propria subnet. In più, per creà una carica significativa, avemu u nostru servitore di prova abbastanza putente.
Postulati
Troppu ùn significa micca bè
A menu carica pudemu portà una risorsa à fallimentu, u megliu. Se pudete fà chì u situ cessà di funziunà nantu à una dumanda per seconda, o ancu una dumanda per minutu, hè grande. Perchè sicondu a lege di a meanness, l'utilizatori o l'attaccanti cascanu accidentalmente in questa vulnerabilità particulare.
Un fallimentu parziale hè megliu cà un fallimentu cumpletu
Avemu sempre cunsigliatu di fà sistemi eterogenei. Inoltre, vale a pena separà à u livellu fisicu, è micca solu per containerizazione. In u casu di a separazione fisica, ancu s'ellu ci hè qualcosa fiasca nantu à u situ, ci hè una alta probabilità chì ùn ferma micca di travaglià cumpletamente, è l'utilizatori continuanu à avè accessu à almenu una parte di e funziunalità.
A bona architettura hè a basa per a sustenibilità
A tolleranza di difetti di una risorsa è a so capacità di resiste à attacchi è carichi deve esse stabilitu in u stadiu di cuncepimentu, in fattu, in u stadiu di disegnu i primi diagrammi di flussu in un bloccu note. Perchè s'ellu ci sò sbagliati fatali, hè pussibule di correggerli in u futuru, ma hè assai difficiule.
Ùn solu u codice deve esse bonu, ma ancu a cunfigurazione
Parechje persone pensanu chì una bona squadra di sviluppu hè una guaranzia di serviziu tolerante à i difetti. Un bonu squadra di sviluppu hè veramente necessariu, ma ci vole ancu esse boni operazioni, boni DevOps. Vale à dì, avemu bisognu di specialisti chì cunfiguranu currettamente Linux è a rete, scrivenu cunfigurazioni currettamente in nginx, stabiliscenu limiti, etc. Altrimenti, a risorsa hà da travaglià bè solu in a prova, è in un certu puntu tuttu romperà in a produzzione.
Differenze trà e teste di carica è di stress
A prova di carica permette di identificà i limiti di u funziunamentu di u sistema. A prova di stress hè destinata à truvà punti debbuli in un sistema è hè aduprata per rompe stu sistema è vede cumu si cumportanu in u prucessu di fallimentu di certi parti. In questu casu, a natura di a carica di solitu resta scunnisciuta à u cliente prima di inizià a prova di stress.
Caratteristiche distintive di l'attacchi L7
Di solitu dividemu tippi di carica in carichi à i livelli L7 è L3 & 4. L7 hè una carica à u nivellu di l'applicazione, a maiò spessu significa solu HTTP, ma significhemu ogni carica à u nivellu di u protocolu TCP.
L'attacchi L7 anu certe caratteristiche distintive. Prima, venenu direttamente à l'appiecazione, vale à dì, hè improbabile chì saranu riflessi per mezu di a rete. Tali attacchi utilizanu a logica, è per quessa, cunsumu CPU, memoria, discu, basa di dati è altre risorse assai efficace è cù pocu trafficu.
HTTP Flood
In u casu di qualsiasi attaccu, a carica hè più faciule di creà chè di trattà, è in u casu di L7 questu hè ancu veru. Ùn hè micca sempre faciule di distinguishà u trafficu d'attaccu da u trafficu legittimu, è più spessu questu pò esse fattu da a freccia, ma se tuttu hè pianificatu currettamente, allora hè impussibile di capiscenu da i logs induve hè l'attaccu è induve sò e dumande legittimi.
Comu primu esempiu, cunzidira un attaccu HTTP Flood. U graficu mostra chì tali attacchi sò di solitu assai putenti; in l'esempiu sottu, u piccu numeru di richieste superava 600 mila per minutu.
HTTP Flood hè u modu più faciule per creà carica. Di genere, ci vole un tipu di strumentu di prova di carica, cum'è ApacheBench, è stabilisce una dumanda è un mira. Cù un approcciu cusì simplice, ci hè una alta probabilità di curriri in u caching di u servitore, ma hè faciule per aggirallu. Per esempiu, aghjunghjendu strings aleatorii à a dumanda, chì furzà u servitore à serve constantemente una pagina fresca.
Inoltre, ùn vi scurdate di l'agente d'utilizatore in u prucessu di creazione di una carica. Parechji agenti d'utilizatori di strumenti di teste populari sò filtrati da l'amministratori di u sistema, è in questu casu, a carica ùn pò micca ghjunghje à u backend. Pudete migliurà significativamente u risultatu inserendu un capu più o menu validu da u navigatore in a dumanda.
Hè simplice quant'è l'attacchi HTTP Flood sò, anu ancu i so svantaghji. Prima, una grande quantità di putere hè necessariu per creà a carica. Siconda, tali attacchi sò assai faciuli di detectà, soprattuttu s'ellu venenu da un indirizzu. In u risultatu, e dumande cumincianu immediatamente à esse filtrate da l'amministratori di u sistema o ancu à u livellu di u fornitore.
Chì circà
Per riduce u nùmeru di richieste per seconda senza perde l'efficienza, avete bisognu di vede un pocu di imaginazione è scopre u situ. Cusì, pudete carricà micca solu u canali o u servitore, ma ancu e parti individuali di l'applicazione, per esempiu, basa di dati o sistemi di schedari. Pudete ancu circà i lochi nantu à u situ chì facenu grandi calculi: calculatrici, pagine di selezzione di prudutti, etc. Infine, spessu succede chì u situ hà qualchì tipu di script PHP chì genera una pagina di parechji centu mila linee. Un tali script carica ancu significativamente u servitore è pò diventà un mira per un attaccu.
Induve circà
Quandu scannemu una risorsa prima di pruvà, prima guardemu, sicuru, à u situ stessu. Cerchemu ogni tipu di campi di input, schedarii pisanti - in generale, tuttu ciò chì pò creà prublemi per a risorsa è rallentà u so funziunamentu. Strumenti di sviluppu banale in Google Chrome è Firefox aiutanu quì, chì mostranu i tempi di risposta di a pagina.
Avemu ancu scansà i subdominii. Per esempiu, ci hè una certa tenda in linea, abc.com, è hà un subdomain admin.abc.com. Hè assai prubabile, questu hè un pannellu amministratore cù l'autorizazione, ma se mette una carica nantu à questu, pò creà prublemi per a risorsa principale.
U situ pò avè un subdominiu api.abc.com. Probabilmente, questu hè una risorsa per l'applicazioni mobili. L'applicazione pò esse truvata in l'App Store o Google Play, installate un puntu d'accessu speciale, dissecte l'API è registrate cunti di prova. U prublema hè chì a ghjente spessu pensa chì tuttu ciò chì hè prutettu da l'autorizazione hè immune à a denegazione di attacchi di serviziu. Suppone, l'autorizazione hè u megliu CAPTCHA, ma ùn hè micca. Hè facilitu per fà 10-20 cunti di teste, ma da a creazione di elli, avemu accessu à funziunalità cumplessu è undisguised.
Naturalmente, fighjemu a storia, in robots.txt è WebArchive, ViewDNS, è cercate e versioni antichi di a risorsa. Calchì volta succede chì i sviluppatori anu spartu, per dì, mail2.yandex.net, ma a vechja versione, mail.yandex.net, ferma. Questu mail.yandex.net ùn hè più supportatu, i risorse di sviluppu ùn sò micca attribuiti à questu, ma cuntinueghja à cunsumà a basa di dati. In cunsiquenza, utilizendu a versione antica, pudete aduprà efficacemente e risorse di u backend è tuttu ciò chì hè daretu à u layout. Di sicuru, questu ùn hè micca sempre accadutu, ma avemu sempre scontru questu abbastanza spessu.
Naturalmente, analizemu tutti i paràmetri di dumanda è a struttura di cookie. Pudete, dì, scaricate qualchì valore in un array JSON in una cookie, creà assai nidificazione è fà chì a risorsa travaglia per un tempu irragionevule.
Ricerca carica
A prima cosa chì vene in mente quandu a ricerca di un situ hè di carricà a basa di dati, postu chì quasi tutti anu una ricerca, è per quasi tutti, sfurtunatamenti, hè pocu prutettu. Per una certa ragione, i sviluppatori ùn prestanu micca abbastanza attenzione à a ricerca. Ma ci hè una ricumandazione quì - ùn deve micca fà richieste di u listessu tipu, perchè pudete scuntrà caching, cum'è u casu cù HTTP flood.
Fà e dumande aleatorii à a basa di dati ùn hè micca sempre efficace. Hè assai megliu per creà una lista di chjave chì sò pertinenti à a ricerca. Se turnemu à l'esempiu di una tenda in linea: dicemu chì u situ vende pneumatici di vittura è permette di stabilisce u raghju di i pneumatici, u tipu di vittura è altri paràmetri. In cunsiquenza, cumminazzioni di parolle pertinenti furzà a basa di dati à travaglià in cundizioni assai più cumplesse.
Inoltre, vale a pena aduprà a paginazione: hè assai più difficiule per una ricerca per rinvià a penultima pagina di i risultati di ricerca chè a prima. Questu hè, cù l'aiutu di a paginazione pudete diversificà ligeramente a carica.
L'esempiu sottu mostra a carica di ricerca. Pò esse vistu chì da u primu secondu di a prova à una velocità di deci richieste per seconda, u situ hè cascatu è ùn hà micca rispostu.
Se ùn ci hè micca una ricerca?
Se ùn ci hè micca una ricerca, questu ùn significa micca chì u situ ùn cuntene micca altri campi di input vulnerabili. Stu campu pò esse l'autorizazione. Oghje, i sviluppatori piacenu fà hashes cumplessi per prutege a basa di dati di login da un attaccu di tavola arcubalenu. Questu hè bonu, ma tali hashes cunsuma assai risorse di CPU. Un grande flussu d'autorizazioni falsi porta à un fallimentu di u processatore, è in u risultatu, u situ cessà di travaglià.
A prisenza nantu à u situ di ogni tipu di forme per cumenti è feedback hè un mutivu per mandà testi assai grande o simpricimenti creanu una inundazione massiva. A volte i siti accettanu i fugliali attaccati, ancu in u formatu gzip. In questu casu, pigliemu un schedariu 1TB, cumpressà à parechji byte o kilobyte usendu gzip è mandà à u situ. Allora hè unzipped è un effettu assai interessante hè ottenutu.
API Rest
Mi piacerebbe pagà un pocu d'attenzione à i servizii populari cum'è l'API Rest. Assicurà un Rest API hè assai più difficiule di un situ web regulare. Ancu i metudi triviali di prutezzione contra a forza bruta di password è altre attività illegittima ùn funziona micca per l'API Rest.
L'API Rest hè assai faciule da rompe perchè accede direttamente à a basa di dati. À u listessu tempu, u fallimentu di un tali serviziu implica cunsiquenzi abbastanza serii per l'affari. U fattu hè chì l'API Rest hè generalmente utilizata micca solu per u situ web principale, ma ancu per l'applicazione mobile è qualchi risorse di cummerciale internu. E s'ellu hè cascatu tuttu questu, l'effettu hè assai più forte chì in u casu di un fallimentu simplice di u situ web.
Caricà u cuntenutu pesante
Se ci hè offrittu di pruvà una applicazione ordinaria di una sola pagina, una pagina di destinazione o un situ web di carta di visita chì ùn hà micca funziunalità cumplessa, cerchemu un cuntenutu pesante. Per esempiu, grandi imagine chì u servitore manda, schedarii binari, documentazione pdf - pruvemu di scaricà tuttu questu. Tali testi caricanu bè u sistema di fugliale è i canali di i canali, è per quessa sò efficaci. Hè vale à dì, ancu s'ellu ùn mette micca u servitore, scarichendu un grande fugliale à bassa velocità, vi basta à sbattà u canali di u servitore di destinazione, è dopu una denegazione di serviziu serà accaduta.
Un esempiu di un tali teste mostra chì à una velocità di 30 RPS u situ hà cessatu di risponde o pruducia 500th server errors.
Ùn vi scurdate di stallà i servitori. Pudete truvà spessu chì una persona hà compru una macchina virtuale, installate Apache quì, cunfigurate tuttu per automaticamente, installate una applicazione PHP, è quì sottu pudete vede u risultatu.
Quì a carica si n'andò à a radica è era solu 10 RPS. Avemu aspittatu 5 minuti è u servitore hè cascatu. Hè vera chì ùn si sà micca cumplettamente perchè hè cascatu, ma ci hè una supposizione chì simpricimenti avia troppu memoria è dunque cessatu di risponde.
Basatu nantu à l'onda
In l'ultimu annu o dui, l'attacchi d'onda sò diventati assai populari. Questu hè duvuta à u fattu chì assai urganisazione cumprà certi pezzi di hardware per a prutezzione DDoS, chì necessitanu un certu tempu per accumulà statistiche per cumincià à filtrà l'attaccu. Questu hè, ùn filtranu micca l'attaccu in i primi 30-40 seconde, perchè accumulanu dati è amparà. In cunsiquenza, in questi 30-40 seconde pudete lancià tantu nantu à u situ chì a risorsa si trova per un bellu pezzu finu à chì tutte e dumande sò sbulicate.
In u casu di l'attaccu sottu, ci era un intervallu di 10 minuti, dopu chì una nova parte mudificata di l'attaccu ghjunse.
Questu hè, a difesa hà amparatu, hà cuminciatu à filtrà, ma una nova parte completamente diversa di l'attaccu hè ghjunta, è a difesa hà cuminciatu à amparà di novu. In fatti, u filtru ferma di travaglià, a prutezzione diventa inefficace, è u situ ùn hè micca dispunibule.
L'attacchi d'onda sò carattarizati da valori assai alti à u piccu, pò ghjunghje à centu mila o un milione di richieste per seconda, in u casu di L7. Se parlemu di L3 & 4, allora ci ponu esse centinaie di gigabits di trafficu, o, per quessa, centinaie di mpps, se cuntate in pacchetti.
U prublema cù tali attacchi hè a sincronizazione. L'attacchi venenu da una botnet è necessitanu un altu gradu di sincronizazione per creà un spike one-time assai grande. E sta coordinazione ùn hè micca sempre u travagliu: qualchì volta l'output hè un tipu di piccu parabolicu, chì pare piuttostu pateticu.
Ùn solu HTTP
In più di HTTP à L7, ci piace à sfruttà altri protokolli. In regula, un situ web regulare, in particulare un hosting regulare, hà protokolli di mail è MySQL chì spuntanu. I protokolli di mail sò sottumessi à menu carichi cà e basa di dati, ma ponu ancu esse carricati abbastanza efficacimente è finiscinu cù una CPU sopracargata in u servitore.
Avemu avutu abbastanza successu cù a vulnerabilità SSH 2016. Avà sta vulnerabilità hè stata riparata per quasi tutti, ma questu ùn significa micca chì a carica ùn pò micca esse sottumessa à SSH. Can. Ci hè simplicemente una grande carica d'autorizazioni, SSH manghja quasi tuttu u CPU nantu à u servitore, è dopu u situ web colapsà da una o duie richieste per seconda. In cunsiquenza, queste una o duie dumande basate nantu à i logs ùn ponu esse distinti da una carica legittima.
Parechje cunnessione chì apremu in i servitori restanu ancu pertinenti. Nanzu, Apache era culpèvule di questu, avà nginx hè veramente culpèvule di questu, postu chì hè spessu cunfiguratu per difettu. U numaru di cunnessione chì nginx pò mantene apertu hè limitatu, cusì apremu stu numeru di cunnessione, nginx ùn accetta più una nova cunnessione, è in u risultatu u situ ùn funziona micca.
U nostru cluster di teste hà abbastanza CPU per attaccà SSL handshake. In principiu, cum'è a pratica mostra, i botnets volte piace ancu fà questu. Da una banda, hè chjaru chì ùn pudete micca fà senza SSL, perchè Google risultati, ranking, security. Per d 'altra banda, SSL hà sfurtunatamenti un prublema di CPU.
L3 & 4
Quandu avemu parlatu di un attaccu à i livelli L3 & 4, di solitu parlemu di un attaccu à u livellu di ligame. Una tale carica hè quasi sempre distinguibile da una legittima, salvu chì ùn sia un attaccu SYN-flood. U prublema cù attacchi SYN-flood per i strumenti di sicurezza hè u so grande volume. U valore massimu L3 & 4 era 1,5-2 Tbit/s. Stu tipu di trafficu hè assai difficiuli di processà ancu per e grande cumpagnie, cumprese Oracle è Google.
SYN è SYN-ACK sò pacchetti chì sò usati per stabilisce una cunnessione. Per quessa, SYN-flood hè difficiule à distingue da una carica legittima: ùn hè micca chjaru s'ellu hè un SYN chì hè vinutu à stabilisce una cunnessione, o parte di una inundazione.
UDP-inundazione
Di genere, l'attaccanti ùn anu micca e capacità chì avemu, cusì l'amplificazione pò esse aduprata per urganizà attacchi. Vale à dì, l'attaccante scansa l'Internet è trova servitori vulnerabili o cunfigurati incorrectamente chì, per esempiu, in risposta à un pacchettu SYN, risponde cù trè SYN-ACK. Spoofing l'indirizzu fonte da l'indirizzu di u servitore di destinazione, hè pussibule aumentà a putenza, per esempiu, trè volte cù un solu pacchettu è redirige u trafficu à a vittima.
U prublema cù l'amplificazioni hè chì sò difficiuli di detectà. Esempii recenti includenu u casu sensazionale di u memcached vulnerabile. In più, avà ci sò assai dispusitivi IoT, càmera IP, chì sò ancu più cunfigurati per difettu, è per difettu sò cunfigurati incorrectamente, chì hè per quessa chì l'attaccanti più spessu facenu attacchi attraversu tali dispositi.
Difficile SYN-inundazione
SYN-flood hè probabilmente u tipu d'attaccu più interessante da u puntu di vista di u sviluppatore. U prublema hè chì l'amministratori di u sistema spessu usanu u bluccatu IP per prutezzione. Inoltre, u bluccatu di l'IP ùn afecta micca solu l'amministratori di u sistema chì agiscenu cù scripts, ma ancu, sfurtunatamenti, certi sistemi di sicurità chì sò acquistati per assai soldi.
Stu metudu pò turnà in un disastru, perchè se l'attaccanti rimpiazzanu l'indirizzi IP, a cumpagnia bluccà a so propria subnet. Quandu u Firewall blucca u so propiu cluster, l'output fallirà l'interazzione esterna è a risorsa falla.
Inoltre, ùn hè micca difficiule di bluccà a vostra propria reta. Se l'uffiziu di u cliente hà una rete Wi-Fi, o se u rendiment di e risorse hè misuratu cù diversi sistemi di surviglianza, allora pigliamu l'indirizzu IP di stu sistema di monitoraghju o l'uffiziu di u cliente Wi-Fi è l'utilizanu cum'è fonte. À a fine, a risorsa pare esse dispunibule, ma l'indirizzi IP di destinazione sò bluccati. Cusì, a reta Wi-Fi di a cunferenza HighLoad, induve u novu pruduttu di a cumpagnia hè presentatu, pò esse bluccatu, è questu implica certi costi di cummerciale è ecunomichi.
Durante a prova, ùn pudemu micca aduprà l'amplificazione attraversu memcached cù qualsiasi risorse esterne, perchè ci sò accordi per mandà u trafficu solu à l'indirizzi IP permessi. In cunsiquenza, usemu l'amplificazione attraversu SYN è SYN-ACK, quandu u sistema risponde à mandà un SYN cù dui o trè SYN-ACK, è à l'output l'attaccu hè multiplicatu da duie o trè volte.
Ferramenti
Unu di i principali strumenti chì usemu per a carica di travagliu L7 hè Yandex-tank. In particulare, un fantasma hè utilizatu com'è pistola, in più ci sò parechje script per generà cartucce è per analizà i risultati.
Tcpdump hè utilizatu per analizà u trafficu di a rete, è Nmap hè utilizatu per analizà u servitore. Per creà a carica à u livellu L3 & 4, OpenSSL è un pocu di a nostra magia cù a biblioteca DPDK sò usati. DPDK hè una biblioteca di Intel chì vi permette di travaglià cù l'interfaccia di a rete sguassendu a pila Linux, aumentandu cusì l'efficienza. Naturalmente, usemu DPDK micca solu à u livellu L3 & 4, ma ancu à u livellu L7, perchè ci permette di creà un flussu di carica assai altu, in a gamma di parechji milioni di richieste per seconda da una macchina.
Avemu ancu aduprà certi generatori di trafficu è arnesi speciale chì scrivimu per teste specifiche. Se ricurdemu a vulnerabilità sottu SSH, allora u settore sopra ùn pò micca esse sfruttatu. Sè attaccà u protocolu di mail, pigliamu utilità di mail o simpricimenti scrivite scripts nantu à elli.
scuperti
In cunclusione, vogliu dì:
- In più di a prova di carica classica, hè necessariu di fà una prova di stress. Avemu un veru esempiu induve u subcontractante di un partner hà fattu solu teste di carica. Hà dimustratu chì a risorsa pò sustene a carica normale. Ma tandu apparsu una carica anormale, i visitori di u situ cuminciaru à utilizà a risorsa un pocu sfarente, è in u risultatu, u subcontractor si mette. Cusì, vale a pena cercà e vulnerabilità ancu s'ellu hè digià prutettu da attacchi DDoS.
- Hè necessariu isolà alcune parti di u sistema da l'altri. Se tenete una ricerca, avete bisognu di trasfurmà à e macchine separate, vale à dì, mancu à Docker. Perchè se a ricerca o l'autorizazione falla, almenu qualcosa continuarà à travaglià. In u casu di una tenda in linea, l'utilizatori cuntinueghjanu à truvà prudutti in u catalogu, andate da l'agregatore, cumprà s'ellu sò digià autorizati, o auturizà via OAuth2.
- Ùn trascurate micca tutti i tipi di servizii cloud.
- Aduprate CDN micca solu per ottimisà i ritardi di a rete, ma ancu cum'è un mezzu di prutezzione contra l'attacchi à l'esaurimentu di u canali è solu inundazioni in u trafficu staticu.
- Hè necessariu di utilizà servizii di prutezzione specializati. Ùn pudete micca prutegge da l'attacchi L3 & 4 à u livellu di u canali, perchè probabilmente ùn avete micca un canale abbastanza. Hè ancu improbabile di cummattiri l'attacchi L7, postu chì ponu esse assai grande. In più, a ricerca di picculi attacchi hè sempre a prerogativa di servizii speciali, algoritmi speciali.
- Aghjurnate regularmente. Questu ùn hè micca solu à u kernel, ma ancu à u daemon SSH, soprattuttu s'ellu avete apertu à l'esternu. In principiu, tuttu deve esse aghjurnatu, perchè hè improbabile di pudè seguità certe vulnerabilità per sè stessu.
Source: www.habr.com