Ovaj članak je četvrti u seriji članaka „Kako kontrolirati mrežnu infrastrukturu“. Sadržaj svih članaka u seriji i poveznice možete pronaći ovdje.

U prvom delu u ovom poglavlju razmatrali smo neke aspekte mrežne sigurnosti segmenta „Data Center“. Ovaj dio će biti posvećen segmentu „Internet Access“.

Internet pristup

Tema sigurnosti je nesumnjivo jedna od najsloženijih tema u svijetu mreža prijenosa podataka. Kao i u prethodnim slučajevima, ne pretvarajući se da pružam dubinu i sveobuhvatnost, ovdje ću razmotriti dovoljno jednostavna, ali, po mom mišljenju, važna pitanja, čiji odgovori će, nadam se, pomoći u povećanju razine zaštite vaše mreže.

Pri auditu ovog segmenta obratite pažnju 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 priručnik od Cisco-a unutar SAFE modela.

Naravno, moguće je da će vas rješenja drugih dobavljača izgledati privlačnije (vidi Gartnerov kvadrant iz 2018;), ali ne pozivajući vas da slijedite u detalje ovaj dizajn, smatrao bih korisnim razumjeti principe i ideje koje leže u njegovoj osnovi.

Napomena
U SAFE segment „Remote Access“ dio je „Internet Access“. No u ovoj seriji članaka razmatrat ćemo ga odvojeno.

Standardni niz opreme u ovom segmentu za mrežu poduzeća (enterprise network) čine

granični usmjerivači (border routers)
vatrozidi

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

Napomena 2
Preskočit ću razmatranje raznih L2/L1 ili overlay L2 over L3 rješenja potrebnih za osiguranje L1/L2 povezanosti i ograničit ću se samo na pitanja razine L3 i više. Djelomično su pitanja L1/L2 razmatrana u poglavlju „Čišćenje i dokumentacija«.

Ako niste pronašli vatrozid u ovom segmentu, ne treba žuriti s zaključcima.

Hajde, kao i u u prethodnom dijelu, krenimo od pitanja, je li u vašem slučaju potrebno koristiti vatrozid u ovom segmentu?

Mogu reći da se čini da je ovo najsmislenije mjesto za korištenje vatrodija i primjenu složenih algoritama filtriranja prometa. U Dijelu 1 spomenuli smo 4 faktora koji mogu ometati korištenje vatrozida u segmentu data centra. No ovdje više nisu tako bitni.

Primjer 1. Kašnjenje
Kada je riječ o internetu, nema smisla govoriti o kašnjenju čak ni od 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 i dalje može biti značajan. Stoga, moguće je da ćete dio prometa (na primjer, promet balansirnih tereta) morati usmjeriti mimo vatrozida.

Primjer 3. Pouzdanost
Ovaj faktor i dalje treba uzeti u obzir, ali s obzirom na nepouzdano stanje samog interneta, njegova važnost za ovaj segment nije toliko značajna kao za podatkovni centar.
Pretpostavimo da vaša usluga radi na http/https (s kratkim sesijama). U tom slučaju možete koristiti dvije neovisne kutije (bez HA) i u slučaju problema s jednom od njih, preusmjeriti sav promet na drugu.
Ili možete koristiti vatrozide u transparentnom modu i u slučaju njihovog kvara, dok se problem ne riješi, usmjeriti promet mimo vatrozida.

Stoga, vjerojatno, samo cena može biti faktor koji će vas natjerati da odustanete od korištenja vatrozida u ovom segmentu.

Važno!
Pojavljuje se iskušenje da se ovaj vatrozid pomiješa s vatrozidom podatkovnog centra (koristiti jedan vatrozid za ove segmente). Rješenje je, u načelu, moguće, ali treba razumjeti da s obzirom na to da vatrozid "Internet Access" zapravo stoji na prednjoj liniji vaše obrane i "preuzima", barem dio zlonamjernog prometa, naravno, treba uzeti u obzir povećani rizik da će ovaj vatrozid prestati raditi. To jest, koristeći iste uređaje u ova dva segmenta, značajno ćete smanjiti dostupnost vašeg segmenta podatkovnog centra.

