Acest articol este al treilea dintr-o serie de articole "Cum să preiei controlul asupra infrastructurii de rețea". Conținutul tuturor articolelor din serie și linkurile pot fi găsite aici.

Nu are sens să vorbim despre eliminarea completă a riscurilor de securitate. În principiu, nu putem să le reducem la zero. De asemenea, trebuie să înțelegem că, pe măsură ce încercăm să facem rețeaua mai sigură, soluțiile noastre devin din ce în ce mai scumpe. Este necesar să găsim un compromis rezonabil pentru rețeaua dumneavoastră între cost, complexitate și securitate.

Desigur, designul de securitate este integrat organic în arhitectura generală, iar soluțiile de securitate utilizate influențează scalabilitatea, fiabilitatea, gestionabilitatea… infrastructurii de rețea, ceea ce trebuie de asemenea avut în vedere.

Dar, reamintesc, că acum nu discutăm despre crearea unei rețele. Conform condițiilor noastre inițiale avem deja un design ales, echipamentele selectate și o infrastructură creată, iar în acest stadiu, trebuie să "trăim" cât mai mult posibil și să găsim soluții în contextul abordării alese anterior.

Sarcina noastră acum este să identificăm riscurile legate de securitate la nivel de rețea și să le reducem la o dimensiune rezonabilă.

Auditul securității rețelei

Dacă în organizația dumneavoastră sunt implementate procese ISO 27k, atunci auditul de securitate și modificările rețelei trebuie să se integreze organic în procesele generale conform acestei abordări. Dar aceste standarde nu se referă totuși la soluții specifice, nu la configurație, nu la design… Nu există sfaturi univoce, nu există standarde care să dicteze detaliat cum ar trebui să fie rețeaua dumneavoastră, aceasta este complexitatea și frumusețea acestei sarcini.

Aș evidenția câteva audite posibile de securitate a rețelei:

auditul configurației echipamentului (hardening)
auditul designului de securitate
auditul acceselor
auditul proceselor

Auditul configurației echipamentului (hardening)

Se pare că, în majoritatea cazurilor, acesta este cel mai bun punct de plecare pentru auditarea și îmbunătățirea securității rețelei dumneavoastră. IMHO, este o bună demonstrație a legii lui Pareto (20% din eforturi dau 80% din rezultate, iar restul de 80% din eforturi - doar 20% din rezultate).

Ideea principală este că de obicei avem recomandări de la furnizori cu privire la "cele mai bune practici" în securitate la configurarea echipamentului. Acest proces se numește “hardening.”

De asemenea, este frecvent întâlnit un chestionar (sau se poate crea unul), bazat pe aceste recomandări, care te va ajuta să determini cât de bine se aliniază configurația echipamentului tău cu aceste „best practices” și, în funcție de rezultate, să efectuezi modificări în rețeaua ta. Aceasta îți va permite să reduci riscurile de securitate într-un mod considerabil, practic fără costuri.

Câteva exemple pentru anumite sisteme de operare Cisco.
Întărirea configurației Cisco IOS
Întărirea configurației Cisco IOS-XR
Întărirea configurației Cisco NX-OS
Lista de verificare a securității de bază Cisco
Pe baza acestor documente poate fi creată o listă de cerințe de configurare pentru fiecare tip de echipament. De exemplu, pentru Cisco N7K VDC, aceste cerințe pot arăta . Cu ajutorul acestuia, se pot instala un cluster Kafka pe Kubernetes cu doar câteva comenzi:.

Astfel, pot fi create fișiere de configurare pentru diferite tipuri de echipamente active din infrastructura ta de rețea. Ulterior, manual sau prin automatizare, poți „încărca” aceste fișiere de configurare. Cum să automatizezi acest proces va fi discutat în detaliu într-o altă serie de articole dedicate orchestrării și automatizării.

Auditul designului de securitate

În general, în rețeaua unei întreprinderi (enterprise network) există, într-o formă sau alta, următoarele segmente:

DC (DMZ servicii publice și centru de date Intranet)
Acces la internet
VPN de acces de la distanță
WAN edge
Filială
Campus (Birou)
Nucleu

Denominațiile sunt preluate din Cisco SAFE modele, dar nu este neapărat nevoie să te limitezi strict la aceste denumiri și la acest model. Totuși, este important să discutăm despre esență și să nu ne pierdem în formalități.

Pentru fiecare dintre aceste segmente, cerințele referitoare la nivelul de securitate, riscurile și, respectiv, soluțiile vor varia.

