Aquest article és el tercer d'una sèrie d'articles "Com prendre el control de la vostra infraestructura de xarxa". Es pot trobar el contingut de tots els articles de la sèrie i els enllaços .
No té sentit parlar d'eliminar completament els riscos de seguretat. En principi, no els podem reduir a zero. També hem d'entendre que a mesura que ens esforcem per fer que la xarxa sigui cada cop més segura, les nostres solucions s'encareixen. Heu de trobar una compensació entre el cost, la complexitat i la seguretat que tingui sentit per a la vostra xarxa.
Per descomptat, el disseny de seguretat s'integra orgànicament a l'arquitectura global i les solucions de seguretat utilitzades afecten l'escalabilitat, la fiabilitat, la maneigabilitat,... de la infraestructura de xarxa, cosa que també s'ha de tenir en compte.
Però deixeu-me recordar que ara no estem parlant de crear una xarxa. Segons el nostre ja hem escollit el disseny, seleccionat l'equipament i creat la infraestructura, i en aquesta etapa, si és possible, hauríem de "viure" i trobar solucions en el context de l'enfocament escollit anteriorment.
La nostra tasca ara és identificar els riscos associats a la seguretat a nivell de xarxa i reduir-los a un nivell raonable.
Auditoria de seguretat de la xarxa
Si la vostra organització ha implementat processos ISO 27k, les auditories de seguretat i els canvis de xarxa haurien d'encaixar perfectament en els processos generals d'aquest enfocament. Però aquests estàndards encara no parlen de solucions específiques, ni de configuració, ni de disseny... No hi ha consells clars, ni estàndards que dictin amb detall com hauria de ser la teva xarxa, aquesta és la complexitat i la bellesa d'aquesta tasca.
Destacaria diverses possibles auditories de seguretat de la xarxa:
- auditoria de configuració de l'equip (enduriment)
- auditoria de disseny de seguretat
- auditoria d'accés
- auditoria de processos
Auditoria de configuració d'equips (enduriment)
Sembla que en la majoria dels casos aquest és el millor punt de partida per auditar i millorar la seguretat de la vostra xarxa. IMHO, aquesta és una bona demostració de la llei de Pareto (el 20% de l'esforç produeix el 80% del resultat, i el 80% restant només produeix el 20% del resultat).
La conclusió és que normalment tenim recomanacions dels venedors sobre les "millors pràctiques" per a la seguretat a l'hora de configurar l'equip. Això s'anomena "enduriment".
També pots trobar sovint un qüestionari (o crear-ne un tu mateix) basat en aquestes recomanacions, que t'ajudarà a determinar si la configuració del teu equip compleix aquestes "pràctiques recomanades" i, d'acord amb el resultat, fer canvis a la teva xarxa. . Això us permetrà reduir significativament els riscos de seguretat amb força facilitat, pràcticament sense cap cost.
Diversos exemples per a alguns sistemes operatius de Cisco.
A partir d'aquests documents, es pot crear una llista de requisits de configuració per a cada tipus d'equip. Per exemple, per a un Cisco N7K VDC aquests requisits podrien semblar .
D'aquesta manera, es poden crear fitxers de configuració per a diferents tipus d'equips actius a la vostra infraestructura de xarxa. A continuació, manualment o mitjançant l'automatització, podeu "carregar" aquests fitxers de configuració. Com automatitzar aquest procés s'explicarà detalladament en una altra sèrie d'articles sobre orquestració i automatització.
Auditoria de disseny de seguretat
Normalment, una xarxa empresarial conté els segments següents d'una forma o una altra:
- DC (Serveis públics DMZ i centre de dades Intranet)
- Accés a internet
- VPN d'accés remot
- Vora WAN
- Branca
- Campus (oficina)
- Nucli
Títols extrets de model, però no cal, per descomptat, adjuntar-se precisament a aquests noms i a aquest model. Tot i així, vull parlar de l'essència i no embussar-me en tràmits.
Per a cadascun d'aquests segments, els requisits de seguretat, els riscos i, en conseqüència, les solucions seran diferents.
Vegem cadascun d'ells per separat per conèixer els problemes que us podeu trobar des del punt de vista del disseny de seguretat. Per descomptat, torno a repetir que en cap cas aquest article pretén ser complet, cosa que no és fàcil (si no impossible) d'aconseguir en aquest tema realment profund i polièdric, però reflecteix la meva experiència personal.
No hi ha una solució perfecta (almenys encara no). Sempre és un compromís. Però és important que la decisió d'utilitzar un enfocament o un altre es prengui de manera conscient, amb una comprensió dels seus pros i contres.
Data Center
El segment més crític des del punt de vista de la seguretat.
I, com és habitual, aquí tampoc no hi ha una solució universal. Tot depèn en gran mesura dels requisits de la xarxa.
És necessari o no un tallafoc?
Sembla que la resposta és òbvia, però no tot és tan clar com podria semblar. I la vostra elecció no només es pot influir preu.
Exemple 1. Retards.
Si la baixa latència és un requisit essencial entre alguns segments de xarxa, que és, per exemple, cert en el cas d'un intercanvi, aleshores no podrem utilitzar tallafocs entre aquests segments. És difícil trobar estudis sobre la latència als tallafocs, però pocs models de commutador poden proporcionar una latència inferior o de l'ordre d'1 mksec, així que crec que si els microsegons són importants per a vostè, els tallafocs no són per a vostè.
Exemple 2. Actuació.
El rendiment dels commutadors L3 superiors sol ser un ordre de magnitud superior al rendiment dels tallafocs més potents. Per tant, en el cas del trànsit d'alta intensitat, també molt probablement haureu de permetre que aquest trànsit passi per alt els tallafocs.
Exemple 3. Fiabilitat
Els tallafocs, especialment els moderns NGFW (Next-Generation FW) són dispositius complexos. Són molt més complexos que els interruptors L3/L2. Ofereixen un gran nombre de serveis i opcions de configuració, per la qual cosa no és estrany que la seva fiabilitat sigui molt menor. Si la continuïtat del servei és fonamental per a la xarxa, és possible que hàgiu de triar què us conduirà a una millor disponibilitat: seguretat amb un tallafoc o la simplicitat d'una xarxa basada en commutadors (o diversos tipus de teixits) amb ACL normals.
En el cas dels exemples anteriors, el més probable és que (com és habitual) haureu de trobar un compromís. Mireu les solucions següents:
- si decidiu no utilitzar tallafocs dins del centre de dades, haureu de pensar com limitar l'accés al perímetre tant com sigui possible. Per exemple, només podeu obrir els ports necessaris des d'Internet (per al trànsit de clients) i l'accés administratiu al centre de dades només des d'amfitrions de salt. En els hosts de salt, feu totes les comprovacions necessàries (autenticació/autorització, antivirus, registre, ...)
- podeu utilitzar una partició lògica de la xarxa del centre de dades en segments, similar a l'esquema descrit a PSEFABRIC . En aquest cas, l'encaminament s'ha de configurar de manera que el trànsit sensible al retard o d'alta intensitat vagi "dins" d'un segment (en el cas de p002, VRF) i no passi pel tallafoc. El trànsit entre diferents segments continuarà passant pel tallafoc. També podeu utilitzar la filtració de rutes entre VRF per evitar redirigir el trànsit a través del tallafoc
- També podeu utilitzar un tallafoc en mode transparent i només per a aquelles VLAN on aquests factors (latència/rendiment) no siguin significatius. Però cal estudiar acuradament les restriccions associades a l'ús d'aquest mod per a cada venedor
- és possible que vulgueu considerar l'ús d'una arquitectura de cadena de serveis. Això permetrà que només el trànsit necessari passi pel tallafoc. En teoria sembla bé, però mai he vist aquesta solució en producció. Vam provar la cadena de servei per a Cisco ACI/Juniper SRX/F5 LTM fa uns 3 anys, però en aquell moment aquesta solució ens semblava "cruda".
Nivell de protecció
Ara heu de respondre a la pregunta de quines eines voleu utilitzar per filtrar el trànsit. Aquestes són algunes de les característiques que solen estar presents a NGFW (per exemple, ):
- tallafocs amb estat (per defecte)
- tallafocs d'aplicacions
- prevenció d'amenaces (antivirus, antispyware i vulnerabilitats)
- Filtrat d'URL
- filtrat de dades (filtrat de contingut)
- bloqueig de fitxers (bloqueig de tipus de fitxers)
- dos protecció
I tampoc tot està clar. Sembla que com més alt sigui el nivell de protecció, millor. Però també cal tenir-ho en compte
- Com més de les funcions del tallafoc anteriors utilitzeu, més car serà naturalment (llicències, mòduls addicionals)
- l'ús d'alguns algorismes pot reduir significativament el rendiment del tallafoc i també augmentar els retards, vegeu per exemple
- com qualsevol solució complexa, l'ús de mètodes de protecció complexos pot reduir la fiabilitat de la vostra solució, per exemple, quan utilitzeu el tallafoc d'aplicacions, em vaig trobar amb el bloqueig d'algunes aplicacions de treball bastant estàndard (dns, smb)
Com sempre, heu de trobar la millor solució per a la vostra xarxa.
És impossible respondre definitivament a la pregunta de quines funcions de protecció es poden requerir. En primer lloc, perquè, per descomptat, depèn de les dades que esteu transmetent o emmagatzemant i que intenteu protegir. En segon lloc, en realitat, sovint l'elecció d'eines de seguretat és una qüestió de fe i confiança en el venedor. No coneixeu els algorismes, no saps l'eficàcia que són i no els pots provar completament.
Per tant, en segments crítics, una bona solució pot ser utilitzar ofertes de diferents empreses. Per exemple, podeu activar l'antivirus al tallafoc, però també utilitzar la protecció antivirus (d'un altre fabricant) localment als amfitrions.
Segmentació
Estem parlant de la segmentació lògica de la xarxa del centre de dades. Per exemple, la partició en VLAN i subxarxes també és una segmentació lògica, però no la tindrem en compte per la seva obvietat. Segmentació interessant tenint en compte entitats com zones de seguretat de FW, VRF (i els seus anàlegs en relació amb diversos proveïdors), dispositius lògics (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Es dóna un exemple d'aquesta segmentació lògica i el disseny del centre de dades demanat actualment .
Després d'haver definit les parts lògiques de la vostra xarxa, podeu descriure com es mou el trànsit entre diferents segments, en quins dispositius es realitzarà el filtratge i amb quins mitjans.
Si la vostra xarxa no té una partició lògica clara i les regles d'aplicació de polítiques de seguretat per a diferents fluxos de dades no estan formalitzades, això vol dir que quan obriu aquest o aquell accés, esteu obligats a resoldre aquest problema, i amb molta probabilitat us ho solucionarà cada cop de manera diferent.
Sovint, la segmentació es basa només en zones de seguretat de FW. Aleshores heu de respondre les preguntes següents:
- quines zones de seguretat necessites
- quin nivell de protecció voleu aplicar a cadascuna d'aquestes zones
- es permetrà el trànsit dins de la zona per defecte?
- si no, quines polítiques de filtratge de trànsit s'aplicaran dins de cada zona
- quines polítiques de filtratge de trànsit s'aplicaran a cada parell de zones (font/destinació)
TCAM
Un problema comú és la manca de TCAM (Ternary Content Addressable Memory), tant per a l'encaminament com per als accessos. IMHO, aquest és un dels problemes més importants a l'hora d'escollir l'equip, de manera que cal tractar aquest problema amb el grau de cura adequat.
Exemple 1. Taula de reenviament TCAM.
Mirem tallafoc
Veiem que la mida de la taula de reenviament IPv4* = 32K
A més, aquest nombre de rutes és comú per a tots els VSYS.Suposem que, segons el vostre disseny, decidiu utilitzar 4 VSYS.
Cadascun d'aquests VSYS està connectat mitjançant BGP a dos PE MPLS del núvol que utilitzeu com a BB. Així, 4 VSYS intercanvien totes les rutes específiques entre si i tenen una taula de reenviament amb aproximadament els mateixos conjunts de rutes (però diferents NH). Perquè cada VSYS té 2 sessions BGP (amb la mateixa configuració), llavors cada ruta rebuda mitjançant MPLS té 2 NH i, en conseqüència, 2 entrades FIB a la Taula de reenviament. Si suposem que aquest és l'únic tallafoc del centre de dades i ha de conèixer totes les rutes, això significarà que el nombre total de rutes al nostre centre de dades no pot ser superior a 32K/(4 * 2) = 4K.Ara, si suposem que tenim 2 centres de dades (amb el mateix disseny) i volem utilitzar VLAN "estires" entre centres de dades (per exemple, per a vMotion), aleshores, per resoldre el problema d'encaminament, hem d'utilitzar rutes d'amfitrió. . Però això vol dir que per a 2 centres de dades no tindrem més de 4096 hosts possibles i, per descomptat, això potser no serà suficient.
Exemple 2. ACL TCAM.
Si teniu previst filtrar el trànsit als commutadors L3 (o altres solucions que utilitzen commutadors L3, per exemple, Cisco ACI), a l'hora de triar l'equip haureu de prestar atenció a l'ACL TCAM.
Suposem que voleu controlar l'accés a les interfícies SVI del Cisco Catalyst 4500. Aleshores, com es pot veure a , per controlar el trànsit de sortida (així com d'entrant) a les interfícies, només podeu utilitzar 4096 línies TCAM. Que quan utilitzeu TCAM3 us donarà uns 4000 mil ACE (línies ACL).
Si us enfronteu al problema d'una TCAM insuficient, primer de tot, per descomptat, heu de considerar la possibilitat d'optimitzar-lo. Per tant, en cas d'un problema amb la mida de la taula de reenviament, cal considerar la possibilitat d'agregar rutes. En cas d'un problema amb la mida TCAM per als accessos, auditar els accessos, eliminar els registres obsolets i superposats i, possiblement, revisar el procediment d'obertura d'accessos (es tractarà amb detall al capítol d'auditoria d'accessos).
Alta disponibilitat
La pregunta és: he d'utilitzar HA per a tallafocs o instal·lar dues caixes independents "en paral·lel" i, si una d'elles falla, encaminar el trànsit per la segona?
Sembla que la resposta és òbvia: utilitzeu HA. La raó per la qual encara sorgeix aquesta pregunta és que, malauradament, els percentatges teòrics i publicitaris 99 i diversos decimals d'accessibilitat a la pràctica resulten estar lluny de ser tan roses. L'HA és lògicament una cosa força complexa, i en equips diferents i amb diferents venedors (no hi va haver excepcions), vam detectar problemes i errors i aturades de servei.
Si utilitzeu HA, tindreu l'oportunitat de desactivar nodes individuals, canviar entre ells sense aturar el servei, cosa que és important, per exemple, quan feu actualitzacions, però al mateix temps teniu una probabilitat molt lluny de zero que els dos nodes es trencarà al mateix temps, i també que la propera actualització no funcionarà tan bé com promet el venedor (aquest problema es pot evitar si teniu l'oportunitat de provar l'actualització en equips de laboratori).
Si no feu servir HA, des del punt de vista de la doble fallada, els vostres riscos són molt més baixos (ja que teniu 2 tallafocs independents), però com que... les sessions no estan sincronitzades, aleshores cada vegada que canvieu entre aquests tallafocs perdràs trànsit. Per descomptat, podeu utilitzar un tallafoc sense estat, però aleshores el punt d'utilitzar un tallafoc es perd en gran mesura.
Per tant, si com a resultat de l'auditoria heu descobert tallafocs solitaris i esteu pensant a augmentar la fiabilitat de la vostra xarxa, llavors HA, per descomptat, és una de les solucions recomanades, però també hauríeu de tenir en compte els inconvenients associats. amb aquest enfocament i, potser, específicament per a la vostra xarxa, una altra solució seria més adequada.
Manejabilitat
En principi, HA també tracta de controlabilitat. En lloc de configurar 2 caixes per separat i tractar el problema de mantenir les configuracions sincronitzades, les gestioneu com si tinguéssiu un dispositiu.
Però potser teniu molts centres de dades i molts tallafocs, llavors aquesta pregunta sorgeix a un nou nivell. I la pregunta no és només sobre la configuració, sinó també sobre
- configuracions de còpia de seguretat
- actualitzacions
- actualitzacions
- seguiment
- registre
I tot això es pot resoldre mitjançant sistemes de gestió centralitzats.
Així, per exemple, si feu servir tallafocs de Palo Alto, aleshores és una solució així.
Continuar.
Font: www.habr.com