Ta članek je četrti v nizu člankov 'Kako prevzeti nadzor nad omrežno infrastrukturo'. Vsebine vseh člankov v seriji in povezave lahko najdete ovde.

V prvega dela v tem poglavju smo obravnavali nekatere vidike varnosti omrežja v segmentu 'Data Center'. Ta del bo posvečen segmentu 'Internet Access'.

Dostop do interneta

Tema varnosti je nedvomno ena najbolj zapletenih tem v svetu omrežij za prenos podatkov. Tako kot v prejšnjih primerih, ne da bi trdil, da zajemam vse in poglobljeno, bom tukaj obravnaval preprosta, a pomembna vprašanja, na katera upam, da bodo pomagala izboljšati raven zaščite vašega omrežja.

Pri auditu tega segmenta bodite pozorni na naslednje vidike:

dizajna
nastavitve BGP
zaščita DOS/DDOS
filtriranje prometa na požarnem zidu

Oblikovanje

Kot primer zasnove tega segmenta za omrežje podjetja bi priporočil vodnik od Cisco v okviru modela SAFE.

Seveda, morda se vam bodo rešitve drugih dobaviteljev zdele bolj privlačne (glej Gartnerjev kvadrant za 2018), toda ne da bi vas pozival, da strogo sledite tej zasnovi, menim, da je vseeno koristno razumeti načela in ideje, ki so v njenem jedru.

Napomena
V segmentu SAFE je 'Remote Access' del 'Internet Access'. Vendar pa se v tej seriji člankov osredotočamo na to tematsko področje ločeno.

Standardni niz opreme v tem segmentu za omrežje podjetja (enterprise network) vključuje

mejne usmerjevalnike (border routers)
požarne zidove

Opomba 1
V tej seriji člankov, ko govorim o požarnih zidovih, imam v mislih NGFW.

Opomba 2
Pustil bom obravnavo različnih vrst L2/L1 ali overlayer L2 over L3 rešitev, potrebnih za zagotavljanje L1/L2 povezanosti in omejim se na vprašanja L3 in višja. Deloma so bila vprašanja L1/L2 obravnavana v poglavju 'Čiščenje in dokumentiranje«.

Če v tem segmentu niste našli požarnega zida, ne hitite s sklepi.

Poglejmo, kot smo v prejšnji del, začnimo z vprašanjem, ali je v vašem primeru nujna uporaba požarnega zida v tem segmentu?

Lahko rečem, da se zdi, da je to najbolj upravičeno mesto za uporabo požarnih zidov in za vključitev zapletenih algoritmov za filtriranje prometa. V části 1 smo omenili 4 dejavnike, ki lahko ovirajo uporabo požarnih zidov v segmentu podatkovnih centrov. Toda tukaj niso tako bistveni.

Primer 1. Kašnjenje
Ko gre za internet, ni smisla govoriti o zakasnitvah niti v velikosti 1 milisekunde. Zato zakasnitev v tem segmentu ne more biti dejavnik, ki bi omejeval uporabo požarnega zid.

Primer 2. Performansa
V nekaterih primerih je ta dejavnik še vedno lahko pomemben. Zato boste morda morali del prometa (na primer, promet uravnoteževalnikov obremenitve) usmeriti mimo požarnega zida.

Primer 3. Zanesljivost
Ta dejavnik je še vedno treba upoštevati, vendar glede na nezanesljivost samega interneta njegova pomembnost za ta segment ni tako velika kot za podatkovni center.
Recimo, da vaš servis deluje preko http/https (s kratkimi sejami). V tem primeru lahko uporabite dve neodvisni škatli (brez HA), in ob težavi z eno od njih preusmerite ves promet na drugo.
Lahko pa uporabite požarne zidove v transparentnem načinu in ob njihovi napaki, medtem ko težavo rešujete, usmerite promet mimo požarnih zidov.

Zato so verjetno le cena tisti dejavnik, ki bi vas lahko odvrnil od uporabe požarnih zidov v tem segmentu.

Důležité!
Obstaja skušnjava, da bi ta požarni zid združili z požarnim zidom podatkovnega centra (uporabite en požarni zid za te segmente). To je načeloma mogoče, vendar je treba razumeti, da ker je požarni zid 'Dostop do Interneta' dejansko na sprednji liniji vaše obrambe in 'prevzema' vsaj del zlonamernega prometa, je nujno upoštevati povečano tveganje, da bo ta požarni zid izključen. To pomeni, da z uporabo istih naprav v teh dveh segmentih precej zmanjšate obstoječost vašega segmenta podatkovnega centra.

