Ovaj je članak četvrti u nizu “Kako preuzeti kontrolu nad svojom mrežnom infrastrukturom.” Sadržaj svih članaka u seriji i poveznice možete pronaći здесь.

В prvi dio U ovom poglavlju pogledali smo neke aspekte mrežne sigurnosti u segmentu podatkovnih centara. Ovaj dio bit će posvećen segmentu “Pristup internetu”.

Pristup Internetu

Tema sigurnosti nedvojbeno je jedna od najsloženijih tema u svijetu podatkovnih mreža. Kao iu prethodnim slučajevima, ne zahtijevajući dubinu i cjelovitost, ovdje ću razmotriti prilično jednostavna, ali, po mom mišljenju, važna pitanja, čiji će odgovori, nadam se, pomoći podići razinu sigurnosti vaše mreže.

Prilikom revizije ovog segmenta obratite pozornost na sljedeće aspekte:

• dizajn
• BGP postavke
• DOS/DDOS zaštita
• filtriranje prometa na vatrozidu

Dizajn

Kao primjer dizajna ovog segmenta za mrežu poduzeća, preporučio bih rukovodstvo od Cisca unutar SIGURNI modeli.

Naravno, možda će vam se rješenje drugih dobavljača činiti privlačnijim (vidi. Gartnerov kvadrant 2018), ali ne potičući vas da detaljno pratite ovaj dizajn, ipak smatram korisnim razumjeti principe i ideje iza njega.

primjedba

U SAFE-u segment "Udaljeni pristup" dio je segmenta "Pristup internetu". Ali u ovoj seriji članaka razmotrit ćemo to zasebno.

Standardni set opreme u ovom segmentu za mrežu poduzeća je

• granični usmjerivači
• vatrozidi

Napomena 1

U ovoj seriji članaka, kada govorim o vatrozidima, mislim NGFW.

Napomena 2

Izostavljam razmatranje raznih vrsta L2/L1 ili preklapanja L2 preko L3 rješenja potrebnih za osiguranje L1/L2 povezivosti i ograničavam se samo na probleme na razini L3 i iznad. Djelomično, pitanja L1/L2 razmatrana su u poglavlju „Čišćenje i dokumentacija”.

Ako u ovom segmentu niste pronašli vatrozid, ne biste trebali žuriti sa zaključcima.

Učinimo isto kao u prethodni dioKrenimo od pitanja je li u ovom segmentu u vašem slučaju potrebno koristiti firewall?

Mogu reći da se ovo čini najopravdanijim mjestom za korištenje vatrozida i primjenu složenih algoritama za filtriranje prometa. U 1 dijelovi Spomenuli smo 4 faktora koji mogu ometati korištenje vatrozida u segmentu podatkovnih centara. Ali ovdje oni više nisu toliko značajni.

Primjer 1. kašnjenje

Što se interneta tiče, nema smisla govoriti o kašnjenjima čak i oko 1 milisekunde. Stoga kašnjenje u ovom segmentu ne može biti faktor koji ograničava korištenje vatrozida.

Primjer 2. Performanse

U nekim slučajevima ovaj faktor može biti značajan. Stoga ćete možda morati dopustiti nekom prometu (na primjer, prometu iz balansera opterećenja) da zaobiđe vatrozid.

Primjer 3. Pouzdanost

Ovaj čimbenik još uvijek treba uzeti u obzir, no ipak, s obzirom na nepouzdanost samog interneta, njegova važnost za ovaj segment nije tako velika kao za podatkovni centar.

Dakle, pretpostavimo da vaša usluga živi na http/https (s kratkim sesijama). U ovom slučaju možete koristiti dva neovisna boxa (bez HA) i ako postoji problem s usmjeravanjem s jednim od njih, prebacite sav promet na drugi.

Ili možete koristiti vatrozid u transparentnom načinu rada i, ako zakaže, dopustiti prometu da zaobiđe vatrozid dok rješava problem.

Stoga, najvjerojatnije samo cijena može biti faktor koji će vas prisiliti da odustanete od upotrebe vatrozida u ovom segmentu.

Važno!

Postoji napast da se ovaj vatrozid kombinira s vatrozidom podatkovnog centra (koristite jedan vatrozid za ove segmente). Rješenje je, načelno, moguće, ali to trebate razumjeti jer Vatrozid za pristup internetu zapravo je na čelu vaše obrane i "preuzima" barem dio zlonamjernog prometa, a onda, naravno, morate uzeti u obzir povećani rizik da će taj vatrozid biti onemogućen. Odnosno, korištenjem istih uređaja u ova dva segmenta značajno ćete smanjiti dostupnost segmenta vašeg podatkovnog centra.

