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

O potpunom uklanjanju sigurnosnih rizika nema smisla govoriti. U principu ih ne možemo svesti na nulu. Također moramo shvatiti da, dok nastojimo mrežu učiniti sve sigurnijom, naša rješenja postaju sve skuplja. Morate pronaći kompromis između cijene, složenosti i sigurnosti koji ima smisla za vašu mrežu.

Naravno, sigurnosni dizajn je organski integriran u cjelokupnu arhitekturu i korištena sigurnosna rješenja utječu na skalabilnost, pouzdanost, upravljivost, ... mrežne infrastrukture, što također treba uzeti u obzir.

Ali podsjetit ću vas da sada ne govorimo o stvaranju mreže. Prema našem početni uvjeti već smo odabrali dizajn, odabrali opremu i napravili infrastrukturu, au ovoj fazi, ako je moguće, treba “živjeti” i pronaći rješenja u kontekstu prethodno odabranog pristupa.

Naš je zadatak sada identificirati rizike povezane sa sigurnošću na razini mreže i smanjiti ih na razumnu razinu.

Revizija sigurnosti mreže

Ako je vaša organizacija implementirala ISO 27k procese, tada bi se sigurnosne revizije i mrežne promjene trebale neprimjetno uklopiti u ukupne procese unutar ovog pristupa. Ali ti se standardi još uvijek ne odnose na specifična rješenja, ne na konfiguraciju, ne na dizajn... Ne postoje jasni savjeti, nema standarda koji u detalje određuju kakva bi vaša mreža trebala biti, to je složenost i ljepota ovog zadatka.

Istaknuo bih nekoliko mogućih revizija sigurnosti mreže:

• revizija konfiguracije opreme (kaljenje)
• revizija sigurnosnog dizajna
• revizija pristupa
• revizija procesa

Revizija konfiguracije opreme (kaljenje)

Čini se da je to u većini slučajeva najbolja polazna točka za reviziju i poboljšanje sigurnosti vaše mreže. IMHO, ovo je dobra demonstracija Paretovog zakona (20% truda daje 80% rezultata, a preostalih 80% truda daje samo 20% rezultata).

Zaključak je da obično imamo preporuke dobavljača u vezi s "najboljim postupcima" za sigurnost prilikom konfiguriranja opreme. To se naziva "stvrdnjavanje".

Također često možete pronaći upitnik (ili ga sami izraditi) na temelju ovih preporuka, koji će vam pomoći da odredite koliko je konfiguracija vaše opreme u skladu s ovim "najboljim praksama" i, u skladu s rezultatom, napravite promjene u svojoj mreži . To će vam omogućiti da značajno smanjite sigurnosne rizike prilično jednostavno, gotovo bez ikakvih troškova.

Nekoliko primjera za neke Cisco operativne sustave.

Ojačavanje Cisco IOS konfiguracije
Ojačavanje Cisco IOS-XR konfiguracije
Ojačavanje konfiguracije Cisco NX-OS
Cisco Baseline sigurnosni kontrolni popis

Na temelju tih dokumenata može se izraditi popis konfiguracijskih zahtjeva za svaku vrstu opreme. Na primjer, za Cisco N7K VDC ovi zahtjevi mogu izgledati ovako tako.

Na ovaj način mogu se kreirati konfiguracijske datoteke za različite vrste aktivne opreme u vašoj mrežnoj infrastrukturi. Zatim, ručno ili korištenjem automatizacije, možete "uploadati" ove konfiguracijske datoteke. O tome kako automatizirati ovaj proces bit će detaljno objašnjeno u drugoj seriji članaka o orkestraciji i automatizaciji.

Revizija sigurnosnog dizajna

Tipično, mreža poduzeća sadrži sljedeće segmente u ovom ili onom obliku:

• DC (javne usluge DMZ i intranet podatkovni centar)
• Pristup Internetu
• VPN s udaljenim pristupom
• WAN rub
• Grana
• Kampus (ured)
• srž

Naslovi preuzeti iz Cisco SIGURNO model, ali nije potrebno, naravno, vezivati ​​se upravo za ove nazive i za ovaj model. Ipak, želim govoriti o suštini, a ne zaglibiti u formalnosti.

Za svaki od ovih segmenata bit će različiti sigurnosni zahtjevi, rizici i sukladno tome rješenja.

