Ta članek je četrti v seriji »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

В 1. del V tem poglavju smo si ogledali nekatere vidike varnosti omrežja v segmentu podatkovnih centrov. Ta del bo namenjen segmentu »Dostop do interneta«.

Dostop do interneta

Tematika varnosti je nedvomno ena najbolj kompleksnih tem v svetu podatkovnih omrežij. Kot v prejšnjih primerih, ne da bi zahteval globino in popolnost, bom tukaj obravnaval precej preprosta, a po mojem mnenju pomembna vprašanja, odgovori na katere upam, da bodo pomagali dvigniti raven varnosti vašega omrežja.

Pri reviziji tega segmenta bodite pozorni na naslednje vidike:

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

Oblikovanje

Kot primer zasnove tega segmenta za podjetniško omrežje bi priporočal vodstvo od Cisca znotraj VARNI modeli.

Seveda se vam bo morda rešitev drugih prodajalcev zdela privlačnejša (glej. Gartnerjev kvadrant 2018), vendar ne da bi vas spodbujal, da podrobno sledite tej zasnovi, se mi zdi koristno razumeti načela in ideje, ki stojijo za njo.

Opomba

V SAFE je segment »Oddaljeni dostop« del segmenta »Dostop do interneta«. Toda v tej seriji člankov ga bomo obravnavali ločeno.

Standardni nabor opreme v tem segmentu za podjetniško omrežje je

• mejni usmerjevalniki
• požarni zidovi

Opomba 1

Ko v tej seriji člankov govorim o požarnih zidovih, mislim NGFW.

Opomba 2

Izpuščam upoštevanje različnih vrst rešitev L2/L1 ali prekrivanja L2 nad L3, potrebnih za zagotavljanje povezljivosti L1/L2, in se omejujem samo na težave na ravni L3 in višje. Delno so bila vprašanja L1/L2 obravnavana v poglavju »Čiščenje in dokumentacija".

Če v tem segmentu niste našli požarnega zidu, potem ne smete hiteti s sklepi.

Naredimo enako kot v prejšnji delZačnimo z vprašanjem: ali je v vašem primeru v tem segmentu nujna uporaba požarnega zidu?

Lahko rečem, da se zdi to najbolj upravičeno mesto za uporabo požarnih zidov in uporabo kompleksnih algoritmov za filtriranje prometa. IN Deli 1 Omenili smo 4 dejavnike, ki lahko motijo ​​uporabo požarnih zidov v segmentu podatkovnih centrov. Toda tukaj niso več tako pomembni.

Primer 1. Zamuda

Kar se tiče interneta, nima smisla govoriti o zamudah niti približno 1 milisekunde. Zato zamuda v tem segmentu ne more biti dejavnik, ki bi omejeval uporabo požarnega zidu.

Primer 2. Produktivnost

V nekaterih primerih je lahko ta dejavnik še vedno pomemben. Zato boste morda morali dovoliti nekaj prometa (na primer promet iz izravnalnikov obremenitve), da obide požarni zid.

Primer 3. Zanesljivost

Ta dejavnik je še vedno treba upoštevati, vendar glede na nezanesljivost samega interneta njegov pomen za ta segment ni tako pomemben kot za podatkovni center.

Predpostavimo torej, da vaša storitev deluje na http/https (s kratkimi sejami). V tem primeru lahko uporabite dva neodvisna predala (brez HA) in če pride do težave z usmerjanjem pri enem od njiju, ves promet prenesete v drugega.

Lahko pa uporabite požarne zidove v preglednem načinu in, če odpovejo, dovolite prometu, da obide požarni zid, medtem ko rešujete težavo.

Zato najverjetneje samo Cena je lahko dejavnik, ki vas bo prisilil, da opustite uporabo požarnih zidov v tem segmentu.

Pomembno!

Obstaja skušnjava, da bi ta požarni zid združili s požarnim zidom podatkovnega centra (za te segmente uporabite en požarni zid). Rešitev je načeloma mogoča, vendar morate to razumeti, ker Požarni zid za dostop do interneta je dejansko v ospredju vaše obrambe in »prevzame« vsaj del zlonamernega prometa, potem pa morate seveda upoštevati povečano tveganje, da bo ta požarni zid onemogočen. To pomeni, da boste z uporabo istih naprav v teh dveh segmentih znatno zmanjšali razpoložljivost segmenta vašega podatkovnega centra.

Kot vedno morate razumeti, da se lahko zasnova tega segmenta zelo razlikuje glede na storitev, ki jo podjetje ponuja. Kot vedno lahko izberete različne pristope glede na vaše zahteve.

Primer

