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

Nu are rost să vorbim despre eliminarea completă a riscurilor de securitate. În principiu, nu le putem reduce la zero. De asemenea, trebuie să înțelegem că, pe măsură ce ne străduim să facem rețeaua din ce în ce mai sigură, soluțiile noastre devin din ce în ce mai scumpe. Trebuie să găsiți un compromis între cost, complexitate și securitate care să aibă sens pentru rețeaua dvs.

Desigur, designul de securitate este integrat organic în arhitectura de ansamblu, iar soluțiile de securitate utilizate afectează scalabilitatea, fiabilitatea, gestionabilitatea, ... a infrastructurii de rețea, care ar trebui să fie luate în considerare.

Dar permiteți-mi să vă reamintesc că acum nu vorbim despre crearea unei rețele. Potrivit noastre condiții inițiale am ales deja designul, am selectat echipamentul și am creat infrastructura, iar în această etapă, dacă este posibil, ar trebui să „trăim” și să găsim soluții în contextul abordării alese anterior.

Sarcina noastră acum este să identificăm riscurile asociate cu securitatea la nivel de rețea și să le reducem la un nivel rezonabil.

Auditul securității rețelei

Dacă organizația dvs. a implementat procese ISO 27k, atunci auditurile de securitate și modificările de rețea ar trebui să se încadreze perfect în procesele generale din această abordare. Dar aceste standarde încă nu sunt despre soluții specifice, nu despre configurare, nu despre design... Nu există sfaturi clare, nici standarde care să dicteze în detaliu cum ar trebui să fie rețeaua dvs., aceasta este complexitatea și frumusețea acestei sarcini.

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

• audit de configurare a echipamentelor (întărire)
• audit de proiectare de securitate
• audit de acces
• audit de proces

Auditul configurației echipamentelor (întărire)

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

Concluzia este că, de obicei, avem recomandări de la furnizori cu privire la „cele mai bune practici” pentru securitate la configurarea echipamentelor. Aceasta se numește „întărire”.

De asemenea, puteți găsi adesea un chestionar (sau să creați unul singur) pe baza acestor recomandări, care vă va ajuta să determinați cât de bine se conformează configurația echipamentului dumneavoastră cu aceste „bune practici” și, în conformitate cu rezultatul, să faceți modificări în rețeaua dvs. . Acest lucru vă va permite să reduceți semnificativ riscurile de securitate destul de ușor, practic fără costuri.

Câteva exemple pentru unele sisteme de operare Cisco.

Întărirea configurației Cisco IOS
Întărirea configurației Cisco IOS-XR
Întărirea configurației Cisco NX-OS
Listă de verificare a securității de bază Cisco

Pe baza acestor documente se poate crea o listă de cerințe de configurare pentru fiecare tip de echipament. De exemplu, pentru un Cisco N7K VDC aceste cerințe ar putea arăta astfel.

În acest fel, fișierele de configurare pot fi create pentru diferite tipuri de echipamente active din infrastructura dvs. de rețea. Apoi, manual sau folosind automatizarea, puteți „încărca” aceste fișiere de configurare. Modul de automatizare a acestui proces va fi discutat în detaliu într-o altă serie de articole despre orchestrare și automatizare.

Audit de proiectare de securitate

De obicei, o rețea de întreprindere conține următoarele segmente într-o formă sau alta:

• DC (Servicii publice DMZ și centru de date Intranet)
• Acces Internet
• VPN de acces la distanță
• Marginea WAN
• Branch firma
• Campus (birou)
• Nucleu

Titluri preluate din Cisco SAFE model, dar nu este necesar, desigur, să fie atașat tocmai acestor denumiri și acestui model. Totuși, vreau să vorbesc despre esență și să nu mă împotesc în formalități.

Pentru fiecare dintre aceste segmente, cerințele de securitate, riscurile și, în consecință, soluțiile vor fi diferite.

Să ne uităm la fiecare dintre ele separat pentru problemele pe care le puteți întâlni din punct de vedere al designului de securitate. Bineînțeles, repet că în niciun caz acest articol nu pretinde a fi complet, ceea ce nu este ușor (dacă nu imposibil) de realizat în această temă cu adevărat profundă și multifațetă, dar reflectă experiența mea personală.

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