Pogledajmo svaki od njih zasebno zbog problema na koje možete naići sa stajališta sigurnosnog dizajna. Naravno, opet ponavljam da ovaj članak ni na koji način ne pretendira na cjelovitost, što nije lako (ako ne i nemoguće) postići u ovoj doista dubokoj i višestranoj temi, već odražava moje osobno iskustvo.

Ne postoji savršeno rješenje (barem ne još). Uvijek je kompromis. No važno je da se odluka o korištenju jednog ili drugog pristupa donese svjesno, uz razumijevanje njegovih prednosti i mana.

Data Center

Sigurnosno najkritičniji segment.
I, kao i obično, ni tu nema univerzalnog rješenja. Sve uvelike ovisi o zahtjevima mreže.

Je li vatrozid potreban ili ne?

Čini se da je odgovor očit, ali nije sve tako jasno kao što se čini. I na vaš izbor može utjecati ne samo cijena.

Primjer 1. Kašnjenja.

Ako je niska latencija bitan zahtjev između nekih mrežnih segmenata, što je, primjerice, točno u slučaju razmjene, tada nećemo moći koristiti vatrozid između tih segmenata. Teško je pronaći studije o kašnjenju u vatrozidima, ali nekoliko modela prekidača može pružiti kašnjenje manje od ili reda veličine 1 mks, pa mislim da ako su vam važne mikrosekunde, vatrozidi nisu za vas.

Primjer 2. Izvođenje.

Propusnost vrhunskih L3 preklopnika obično je za red veličine veća od propusnosti najjačih vatrozida. Stoga, u slučaju prometa visokog intenziteta, najvjerojatnije ćete morati dopustiti da ovaj promet zaobiđe vatrozid.

Primjer 3. Pouzdanost.

Vatrozidi, posebno moderni NGFW (Next-Generation FW) su složeni uređaji. Mnogo su složeniji od L3/L2 sklopki. Pružaju veliki broj usluga i mogućnosti konfiguracije, pa ne čudi da je njihova pouzdanost znatno manja. Ako je kontinuitet usluge kritičan za mrežu, tada ćete možda morati odabrati što će dovesti do bolje dostupnosti - sigurnost s vatrozidom ili jednostavnost mreže izgrađene na preklopnicima (ili raznim vrstama tkanina) koristeći regularne ACL-ove.

U slučaju gore navedenih primjera, najvjerojatnije ćete (kao i obično) morati pronaći kompromis. Pogledajte sljedeća rješenja:

• ako odlučite ne koristiti vatrozid unutar podatkovnog centra, tada trebate razmisliti o tome kako ograničiti pristup oko perimetra što je više moguće. Na primjer, možete otvoriti samo potrebne portove s Interneta (za klijentski promet) i administrativni pristup podatkovnom centru samo sa jump hostova. Na jump hostovima izvršite sve potrebne provjere (autentifikacija/autorizacija, antivirus, logiranje, ...)
• možete koristiti logičku particiju mreže podatkovnog centra u segmente, slično shemi opisanoj u PSEFABRIC-u primjer p002. U ovom slučaju, usmjeravanje mora biti konfigurirano na takav način da promet osjetljiv na kašnjenje ili promet visokog intenziteta ide "unutar" jednog segmenta (u slučaju p002, VRF) i ne prolazi kroz vatrozid. Promet između različitih segmenata nastavit će ići kroz vatrozid. Također možete koristiti curenje rute između VRF-ova kako biste izbjegli preusmjeravanje prometa kroz vatrozid
• Također možete koristiti vatrozid u transparentnom načinu rada i samo za one VLAN-ove gdje ovi faktori (latencija/performanse) nisu značajni. Ali morate pažljivo proučiti ograničenja povezana s upotrebom ovog moda za svakog dobavljača
• možda biste trebali razmotriti korištenje arhitekture lanca usluga. Ovo će dopustiti da samo potreban promet prođe kroz vatrozid. Izgleda lijepo u teoriji, ali nikad nisam vidio ovo rješenje u proizvodnji. Testirali smo servisni lanac za Cisco ACI/Juniper SRX/F5 LTM prije otprilike 3 godine, ali tada nam se ovo rješenje činilo “surovim”.

Razina zaštite

Sada trebate odgovoriti na pitanje koje alate želite koristiti za filtriranje prometa. Evo nekih značajki koje su obično prisutne u NGFW (na primjer, ovdje):

• vatrozid s praćenjem stanja (zadano)
• vatrozid aplikacije
• prevencija prijetnji (antivirus, anti-spyware i ranjivost)
• Filtriranje URL-a
• filtriranje podataka (filtriranje sadržaja)
• blokiranje datoteka (blokiranje vrsta datoteka)
• dos zaštita