Če ste ponudnik vsebine z omrežjem CDN (glejte npr. serija člankov), potem morda ne boste želeli ustvariti infrastrukture na desetine ali celo stotine točk prisotnosti z uporabo ločenih naprav za usmerjanje in filtriranje prometa. To bo drago in morda preprosto nepotrebno.

Za BGP vam ni nujno, da imate namenske usmerjevalnike, uporabite lahko odprtokodna orodja, kot je Quagga. Torej je morda vse, kar potrebujete, strežnik ali več strežnikov, stikalo in BGP.

V tem primeru lahko vaš strežnik ali več strežnikov igra vlogo ne le strežnika CDN, ampak tudi usmerjevalnika. Seveda je še veliko podrobnosti (na primer, kako zagotoviti uravnoteženje), vendar je izvedljivo in je to pristop, ki smo ga uspešno uporabili za enega od naših partnerjev.

Lahko imate več podatkovnih centrov s popolno zaščito (požarni zidovi, storitve zaščite DDOS, ki jih zagotavljajo vaši internetni ponudniki) in na desetine ali stotine "poenostavljenih" točk prisotnosti samo s stikali in strežniki L2.

Kako pa je z zaščito v tem primeru?

Poglejmo na primer nedavno priljubljeno DNS Amplification DDOS napad. Njegova nevarnost je v tem, da se ustvari velika količina prometa, ki preprosto "zamaši" 100% vseh vaših povezav navzgor.

Kaj imamo v primeru našega dizajna.

• če uporabljate AnyCast, potem se promet porazdeli med vaše točke prisotnosti. Če je vaša skupna pasovna širina terabitov, vas to samo po sebi dejansko (vendar je bilo v zadnjem času več napadov z zlonamernim prometom v terabitnem redu) ščiti pred "prepolnimi" navzgornjimi povezavami
• Če pa se nekatere navzgornje povezave zamašijo, preprosto odstranite to spletno mesto iz storitve (prenehajte oglaševati predpono)
• povečate lahko tudi delež prometa, poslanega iz vaših "polnih" (in temu primerno zaščitenih) podatkovnih centrov, s čimer odstranite znaten del zlonamernega prometa iz nezaščitenih točk prisotnosti

In še ena majhna opomba k temu primeru. Če pošljete dovolj prometa prek IX-jev, potem to tudi zmanjša vašo ranljivost za takšne napade

Nastavitev BGP

Tukaj sta dve temi.

• Povezljivost
• Nastavitev BGP

Malo smo že govorili o povezljivosti v Deli 1. Bistvo je zagotoviti, da promet do vaših strank sledi optimalni poti. Čeprav pri optimalnosti ne gre vedno le za zakasnitev, je nizka zakasnitev običajno glavni pokazatelj optimalnosti. Nekaterim podjetjem je to bolj pomembno, drugim manj. Vse je odvisno od storitve, ki jo nudite.

Primer 1

Če ste borza in so vašim strankam pomembni časovni intervali, krajši od milisekund, potem o kakršnem koli internetu seveda sploh ne more biti govora.

Primer 2

Če ste igralniško podjetje in so vam pomembne desetine milisekund, potem vam je povezljivost seveda zelo pomembna.

Primer 3

Prav tako morate razumeti, da je zaradi lastnosti protokola TCP hitrost prenosa podatkov znotraj ene TCP seje odvisna tudi od RTT (Round Trip Time). Omrežja CDN se gradijo tudi za rešitev te težave s premikanjem strežnikov za distribucijo vsebine bližje uporabniku te vsebine.

Preučevanje povezljivosti je zanimiva tema sama po sebi, vredna svojega članka ali serije člankov in zahteva dobro razumevanje, kako internet »deluje«.

Uporabni viri:

ripe.net
bgp.he.net

Primer

Dal bom samo en majhen primer.

Predpostavimo, da je vaš podatkovni center v Moskvi in ​​imate eno navzgornjo povezavo - Rostelecom (AS12389). V tem primeru (single homed) ne potrebujete BGP in najverjetneje kot javne naslove uporabljate skupino naslovov Rostelecoma.

Recimo, da nudite določeno storitev in imate zadostno število strank iz Ukrajine, ki se pritožujejo zaradi velikih zamud. Med raziskovanjem ste ugotovili, da so naslovi IP nekaterih od njih v mreži 37.52.0.0/21.

Če ste zagnali traceroute, ste videli, da promet poteka prek AS1299 (Telia), in z zagonom ping ste dobili povprečni RTT 70 - 80 milisekund. To si lahko ogledate tudi na ogledalo Rostelecom.