Kao i obično, treba razumjeti da, ovisno o usluzi koju poduzeće pruža, dizajn ovog segmenta može značajno varirati. Kao i obično, možete odabrati različite pristupe ovisno o zahtjevima.

Primjer
Ako ste davatelj sadržaja s CDN mrežom (vidi, na primjer, seriju članaka), možda nećete željeti stvoriti desetke, a možda i stotine točaka prisutnosti infrastrukture koristeći pojedinačne uređaje za rutiranje i filtriranje prometa. To će biti skupo, a može se pokazati i kao suvišno.
Za BGP vam uopće nije potrebno imati izdvojene usmjerivače, možete koristiti open-source alate, na primjer, Quagga. Stoga, možda vam je sve što trebate - poslužitelj ili nekoliko poslužitelja, prekidač 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, tu je još mnogo detalja (na primjer, kako osigurati ravnotežu), ali to je izvedivo, i ovaj pristup smo uspješno primijenili za jednog od naših partnera.
Možete imati nekoliko datacentara s punom zaštitom (vatrozidi, usluge zaštite od DDOS-a koje pružaju vaši internetski davatelji) i desetke ili stotine "pojednostavljenih" točaka prisutnosti samo s L2 prekidačima i poslužiteljima.
A što je s zaštitom u ovom slučaju?
Razmotrimo, na primjer, popularni u posljednje vrijeme DNS Amplification DDOS napad. Njegova opasnost leži u tome što se generira velika količina prometa, koji jednostavno "začepljuje" 100% svih vaših uplinkova.
Što imamo u slučaju našeg dizajna.

ako koristite AnyCast, tada se promet raspoređuje između vaših točaka prisutnosti. Ako je ukupni protok za vas terabiti, to samo po sebi zapravo (usprkos činjenici da je u posljednje vrijeme bilo nekoliko napada s malicioznim prometom u rasponu terabita) štiti vas od "preopterećenja" uplinkova.

ako se ipak neki uplinkovi "začepe", jednostavno izvlačite tu lokaciju iz upotrebe (prestajete najavljivati prefiks).

možete također povećati udio prometa koji dolazi s vaših "punopravnih" (i, sukladno tome, zaštićenih) datacentara, čime uklanjate značajan dio malicioznog prometa s nezaštićenih točaka prisutnosti.
I još jedna mala napomena na ovaj primjer. Ako dovoljno prometa šaljete preko IX-ova, to također smanjuje vašu podložnost sličnim napadima.

Postavljanje BGP-a

Ovdje su dvije teme.

Povezivost
Postavljanje BGP-a

O povezivosti smo već malo govorili u Dijelu 1. Suština je da promet prema vašim klijentima ide optimalnim putem. Iako, optimalnost — to nije uvijek samo o kašnjenju, ali obično je upravo nisko kašnjenje glavni pokazatelj optimalnosti. Za neke tvrtke to je važnije, za druge manje. Sve ovisi o usluzi koju pružate.

Primjer 1
Ako ste burza i vremenski intervali manji od milisekunde su bitni za vaše klijente, jasno je da internet ne može niti biti tema.

Primjer 2
Ako ste igračka kompanija i bitni su vam deseci milisekundi, onda je povezanost za vas izuzetno važna.

Primjer 3
Također treba razumjeti da, zbog svojstava TCP protokola, brzina prijenosa podataka unutar jedne TCP sesije također ovisi o RTT (Round Trip Time). CDN mreže se grade, među ostalim, i za rješavanje ovog problema, smještajući servere za distribuciju sadržaja bliže potrošaču tog sadržaja.

Istraživanje povezanosti je zasebna zanimljiva tema, dostojna posebnog članka ili niza članaka i zahtijeva dobro razumijevanje kako je 'internet' 'konstruiran'.

Koristeći resurse:

ripe.net
bgp.he.net