Data Center

Segmentul cel mai critic din punct de vedere al siguranței.
Și, ca de obicei, nici aici nu există o soluție universală. Totul depinde foarte mult de cerințele rețelei.

Este necesar sau nu un firewall?

S-ar părea că răspunsul este evident, dar totul nu este chiar atât de clar pe cât ar părea. Iar alegerea ta poate fi influențată nu numai preț.

Exemplul 1. Întârzieri.

Dacă latența scăzută este o cerință esențială între unele segmente de rețea, ceea ce este, de exemplu, adevărat în cazul unui schimb, atunci nu vom putea folosi firewall-uri între aceste segmente. Este greu să găsești studii despre latența în firewall-uri, dar puține modele de switch pot oferi o latență mai mică sau de ordinul a 1 mksec, așa că cred că dacă microsecundele sunt importante pentru tine, atunci firewall-urile nu sunt pentru tine.

Exemplul 2. Performanță.

Debitul comutatoarelor L3 de top este de obicei cu un ordin de mărime mai mare decât debitul celor mai puternice firewall-uri. Prin urmare, în cazul traficului de mare intensitate, cel mai probabil va trebui să permiteți acestui trafic să ocolească firewall-urile.

Exemplul 3. Fiabilitate.

Firewall-urile, în special NGFW modern (Next-Generation FW) sunt dispozitive complexe. Sunt mult mai complexe decât comutatoarele L3/L2. Ele oferă un număr mare de servicii și opțiuni de configurare, așa că nu este de mirare că fiabilitatea lor este mult mai mică. Dacă continuitatea serviciului este esențială pentru rețea, atunci poate fi necesar să alegeți ceea ce va duce la o disponibilitate mai bună - securitate cu un firewall sau simplitatea unei rețele construite pe switch-uri (sau diferite tipuri de fabrici) folosind ACL-uri obișnuite.

În cazul exemplelor de mai sus, cel mai probabil (ca de obicei) va trebui să găsiți un compromis. Privește următoarele soluții:

• dacă decideți să nu utilizați firewall-uri în interiorul centrului de date, atunci trebuie să vă gândiți cum să limitați accesul în jurul perimetrului cât mai mult posibil. De exemplu, puteți deschide doar porturile necesare de pe Internet (pentru traficul clienților) și accesul administrativ la centrul de date numai de la gazde de salt. Pe gazdele de salt, efectuați toate verificările necesare (autentificare/autorizare, antivirus, înregistrare, ...)
• puteți utiliza o partiție logică a rețelei centrului de date în segmente, similară cu schema descrisă în PSEFABRIC exemplu p002. În acest caz, rutarea trebuie configurată astfel încât traficul sensibil la întârziere sau de mare intensitate să treacă „în cadrul” unui segment (în cazul p002, VRF) și să nu treacă prin firewall. Traficul dintre diferite segmente va continua să treacă prin firewall. De asemenea, puteți utiliza scurgerile de rute între VRF-uri pentru a evita redirecționarea traficului prin firewall
• De asemenea, puteți utiliza un firewall în modul transparent și numai pentru acele VLAN-uri în care acești factori (latență/performanță) nu sunt semnificativi. Dar trebuie să studiați cu atenție restricțiile asociate cu utilizarea acestui mod pentru fiecare furnizor
• poate doriți să luați în considerare utilizarea unei arhitecturi de lanț de servicii. Acest lucru va permite doar traficul necesar să treacă prin firewall. Arată bine în teorie, dar nu am văzut niciodată această soluție în producție. Am testat lanțul de servicii pentru Cisco ACI/Juniper SRX/F5 LTM în urmă cu aproximativ 3 ani, dar la acel moment această soluție ni se părea „brută”.

Nivel de protecție

Acum trebuie să răspundeți la întrebarea ce instrumente doriți să utilizați pentru a filtra traficul. Iată câteva dintre caracteristicile care sunt de obicei prezente în NGFW (de exemplu, aici):

