Kako preuzeti kontrolu nad vašom mrežnom infrastrukturom. Treće poglavlje. Mrežna sigurnost. Drugi dio

Ovaj članak je četvrti u nizu “Kako preuzeti kontrolu nad svojom mrežnom infrastrukturom”. Sadržaj svih članaka u seriji i linkove možete pronaći ovdje.

В prvi deo U ovom poglavlju pogledali smo neke aspekte mrežne sigurnosti u segmentu Data Center. Ovaj dio će biti posvećen segmentu „Pristup Internetu“.

Kako preuzeti kontrolu nad vašom mrežnom infrastrukturom. Treće poglavlje. Mrežna sigurnost. Drugi dio

pristup Internetu

Tema sigurnosti je nesumnjivo jedna od najsloženijih tema u svijetu podatkovnih mreža. Kao iu prethodnim slučajevima, bez traženja dubine i potpunosti, ovdje ću razmotriti prilično jednostavna, ali, po mom mišljenju, važna pitanja, čiji će odgovori, nadam se, pomoći da se podigne nivo sigurnosti vaše mreže.

Prilikom revizije ovog segmenta obratite pažnju na sljedeće aspekte:

  • dizajn
  • BGP postavke
  • DOS/DDOS zaštita
  • filtriranje saobraćaja na firewall-u

Dizajn

Kao primjer dizajna ovog segmenta za poslovnu mrežu, preporučio bih vodič iz Cisco-a iznutra SIGURNI modeli.

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

Napomena:

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

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

  • granični ruteri
  • zaštitni zidovi

Napomena 1

U ovoj seriji članaka, kada govorim o zaštitnim zidovima, mislim NGFW.

Napomena 2

Izostavljam razmatranje različitih vrsta L2/L1 ili preklapanja L2 preko L3 rješenja neophodnih za osiguranje L1/L2 povezivanja i ograničavam se samo na probleme na nivou L3 i više. Djelomično, pitanja L1/L2 su razmatrana u poglavlju “Čišćenje i dokumentacija".

Ako niste pronašli zaštitni zid u ovom segmentu, onda ne biste trebali žuriti sa zaključcima.

Uradimo isto kao u prethodni dioPočnimo s pitanjem: da li je u vašem slučaju potrebno koristiti firewall u ovom segmentu?

Mogu reći da je ovo najopravdanije mjesto za korištenje zaštitnih zidova i primjenu složenih algoritama za filtriranje prometa. IN 1 dijelovi Spomenuli smo 4 faktora koji mogu ometati upotrebu zaštitnih zidova u segmentu data centra. Ali ovdje oni više nisu toliko značajni.

Primer 1. Kašnjenje

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

Primer 2. Produktivnost

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

Primer 3. Pouzdanost

Ovaj faktor još treba uzeti u obzir, ali ipak, s obzirom na nepouzdanost samog interneta, njegov značaj za ovaj segment nije toliko značajan kao za data centar.

Dakle, pretpostavimo da vaš servis živi na vrhu http/https (sa kratkim sesijama). U ovom slučaju možete koristiti dva nezavisna kutija (bez HA) i ako postoji problem s rutiranjem s jednim od njih, sav promet prebacite u drugi.

Ili možete koristiti zaštitne zidove u transparentnom načinu rada i, ako ne uspiju, dozvoliti prometu da zaobiđe zaštitni zid dok rješavate problem.

Stoga, najvjerovatnije samo cijena može biti faktor koji će vas primorati da napustite upotrebu firewall-a u ovom segmentu.

Važno!

Postoji iskušenje da se ovaj zaštitni zid kombinuje sa zaštitnim zidom centra podataka (koristite jedan zaštitni zid za ove segmente). Rješenje je u principu moguće, ali to morate razumjeti jer Firewall za pristup Internetu je zapravo na čelu vaše odbrane i "preuzima" barem dio zlonamjernog prometa, tada, naravno, morate uzeti u obzir povećani rizik da će ovaj zaštitni zid 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, morate shvatiti da u zavisnosti od usluge koju kompanija pruža, dizajn ovog segmenta može uvelike varirati. Kao i uvijek, možete odabrati različite pristupe ovisno o vašim zahtjevima.