Kot običajno, je treba razumeti, da se lahko zasnova tega segmenta precej razlikuje glede na storitev, ki jo podjetje nudi. Kot običajno, lahko izberete različne pristope, odvisno od zahtev.

Primer
Če ste ponudnik vsebin s CDN omrežjem (glejte na primer, niz člankov), morda ne boste želeli ustvarjati infrastrukture z desetimi ali sto točkami prisotnosti z uporabo ločenih naprav za usmerjanje in filtriranje prometa. To bi bilo drago in preprosto morda celo odveč.
Za BGP vam ni treba imeti posebej dodeljene usmerjevalnike; lahko uporabite orodja z odprto kodo, na primer, Quagga. Zato je morda vse, kar potrebujete, strežnik ali več strežnikov, st switches in BGP.
V tem primeru vaš strežnik ali več strežnikov lahko igrata vlogo ne samo CDN strežnika, temveč tudi usmerjevalnika. Seveda je tu še veliko podrobnosti (na primer, kako zagotoviti uravnoteženje), vendar je to izvedljivo, in ta pristop smo uspešno uporabili za enega od naših partnerjev.
Imate lahko več podatkovnih centrov z ustrezno zaščito ( požarni zidovi, storitve zaščite pred DDOS, ki jih zagotavljajo vaši internetni ponudniki) in desetine ali stotine 'poenostavljenih' točk prisotnosti samo z L2 st switches in strežniki.
Kako pa je z zaščito v tem primeru?
Oglejmo si, na primer, v zadnjem času priljubljeno napad DNS amplifikacije DDOS.Njena nevarnost je v tem, da se ustvari veliko količino prometa, ki preprosto 'zapolni' 100 % vseh vaših povezav.
Kaj imamo v primeru našega oblikovanja.

Če uporabljate AnyCast, se promet porazdeli med vašimi točkami prisotnosti. Če imate skupno širino pasu v terabits, vas to dejansko (kljub temu, da je v zadnjem času prišlo do več napadov z zlonamernim prometom v višini terabita) ščiti pred 'preobremenitvijo' povezav.

Če pa so nekatere povezave še vedno 'zapečene', preprosto odstranite to lokacijo iz obratovanja (prenehajte z napovedovanjem prefiksa).

Lahko tudi povečate delež prometa, ki ga oddajate iz vaših 'polnih' (in s tem zaščitenih) podatkovnih centrov, s čimer odstranite pomemben del zlonamernega prometa z nezaščitenih točk prisotnosti.
In še ena majhna opomba k temu primeru. Če dovolj prometa oddajate preko IX-ov, to tudi zmanjša vašo dovzetnost za podobne napade.

Postavljanje BGP-a

Tukaj sta dve temi.

Povezljivost
Postavljanje BGP-a

O povezljivosti smo že rahlo govorili v části 1. Bistvo je, da promet k vašim strankam poteka po optimalni poti. Čeprav optimalnost ni vedno samo o zakasnitvi, pa je običajno nizka zakasnitev glavni pokazatelj optimalnosti. Za nekatere družbe je to pomembnejše, za druge manj. Vse je odvisno od storitve, ki jo ponujate.

Primer 1
Če ste borza in so za vaše stranke pomembni časovni intervali, krajši od milisekund, potem o internetu sploh ne more biti govora.

Primer 2
Če ste igričarska podjetje in so za vas pomembne desetine milisekund, je seveda povezljivost za vas zelo pomembna.

Primer 3
Prav tako je treba razumeti, da hitrost prenosa podatkov v okviru ene TCP seje tudi odvisna od RTT (Round Trip Time), zaradi lastnosti protokola TCP. CDN omrežja so zgrajena tudi za reševanje tega problema, saj postavljajo strežnike za razdeljevanje vsebin bliže končnemu uporabniku.

Raziskovanje povezljivosti je ločena zanimiva tema, ki si zasluži ločen članek ali serijo člankov in zahteva dobro razumevanje, kako je 'zgrajen' internet.

Koristni viri:

ripe.net
bgp.he.net

