Legitimni promet na DDoS-Guard mreži nedavno je premašio sto gigabita u sekundi. Trenutno 50% našeg prometa generiraju klijentski web servisi. Radi se o nekoliko desetina hiljada domena, veoma različitih i u većini slučajeva zahtijevaju individualni pristup.
Ispod reza je kako upravljamo prednjim čvorovima i izdajemo SSL certifikate za stotine hiljada lokacija.
Postavljanje pročelja za jednu lokaciju, čak i vrlo veliku, je jednostavno. Uzimamo nginx ili haproxy ili lighttpd, konfiguriramo ga prema vodičima i zaboravimo na to. Ako treba nešto promijeniti, izvršimo ponovno učitavanje i ponovo zaboravimo.
Sve se mijenja kada obrađujete velike količine prometa u hodu, procjenjujete legitimnost zahtjeva, komprimirate i keširate korisnički sadržaj, a istovremeno mijenjate parametre nekoliko puta u sekundi. Korisnik želi vidjeti rezultat na svim vanjskim čvorovima odmah nakon što promijeni postavke na svom ličnom računu. Korisnik također može preuzeti nekoliko hiljada (a ponekad i desetine hiljada) domena sa pojedinačnim parametrima obrade prometa putem API-ja. Sve bi to trebalo odmah proraditi i u Americi, i u Europi, i u Aziji - zadatak nije najtrivijalan, s obzirom da samo u Moskvi postoji nekoliko fizički odvojenih filtracijskih čvorova.
Zašto postoji mnogo velikih pouzdanih čvorova širom svijeta?
-
Kvaliteta usluge za klijentski promet - zahtjevi iz SAD-a moraju se obraditi u SAD-u (uključujući napade, raščlanjivanje i druge anomalije), a ne povući u Moskvu ili Evropu, nepredvidivo povećavajući kašnjenje obrade.
-
Saobraćaj napada mora biti lokaliziran - tranzitni operateri mogu degradirati tokom napada, čiji obim često prelazi 1Tbps. Prenošenje napadačkog saobraćaja preko transatlantskih ili transazijskih veza nije dobra ideja. Imali smo stvarne slučajeve kada su operateri Tier-1 govorili: „Obim napada koji primate je opasan za nas.“ Zato prihvatamo dolazne streamove što bliže njihovim izvorima.
-
Strogi zahtjevi za kontinuitetom usluge - centri za čišćenje ne bi trebali ovisiti jedni o drugima niti o lokalnim događajima u našem svijetu koji se brzo mijenja. Jeste li isključili struju na svih 11 spratova MMTS-9 na nedelju dana? - nema problema. Niti jedan klijent koji nema fizičku vezu na ovoj lokaciji neće patiti, a web servisi neće patiti ni pod kojim okolnostima.
Kako upravljati svim ovim?
Konfiguracije usluga treba da se distribuiraju na sve prednje čvorove što je brže moguće (idealno trenutno). Ne možete samo uzeti i ponovo izgraditi tekstualne konfiguracije i ponovo pokrenuti demone pri svakoj promjeni - isti nginx drži procese ugašenim (isključivanje radnika) još nekoliko minuta (ili možda sati ako postoje duge sesije websocketa).
Prilikom ponovnog učitavanja nginx konfiguracije, sljedeća slika je sasvim normalna:
O korištenju memorije:
Stari radnici jedu memoriju, uključujući memoriju koja linearno ne zavisi od broja konekcija - to je normalno. Kada se klijentske veze zatvore, ova memorija će se osloboditi.
Zašto ovo nije bio problem kada je nginx tek počeo? Nije bilo HTTP/2, nije bilo WebSocketa, nije bilo velikih dugotrajnih veza. 70% našeg web prometa je HTTP/2, što znači vrlo duge veze.
Rješenje je jednostavno - nemojte koristiti nginx, ne upravljajte frontovima na osnovu tekstualnih datoteka i svakako nemojte slati zipovane tekstualne konfiguracije preko transpacifičkih kanala. Kanali su, naravno, zagarantovani i rezervirani, ali to ih ne čini manje transkontinentalnim.
Imamo vlastiti prednji server-balanser, o čijoj unutrašnjosti ću govoriti u sljedećim člancima. Glavna stvar koju može da uradi je da primeni hiljade izmena konfiguracije u sekundi u hodu, bez restartovanja, ponovnog učitavanja, naglog povećanja potrošnje memorije i svega toga. Ovo je vrlo slično Hot Code Reloadu, na primjer u Erlangu. Podaci se pohranjuju u geo-distribuiranoj bazi podataka ključ/vrijednost i odmah ih čitaju prednji aktuatori. One. učitate SSL sertifikat preko web interfejsa ili API-ja u Moskvi i za nekoliko sekundi je spreman za odlazak u naš centar za čišćenje u Los Anđelesu. Ako se iznenada dogodi svetski rat i internet nestane u celom svetu, naši čvorovi će nastaviti da rade autonomno i popravljaju podeljeni mozak čim jedan od namenskih kanala Los Anđeles-Amsterdam-Moskva, Moskva-Amsterdam-Hong Kong- Los-Los postaje dostupan Angeles ili barem jedan od GRE rezervnih slojeva.
Ovaj isti mehanizam nam omogućava da trenutno izdamo i obnovimo Let's Encrypt certifikate. Vrlo jednostavno funkcionira ovako:
-
Čim vidimo barem jedan HTTPS zahtjev za domenu našeg klijenta bez certifikata (ili sa isteklim certifikatom), vanjski čvor koji je prihvatio zahtjev to prijavljuje internom certifikacijskom tijelu.
-
Ako korisnik nije zabranio izdavanje Let's Encrypt, certifikacijsko tijelo generiše CSR, prima token za potvrdu od LE i šalje ga na sve frontove preko šifrovanog kanala. Sada bilo koji čvor može potvrditi zahtjev za validaciju od LE.
-
Za nekoliko trenutaka ćemo dobiti ispravan certifikat i privatni ključ i na isti način ga poslati na frontove. Opet, bez ponovnog pokretanja demona
-
7 dana prije isteka roka, pokreće se postupak za ponovno dobijanje certifikata
Trenutno rotiramo 350k sertifikata u realnom vremenu, potpuno transparentno za korisnike.
U sljedećim člancima iz serije govorit ću o drugim značajkama obrade velikog web prometa u realnom vremenu - na primjer, o analizi RTT-a korištenjem nepotpunih podataka za poboljšanje kvalitete usluge za tranzitne klijente i općenito o zaštiti tranzitnog prometa od terabit napadi, o isporuci i agregaciji saobraćajnih informacija, o WAF-u, gotovo neograničenom CDN-u i mnogim mehanizmima za optimizaciju isporuke sadržaja.
Samo registrovani korisnici mogu učestvovati u anketi. molim.
Šta biste prvo željeli znati?
-
14,3%Algoritmi za grupisanje i analizu kvaliteta web saobraćaja<3
-
33,3%Unutrašnjost DDoS-Guard7 balansera
-
9,5%Zaštita tranzitnog L3/L4 saobraćaja2
-
0,0%Zaštita web stranica od tranzitnog prometa0
-
14,3%Zaštitni zid web aplikacije3
-
28,6%Zaštita od raščlanjivanja i klikanja6
Glasao je 21 korisnik. 6 korisnika je bilo uzdržano.
izvor: www.habr.com