Să examinăm fiecare dintre ele în parte în ceea ce privește problemele întâmpinate din perspectiva designului de securitate. Desigur, repet, această articolă nu își propune să fie cuprinzătoare, deoarece este greu să atingi acest obiectiv într-o temă atât de profundă și complexă (dacă este posibil), dar reflectă experiența mea personală.

Nu există o soluție perfectă (cel puțin nu în prezent). Este întotdeauna un compromis. Dar este important ca decizia de a aplica un anumit abord să fie luată în mod conștient, cu o înțelegere a atât avantajelor, cât și dezavantajelor sale.

Data Center

Segmentul cel mai critic din perspectiva securității.
Și, ca de obicei, aici nu există o soluție universală. Totul depinde foarte mult de cerințele rețelei.

Este necesar un firewall?

Răspunsul pare evident, dar nu totul este atât de clar cum ar putea părea. De asemenea, alegerea dumneavoastră poate fi influențată nu doar de prețul.

Exemplul 1. Întârzierea.
Dacă o întârziere scăzută între anumite segmente de rețea este o cerință esențială, așa cum este cazul burselor, atunci nu vom putea folosi firewall-uri între aceste segmente. Este greu să găsim studii despre întârzierea în firewall-uri, dar doar câteva modele de switch-uri pot oferi întârzieri mai mici sau de aproximativ 1 mksec, astfel încât, cred că dacă microsecundele sunt importante pentru dumneavoastră, atunci firewall-urile nu sunt pentru dumneavoastră.

Exemplul 2. Performanță.
Lățimea de bandă a celor mai performante switch-uri L3 este de obicei cu un ordin mai mare decât lățimea de bandă a celor mai performante firewall-uri. Așadar, în cazul unui trafic de mare intensitate, de obicei, va trebui să redirecționați acest trafic pentru a evita firewall-urile.

Exemplul 3. Fiabilitate.
Firewall-urile, în special cele moderne NGFW (Next-Generation FW), sunt dispozitive complexe. Ele sunt mult mai complexe decât switch-urile L3/L2. Acestea oferă o mulțime de servicii și opțiuni de configurare, așa că nu este de mirare că fiabilitatea lor este considerabil mai scăzută. Dacă continuitatea serviciului este critică pentru rețea, atunci, poate, va trebui să alegeți ce va duce la o disponibilitate mai bună — securitate prin firewall sau simplitate în rețea, construită pe switch-uri (sau tipuri diferite de fabrici) folosind ACL-uri obișnuite.

În cazul exemplelor enumerate mai sus, va trebui, de obicei, să căutați un compromis. Privind următoarele soluții:

dacă ați decis să nu utilizați firewall-uri în interiorul centrului de date, trebuie să vă gândiți cum să limitați accesul la maximum la nivelul perimetrului. De exemplu, puteți deschide doar porturile necesare din Internet (pentru traficul clienților) și accesul administrativ în centrul de date doar de pe hosts de tip jump. Pe hosts de tip jump să efectuați toate verificările necesare (autentificare/autorizare, antivirus, logare, ...)
puteți folosi o divizare logică a rețelei centrului de date în segmente, similar cu schema descrisă în PSEFABRIC exemplu p002. În acest caz, rutarea trebuie să fie configurată astfel încât traficul sensibil la întârziere sau traficul de intensitate mare să circule „în interiorul” unui singur segment (în cazul p002, al VRF-ului) și să nu treacă prin firewall. Totuși, traficul între diferite segmente va continua să treacă prin firewall. De asemenea, se poate folosi route leaking între VRF-uri pentru a evita redirecționarea traficului prin firewall.
De asemenea, se poate folosi firewall-ul în modul transparent și doar pentru acele VLAN-uri unde acești factori (întârziere/performance) nu sunt semnificativi. Dar trebuie studiate cu atenție limitările legate de utilizarea acestui mod, pentru fiecare furnizor.
Puteți lua în considerare aplicarea arhitecturii service chain. Aceasta va permite direcționarea prin firewall doar a traficului necesar. Teoretic, pare frumos, dar nu am văzut niciodată această soluție în producție. Am testat service chain pentru Cisco ACI/Juniper SRX/F5 LTM acum aproximativ 3 ani, dar pe atunci această soluție ni s-a părut „necoaptă”.

Nivel de protecție

Acum trebuie să răspundem la întrebarea ce instrumente doriți să aplicați pentru filtrarea traficului. Iată câteva dintre opțiunile care sunt de obicei prezente în NGFW (de exemplu, aici):