A nije ni sve jasno. Čini se da što je viša razina zaštite, to bolje. Ali morate i to uzeti u obzir

• Što više gore navedenih funkcija vatrozida koristite, to će naravno biti skuplje (licence, dodatni moduli)
• korištenje nekih algoritama može značajno smanjiti propusnost vatrozida i također povećati kašnjenja, pogledajte na primjer ovdje
• kao i svako složeno rješenje, korištenje složenih metoda zaštite može smanjiti pouzdanost vašeg rješenja, na primjer, prilikom korištenja vatrozida aplikacije naišao sam na blokiranje nekih prilično standardnih radnih aplikacija (dns, smb)

Kao i uvijek, morate pronaći najbolje rješenje za svoju mrežu.

Nemoguće je definitivno odgovoriti na pitanje koje zaštitne funkcije mogu biti potrebne. Prvo, jer to naravno ovisi o podacima koje prenosite ili pohranjujete i pokušavate zaštititi. Drugo, u stvarnosti je izbor sigurnosnih alata često stvar vjere i povjerenja u dobavljača. Ne poznajete algoritme, ne znate koliko su učinkoviti i ne možete ih u potpunosti testirati.

Stoga bi u kritičnim segmentima dobro rješenje moglo biti korištenje ponuda različitih tvrtki. Na primjer, možete omogućiti antivirusnu zaštitu na vatrozidu, ali i koristiti antivirusnu zaštitu (drugog proizvođača) lokalno na hostovima.

Segmentacija