Primjer
Pružam samo jedan mali primjer.
Pretpostavimo da se vaš data centar nalazi u Moskvi i da imate jedini uplink – Rostelecom (AS12389). U ovom slučaju (single homed) BGP vam nije potreban i kao javne adrese vjerojatno koristite adresni raspon od Rostelecoma.
Pretpostavimo da pružate neku uslugu i imate dovoljno klijenata iz Ukrajine koji se žale na velike latencije. Kada ste istraživali, otkrili ste da IP adrese nekih od njih pripadaju mreži 37.52.0.0/21.
Izvršavajući traceroute, primijetili ste da promet prolazi kroz AS1299 (Telia), a izvršavajući ping, dobili ste prosječni RTT od 70 — 80 milisekundi. Ovo također možete vidjeti na looking glass Rostelecoma.
Alatom whois (na web stranici ripe.net ili lokalnom alatu) lako možete utvrditi da blok 37.52.0.0/21 pripada AS6849 (Ukrtelecom).
Nakon toga, odlaskom na bgp.he.net vidite da AS6849 nema odnose s AS12389 (nisu ni klijenti ni uplinkovi jedni drugima, niti imaju peering). No, ako pogledate popis peera za AS6849, vidjet ćete, na primjer, AS29226 (Mastertel) i AS31133 (Megafon).
Pronašavši looking glass tih pružatelja, možete usporediti putanju i RTT. Na primjer, za Mastertel RTT će biti otprilike 30 milisekundi.
Dakle, ako je razlika između 80 i 30 milisekundi značajna za vašu uslugu, možda biste trebali razmisliti o povezanosti, dobiti svoj AS broj u RIPE-u, svoj raspon adresa i povezati dodatne uplinkove i/ili stvoriti prisutnost na IX-ima.

Korištenjem BGP-a ne samo da možete poboljšati povezanost, već također rezervirate svoju internet vezu.

Ovaj dokument sadrži preporuke za konfiguraciju BGP-a. Iako su ove preporuke izrađene na osnovu 'najbolje prakse' pružatelja usluga, one su svakako korisne te bi trebale biti dio **hardening-a**, o kojem smo razgovarali u prvom delu.

DOS/DDOS zaštita

Danas su DOS/DDOS napadi postali svakodnevna stvar za mnoge tvrtke. U stvarnosti, na neki način, često vas napadaju. To što to trenutno ne primjećujete znači samo da do sada nije organiziran ciljani napad na vas, i da su sredstva zaštite koja koristite, možda nesvjesno (različite ugrađene zaštite operativnih sustava), dovoljna kako bi se degradacija pružane usluge minimalizirala za vas i vaše klijente.

Postoje internetski resursi koji, na temelju logova s opreme, u stvarnom vremenu prikazuju lijepe karte napada.

Ovdje linkove na njih možete pronaći.

Moj omiljeni karta od CheckPoint-a.

Zaštita od DDOS/DOS napada obično je višeslojna. Da biste razumjeli zašto, trebate razumjeti koje vrste DOS/DDOS napada postoje (vidi, na primjer, ovdje ili ovdje)

Dakle, imamo tri tipa napada:

volumetrički napadi
protokolni napadi
aplikacijski napadi

Ako se od posljednja dva tipa napada možete zaštititi sami, koristeći, na primjer, vatrozide, ne možete se sami zaštititi od napada usmjerenih na 'preopterećenje' vaših uplinkova (naravno, ako vaša ukupna propusnost internet kanala nije mjerena u terabitima, a još bolje, u desecima terabita).

Stoga, prva linija obrane su zaštite od 'volumetričkih' napada i tu zaštitu bi vam trebao osigurati vaš pružatelj ili pružatelji usluga. Ako to još niste shvatili, jednostavno imate sreće.

Primjer
Pretpostavimo da imate nekoliko uplinkova, ali samo jedan od pružatelja može vam pružiti ovu zaštitu. No, ako sav promet prolazi kroz jednog pružatelja, kako onda s povezanostima o kojima smo malo prije razgovarali?
Tijekom napada, u tom slučaju, morat ćete dijelom žrtvovati povezanost. No

ovo je samo tokom napada. Možete ručno ili automatski ponovno konfigurirati BGP, tako da promet ide samo kroz provajdera koji vam pruža "kišobran". Nakon završetka napada možete vratiti usmjeravanje na prethodno stanje.

nije nužno preusmjeravati sav promet. Ako na primjer vidite da kroz neke uplinke ili peering nije u tijeku napad (ili je promet nevažan), možete i dalje najavljivati prefikse s konkurentnim atributima prema tim BGP susjedima.

Zaštitu od „protocol attacks“ i „application attacks“ također možete prebaciti na partnere.
Evo ovdje možete pročitati dobro istraživanje (prijevod). Iako je članak star dvije godine, to će vam dati predstavu o pristupima kako se možete zaštititi od DDoS napada.