firewalling de tip stateful (implicit)
firewalling de aplicații
prevenirea amenințărilor (antivirus, anti-spyware și vulnerabilitate)
filtrarea URL-urilor
filtrarea datelor (filtrarea conținutului)
blocarea fișierelor (blocarea tipurilor de fișiere)
protecția DOS

Și nu toate sunt clare. S-ar putea să pară că, cu cât nivelul de protecție este mai mare, cu atât este mai bine. Dar trebuie să țineți cont și de faptul că

cu cât utilizați mai multe dintre funcțiile enumerate mai sus ale firewall-ului, cu atât va fi evident mai scump (licențe, module suplimentare).
utilizarea unor algoritmi poate reduce semnificativ lățimea de bandă a firewall-ului, precum și să crească întârzierile, vezi de exemplu aici
așa cum se întâmplă cu orice soluție complexă, utilizarea unor metode de protecție complexe poate reduce fiabilitatea soluției dvs., de exemplu, în utilizarea firewall-ului de aplicație m-am confruntat cu blocarea unor aplicații care funcționează în mod standard (dns, smb).

Trebuie, ca de obicei, să găsiți soluția optimă pentru rețeaua dvs.

Nu se poate răspunde clar la întrebarea ce funcții de protecție pot fi necesare. În primul rând, pentru că, desigur, depinde de datele pe care le transmiteți sau le stocați și pe care încercați să le protejați. În al doilea rând, de fapt, adesea alegerea mijloacelor de protecție este o chestiune de credință și încredere în furnizor. Nu știți algoritmii, nu știți cât de eficienți sunt și nu puteți să îi testați complet.

De aceea, în segmente critice, o soluție bună ar putea fi utilizarea ofertelor de la diferite companii. De exemplu, puteți activa un antivirus pe firewall, dar, de asemenea, să utilizați protecția antivirus (de la un alt furnizor) local pe gazde.

Segmentare

Este vorba despre segmentarea logică a rețelei centrului de date. De exemplu, împărțirea în VLAN-uri și subrețele este, de asemenea, o segmentare logică, dar nu o vom considera din cauza evidenței sale. Interesantă este segmentarea având în vedere entități precum zonele de securitate FW, VRF (și omologii acestora în raport cu diferiți furnizori), dispozitive logice (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, …), …

Un exemplu de această segmentare logică și de design-ul cerut în prezent pentru centrul de date este prezentat în p002 proiectul PSEFABRIC.

După ce ați definit părțile logice ale rețelei dvs., puteți descrie cum se mișcă traficul între diferitele segmente, pe ce dispozitive se va realiza filtrarea și cu ce mijloace.

Dacă rețeaua dvs. nu are o împărțire logică clară și nu sunt formalizate regulile de aplicare a politicilor de securitate pentru diferitele fluxuri de date, aceasta înseamnă că la deschiderea unui anumit acces va trebui să rezolvați această problemă, iar cu o mare probabilitate o veți rezolva de fiecare dată diferit.

Adesea, segmentarea se bazează doar pe zonele de securitate FW. Atunci, trebuie să răspundeți la următoarele întrebări:

ce zone de securitate aveți nevoie
ce nivel de protecție doriți să aplicați fiecărei dintre aceste zone
va fi permis traficul intra-zone în mod implicit
dacă nu, ce politici de filtrare a traficului vor fi aplicate în interiorul fiecărei zone
ce politici de filtrare a traficului vor fi aplicate pentru fiecare pereche de zone (sursă/destinație)

TCAM

O problemă frecvent întâlnită este insuficiența TCAM (Ternary Content Addressable Memory), atât pentru rutare, cât și pentru acces. În opinia mea, aceasta este una dintre cele mai importante aspecte în alegerea echipamentului, așadar trebuie abordată cu atenția cuvenită.