Primjer:

Ako ste dobavljač sadržaja, sa CDN mrežom (pogledajte npr. serija članaka), tada možda ne želite da kreirate infrastrukturu na desetinama ili čak stotinama tačaka prisutnosti koristeći zasebne uređaje za rutiranje i filtriranje saobraćaja. Biće skupo, a možda i jednostavno nepotrebno.

Za BGP ne morate nužno imati namjenske rutere, možete koristiti alate otvorenog koda kao što je Quagga. Dakle, možda je sve što vam treba je server ili nekoliko servera, prekidač i BGP.

U ovom slučaju, vaš server ili nekoliko servera mogu igrati ulogu ne samo CDN servera, već i rutera. Naravno, ima još puno detalja (kao što je kako osigurati balansiranje), ali to je izvodljivo, i to je pristup koji smo uspješno koristili za jednog od naših partnera.

Možete imati nekoliko centara podataka sa potpunom zaštitom (firewall, usluge DDOS zaštite koje pružaju vaši internet provajderi) i desetine ili stotine „pojednostavljenih“ tačaka prisutnosti sa samo L2 prekidačima i serverima.

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

Pogledajmo, na primjer, nedavno popularne DNS Amplifikacija DDOS napad. Njegova opasnost leži u činjenici da se generiše velika količina saobraćaja, koja jednostavno „začepi“ 100% svih vaših uplink-ova.

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

  • ako koristite AnyCast, tada se promet distribuira između vaših tačaka prisutnosti. Ako je vaša ukupna propusnost terabita, onda vas to samo po sebi (međutim, nedavno je bilo nekoliko napada sa zlonamjernim prometom reda terabita) štiti od "prelijevanja" uplinkova
  • Međutim, ako se neki uplinkovi začepe, jednostavno uklonite ovu stranicu iz usluge (prestanite oglašavati prefiks)
  • također možete povećati udio prometa koji se šalje iz vaših "punih" (i, shodno tome, zaštićenih) podatkovnih centara, uklanjajući tako značajan dio zlonamjernog prometa sa nezaštićenih točaka prisutnosti

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

Konfigurisanje BGP-a

Ovdje postoje dvije teme.

  • Povezivanje
  • Konfigurisanje BGP-a

Već smo malo pričali o povezivanju u 1 dijelovi. Poenta je osigurati da promet do vaših kupaca prati optimalnu putanju. Iako se optimalnost ne odnosi uvijek samo na kašnjenje, niska latencija je obično glavni pokazatelj optimalnosti. Za neke kompanije je ovo važnije, za druge manje. Sve zavisi od usluge koju pružate.

primjer 1

Ako ste berza, a vašim klijentima su važni vremenski intervali manji od milisekundi, onda, naravno, ne može biti govora ni o kakvom internetu.

primjer 2

Ako ste kompanija za igre i desetine milisekundi su vam važne, onda vam je, naravno, vrlo važna povezanost.

primjer 3

Takođe morate da shvatite da, zbog svojstava TCP protokola, brzina prenosa podataka unutar jedne TCP sesije takođe zavisi od RTT (Round Trip Time). CDN mreže se također grade kako bi riješile ovaj problem tako što će servere za distribuciju sadržaja približiti potrošaču ovog sadržaja.

Proučavanje povezanosti je zanimljiva tema sama po sebi, vrijedna svog članka ili serije članaka, i zahtijeva dobro razumijevanje kako Internet „funkcioniše“.

Korisni resursi:

ripe.net
bgp.he.net

Primjer:

Dat ću samo jedan mali primjer.