Kao i uvijek, trebate razumjeti da ovisno o usluzi koju tvrtka pruža, dizajn ovog segmenta može uvelike varirati. Kao i uvijek, možete odabrati različite pristupe ovisno o svojim zahtjevima.

Primjer

Ako ste davatelj sadržaja, s CDN mrežom (pogledajte, na primjer, serija članaka), onda možda nećete htjeti stvoriti infrastrukturu preko desetaka ili čak stotina točaka prisutnosti koristeći zasebne uređaje za usmjeravanje i filtriranje prometa. To će biti skupo, a može jednostavno biti nepotrebno.

Za BGP ne morate nužno imati namjenske usmjerivače, možete koristiti alate otvorenog koda kao što su Quagga. Možda je sve što trebate poslužitelj ili više poslužitelja, preklopnik i BGP.

U ovom slučaju vaš poslužitelj ili nekoliko poslužitelja mogu igrati ulogu ne samo CDN poslužitelja, već i usmjerivača. Naravno, ima još puno detalja (kao što je kako osigurati balansiranje), ali to je izvedivo i to je pristup koji smo uspješno upotrijebili za jednog od naših partnera.

Možete imati nekoliko podatkovnih centara s potpunom zaštitom (vatrozidi, usluge zaštite od DDOS-a koje pružaju vaši internetski provajderi) i desetke ili stotine "pojednostavljenih" točaka prisutnosti sa samo L2 sklopkama i poslužiteljima.

Ali što je sa zaštitom u ovom slučaju?

Pogledajmo, na primjer, nedavno popularne DNS Amplification DDOS napad. Njegova opasnost leži u činjenici da se stvara velika količina prometa, koja jednostavno "začepi" 100% svih vaših uplinkova.

Što imamo u slučaju našeg dizajna.

• ako koristite AnyCast, onda se promet distribuira između vaših točaka prisutnosti. Ako je vaša ukupna širina pojasa terabita, onda vas to zapravo samo po sebi (međutim, nedavno je bilo nekoliko napada sa zlonamjernim prometom reda veličine terabita) štiti od "prelijevanja" uzlaznih veza
• Međutim, ako se neke uzlazne veze začepe, jednostavno uklonite ovu stranicu iz usluge (prestanite oglašavati prefiks)
• također možete povećati udio prometa poslanog iz vaših "punih" (i, sukladno tome, zaštićenih) podatkovnih centara, uklanjajući tako značajan dio zlonamjernog prometa s nezaštićenih točaka prisutnosti

I još jedna mala napomena uz ovaj primjer. Ako šaljete dovoljno prometa kroz IX-ove, to također smanjuje vašu ranjivost na takve napade

Postavljanje BGP-a

Ovdje postoje dvije teme.

• Povezivost
• Postavljanje BGP-a

Već smo malo govorili o povezanosti u 1 dijelovi. Poanta je osigurati da promet do vaših klijenata slijedi optimalnu putanju. Iako optimalnost nije uvijek samo latencija, niska latencija obično je glavni pokazatelj optimalnosti. Za neke tvrtke to je važnije, za druge manje. Sve ovisi o usluzi koju pružate.

Primjer 1

Ako ste mjenjačnica, a vašim su klijentima bitni vremenski intervali manji od milisekundi, onda, naravno, ni o kakvom Internetu ne može biti govora.

Primjer 2

Ako ste gaming tvrtka i deseci milisekundi su vam važni, onda vam je, naravno, povezanost vrlo važna.

Primjer 3

Također morate razumjeti da, zbog svojstava TCP protokola, brzina prijenosa podataka unutar jedne TCP sesije također ovisi o RTT (Round Trip Time). CDN mreže također se grade kako bi riješile ovaj problem pomicanjem poslužitelja za distribuciju sadržaja bliže potrošaču ovog sadržaja.

Proučavanje povezanosti zanimljiva je tema sama po sebi, vrijedna vlastitog članka ili niza članaka i zahtijeva dobro razumijevanje načina na koji Internet "funkcionira".

Korisni resursi:

ripe.net
bgp.he.net

Primjer

Navest ću samo jedan mali primjer.

Pretpostavimo da se vaš podatkovni centar nalazi u Moskvi i da imate jednu uzlaznu vezu - Rostelecom (AS12389). U ovom slučaju (single homed) ne trebate BGP i najvjerojatnije ćete koristiti skup adresa iz Rostelecoma kao javne adrese.

Pretpostavimo da pružate određenu uslugu i imate dovoljan broj klijenata iz Ukrajine, a oni se žale na velika kašnjenja. Tijekom vašeg istraživanja otkrili ste da su IP adrese nekih od njih u mreži 37.52.0.0/21.

