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

Nema smisla govoriti o potpunom otklanjanju sigurnosnih rizika. U principu, ne možemo ih svesti na nulu. Također moramo shvatiti da kako nastojimo učiniti mrežu 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 se također mora uzeti u obzir.

Ali da vas podsjetim da sada ne govorimo o stvaranju mreže. Prema našim početni uslovi već smo odabrali dizajn, odabrali opremu i kreirali infrastrukturu, a u ovoj fazi, ako je moguće, treba da „živimo” i pronađemo rješenja u kontekstu prethodno odabranog pristupa.

Naš zadatak je da identifikujemo rizike povezane sa bezbednošću na nivou mreže i svedemo ih na razuman nivo.

Revizija mrežne sigurnosti

Ako je vaša organizacija implementirala ISO 27k procese, onda bi se sigurnosne revizije i promjene mreže trebale neprimjetno uklopiti u ukupne procese unutar ovog pristupa. Ali ovi standardi se i dalje ne odnose na konkretna rješenja, ne na konfiguraciju, ne na dizajn... Nema jasnih savjeta, nema standarda koji diktiraju do detalja kakva bi vaša mreža trebala biti, u tome je složenost i ljepota ovog zadatka.

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

• revizija konfiguracije opreme (očvršćavanje)
• revizija sigurnosnog dizajna
• revizija pristupa
• revizija procesa

Revizija konfiguracije opreme (očvršćavanje)

Čini se da je u većini slučajeva ovo najbolja polazna tač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).

Suština je da obično imamo preporuke dobavljača u vezi sa „najboljim praksama“ za sigurnost prilikom konfigurisanja opreme. To se zove "otvrdnjavanje".

Također često možete pronaći upitnik (ili ga sami kreirati) na osnovu ovih preporuka, koji će vam pomoći da utvrdite koliko je konfiguracija vaše opreme u skladu s ovim „najboljim praksama“ i, u skladu s rezultatom, napravite promjene u vašoj mreži . Ovo će vam omogućiti da značajno smanjite sigurnosne rizike prilično lako, gotovo bez troškova.

Nekoliko primjera za neke Cisco operativne sisteme.

Učvršćivanje Cisco IOS konfiguracije
Učvršćivanje konfiguracije Cisco IOS-XR
Učvršćivanje konfiguracije Cisco NX-OS
Cisco Baseline Security Check List

Na osnovu ovih dokumenata može se napraviti lista konfiguracijskih zahtjeva za svaku vrstu opreme. Na primjer, za Cisco N7K VDC ovi zahtjevi mogu izgledati ovako tako.

Na ovaj način se mogu kreirati konfiguracijski fajlovi za različite vrste aktivne opreme u vašoj mrežnoj infrastrukturi. Zatim, ručno ili pomoću automatizacije, možete "uploadati" ove konfiguracijske datoteke. Kako automatizirati ovaj proces će se detaljno raspravljati u drugoj seriji članaka o orkestraciji i automatizaciji.

Revizija sigurnosnog dizajna

Mreža preduzeća obično sadrži sljedeće segmente u ovom ili onom obliku:

• DC (Javni servisi DMZ i Intranet data centar)
• pristup Internetu
• VPN za daljinski pristup
• WAN rub
• grana
• kampus (kancelarija)
• jezgro

Naslovi preuzeti iz Cisco SAFE modela, ali nije potrebno, naravno, vezati se upravo za ove nazive i za ovaj model. Ipak, želim da pričam o suštini i da ne zaglibim u formalnosti.

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

Pogledajmo svaki od njih posebno za probleme na koje možete naići sa stanovišta sigurnosnog dizajna. Naravno, opet ponavljam da ovaj članak ni na koji način ne pretenduje na potpun, što nije lako (ako ne i nemoguće) postići u ovoj zaista dubokoj i višeznačnoj temi, ali odražava moje lično iskustvo.

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

Data centar

Najkritičniji segment sa sigurnosne tačke gledišta.
A, kao i obično, ni ovdje nema univerzalnog rješenja. Sve u velikoj mjeri ovisi o zahtjevima mreže.

Da li je firewall neophodan ili ne?

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

Primer 1. Kašnjenja.

Ako je mala latencija bitan zahtjev između nekih segmenata mreže, što je, na primjer, tačno u slučaju razmjene, tada nećemo moći koristiti firewall između ovih segmenata. Teško je pronaći studije o kašnjenju u zaštitnim zidovima, ali nekoliko modela prekidača može osigurati kašnjenje manje od ili reda veličine 1 mksec, tako da mislim da ako su vam mikrosekunde važne, onda zaštitni zidovi nisu za vas.