U principu, možete se time i ograničiti, potpuno outsourcajući vašu zaštitu. Ovo rješenje ima svoje prednosti, ali postoji i očigledan nedostatak. Riječ je o tome da bi se moglo raditi (opet, ovisno o tome čime se vaša tvrtka bavi) o preživljavanju poslovanja. I povjeriti takve stvari vanjskim organizacijama…

Zato hajde da razmotrimo kako organizirati drugu i treću liniju obrane (kao dodatak zaštiti od provajdera).

Dakle, druga linija zaštite je filtracija i ograničivači prometa (policers) na ulazu u vašu mrežu.

Primjer 1
Pretpostavimo da ste se "zaklonili kišobranom" od DDoS-a pomoću jednog od provajdera. Pretpostavimo da ovaj provajder koristi Arbor za filtraciju prometa i filtre na granici svoje mreže.
Propusnost koju Arbor može "obraditi" je ograničena, i provajder naravno ne može stalno propusiti promet svih svojih partnera koji su naručili ovu uslugu kroz filtrirajuću opremu. Stoga se u normalnim uvjetima promet ne filtrira.
Pretpostavimo da se odvija SYN flood napad. Iako ste naručili uslugu koja automatski preusmjerava promet na filtriranje u slučaju napada, to se ne događa odmah. Tijekom minute ili više ostajete pod napadom. To može dovesti do kvara vaše opreme ili degradacije usluge. U tom slučaju ograničenje prometa na graničnom usmjeravanju, iako će rezultirati time da neki TCP sesije tijekom tog vremena ne budu uspostavljene, spasit će vašu infrastrukturu od većih problema.

Primjer 2
Abnormalno velika količina SYN paketa može biti rezultat ne samo SYN flood napada. Pretpostavimo da pružate uslugu koja istovremeno može imati oko 100 tisuća TCP veza (u jednom data centru).
Pretpostavimo da je zbog kratkotrajnog problema s jednim od vaših glavnih pružatelja usluga pola sesija 'izbačeno'. Ako je vaša aplikacija konstruirana tako da, 'ne razmišljajući', odmah (ili nakon nekog istog vremenskog intervala za sve sesije) pokušava ponovno uspostaviti vezu, tada ćete otprilike u isto vrijeme primiti najmanje 50 tisuća SYN paketa.
Ako uz ove sesije, primjerice, treba raditi ssl/tls handshake, što uključuje razmjenu certifikata, s gledišta iscrpljivanja resursa za vaš ravnoteživač opterećenja to će biti mnogo jači 'DDoS' od običnog SYN flood-a. Naizgled, ravnoteživači bi trebali uspješno obraditi takve situacije, ali … nažalost, naišli smo na taj problem.
I, naravno, policer na graničnom usmjerivaču u ovom slučaju će spasiti vašu opremu.

Treći nivo zaštite od DDoS/DOS su postavke vašeg vatrozida.

Ovdje možete kontrolirati napade drugog i trećeg tipa. U suštini, sve što dođe do vatrozida može se filtrirati ovdje.

Savjet
Pokušajte dati vatrozidu što je moguće manje posla filtrirajući što više na prvim dvjema linijama obrane. I to je razlog.
Da li vam se ikada dogodilo da ste slučajno generirali promet kako biste provjerili, na primjer, koliko je operacijski sustav vaših poslužitelja otporan na DDOS napade, i pritom 'ubijali' svoj vatrozid opterećujući ga do 100 posto, koristeći promet u uobičajenoj intenzitetu? Ako ne, možda jednostavno zato što niste pokušali?
Uglavnom, vatrozid, kao što sam već rekao — složena je stvar, i dobro funkcionira s poznatim ranjivostima i provjerenim rješenjima, ali ako pošaljete nešto neobično, jednostavno neki otpad ili pakete s krivim zaglavljima, postoji značajna (s obzirom na moje iskustvo) vjerojatnost da možete zbuniti čak i najnaprednije opreme. Stoga, u fazi 2 pomoću uobičajenih ACL (na L3/L4 razini) propuštajte u svoju mrežu samo onaj promet koji bi trebao ući.