Pretpostavimo da se vaš data centar nalazi u Moskvi i da imate jedan uplink - Rostelecom (AS12389). U ovom slučaju (single homed) ne treba vam BGP, a najvjerovatnije koristite skup adresa od Rostelecoma kao javne adrese.

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

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

Koristeći whois uslužni program (na ripe.net ili lokalni uslužni program), možete lako utvrditi da blok 37.52.0.0/21 pripada AS6849 (Ukrtelecom).

Dalje, odlaskom na bgp.he.net vidite da AS6849 nema nikakvu vezu sa AS12389 (oni nisu ni klijenti ni uplinkovi jedni prema drugima, niti imaju peering). Ali ako pogledate spisak vršnjaka za AS6849, vidjet ćete, na primjer, AS29226 (Mastertel) i AS31133 (Megafon).

Kada pronađete ogledalo ovih provajdera, možete uporediti putanju 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 povezivanju, dobiti svoj AS broj, vaš skup adresa od RIPE-a i povezati dodatne uplinkove i/ili stvoriti tačke prisutnosti na IX-ovima.

Kada koristite BGP, ne samo da imate priliku da poboljšate povezanost, već i suvišno održavate svoju internet vezu.

Ovaj dokument sadrži preporuke za konfigurisanje BGP-a. Unatoč činjenici da su ove preporuke razvijene na temelju “najbolje prakse” provajdera, ipak (ako vaše BGP postavke nisu baš osnovne) one su nesumnjivo korisne i zapravo bi trebale biti dio učvršćivanja o kojem smo raspravljali u prvi deo.

DOS/DDOS zaštita

Sada su DOS/DDOS napadi postali svakodnevna stvarnost mnogih kompanija. U stvari, često ste napadnuti u ovom ili onom obliku. Činjenica da to još niste primijetili samo znači da ciljani napad još uvijek nije organiziran na vas, te da su mjere zaštite koje koristite, čak i nesvjesno (razne ugrađene zaštite operativnih sistema), dovoljne da osigurajte da je degradacija pružene usluge svedena na minimum za vas i vaše klijente.

Postoje Internet resursi koji, na osnovu evidencije opreme, crtaju prekrasne karte napada u realnom vremenu.

to je možete pronaći linkove do njih.

My lovely kartica od CheckPointa.

Zaštita od DDOS/DOS-a je obično slojevita. Da biste razumjeli zašto, morate razumjeti koje vrste DOS/DDOS napada postoje (pogledajte npr. ovdje ili ovdje)

Odnosno, imamo tri vrste napada:

  • volumetrijske napade
  • protokolarni napadi
  • napadi aplikacija

Ako se možete zaštititi od posljednje dvije vrste napada korištenjem, na primjer, firewall-a, onda se ne možete zaštititi od napada koji imaju za cilj “prevladati” vaše uplinkove (naravno, ako se vaš ukupan kapacitet internet kanala ne izračunava u terabitima, ili još bolje, u desetinama terabita).

Dakle, prva linija odbrane je zaštita od “volumetrijskih” napada, a vaš provajder ili provajderi moraju vam pružiti ovu zaštitu. Ako ovo još niste shvatili, onda ste za sada samo sretnici.

Primjer:

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

U ovom slučaju ćete morati djelimično žrtvovati povezanost tokom 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 provajdera koji vam daje „kišobran“. Nakon što napad završi, možete vratiti rutiranje u prethodno stanje
  • Nije potrebno prenijeti sav promet. Ako, na primjer, vidite da nema napada preko nekih uplink-ova ili peeringa (ili promet nije značajan), možete nastaviti oglašavati prefikse sa konkurentnim atributima prema ovim BGP susjedima.

Također možete delegirati zaštitu od “napada protokola” i “napada na aplikacije” na svoje partnere.
ovdje ovdje možete pročitati dobru studiju (prevod). Istina, članak je star dvije godine, ali će vam dati ideju o pristupima kako se možete zaštititi od DDOS napada.