• firewall cu stare (implicit)
• firewall-ul aplicației
• prevenirea amenințărilor (antivirus, anti-spyware și vulnerabilitate)
• Filtrare URL
• filtrarea datelor (filtrarea conținutului)
• blocarea fișierelor (blocarea tipurilor de fișiere)
• dos protectie

Și nici totul nu este clar. S-ar părea că cu cât este mai mare nivelul de protecție, cu atât mai bine. Dar trebuie să iei în considerare și asta

• Cu cât folosiți mai multe dintre funcțiile firewall de mai sus, cu atât va fi mai scump (licențe, module suplimentare)
• utilizarea unor algoritmi poate reduce semnificativ debitul firewall-ului și, de asemenea, poate crește întârzierile, vezi de exemplu aici
• ca orice soluție complexă, utilizarea unor metode complexe de protecție poate reduce fiabilitatea soluției dvs., de exemplu, atunci când utilizați firewall-ul aplicației, am întâlnit blocarea unor aplicații de lucru destul de standard (dns, smb)

Ca întotdeauna, trebuie să găsiți cea mai bună soluție pentru rețeaua dvs.

Este imposibil să răspundem definitiv la întrebarea ce funcții de protecție pot fi necesare. În primul rând, pentru că depinde desigur de datele pe care le transmiteți sau stocați și încercați să le protejați. În al doilea rând, în realitate, adesea alegerea instrumentelor de securitate este o chestiune de încredere și încredere în furnizor. Nu cunoașteți algoritmii, nu știți cât de eficienți sunt și nu îi puteți testa pe deplin.

Prin urmare, în segmentele critice, o soluție bună poate fi folosirea ofertelor de la diferite companii. De exemplu, puteți activa antivirus pe firewall, dar și să utilizați protecția antivirus (de la alt producător) local pe gazde.

Segmentarea