Primer
Navedel bom le en majhen primer.
Recimo, da se vaš podatkovni center nahaja v Moskvi in imate edini uplink – Rostelekom (AS12389). V tem primeru (single homed) BGP ne potrebujete, in kot javne naslove najverjetneje uporabljate naslovni razpon od Rostelekoma.
Recimo, da zagotavljate neko storitev in imate dovolj strank iz Ukrajine, ki se pritožujejo zaradi velikih zamud. Pri raziskovanju ste ugotovili, da IP naslovi nekaterih od njih ležijo v omrežju 37.52.0.0/21.
Po izvedbi traceroute ste videli, da promet potuje preko AS1299 (Telia), in po izvedbi pinga ste dobili povprečni RTT 70 – 80 milisekund. To lahko vidite tudi na looking glass Rostelekoma.
S pomočjo orodja whois (na spletnem mestu ripe.net ali lokalnim orodjem) lahko enostavno določite, da blok 37.52.0.0/21 pripada AS6849 (Ukrtelecom).
Nato, ko odprete bgp.he.net vidite, da AS6849 nima odnosov z AS12389 (niso si medsebojno stranke ali uplink, prav tako pa nimajo peeringa). Če pa si ogledate seznam peerov za AS6849, boste videli, na primer, AS29226 (Mastertel) in AS31133 (Megafon).
Ko najdete looking glass teh ponudnikov, lahko primerjate pot in RTT. Na primer, za Mastertel bo RTT že okoli 30 milisekund.
Tako, če je razlika med 80 in 30 milisekundami pomembna za vašo storitev, potem se morda res morate zamisliti o povezljivosti, pridobiti svoj AS številko v RIPE, svoj razpon naslovov in povezati dodatne uplinke in/ali ustvariti prisotnost na IX-ih.

S použitím BGP nejenže zlepšíte konektivitu, ale také si rezervujete své internetové připojení.

Tento dokument obsahuje doporučení pro konfiguraci BGP. I když byla tato doporučení vytvořena na základě „best practice“ poskytovatelů, stále (pokud vaše BGP nastavení nejsou zcela elementární) jsou nepochybně užitečná a měly by být součástí hardeningu, o kterém jsme diskutovali v prvega dela.

zaščita DOS/DDOS

V současné době se útoky DOS/DDOS staly každodenní realitou pro mnoho společností. Ve skutečnosti vás v nějaké podobě útočí poměrně často. To, že si toho zatím nevšimli, naznačuje, že proti vám nebyl uspořádán cílený útok a že ochranné prostředky, které používáte, i když to možná ani netušíte (různé vestavěné ochrany operačních systémů), jsou dostatečné k minimalizaci degradace poskytované služby pro vás a vaše zákazníky.

Existují internetové zdroje, které na základě logů z zařízení v reálném čase vykreslují krásné mapy útoků.

Tukaj můžete najít odkazy na ně.

Moje oblíbená mapa od CheckPoint.

Ochrana proti DDOS/DOS obvykle probíhá v několika vrstvách. Abychom pochopili proč, musíme rozumět tomu, jaké typy DOS/DDOS útoků existují (viz například ovde ili ovde)

To znamená, že máme tři typy útoků:

volumetric attacks
protocol attacks
application attacks

Pokud se můžete bránit před posledními dvěma typy útoků sami pomocí například firewallů, pak před útoky zaměřenými na „přetížení“ vašich uplinků se sami neubráníte (pokud vaše celková kapacita internetových kanálů není v terabitech, a ještě lépe, v desítkách terabit).

Proto první linie obrany je ochrana před „volumetric“ útoky a tuto ochranu by vám měl zajistit váš poskytovatel nebo poskytovatelé. Pokud jste to dosud nepochopili, prostě máte zatím štěstí.

Primer
Předpokládejme, že máte několik uplinků, ale pouze jeden z poskytovatelů vám může tuto ochranu poskytnout. Ale pokud veškerý provoz bude probíhat přes jednoho poskytovatele, jak tedy s konektivitou, kterou jsme krátce diskutovali dříve?
Během útoku budete muset v tomto případě do určité míry obětovat konektivitu. Ale

to je samo za vrijeme napada. Možete ručno ili automatski rekonfigurirati BGP tijekom napada, kako bi promet išao samo kroz davatelja koji vam pruža "kišobran". Nakon završetka napada možete vratiti usmjeravanje u prvotno stanje.