Primer 2. Performanse.

Propusnost vrhunskih L3 prekidača je obično za red veličine veća od propusnosti najmoćnijih zaštitnih zidova. Stoga, u slučaju saobraćaja visokog intenziteta, najvjerovatnije ćete morati dozvoliti ovom prometu da zaobiđe firewall.

Primer 3. Pouzdanost.

Zaštitni zidovi, posebno moderni NGFW (Next-Generation FW) su složeni uređaji. Oni su mnogo složeniji od L3/L2 prekidača. Pružaju veliki broj usluga i opcija konfiguracije, pa ne čudi da je njihova pouzdanost znatno niža. Ako je kontinuitet usluge kritičan za mrežu, tada ćete možda morati da odaberete šta će dovesti do bolje dostupnosti - sigurnost sa zaštitnim zidom ili jednostavnost mreže izgrađene na prekidačima (ili raznim vrstama tkanina) koristeći obične ACL-ove.

U slučaju gornjih primjera, najvjerovatnije ćete (kao i obično) morati pronaći kompromis. Obratite pažnju na sljedeća rješenja:

• ako odlučite da ne koristite firewall unutar podatkovnog centra, onda morate 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, logovanje,...)
• možete koristiti logičku particiju mreže centara podataka na segmente, slično šemi opisanoj u PSEFABRIC primjer p002. U ovom slučaju, rutiranje mora biti konfigurisano na takav način da saobraćaj osetljiv na kašnjenje ili saobraćaj visokog intenziteta ide „unutar” jednog segmenta (u slučaju p002, VRF) i da ne prolazi kroz zaštitni zid. Saobraćaj između različitih segmenata će i dalje prolaziti kroz zaštitni zid. Također možete koristiti propuštanje ruta između VRF-ova kako biste izbjegli preusmjeravanje prometa kroz zaštitni zid
• Takođe možete koristiti zaštitni zid u transparentnom načinu rada i to samo za one VLAN-ove gdje ovi faktori (latencija/performanse) nisu značajni. Ali morate pažljivo proučiti ograničenja povezana s korištenjem ovog moda za svakog dobavljača
• možda biste željeli razmotriti korištenje arhitekture lanca usluga. Ovo će omogućiti samo potrebnom saobraćaju da prođe kroz zaštitni zid. U teoriji izgleda lijepo, ali nikada nisam vidio ovo rješenje u proizvodnji. Testirali smo servisni lanac za Cisco ACI/Juniper SRX/F5 LTM prije otprilike 3 godine, ali nam se u to vrijeme ovo rješenje činilo “sirovim”.

Nivo zaštite

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

• zaštitni zid sa stanjem (zadano)
• 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)
• dos zaštita

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

• Što više gore navedenih funkcija firewall koristite, to će naravno biti skuplji (licence, dodatni moduli)
• upotreba nekih algoritama može značajno smanjiti propusnost zaštitnog zida i povećati kašnjenja, vidi na primjer ovdje
• kao i svako složeno rješenje, korištenje složenih metoda zaštite može umanjiti pouzdanost vašeg rješenja, na primjer, prilikom korištenja vatrozida aplikacija, naišao sam na blokiranje nekih sasvim 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 funkcije zaštite mogu biti potrebne. Prvo, jer to naravno ovisi o podacima koje prenosite ili pohranjujete i pokušavate zaštititi. Drugo, u stvarnosti, često je izbor sigurnosnih alata stvar vjere i povjerenja u dobavljača. Ne poznajete algoritme, ne znate koliko su efikasni i ne možete ih u potpunosti testirati.

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

Segmentacija