Pokretanjem traceroutea vidjeli ste da promet ide preko AS1299 (Telia), a pokretanjem pinga dobili ste prosječni RTT od 70 - 80 milisekundi. Ovo također možete vidjeti na ogledalo Rostelecom.

Pomoću uslužnog programa whois (na ripe.net ili lokalnog uslužnog programa) možete lako utvrditi da blok 37.52.0.0/21 pripada AS6849 (Ukrtelecom).

Dalje, odlaskom na bgp.he.net vidite da AS6849 nema veze s AS12389 (nisu ni klijenti ni uzlazne veze jedni s drugima, niti imaju peering). Ali ako pogledate popis vršnjaka za AS6849 vidjet ćete, na primjer, AS29226 (Mastertel) i AS31133 (Megafon).

Nakon što pronađete ogledalo ovih pružatelja usluga, možete usporediti put i RTT. Na primjer, za Mastertel RTT će biti oko 30 milisekundi.

Dakle, ako je razlika između 80 i 30 milisekundi značajna za vašu uslugu, onda možda trebate razmisliti o povezivosti, nabaviti svoj AS broj, skup adresa od RIPE-a i povezati dodatne uplinkove i/ili stvoriti točke prisutnosti na IX-ovima.

Kada koristite BGP, ne samo da imate priliku poboljšati povezanost, već i redundantno održavate svoju internetsku vezu.

Ovaj dokument sadrži preporuke za konfiguriranje BGP-a. Unatoč činjenici da su ove preporuke razvijene na temelju "najbolje prakse" pružatelja usluga, svejedno (ako vaše BGP postavke nisu sasvim osnovne) one su nedvojbeno korisne i zapravo bi trebale biti dio ojačanja o kojem smo raspravljali u prvi dio.

DOS/DDOS zaštita

Sada su DOS/DDOS napadi postali svakodnevna stvarnost za mnoge tvrtke. Zapravo, često ste napadnuti u ovom ili onom obliku. To što to još niste primijetili samo znači da protiv vas još nije organiziran ciljani napad te da su mjere zaštite koje koristite, čak možda i ne znajući (razne ugrađene zaštite operativnih sustava), dovoljne da osigurati da degradacija pružene usluge bude minimalizirana za vas i vaše klijente.

Postoje internetski resursi koji na temelju zapisa opreme crtaju prekrasne karte napada u stvarnom vremenu.

Ovdje možete pronaći poveznice na njih.

Moja omiljena karta iz CheckPointa.

Zaštita od DDOS/DOS obično je slojevita. Da biste razumjeli zašto, morate razumjeti koje vrste DOS/DDOS napada postoje (pogledajte, na primjer, здесь ili здесь)

Odnosno, imamo tri vrste napada:

• volumetrijski napadi
• protokolarni napadi
• napadi aplikacija

Ako se od posljednje dvije vrste napada možete zaštititi pomoću npr. vatrozida, onda se ne možete zaštititi od napada koji imaju za cilj “preplaviti” vaše uplinkove (naravno, ako vaš ukupni kapacitet internetskih kanala nije izračunat u terabitima, ili još bolje, u desecima terabita).

Stoga je prva linija obrane zaštita od "volumetrijskih" napada, a vaš pružatelj ili pružatelji usluga moraju vam pružiti ovu zaštitu. Ako to još niste shvatili, onda ste za sada samo sretnici.

Primjer

Recimo da imate nekoliko uplinkova, ali samo jedan od pružatelja vam može pružiti ovu zaštitu. Ali ako sav promet ide preko jednog pružatelja usluga, što je onda s vezom o kojoj smo ukratko raspravljali malo ranije?

U ovom slučaju, morat ćete djelomično žrtvovati povezanost tijekom napada. Ali

• ovo je samo za vrijeme trajanja napada. U slučaju napada, možete ručno ili automatski rekonfigurirati BGP tako da promet ide samo preko pružatelja koji vam daje "kišobran". Nakon završetka napada možete vratiti rutiranje u prethodno stanje
• Nije potrebno prenijeti sav promet. Ako, na primjer, vidite da nema napada preko nekih uplinkova ili peeringa (ili promet nije značajan), možete nastaviti oglašavati prefikse s konkurentskim atributima prema tim BGP susjedima.

Također možete delegirati zaštitu od "napada na protokole" i "napada na aplikacije" svojim partnerima.
ovdje je здесь možete pročitati dobru studiju (prijevod). Istina, članak je star dvije godine, ali će vam dati ideju o pristupima kako se možete zaštititi od DDOS napada.