nije nužno preusmjeriti sav promet. Ako, na primjer, primijetite da kroz određene uplinke ili peering nije bilo napada (ili promet nije značajan), možete nastaviti oglašavati prefikse s konkurentnim atributima prema tim BGP susjedima.

Zaštitu od "protocol attacks" i "application attacks" također možete prepustiti partnerima.
Evo ovde možete pročitati dobru studiju (prevod). Iako je članak star dvije godine, dat će vam uvid u pristupe kako se možete zaštititi od DDOS napada.

U načelu, možete se time i ograničiti, potpuno prepuštajući svoju zaštitu outsourcingu. Ovo rješenje ima svoje prednosti, ali očito i nedostatke. Naime, ovisno o poslovanju vaše tvrtke, može biti riječ o preživljavanju. Povjeriti takve stvari vanjskim organizacijama...

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

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

Primer 1
Pretpostavimo da ste se "pokriti kišobranom" od DDOS-a uz pomoć jednog od davatelja. Pretpostavimo da taj davatelj koristi Arbor za filtraciju prometa i filtre na granici svoje mreže.
Propusnost koju Arbor može "obrađivati" je ograničena, i davatelj naravno ne može stalno propuštati promet svih svojih partnera koji su naručili ovu uslugu kroz opremu za filtriranje. Stoga pod normalnim uvjetima promet se ne filtrira.
Predpostavimo, da poteka SYN flood napad. Tudi če ste naročili storitev, pri kateri se promet samodejno preusmeri na filtriranje v primeru napada, to ne zgodi takoj. Vsaj minuto ali več ostanete pod napadom. To lahko privede do izpada vaše opreme ali degradacije storitev. V tem primeru omejitev prometa na robnih usmerjevalnikih, čeprav bo povzročila, da nekaj TCP sej v tem času ne bo vzpostavljenih, vendar bo zaščitila vašo infrastrukturo pred obsežnejšimi težavami.

Primer 2
Abnormalno veliko število SYN paketov ni nujno samo posledica SYN flood napada. Predpostavimo, da nudite storitev, pri kateri imate hkrati lahko okoli 100.000 TCP povezav (v enem podatkovnem centru).
Predpostavimo, da je zaradi kratkoročne težave pri enem od vaših glavnih ponudnikov polovica sej 'izpadla'. Če vaša aplikacija deluje tako, da takoj (ali po nekem enotnem intervalu za vse seje) poskuša ponovno vzpostaviti povezavo, boste približno hkrati prejeli najmanj 50.000 SYN paketov.
Če pa je nad temi seji na primer v teku ssl/tls handshake, kar predvideva izmenjavo certifikatov, bo z vidika izčrpavanja virov za vaš uravnoteževalnik obremenitve to močneje 'DDOS' kot preprost SYN flood. Zdi se, da bi morali uravnoteževalniki obremenitve obvladovati takšne dogodke, vendar ... žal smo se soočili s to težavo v polni meri.
In seveda, policer na robnem usmerjevalniku bo zaščitil vašo opremo tudi v tem primeru.

Tretja raven zaščite pred DDOS/DOS so nastavitve vaše požarne pregrade.

Tukaj lahko obvladate tako napade drugega kot tretjega tipa. Na splošno lahko vse, kar pride do požarne pregrade, filtrirate tukaj.

Nasvet
Poskusite požarni pregradi nuditi čim manj dela, saj čim več filtrirate na dveh prvih obrambnih linijah. In to je razlog.
Ali vam se je kdaj zgodilo, da ste slučajno, ko ste generirali promet, da bi preverili, kako dobro je operacijski sistem vaših strežnikov odporen na napade DDOS, "ubili" svoj požarni zid, ko ste ga obremenili do 100 odstotkov s prometom običajne intenzivnosti? Če ne, morda preprosto zato, ker tega še niste poskusili?
Na splošno je požarni zid, kot sem že omenil — zapletena zadeva, ki dobro deluje z znanimi ranljivostmi in preizkušenimi rešitvami, vendar če pošljete kaj nenavadnega, preprosto kakšne odpadke ali pakete z napačnimi glavi, potem imate z določenim, ne tako majhnim (glede na moje izkušnje) verjetnostjo možnost, da zmotite tudi vrhunsko opremo. Zato na stopnji 2 z običajnimi ACL (na ravni L3/L4) v vašo omrežje spustite le tisti promet, ki naj tja vstopa.