U principu, možete se ograničiti na ovo, potpuno prepustivši svoju zaštitu vanjskim suradnicima. Ova odluka ima prednosti, ali postoji i očigledan nedostatak. Činjenica je da možemo razgovarati (opet, ovisno o tome čime se vaša kompanija bavi) o opstanku poslovanja. I povjerite takve stvari trećim licima...

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

Dakle, druga linija odbrane je filtriranje i ograničavači saobraćaja (policiri) na ulazu u vašu mrežu.

primjer 1

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

Propusnost koju Arbor može „obraditi“ je ograničena, a provajder, naravno, ne može stalno propuštati saobraćaj svih svojih partnera koji naruče ovu uslugu kroz opremu za filtriranje. Zbog toga se u normalnim uslovima saobraćaj 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. Minut 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 saobraćaja na rubnom rutiranju, iako će dovesti do činjenice da neke TCP sesije neće biti uspostavljene za to vrijeme, spasit će vašu infrastrukturu od problema većih razmjera.

primjer 2

Nenormalno veliki 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 hiljada TCP konekcija (na jedan data centar).

Recimo da je kao rezultat kratkotrajnog problema s jednim od vaših glavnih provajdera polovina vaših sesija prekinuta. Ako je vaša aplikacija dizajnirana tako da, bez razmišljanja, odmah (ili nakon nekog vremenskog intervala koji je isti za sve sesije) pokuša ponovo uspostaviti vezu, tada ćete dobiti najmanje 50 hiljada SYN paketa otprilike istovremeno.

Ako, na primjer, morate pokrenuti ssl/tls rukovanje na vrhu ovih sesija, što uključuje razmjenu certifikata, onda će sa stanovišta iscrpljivanja resursa za balansiranje opterećenja ovo biti mnogo jači „DDOS“ od jednostavnog SYN flood. Čini se da bi balanseri trebali da se bave ovakvim događajima, ali... nažalost, mi smo suočeni sa takvim problemom.

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

Treći nivo zaštite od DDOS/DOS-a su postavke vašeg zaštitnog zida.

Ovdje možete zaustaviti oba napada drugog i trećeg tipa. Općenito, ovdje se može filtrirati sve što stigne do firewall-a.

Savjet

Pokušajte da zaštitnom zidu date što manje posla, filtrirajući što je više moguće na prve dvije linije odbrane. I zato.

Da li vam se ikad dogodilo da ste slučajno, dok ste generirali promet da biste provjerili, na primjer, koliko je operativni sistem vaših servera otporan na DDOS napade, "ubili" svoj firewall, učitavši ga do 100 posto, sa prometom normalnog intenziteta ? Ako ne, možda je to jednostavno zato što niste probali?

Općenito, firewall je, kao što rekoh, složena stvar, i dobro radi sa poznatim ranjivostima i testiranim rješenjima, ali ako pošaljete nešto neobično, samo neko smeće ili pakete sa pogrešnim zaglavljem, onda ste s nekim, a ne sa tako mala vjerovatnoća (na osnovu mog iskustva), možete zapanjiti čak i vrhunsku opremu. Stoga, u fazi 2, koristeći obične ACL-ove (na nivou L3/L4), dozvolite samo promet u vašu mrežu koji bi trebao ući tamo.

Filtriranje saobraćaja na firewall-u

Nastavimo razgovor o firewall-u. Morate shvatiti da su DOS/DDOS napadi samo jedna vrsta sajber napada.

Pored DOS/DDOS zaštite, možemo imati i nešto poput sljedeće liste funkcija:

  • zaštitni zid aplikacija
  • prevencija prijetnji (antivirus, anti-špijunski softver i ranjivost)
  • Filtriranje URL-a
  • filtriranje podataka (filtriranje sadržaja)
  • blokiranje fajlova (blokiranje tipova datoteka)

Na vama je da odlučite šta vam je potrebno sa ove liste.

Nastaviti

izvor: www.habr.com

Dodajte komentar