Riječ je o logičnoj segmentaciji mreže podatkovnog centra. Na primjer, particioniranje na VLAN-ove i podmreže je također logično segmentiranje, ali ga nećemo razmatrati zbog njegove očiglednosti. Zanimljiva segmentacija koja uzima u obzir takve entitete kao što su FW sigurnosne zone, VRF-ovi (i njihovi analozi u odnosu na razne dobavljače), logički uređaji (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Primjer takve logične segmentacije i trenutno traženog dizajna podatkovnog centra dan je u p002 projekta PSEFABRIC.

Nakon što ste definirali logičke dijelove vaše mreže, možete opisati kako se promet kreće između različitih segmenata, na kojim uređajima će se vršiti filtriranje i na koji način.

Ako vaša mreža nema jasnu logičku particiju i pravila za primjenu sigurnosnih politika za različite protoke podataka nisu formalizirana, to znači da kada otvorite ovaj ili onaj pristup, prisiljeni ste riješiti ovaj problem i s velikom vjerojatnošću riješit će to svaki put drugačije.

Često se segmentacija temelji samo na FW sigurnosnim zonama. Zatim morate odgovoriti na sljedeća pitanja:

• koje sigurnosne zone trebate
• koju razinu zaštite želite primijeniti na svaku od ovih zona
• hoće li promet unutar zone biti dopušten prema zadanim postavkama?
• ako ne, koja će se politika filtriranja prometa primjenjivati ​​unutar svake zone
• koja će se pravila filtriranja prometa primijeniti za svaki par zona (izvor/odredište)

TCAM

Čest problem je nedovoljno TCAM-a (Ternary Content Addressable Memory), kako za usmjeravanje tako i za pristupe. IMHO, ovo je jedno od najvažnijih pitanja pri odabiru opreme, tako da ovom pitanju morate pristupiti s odgovarajućim stupnjem pažnje.

Primjer 1. Tablica prosljeđivanja TCAM.

razmotrimo Palo Alto 7 tisuća vatrozid
Vidimo da je veličina tablice IPv4 prosljeđivanja* = 32K
Štoviše, ovaj broj ruta je zajednički za sve VSYS-ove.

Pretpostavimo da ste prema svom dizajnu odlučili koristiti 4 VSYS.
Svaki od tih VSYS-ova povezan je putem BGP-a s dva MPLS PE-a u oblaku koji koristite kao BB. Dakle, 4 VSYS međusobno razmjenjuju sve specifične rute i imaju tablicu prosljeđivanja s približno istim skupovima ruta (ali različitim NH). Jer svaki VSYS ima 2 BGP sesije (s istim postavkama), zatim svaka ruta primljena putem MPLS-a ima 2 NH i, sukladno tome, 2 FIB unosa u Forwarding Table. Ako pretpostavimo da je ovo jedini vatrozid u podatkovnom centru i mora znati za sve rute, onda će to značiti da ukupan broj ruta u našem podatkovnom centru ne može biti veći od 32K/(4 * 2) = 4K.

Sada, ako pretpostavimo da imamo 2 podatkovna centra (s istim dizajnom), i želimo koristiti VLAN-ove "razvučene" između podatkovnih centara (na primjer, za vMotion), tada da bismo riješili problem usmjeravanja, moramo koristiti host rute . Ali to znači da za 2 podatkovna centra nećemo imati više od 4096 mogućih hostova i, naravno, to možda neće biti dovoljno.

Primjer 2. ACL TCAM.

Ako planirate filtrirati promet na L3 preklopnicima (ili drugim rješenjima koja koriste L3 preklopnike, na primjer, Cisco ACI), tada pri odabiru opreme obratite pozornost na TCAM ACL.

Pretpostavimo da želite kontrolirati pristup na SVI sučeljima Cisco Catalyst 4500. Tada, kao što se može vidjeti iz ovaj članak, za kontrolu odlaznog (kao i dolaznog) prometa na sučeljima, možete koristiti samo 4096 TCAM linija. Što će vam pri korištenju TCAM3 dati oko 4000 tisuća ACE (ACL linija).

Ako ste suočeni s problemom nedovoljnog TCAM-a, prije svega, naravno, trebate razmotriti mogućnost optimizacije. Dakle, u slučaju problema s veličinom tablice prosljeđivanja, trebate razmotriti mogućnost združivanja ruta. U slučaju problema s veličinom TCAM-a za pristupe, izvršite reviziju pristupa, uklonite zastarjele zapise i zapise koji se preklapaju i eventualno revidirajte postupak za otvaranje pristupa (detaljnije će se raspravljati u poglavlju o reviziji pristupa).

Visoka dostupnost

Pitanje je: trebam li koristiti HA za vatrozid ili instalirati dva neovisna boxa "paralelno" i, ako jedan od njih zakaže, usmjeravati promet kroz drugi?

Čini se da je odgovor očit - koristite HA. Razlog zašto se to pitanje i dalje postavlja je taj što se, nažalost, teoretski i reklamni 99 i nekoliko decimalnih postotaka dostupnosti u praksi pokazuju daleko od tako ružičastih. HA je logično dosta složena stvar, i na različitoj opremi, i kod različitih dobavljača (nije bilo iznimaka), uhvatili smo probleme i bugove i zastoj servisa.

Ako koristite HA, imat ćete priliku isključiti pojedinačne čvorove, prebacivati ​​se između njih bez zaustavljanja usluge, što je važno, primjerice, prilikom nadogradnji, ali u isto vrijeme imate vjerojatnost daleko od nule da oba čvora će se pokvariti u isto vrijeme, kao i da sljedeća nadogradnja neće ići tako glatko kao što dobavljač obećava (ovaj se problem može izbjeći ako imate priliku testirati nadogradnju na laboratorijskoj opremi).

Ako ne koristite HA, tada su sa stajališta dvostrukog kvara vaši rizici puno manji (budući da imate 2 neovisna vatrozida), ali budući da... sesije nisu sinkronizirane, svaki put kada se prebacite između ovih vatrozida izgubit ćete promet. Možete, naravno, koristiti vatrozid bez statusa, ali tada se gubi smisao korištenja vatrozida.

Stoga, ako ste kao rezultat revizije otkrili usamljene vatrozide i razmišljate o povećanju pouzdanosti svoje mreže, tada je HA, naravno, jedno od preporučenih rješenja, ali također biste trebali uzeti u obzir nedostatke povezane s s ovim pristupom i, možda, posebno za vašu mrežu, drugo bi rješenje bilo prikladnije.

Upravljivost

U principu, HA se također odnosi na upravljivost. Umjesto da zasebno konfigurirate 2 kutije i bavite se problemom sinkronizacije konfiguracija, upravljate njima kao da imate jedan uređaj.

Ali možda imate mnogo podatkovnih centara i mnogo vatrozida, onda se ovo pitanje pojavljuje na novoj razini. A pitanje nije samo o konfiguraciji, već i o

• sigurnosne konfiguracije
• nadopune
• nadogradnje
• praćenje
• sječa

A sve se to može riješiti centraliziranim sustavima upravljanja.

Dakle, na primjer, ako koristite vatrozid Palo Alto, onda panorama je takvo rješenje.

Nastaviti.

Izvor: www.habr.com