U načelu, možete se ograničiti na ovo, potpuno prepustiti svoju zaštitu vanjskim suradnicima. Postoje prednosti ove odluke, ali postoji i očiti nedostatak. Činjenica je da možemo govoriti (opet, ovisno o tome čime se vaša tvrtka bavi) o opstanku poslovanja. I takve stvari povjeravajte trećim osobama...

Stoga, pogledajmo kako organizirati drugu i treću liniju obrane (kao dodatak zaštiti od davatelja).

Dakle, druga linija obrane su filtriranje i ograničavači prometa (policajci) na ulazu u vašu mrežu.

Primjer 1

Pretpostavimo da ste se uz pomoć nekog od provajdera pokrili kišobranom protiv DDOS-a. Pretpostavimo da ovaj pružatelj koristi Arbor za filtriranje prometa i filtriranje na rubu svoje mreže.

Propusnost koju Arbor može "obraditi" je ograničena, a pružatelj, naravno, ne može stalno propuštati promet svih svojih partnera koji naručuju ovu uslugu kroz opremu za filtriranje. Stoga se u normalnim uvjetima promet ne filtrira.

Pretpostavimo da postoji SYN flood napad. Čak i ako ste naručili uslugu koja automatski prebacuje promet na filtriranje u slučaju napada, to se ne događa odmah. Minutu ili više ostajete pod napadom. A to može dovesti do kvara vaše opreme ili degradacije usluge. U ovom slučaju, ograničavanje prometa na rubnom usmjeravanju, iako će dovesti do činjenice da se neke TCP sesije neće uspostaviti tijekom tog vremena, spasit će vašu infrastrukturu od problema većih razmjera.

Primjer 2

Nenormalno velik broj SYN paketa ne može biti samo rezultat SYN flood napada. Pretpostavimo da pružate uslugu u kojoj možete istovremeno imati oko 100 tisuća TCP veza (na jedan podatkovni centar).

Recimo da je kao rezultat kratkotrajnog problema s jednim od vaših glavnih pružatelja polovica vaših sesija izbačena. Ako je vaša aplikacija dizajnirana na način da, bez razmišljanja, odmah (ili nakon nekog vremenskog intervala koji je isti za sve sesije) pokuša ponovno uspostaviti vezu, tada ćete primiti najmanje 50 tisuća SYN paketa otprilike istovremeno.

Ako, na primjer, morate pokrenuti ssl/tls rukovanje povrh ovih sesija, što uključuje razmjenu certifikata, tada će sa stajališta iscrpljivanja resursa za vaš balanser opterećenja, ovo biti puno jači "DDOS" od jednostavnog SYN poplava. Čini se da bi balanseri trebali rješavati takve događaje, ali... nažalost, suočeni smo s takvim problemom.

I, naravno, policajac na rubnom ruteru će iu ovom slučaju spasiti vašu opremu.

Treća razina zaštite od DDOS/DOS-a su vaše postavke vatrozida.

Ovdje možete zaustaviti oba napada druge i treće vrste. Općenito, ovdje se može filtrirati sve što stigne do vatrozida.

vijeće

Pokušajte vatrozidu dati što manje posla, filtrirajući što je više moguće na prve dvije linije obrane. I zato.

Je li vam se ikada dogodilo da ste slučajno, dok ste generirali promet za provjeru, primjerice, koliko je operativni sustav vaših servera otporan na DDOS napade, “ubili” svoj vatrozid, opteretivši ga na 100 posto, s normalnim intenzitetom prometa ? Ako niste, možda je to jednostavno zato što niste probali?

Općenito, vatrozid je, kao što sam rekao, složena stvar i dobro radi s poznatim propustima i testiranim rješenjima, ali ako pošaljete nešto neobično, samo neko smeće ili pakete s netočnim zaglavljima, onda ste s nekima, a ne s tako mala vjerojatnost (na temelju mog iskustva), možete zaglupiti čak i vrhunsku opremu. Stoga, u fazi 2, korištenjem regularnih ACL-ova (na razini L3/L4), dopustite samo promet u svoju mrežu koji tamo treba ući.

Filtriranje prometa na vatrozidu

Nastavimo razgovor o vatrozidu. Morate razumjeti da su DOS/DDOS napadi samo jedna vrsta cyber napada.

Uz DOS/DDOS zaštitu, također možemo imati nešto poput sljedećeg popisa značajki:

• vatrozid aplikacije
• prevencija prijetnji (antivirus, anti-spyware i ranjivost)
• Filtriranje URL-a
• filtriranje podataka (filtriranje sadržaja)
• blokiranje datoteka (blokiranje vrsta datoteka)

Na vama je da odlučite što vam je potrebno s ovog popisa.

Da bi se nastavila

Izvor: www.habr.com