Vorbim despre segmentarea logică a rețelei de centre de date. De exemplu, partiționarea în VLAN-uri și subrețele este, de asemenea, o segmentare logică, dar nu o vom lua în considerare din cauza evidenței sale. Segmentare interesantă ținând cont de astfel de entități precum zonele de securitate FW, VRF-uri (și analogii acestora în relație cu diverși furnizori), dispozitive logice (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Un exemplu de astfel de segmentare logică și proiectarea centrului de date solicitată în prezent este dat în p002 al proiectului PSEFABRIC.

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

Dacă rețeaua dvs. nu are o partiție logică clară și regulile de aplicare a politicilor de securitate pentru diferite fluxuri de date nu sunt formalizate, aceasta înseamnă că atunci când deschideți acest sau acel acces, sunteți obligat să rezolvați această problemă și, cu o mare probabilitate, o va rezolva de fiecare dată diferit.

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

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

CECST

O problemă comună este TCAM (Ternary Content Addressable Memory) insuficientă, atât pentru rutare, cât și pentru accesări. IMHO, aceasta este una dintre cele mai importante probleme atunci când alegeți echipamentul, așa că trebuie să tratați această problemă cu gradul adecvat de grijă.

Exemplul 1. Tabel de redirecționare TCAM.

Să ne uităm la Palo Alto 7k firewall
Vedem că dimensiunea tabelului de redirecționare IPv4* = 32K
Mai mult, acest număr de rute este comun pentru toate VSYS-urile.

Să presupunem că, în funcție de designul dvs., decideți să utilizați 4 VSYS.
Fiecare dintre aceste VSYS este conectat prin BGP la două PE MPLS din cloud pe care le utilizați ca BB. Astfel, 4 VSYS schimbă toate rutele specifice între ele și au un tabel de redirecționare cu aproximativ aceleași seturi de rute (dar NH-uri diferite). Deoarece fiecare VSYS are 2 sesiuni BGP (cu aceleași setări), apoi fiecare rută primită prin MPLS are 2 NH și, în consecință, 2 intrări FIB în tabelul de redirecționare. Dacă presupunem că acesta este singurul firewall din centrul de date și trebuie să știe despre toate rutele, atunci aceasta va însemna că numărul total de rute din centrul nostru de date nu poate fi mai mare de 32K/(4 * 2) = 4K.

Acum, dacă presupunem că avem 2 centre de date (cu același design) și dorim să folosim VLAN-uri „întinse” între centre de date (de exemplu, pentru vMotion), atunci pentru a rezolva problema de rutare, trebuie să folosim rute gazdă . Dar asta înseamnă că pentru 2 centre de date nu vom avea mai mult de 4096 de gazde posibile și, desigur, acest lucru poate să nu fie suficient.

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 atunci când alegeți echipament, ar trebui să acordați atenție ACL TCAM.

Să presupunem că doriți să controlați accesul pe interfețele SVI ale Cisco Catalyst 4500. Apoi, după cum se poate vedea din din acest articol, pentru a controla traficul de ieșire (precum și de intrare) pe interfețe, puteți utiliza doar 4096 de linii TCAM. Care atunci când utilizați TCAM3 vă va oferi aproximativ 4000 de mii de ACE (linii ACL).

Dacă vă confruntați cu problema TCAM insuficientă, atunci, în primul rând, desigur, trebuie să luați în considerare posibilitatea de optimizare. Deci, în cazul unei probleme cu dimensiunea tabelului de redirecționare, trebuie să luați în considerare posibilitatea de a agrega rute. În cazul unei probleme cu dimensiunea TCAM pentru accesări, auditați accesele, eliminați înregistrările învechite și suprapuse și, eventual, revizuiți procedura de deschidere a acceselor (va fi discutată în detaliu în capitolul privind auditarea acceselor).

Valabilitate mare

Întrebarea este: ar trebui să folosesc HA pentru firewall-uri sau să instalez două casete independente „în paralel” și, dacă una dintre ele eșuează, să direcționez traficul prin a doua?

S-ar părea că răspunsul este evident - folosiți HA. Motivul pentru care încă mai apare această întrebare este că, din păcate, procentele teoretice și publicitare 99 și câteva zecimale ale accesibilității în practică se dovedesc a fi departe de a fi atât de roz. HA este, în mod logic, un lucru destul de complex, iar pe diferite echipamente și cu diferiți furnizori (nu au existat excepții), am prins probleme și bug-uri și opriri de service.

Dacă utilizați HA, veți avea ocazia să dezactivați nodurile individuale, să comutați între ele fără a opri serviciul, ceea ce este important, de exemplu, atunci când faceți upgrade, dar, în același timp, aveți o probabilitate departe de zero ca ambele noduri se va rupe în același timp și, de asemenea, că în următoarea actualizare nu va merge la fel de bine cum promite furnizorul (această problemă poate fi evitată dacă aveți ocazia să testați upgrade-ul pe echipamente de laborator).

Dacă nu folosești HA, atunci din punct de vedere al dublei eșecuri riscurile tale sunt mult mai mici (din moment ce ai 2 firewall-uri independente), dar din moment ce... sesiunile nu sunt sincronizate, atunci de fiecare dată când comutați între aceste firewall-uri veți pierde trafic. Puteți, desigur, să utilizați firewall-ul fără stat, dar atunci punctul de utilizare a unui firewall este în mare parte pierdut.

Prin urmare, dacă în urma auditului ați descoperit firewall-uri singuratice și vă gândiți să creșteți fiabilitatea rețelei dvs., atunci HA, desigur, este una dintre soluțiile recomandate, dar ar trebui să țineți cont și de dezavantajele asociate. cu această abordare și, poate, în mod specific pentru rețeaua dvs., o altă soluție ar fi mai potrivită.

Gestionabilitate

În principiu, HA este și despre controlabilitate. În loc să configurați 2 casete separat și să vă ocupați de problema menținerii configurațiilor sincronizate, le gestionați ca și cum ați avea un singur dispozitiv.

Dar poate că aveți multe centre de date și multe firewall-uri, atunci această întrebare apare la un nou nivel. Și întrebarea nu este doar despre configurare, ci și despre

• configurații de rezervă
• actualizări
• upgrade-uri
• monitorizarea
• Logare

Și toate acestea pot fi rezolvate prin sisteme de management centralizate.

Deci, de exemplu, dacă utilizați firewall-uri Palo Alto, atunci Panorama este o astfel de solutie.

Pentru a fi continuat.

Sursa: www.habr.com