Exemplul 1. Tabelul de Rutare TCAM.
Să analizăm Palo Alto 7k firewall.
Observăm că dimensiunea tabelului de rutare IPv4* = 32K
Acest număr de rute este total pentru toate VSYS-urile.
Să presupunem că, conform designului dvs., ați decis să utilizați 4 VSYS-uri.
Fiecare dintre aceste VSYS-uri este conectat prin BGP la două PE ale rețelei MPLS, pe care o folosiți ca BB. Astfel, cele 4 VSYS-uri schimbă toate rutele specifice între ele și au un tabel de rutare cu seturi aproximativ identice de rute (dar NH diferite). Deoarece fiecare VSYS are 2 sesiuni BGP (cu setări identice), fiecare rută obținută prin MPLS are 2 NH și, prin urmare, 2 înregistrări FIB în Tabelul de Rutare. Dacă presupunem că acesta este singurul firewall din data center și că trebuie să cunoască toate rutele, atunci asta ar însemna că numărul total de rute din data center-ul nostru nu poate depăși 32K/(4 * 2) = 4K.
Acum, dacă presupunem că avem 2 data centere (cu același design) și dorim să folosim VLAN-uri "extinse" între data centere (de exemplu, pentru vMotion), pentru a rezolva problema rutării, trebuie să folosim rute gazdă. Dar asta înseamnă că în cele 2 data centere nu vor fi mai mult de 4096 de gazde posibile și, desigur, acesta ar putea fi un număr insuficient.

Exemplul 2. ACL TCAM.
Dacă intenționați să filtrați traficul pe comutatoarele L3 (sau alte soluții care utilizează comutatoare L3, de exemplu, Cisco ACI), atunci când alegeți echipamentul, trebuie să acordați atenție TCAM-ului ACL.
Să presupunem că doriți să controlați accesul pe interfețele SVI ale Cisco Catalyst 4500. Atunci, așa cum se poate observa din acestui articol, pentru a controla traficul de ieșire (la fel ca și traficul de intrare) pe interfețe, puteți folosi doar 4096 de linii TCAM. Ceea ce, folosind TCAM3, vă va oferi aproximativ 4000 de ACE (linii ACL).

În cazul în care te confrunți cu o problemă de insuficiență TCAM, în primul rând, trebuie să iei în considerare optimizarea. De exemplu, în cazul unei probleme cu dimensiunea Tabelei de Înaintare, ar trebui să te gândești la agregarea rutelor. Dacă există o problemă cu dimensiunea TCAM pentru accesuri - auditul accesurilor, eliminarea înregistrărilor învechite și suprapuse, precum și, poate, reconsiderarea procedurii de deschidere a accesurilor (aceasta va fi detaliat în capitolul dedicat auditului accesurilor).

Disponibilitate ridicată

Întrebarea este dacă să folosești HA pentru firewall-uri sau să configurezi «paralel» două unități independente și, în cazul în care una dintre ele cedează, să dirijezi traficul prin a doua?

Se pare că răspunsul este evident – folosește HA. Motivul pentru care această întrebare apare totuși se datorează faptului că, din păcate, teoreticele și promoționalele 99 și câteva zecimale procente de disponibilitate se dovedesc, în practică, a fi departe de a fi atât de optimiste. HA este un lucru logic suficient de complex, și pe diverse echipamente și cu diferiți furnizori (nu au fost excepții) am interceptat probleme, bug-uri și opriri ale serviciului.

În cazul utilizării HA, vei avea posibilitatea de a opri noduri individuale, comutând între ele fără a opri serviciul, ceea ce este important, de exemplu, în timpul actualizărilor, dar în același timp există o probabilitate semnificativă ca ambele noduri să se defecteze simultan, precum și că următoarea actualizare nu va decurge la fel de ușor cum promite furnizorul (această problemă poate fi evitată dacă ai posibilitatea de a testa actualizarea pe echipamente de laborator).

Dacă nu folosești HA, atunci din punctul de vedere al dublei defecțiuni, riscurile tale sunt semnificativ mai mici (deoarece ai 2 firewall-uri independente), dar, deoarece sesiunile nu sunt sincronizate, de fiecare dată când se va face comutarea între aceste firewall-uri, vei pierde trafic. Poate fi folosit firewalling fără stare, dar atunci sensul utilizării unui firewall se pierde în mare parte.

Prin urmare, dacă în urma auditului ai descoperit firewall-uri izolate și te gândești la îmbunătățirea fiabilității rețelei tale, atunci HA este, desigur, una dintre soluțiile recomandate, dar trebuie să iei în considerare și dezavantajele asociate acestui abordare și, poate, pentru rețeaua ta o soluție diferită ar fi mai potrivită.

Confort în gestionare (managability)

Practic, HA se referă și la gestionabilitate. În loc să configurați separat două dispozitive și să rezolvați problema sincronizării configurațiilor, le gestionați astfel încât să fie ca și cum ați avea un singur dispozitiv.

Dar, poate aveți multe centre de date și multe firewall-uri, iar atunci această problemă devine de un alt nivel. Și problema nu este doar legată de configurare, ci și de