Riječ je o logičnoj segmentaciji mreže data centara. Na primjer, particioniranje na VLAN-ove i podmreže je također logična segmentacija, ali je nećemo razmatrati zbog njene očiglednosti. Zanimljiva segmentacija uzimajući u obzir entitete kao što su FW sigurnosne zone, VRF-ovi (i njihovi analozi u odnosu na različite dobavljače), logički uređaji (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Dat je primjer takve logičke segmentacije i trenutno traženog dizajna podatkovnog centra p002 projekta PSEFABRIC.

Nakon što definirate 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 tokove podataka nisu formalizirana, to znači da ste, kada otvorite ovaj ili onaj pristup, prisiljeni riješiti ovaj problem, a s velikom vjerovatnoćom rješavat će to svaki put drugačije.

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

• koje sigurnosne zone su vam potrebne
• koji nivo zaštite želite primijeniti na svaku od ovih zona
• da li će saobraćaj unutar zone biti standardno dozvoljen?
• ako ne, koje politike filtriranja saobraćaja će se primjenjivati ​​unutar svake zone
• koje će se politike filtriranja prometa primijeniti za svaki par zona (izvor/odredište)

TCAM

Čest problem je nedovoljan TCAM (ternarna adresabilna memorija sadržaja), kako za rutiranje tako i za pristupe. IMHO, ovo je jedno od najvažnijih pitanja pri odabiru opreme, tako da se prema ovom pitanju morate odnositi s odgovarajućim stepenom pažnje.

Primjer 1. Tablica prosljeđivanja TCAM.

Razmotrimo Palo Alto 7k firewall
Vidimo da je veličina tabele za prosleđivanje IPv4* = 32K
Štaviše, ovaj broj ruta je zajednički za sve VSYS.

Pretpostavimo da ste prema vašem dizajnu odlučili koristiti 4 VSYS.
Svaki od ovih VSYS-ova je povezan preko BGP-a na dva MPLS PE-a u oblaku koji koristite kao BB. Dakle, 4 VSYS međusobno razmjenjuju sve specifične rute i imaju tabelu prosljeđivanja sa približno istim skupovima ruta (ali različitim NH-ovima). Jer svaki VSYS ima 2 BGP sesije (sa istim postavkama), tada svaka ruta primljena preko MPLS-a ima 2 NH i, shodno tome, 2 FIB unosa u tabeli prosleđivanja. Ako pretpostavimo da je ovo jedini firewall u podatkovnom centru i da 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 (sa istim dizajnom) i želimo koristiti VLAN-ove "rastegnute" između podatkovnih centara (na primjer, za vMotion), onda da bismo riješili problem rutiranja, moramo koristiti rute hosta . Ali to znači da za 2 data 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 prekidačima (ili drugim rješenjima koja koriste L3 prekidače, na primjer, Cisco ACI), tada pri odabiru opreme obratite pažnju na TCAM ACL.

Pretpostavimo da želite da kontrolišete pristup na SVI interfejsima Cisco Catalyst 4500. Zatim, kao što se može videti iz ovog člana, za kontrolu odlaznog (kao i dolaznog) saobraćaja na interfejsima, možete koristiti samo 4096 TCAM linija. Što će vam kada koristite TCAM3 dati oko 4000 hiljada ACE (ACL linija).

Ako ste suočeni s problemom nedovoljnog TCAM-a, tada, prije svega, naravno, morate razmotriti mogućnost optimizacije. Dakle, u slučaju problema s veličinom tabele prosljeđivanja, morate razmotriti mogućnost agregiranja ruta. U slučaju problema sa veličinom TCAM-a za pristupe, izvršite reviziju pristupa, uklonite zastarele i preklapajuće zapise i eventualno revidirajte proceduru otvaranja pristupa (detaljnije će biti razmotreno u poglavlju o reviziji pristupa).

Visoka dostupnost

Pitanje je: da li da koristim HA za firewall ili da instaliram dva nezavisna boksa „paralelno” i, ako jedan od njih pokvari, usmeravam saobraćaj kroz drugi?

Čini se da je odgovor očigledan - koristite HA. Razlog zašto se ovo pitanje još uvijek postavlja je taj što se, nažalost, teorijski i reklamni 99 i nekoliko decimalnih postotaka dostupnosti u praksi ispostavilo da su daleko od tako ružičastih. HA je logično prilično složena stvar, i na različitoj opremi, i kod različitih dobavljača (nije bilo izuzetaka), uhvatili smo probleme i greške i zaustavili servis.

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

Ako ne koristite HA, onda su sa stanovišta dvostrukog kvara vaši rizici mnogo manji (pošto imate 2 nezavisna firewall-a), ali pošto... sesije nisu sinkronizirane, tada ćete svaki put kada se prebacite između ovih zaštitnih zidova izgubiti promet. Možete, naravno, koristiti zaštitni zid bez stanja, ali tada se smisao korištenja zaštitnog zida u velikoj mjeri gubi.

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

Upravljivost

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

Ali možda imate mnogo centara podataka i mnogo zaštitnih zidova, onda se ovo pitanje postavlja na novom nivou. I pitanje nije samo u konfiguraciji, već io tome

• rezervne konfiguracije
• ažuriranja
• nadogradnje
• praćenje
• logging

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

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

Nastaviti.

izvor: www.habr.com