S pomočjo pripomočka whois (na ripe.net ali lokalnem pripomočku) lahko enostavno ugotovite, da blok 37.52.0.0/21 pripada AS6849 (Ukrtelecom).

Naprej, tako da greste na bgp.he.net vidite, da AS6849 ni v nobenem razmerju z AS12389 (nista ne odjemalca ne navzgornja povezava drug do drugega, niti nimata enakovrednega povezovanja). Toda če pogledate seznam vrstnikov za AS6849 boste videli na primer AS29226 (Mastertel) in AS31133 (Megafon).

Ko najdete ogledalo teh ponudnikov, lahko primerjate pot in RTT. Na primer, za Mastertel bo RTT približno 30 milisekund.

Torej, če je razlika med 80 in 30 milisekundami pomembna za vašo storitev, potem morate morda razmisliti o povezljivosti, pridobiti svojo številko AS, svojo skupino naslovov od RIPE in povezati dodatne povezave navzgor in/ali ustvariti točke prisotnosti na IX-jih.

Ko uporabljate BGP, nimate le priložnosti za izboljšanje povezljivosti, ampak tudi redundantno vzdržujete internetno povezavo.

Ta dokument vsebuje priporočila za konfiguracijo BGP. Kljub dejstvu, da so bila ta priporočila razvita na podlagi »najboljše prakse« ponudnikov, so kljub temu (če vaše nastavitve BGP niso povsem osnovne) nedvomno uporabna in bi morala biti del utrjevanja, o katerem smo razpravljali v 1. del.

DOS/DDOS zaščita

Zdaj so DOS/DDOS napadi postali vsakdanja realnost mnogih podjetij. Pravzaprav ste pogosto napadeni v takšni ali drugačni obliki. Dejstvo, da tega še niste opazili, pomeni le, da proti vam še ni bil organiziran ciljni napad in da zaščitni ukrepi, ki jih uporabljate, morda tudi ne da bi vedeli (različne vgrajene zaščite operacijskih sistemov), zadostujejo za zagotoviti, da je poslabšanje ponujene storitve za vas in vaše stranke čim manjše.

Obstajajo internetni viri, ki na podlagi dnevnikov opreme v realnem času rišejo čudovite karte napadov.

Tukaj lahko najdete povezave do njih.

Moja najljubša Zemljevid iz CheckPointa.

Zaščita pred DDOS/DOS je običajno večplastna. Če želite razumeti, zakaj, morate razumeti, katere vrste napadov DOS/DDOS obstajajo (glejte, na primer, tukaj ali tukaj)

To pomeni, da imamo tri vrste napadov:

• volumetrični napadi
• protokolarni napadi
• napadi aplikacij

Če se pred zadnjima dvema vrstama napadov lahko zaščitite na primer s požarnimi zidovi, se ne morete zaščititi pred napadi, katerih cilj je "preobremenitev" vaših povezav navzgor (seveda, če vaša skupna zmogljivost internetnih kanalov ni izračunana v terabitih, ali še bolje, v desetih terabitih).

Zato je prva obrambna linija zaščita pred "volumetričnimi" napadi in vaš ponudnik ali ponudniki vam morajo zagotoviti to zaščito. Če tega še niste dojeli, potem imate zaenkrat samo srečo.

Primer

Recimo, da imate več povezav navzgor, vendar vam to zaščito lahko zagotovi samo eden od ponudnikov. Če pa gre ves promet prek enega ponudnika, kaj je potem s povezljivostjo, o kateri smo na kratko govorili malo prej?

V tem primeru boste morali med napadom delno žrtvovati povezljivost. Ampak

• to velja samo za čas trajanja napada. V primeru napada lahko BGP ročno ali avtomatsko prenastavite tako, da promet poteka samo prek ponudnika, ki vam zagotavlja "dežnik". Po končanem napadu lahko vrnete usmerjanje v prejšnje stanje
• Ni potrebno prenesti celotnega prometa. Če na primer vidite, da ni napadov prek nekaterih povezav navzgor ali enakovrednih povezav (ali promet ni pomemben), lahko nadaljujete z oglaševanjem predpon s konkurenčnimi atributi do teh sosedov BGP.

Zaščito pred »napadi na protokole« in »napadi na aplikacije« lahko prenesete tudi na svoje partnerje.
Tu tukaj lahko prebereš dobro študijo (prevod). Resda je članek star dve leti, vendar vam bo dal predstavo o pristopih, kako se zaščititi pred DDOS napadi.

Načeloma se lahko omejite na to in svojo zaščito popolnoma oddate zunanjim izvajalcem. Ta odločitev ima prednosti, vendar obstaja tudi očitna pomanjkljivost. Dejstvo je, da lahko govorimo (spet odvisno od tega, kaj vaše podjetje počne) o preživetju posla. In take stvari zaupajte tretjim...

Zato si poglejmo, kako organizirati drugo in tretjo obrambno linijo (kot dodatek zaščiti pred ponudnikom).

Druga obrambna linija je torej filtriranje in omejevalniki prometa (policisti) na vhodu v vaše omrežje.

Primer 1

Recimo, da ste se s pomočjo enega izmed ponudnikov pokrili z dežnikom proti DDOS-u. Predpostavimo, da ta ponudnik uporablja Arbor za filtriranje prometa in filtrira na robu svojega omrežja.

Pasovna širina, ki jo Arbor lahko »obdela«, je omejena, ponudnik pa seveda ne more nenehno prenašati prometa vseh svojih partnerjev, ki naročajo to storitev, skozi filtrirno opremo. Zato v normalnih pogojih promet ni filtriran.

Predpostavimo, da gre za napad SYN flood. Tudi če ste naročili storitev, ki v primeru napada samodejno preklopi promet na filtriranje, se to ne zgodi takoj. Minuto ali več ostaneš pod napadom. In to lahko povzroči okvaro vaše opreme ali poslabšanje storitve. V tem primeru omejevanje prometa na robnem usmerjanju, čeprav bo vodilo do dejstva, da nekatere seje TCP v tem času ne bodo vzpostavljene, bo vašo infrastrukturo rešilo pred težavami večjega obsega.

Primer 2

Nenormalno veliko število paketov SYN morda ni samo posledica napada SYN flood. Predpostavimo, da ponujate storitev, pri kateri imate lahko hkrati približno 100 tisoč TCP povezav (v en podatkovni center).

Recimo, da je zaradi kratkotrajne težave z enim od vaših glavnih ponudnikov polovica vaših sej prekinjena. Če je vaša aplikacija zasnovana tako, da brez premisleka takoj (ali po določenem časovnem intervalu, ki je enak za vse seje) poskuša znova vzpostaviti povezavo, potem boste prejeli približno 50 tisoč SYN paketov. istočasno.

Če morate na primer zagnati rokovanje ssl/tls poleg teh sej, kar vključuje izmenjavo potrdil, potem bo z vidika izčrpavanja virov za vaš izravnalnik obremenitve to veliko močnejši »DDOS« kot preprost SYN poplava. Zdi se, da bi morali ravnotežji obravnavati takšne dogodke, toda ... na žalost se soočamo s takšno težavo.

In seveda bo policist na robnem usmerjevalniku tudi v tem primeru rešil vašo opremo.

Tretja raven zaščite pred DDOS/DOS so nastavitve požarnega zidu.

Tukaj lahko zaustavite oba napada druge in tretje vrste. Na splošno je tukaj mogoče filtrirati vse, kar doseže požarni zid.

Nasvet

Poskusite dati požarnemu zidu čim manj dela in filtrirajte čim več na prvih dveh obrambnih linijah. In zato.

Se vam je že kdaj zgodilo, da ste po naključju med ustvarjanjem prometa za preverjanje, na primer, kako odporen je operacijski sistem vaših strežnikov na napade DDOS, »ubili« požarni zid in ga naložili na 100 odstotkov, promet pa je bil normalen ? Če ne, je morda preprosto zato, ker niste poskusili?

Na splošno je požarni zid, kot sem rekel, zapletena stvar in dobro deluje z znanimi ranljivostmi in preizkušenimi rešitvami, če pa pošljete nekaj nenavadnega, samo nekaj smeti ali pakete z napačnimi glavami, potem ste z nekaterimi, ne z tako majhna verjetnost (glede na moje izkušnje) lahko omamiš celo vrhunsko opremo. Zato na 2. stopnji z uporabo običajnih ACL (na ravni L3/L4) dovolite samo promet v vaše omrežje, ki bi moral vstopiti tja.

Filtriranje prometa na požarnem zidu

Nadaljujmo pogovor o požarnem zidu. Morate razumeti, da so napadi DOS/DDOS le ena vrsta kibernetskega napada.

Poleg zaščite DOS/DDOS lahko imamo tudi nekaj podobnega naslednjemu seznamu funkcij:

• požarni zid aplikacije
• preprečevanje groženj (protivirusna, protivohunska programska oprema in ranljivost)
• Filtriranje URL-jev
• filtriranje podatkov (filtriranje vsebine)
• blokiranje datotek (blokiranje vrst datotek)

Na vas je, da se odločite, kaj s tega seznama potrebujete.

Se nadaljuje

Vir: www.habr.com