{"id":31058,"date":"2019-10-31T21:39:12","date_gmt":"2019-10-31T18:39:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya\/"},"modified":"2019-10-31T21:39:12","modified_gmt":"2019-10-31T18:39:12","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","title":{"rendered":"C\u00f3mo tomar el control de la infraestructura de red. Cap\u00edtulo tercero. Seguridad de red. Parte primera","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Este art\u00edculo es el tercero en una serie titulada \u00abC\u00f3mo tomar el control de la infraestructura de red\u00bb. El contenido de todos los art\u00edculos de la serie y los enlaces se pueden encontrar <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">aqu\u00ed<\/a><\/noindex><\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"C\u00f3mo tomar el control de la infraestructura de red. Cap\u00edtulo tercero. Seguridad de red. Parte primera\" src=\"\/wp-content\/uploads\/2019\/04\/cdf33cc6797d26df8fef5533f2570c47.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo tiene sentido hablar de la eliminaci\u00f3n completa de riesgos de seguridad. En principio, no podemos reducirlos a cero. Tambi\u00e9n es importante entender que, al intentar hacer la red cada vez m\u00e1s segura, nuestras soluciones se vuelven cada vez m\u00e1s costosas. Es necesario encontrar un compromiso razonable para su red entre el precio, la complejidad y la seguridad. <\/p>\n<p>Por supuesto, el dise\u00f1o de la seguridad est\u00e1 org\u00e1nicamente integrado en la arquitectura general y las soluciones de seguridad utilizadas influyen en la escalabilidad, fiabilidad, gestionabilidad, \u2026 de la infraestructura de red, lo cual tambi\u00e9n debe ser considerado.<\/p>\n<p>Sin embargo, debo recordar que ahora no estamos hablando de construir una red. De acuerdo con nuestras <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/433614\/\">condiciones iniciales<\/a><\/noindex> ya tenemos el dise\u00f1o seleccionado, el equipo elegido y la infraestructura creada, y en esta etapa debemos, en la medida de lo posible, \u00abvivir\u00bb y encontrar soluciones en el contexto del enfoque elegido previamente.<\/p>\n<p>Nuestra tarea ahora es identificar los riesgos relacionados con la seguridad a nivel de red y reducirlos a un nivel razonable. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Auditor\u00eda de seguridad de red<\/h1>\n<p>\nSi en su organizaci\u00f3n se han implementado procesos ISO 27k, la auditor\u00eda de seguridad y los cambios en la red deben integrarse armoniosamente en los procesos generales dentro de este enfoque. Pero estas normas no se refieren espec\u00edficamente a soluciones concretas, no a configuraciones, no a dise\u00f1os\u2026 No hay consejos inequ\u00edvocos, no hay normas que dicten en detalle c\u00f3mo debe ser su red, en eso radica la complejidad y la belleza de esta tarea.<\/p>\n<p>Destacar\u00eda algunas posibles auditor\u00edas de seguridad de red:<\/p>\n<ul>\n<li>auditor\u00eda de configuraci\u00f3n del equipo (hardening)<\/li>\n<li>auditor\u00eda del dise\u00f1o de seguridad<\/li>\n<li>auditor\u00eda de accesos<\/li>\n<li>auditor\u00eda de procesos<\/li>\n<\/ul>\n<p><\/p>\n<h1>Auditor\u00eda de configuraci\u00f3n de hardware (hardening)<\/h1>\n<p>\nParece que en la mayor\u00eda de los casos este es el mejor punto de partida para auditar y mejorar la seguridad de su red. IMHO, es una buena demostraci\u00f3n de la ley de Pareto (el 20 % de los esfuerzos da el 80 % de los resultados, mientras que el 80 % restante de los esfuerzos solo da el 20 % del resultado). <\/p>\n<p>La esencia es que normalmente tenemos recomendaciones de proveedores sobre las \u00abmejores pr\u00e1cticas\u00bb de seguridad al configurar el equipo. Esto se llama \u201chardening\u201d.<\/p>\n<p>Tambi\u00e9n se puede encontrar un cuestionario (o elaborarlo uno mismo) basado en estas recomendaciones, que te ayudar\u00e1 a determinar qu\u00e9 tan bien la configuraci\u00f3n de tu hardware se alinea con estas \"mejores pr\u00e1cticas\" y, seg\u00fan los resultados, realizar cambios en tu red. Esto te permitir\u00e1 reducir significativamente los riesgos de seguridad de manera bastante f\u00e1cil y pr\u00e1cticamente sin costos.<\/p>\n<blockquote><p>Algunos ejemplos para ciertos sistemas operativos de Cisco.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/support\/docs\/ip\/access-lists\/13608-21.html\">Fortalecimiento de la Configuraci\u00f3n de Cisco IOS<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.cisco.com\/security\/center\/resources\/increase_security_ios_xr_devices.html\">Fortalecimiento de la Configuraci\u00f3n de Cisco IOS-XR<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.cisco.com\/security\/center\/resources\/securing_nx_os.html\">Fortalecimiento de la Configuraci\u00f3n de Cisco NX-OS<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/solutions\/Enterprise\/Security\/Baseline_Security\/securebasebook\/appendxD.html\">Lista de Verificaci\u00f3n de Seguridad Baseline de Cisco<\/a><\/noindex><\/p>\n<p>A partir de estos documentos, se puede crear una lista de requisitos de configuraci\u00f3n para cada tipo de hardware. Por ejemplo, para el Cisco N7K VDC, estos requisitos podr\u00edan ser <noindex><a rel=\"nofollow\" href=\"https:\/\/www.dropbox.com\/s\/hnat6yriyptigzb\/7k_hard.xlsx?dl=0\">as\u00ed<\/a><\/noindex>.<\/p><\/blockquote>\n<p>\nDe este modo, se pueden crear archivos de configuraci\u00f3n para diferentes tipos de hardware activo en tu infraestructura de red. Luego, manualmente o utilizando automatizaci\u00f3n, puedes \"cargar\" estos archivos de configuraci\u00f3n. C\u00f3mo automatizar este proceso se tratar\u00e1 en otra serie de art\u00edculos dedicados a la orquestaci\u00f3n y automatizaci\u00f3n.<\/p>\n<h1>Auditor\u00eda del dise\u00f1o de seguridad<\/h1>\n<p>\nNormalmente, en la red de una empresa (enterprise network), de alguna manera, est\u00e1n presentes los siguientes segmentos: <\/p>\n<ul>\n<li>DC (Servicios p\u00fablicos DMZ y centro de datos Intranet)<\/li>\n<li>Acceso a Internet<\/li>\n<li>VPN de acceso remoto<\/li>\n<li>WAN edge<\/li>\n<li>Sucursal<\/li>\n<li>Campus (Oficina)<\/li>\n<li>Core<\/li>\n<\/ul>\n<p>\nLos nombres se tomaron de <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/solutions\/Enterprise\/Security\/SAFE_RG\/SAFE_rg\/chap1.html\">modelo:<\/a><\/noindex> modelos, pero por supuesto no es necesario atenerse a esos nombres y a este modelo. Al final, es importante hablar de la esencia y no quedar atrapado en formalidades.<\/p>\n<p>Para cada uno de estos segmentos, los requisitos de seguridad, riesgos y, en consecuencia, las soluciones ser\u00e1n diferentes.<\/p>\n<p>Analicemos cada uno de ellos por separado para identificar problemas que puedas enfrentar desde el punto de vista del dise\u00f1o de seguridad. Por supuesto, reitero nuevamente que este art\u00edculo no pretende ser exhaustivo, alcanzar lo cual en este tema realmente profundo y multifac\u00e9tico es complicado (si es que es posible), pero refleja mi experiencia personal.<\/p>\n<p>No existe una soluci\u00f3n perfecta (al menos no en este momento). Siempre es un compromiso. Pero es importante que la decisi\u00f3n de aplicar un enfoque u otro se tome de manera consciente, entendiendo tanto sus ventajas como sus desventajas.<\/p>\n<h2>Centro de Datos<\/h2>\n<p>\nEl segmento m\u00e1s cr\u00edtico desde el punto de vista de la seguridad.<br \/>\nY, como de costumbre, aqu\u00ed tampoco hay una soluci\u00f3n universal. Todo depende en gran medida de los requisitos de la red. <\/p>\n<h3>\u00bfSe necesita un firewall?<\/h3>\n<p>\nParece que la respuesta es obvia, pero no es tan sencilla como podr\u00eda parecer. Y tu elecci\u00f3n puede verse influenciada no solo por<b> precio<\/b>. <\/p>\n<blockquote><p>Ejemplo 1. <b>Retrasos.<\/b><\/p>\n<p>Si entre algunos segmentos de la red se requiere una baja latencia, lo cual es cierto, por ejemplo, en el caso de una bolsa de valores, entonces no podremos usar cortafuegos entre esos segmentos. Es dif\u00edcil encontrar investigaciones sobre la latencia en cortafuegos, pero solo unos pocos modelos de conmutadores pueden proporcionar latencias de menos de 1 mksec, as\u00ed que creo que si los microsegundos son importantes para ti, los cortafuegos no son la opci\u00f3n adecuada.<\/p><\/blockquote>\n<blockquote><p>Ejemplo 2. <b>Rendimiento.<\/b><\/p>\n<p>El ancho de banda de los mejores conmutadores L3 suele ser significativamente superior al de los cortafuegos m\u00e1s eficientes. Por lo tanto, en el caso de tr\u00e1fico de alta intensidad, probablemente tendr\u00e1s que redirigir ese tr\u00e1fico alrededor de los cortafuegos.<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>Ejemplo 3. <b>Confiabilidad.<\/b><\/p>\n<p>Los cortafuegos, especialmente los NGFW modernos (Next-Generation FW), son dispositivos complejos. Son significativamente m\u00e1s complejos que los conmutadores L3\/L2. Ofrecen una gran cantidad de servicios y opciones de configuraci\u00f3n, por lo que no es sorprendente que su fiabilidad sea considerablemente menor. Si la continuidad del servicio es cr\u00edtica para la red, es posible que debas elegir entre lo que proporcionar\u00e1 mejor disponibilidad: la protecci\u00f3n con un cortafuegos o la simplicidad de una red construida sobre conmutadores (o diversos tipos de f\u00e1bricas) utilizando ACL comunes.<\/p><\/blockquote>\n<p> En los ejemplos mencionados anteriormente, seguramente (como es habitual) tendr\u00e1s que encontrar un compromiso. Considera las siguientes soluciones: <\/p>\n<ul>\n<li>si decides no usar cortafuegos dentro del centro de datos, debes pensar en c\u00f3mo limitar al m\u00e1ximo los accesos por el per\u00edmetro. Por ejemplo, puedes abrir solo los puertos necesarios desde Internet (para el tr\u00e1fico de clientes) y los accesos administrativos al centro de datos solo desde hosts de salto. En los hosts de salto, realiza toda la verificaci\u00f3n necesaria (autenticaci\u00f3n\/autorizaci\u00f3n, antivirus, registro, ...)<\/li>\n<li>puedes utilizar la segmentaci\u00f3n l\u00f3gica de la red del centro de datos en segmentos, similar al esquema descrito en PSEFABRIC <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nihole\/PSEFABRIC\/wiki\/p002-design\">ejemplo p002<\/a><\/noindex>La configuraci\u00f3n de enrutamiento debe estar dise\u00f1ada de manera que el tr\u00e1fico sensible a la latencia o de alta intensidad circule \"dentro\" de un solo segmento (en el caso de p002, del VRF) y no pase a trav\u00e9s del firewall. Sin embargo, el tr\u00e1fico entre diferentes segmentos seguir\u00e1 pasando a trav\u00e9s del firewall. Tambi\u00e9n se puede utilizar el route leaking entre VRFs para evitar el redireccionamiento del tr\u00e1fico a trav\u00e9s del firewall.<\/li>\n<li>Tambi\u00e9n se puede usar el firewall en modo transparente y solo para aquellas VLAN donde estos factores (latencia\/rendimiento) no son significativos. Pero es importante estudiar atentamente las limitaciones asociadas con el uso de este modo para cada proveedor.<\/li>\n<li>Puede considerar aplicar una arquitectura de service chain. Esto permitir\u00e1 dirigir solo el tr\u00e1fico necesario a trav\u00e9s del firewall. Te\u00f3ricamente suena bien, pero nunca he visto esta soluci\u00f3n en producci\u00f3n. Probatamos service chain para Cisco ACI\/Juniper SRX\/F5 LTM hace aproximadamente 3 a\u00f1os, pero en ese momento esta soluci\u00f3n nos pareci\u00f3 \"inmadura\".<\/li>\n<\/ul>\n<p><\/p>\n<h3>Nivel de protecci\u00f3n<\/h3>\n<p>\nAhora es necesario responder a la pregunta, qu\u00e9 herramientas desea aplicar para la filtraci\u00f3n de tr\u00e1fico. Aqu\u00ed hay algunas de las capacidades que generalmente se encuentran en un NGFW (por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.paloaltonetworks.com\/pan-os\/8-0\/pan-os-admin\/policy\/security-profiles.html\">aqu\u00ed<\/a><\/noindex>):<\/p>\n<ul>\n<li>firewalling stateful (por defecto)<\/li>\n<li>firewalling de aplicaciones<\/li>\n<li>prevenci\u00f3n de amenazas (antivirus, anti-spyware y vulnerabilidades)<\/li>\n<li>filtrado de URL<\/li>\n<li>filtrado de datos (filtrado de contenido)<\/li>\n<li>bloqueo de archivos (bloqueo de tipos de archivos)<\/li>\n<li>protecci\u00f3n dos<\/li>\n<\/ul>\n<p>\nY tampoco es todo tan claro. Aparentemente, cuanto mayor es el nivel de protecci\u00f3n, mejor. Pero tambi\u00e9n necesita considerar que<\/p>\n<ul>\n<li>cuantas m\u00e1s de las funciones mencionadas del firewall use, naturalmente ser\u00e1 m\u00e1s caro (licencias, m\u00f3dulos adicionales).<\/li>\n<li>El uso de ciertos algoritmos puede reducir significativamente el ancho de banda del firewall y aumentar la latencia, v\u00e9ase por ejemplo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.paloaltonetworks.com\/products\/secure-the-network\/next-generation-firewall\/pa-7000-series\">aqu\u00ed<\/a><\/noindex><\/li>\n<li>Como cualquier soluci\u00f3n compleja, el uso de m\u00e9todos de protecci\u00f3n complicados puede reducir la fiabilidad de su soluci\u00f3n; por ejemplo, al utilizar firewall de aplicaciones, me he encontrado con el bloqueo de algunas aplicaciones que funcionan de manera bastante est\u00e1ndar (DNS, SMB).<\/li>\n<\/ul>\n<p>\nComo siempre, debe encontrar la soluci\u00f3n \u00f3ptima para su red.<\/p>\n<p>No se puede responder de manera definitiva a la pregunta de qu\u00e9 funciones de protecci\u00f3n pueden ser necesarias. En primer lugar, porque depende de los datos que transmite o almacena y est\u00e1 intentando proteger. En segundo lugar, en realidad, a menudo la elecci\u00f3n de los medios de protecci\u00f3n es una cuesti\u00f3n de fe y confianza en el proveedor. No conoce los algoritmos, no sabe cu\u00e1n efectivos son y no puede probarlos completamente. <\/p>\n<p>Por lo tanto, en segmentos cr\u00edticos, una buena soluci\u00f3n puede ser utilizar ofertas de diferentes compa\u00f1\u00edas. Por ejemplo, puede habilitar antivirus en el firewall, pero tambi\u00e9n usar protecci\u00f3n antivirus (de otro fabricante) localmente en los hosts.<\/p>\n<h3>Segmentaci\u00f3n<\/h3>\n<p>\nSe trata de la segmentaci\u00f3n l\u00f3gica de la red del centro de datos. Por ejemplo, dividir en VLAN y subredes tambi\u00e9n es segmentaci\u00f3n l\u00f3gica, pero no la consideraremos por su obviedad. Nos interesa la segmentaci\u00f3n teniendo en cuenta entidades como zonas de seguridad FW, VRF (y sus an\u00e1logos aplicables a diferentes proveedores), dispositivos l\u00f3gicos (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, \u2026), \u2026<\/p>\n<blockquote><p>Un ejemplo de tal segmentaci\u00f3n l\u00f3gica y un dise\u00f1o actualmente demandado de centro de datos se presenta en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/nihole\/PSEFABRIC\/wiki\/p002-design\">p002 del proyecto PSEFABRIC<\/a><\/noindex>.<\/p><\/blockquote>\n<p> Al definir las partes l\u00f3gicas de su red, puede describir c\u00f3mo se mueve el tr\u00e1fico entre diferentes segmentos, en qu\u00e9 dispositivos se realizar\u00e1 la filtraci\u00f3n y con qu\u00e9 herramientas.<\/p>\n<p>Si su red carece de una clara divisi\u00f3n l\u00f3gica y no se han formalizado las reglas para la aplicaci\u00f3n de pol\u00edticas de seguridad para diferentes flujos de datos, entonces significa que al abrir un acceso determinado deber\u00e1 enfrentar esta tarea, y con alta probabilidad lo resolver\u00e1 de manera diferente cada vez. <\/p>\n<p>A menudo, la segmentaci\u00f3n se basa \u00fanicamente en zonas de seguridad FW. Entonces, necesita responder las siguientes preguntas:<\/p>\n<ul>\n<li>\u00bfQu\u00e9 zonas de seguridad necesita?<\/li>\n<li>\u00bfQu\u00e9 nivel de protecci\u00f3n desea aplicar a cada una de estas zonas? <\/li>\n<li>\u00bfSe permitir\u00e1 el tr\u00e1fico intra-zona por defecto? <\/li>\n<li>Si no, \u00bfqu\u00e9 pol\u00edticas de filtraci\u00f3n de tr\u00e1fico se aplicar\u00e1n dentro de cada una de las zonas?<\/li>\n<li>\u00bfQu\u00e9 pol\u00edticas de filtraci\u00f3n de tr\u00e1fico se aplicar\u00e1n para cada par de zonas (source\/destination)?<\/li>\n<\/ul>\n<p><\/p>\n<h3>TCAM<\/h3>\n<p>\nA menudo se presenta el problema de la insuficiencia de TCAM (Ternary Content Addressable Memory), tanto para el enrutamiento como para los accesos. IMHO, esta es una de las cuestiones m\u00e1s importantes al elegir hardware, por lo que se debe tratar este asunto con el debido cuidado.<\/p>\n<blockquote><p>Ejemplo 1. TCAM de tabla de reenv\u00edo.<\/p>\n<p>Examinemos <noindex>Palo Alto 7k<\/noindex> firewall.<br \/>\nVemos que el tama\u00f1o de la tabla de reenv\u00edo IPv4* = 32K<br \/>\nEste n\u00famero de rutas es total para todos los VSYS.<\/p>\n<p>Supongamos que, de acuerdo con su dise\u00f1o, decidi\u00f3 utilizar 4 VSYS.<br \/>\nCada uno de estos VSYS est\u00e1 conectado a dos PE de la nube MPLS mediante BGP, que utilizas como BB. De esta manera, 4 VSYS intercambian todas las rutas espec\u00edficas entre s\u00ed y tienen una tabla de reenv\u00edo con conjuntos de rutas aproximadamente iguales (pero con NH diferentes). Como cada VSYS tiene 2 sesiones BGP (con la misma configuraci\u00f3n), cada ruta obtenida a trav\u00e9s de MPLS tiene 2 NH y, por consiguiente, 2 entradas FIB en la tabla de reenv\u00edo. Si asumimos que este es el \u00fanico firewall en el centro de datos y debe conocer todas las rutas, esto significar\u00e1 que el n\u00famero total de rutas en nuestro centro de datos no puede ser m\u00e1s de 32K\/(4 * 2) = 4K. <\/p>\n<p>Ahora, supongamos que tenemos 2 centros de datos (con el mismo dise\u00f1o) y queremos utilizar VLANs \"extendidas\" entre los centros de datos (por ejemplo, para vMotion). Para resolver el problema de enrutamiento, debemos usar rutas de host. Pero esto significa que en 2 centros de datos tendremos no m\u00e1s de 4096 hosts posibles y, por supuesto, esto puede ser insuficiente.<\/p><\/blockquote>\n<blockquote><p>Ejemplo 2. ACL TCAM.<\/p>\n<p>Si planeas filtrar tr\u00e1fico en conmutadores L3 (u otras soluciones que utilizan conmutadores L3, como Cisco ACI), al elegir el hardware debes prestar atenci\u00f3n a la ACL TCAM.<\/p>\n<p>Supongamos que deseas controlar los accesos en las interfaces SVI de Cisco Catalyst 4500. Entonces, como se puede ver en <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cisco.com\/c\/en\/us\/support\/docs\/switches\/catalyst-4000-series-switches\/66978-tcam-cat-4500.html\">de este art\u00edculo<\/a><\/noindex>, para controlar el tr\u00e1fico saliente (as\u00ed como el entrante) en las interfaces, solo puedes utilizar 4096 l\u00edneas de TCAM. Lo que, al utilizar TCAM3, te dar\u00e1 alrededor de 4000 ACE (l\u00edneas ACL).<\/p><\/blockquote>\n<p> En caso de que enfrentes el problema de insuficiencia de TCAM, primero, por supuesto, debes considerar la posibilidad de optimizaci\u00f3n. As\u00ed, en caso de un problema con el tama\u00f1o de la tabla de reenv\u00edo, debes considerar la posibilidad de agregar rutas. En el caso de un problema con el tama\u00f1o de TCAM para accesos, se debe hacer una auditor\u00eda de accesos, eliminar entradas obsoletas y superpuestas, as\u00ed como, posiblemente, revisar el procedimiento de apertura de accesos (se analizar\u00e1 en detalle en el cap\u00edtulo dedicado a la auditor\u00eda de accesos).<\/p>\n<h3>Alta Disponibilidad<\/h3>\n<p>\nLa pregunta es, \u00bfusar HA para firewalls o colocar \"paralelamente\" dos cajas independientes y, en caso de que falle una de ellas, enrutar el tr\u00e1fico a trav\u00e9s de la segunda?<\/p>\n<p>A primera vista, la respuesta es obvia: utilizar HA. La raz\u00f3n por la que esta pregunta surge es que, desafortunadamente, los te\u00f3ricos y los publicitarios afirman porcentajes de disponibilidad cercanos al 99,9%, pero en la pr\u00e1ctica, esto no se traduce en una experiencia tan optimista. HA es un asunto l\u00f3gicamente complejo, y hemos encontrado problemas y fallos, as\u00ed como interrupciones del servicio en distintos equipos y con diferentes proveedores.<\/p>\n<p>En caso de utilizar HA, obtendr\u00e1s la posibilidad de apagar nodos individuales y cambiar entre ellos sin detener el servicio, lo cual es importante, por ejemplo, durante las actualizaciones. Sin embargo, existe una probabilidad no despreciable de que ambos nodos se da\u00f1en simult\u00e1neamente, adem\u00e1s de que la siguiente actualizaci\u00f3n puede no ser tan fluida como promete el proveedor (este problema se puede evitar si tienes la capacidad de probar la actualizaci\u00f3n en equipos de laboratorio).<\/p>\n<p>Si no utilizas HA, en t\u00e9rminos de fallos dobles, tus riesgos son significativamente m\u00e1s bajos (ya que cuentas con 2 firewalls independientes), pero como las sesiones no est\u00e1n sincronizadas, cada vez que realices un cambio entre estos firewalls, perder\u00e1s tr\u00e1fico. Claro, puedes usar firewalls sin estado, pero entonces el sentido de usar un firewall se pierde en gran medida.<\/p>\n<p>Por lo tanto, si como resultado de una auditor\u00eda has encontrado firewalls aislados y est\u00e1s considerando incrementar la fiabilidad de tu red, entonces HA es, sin duda, una de las soluciones recomendadas. Sin embargo, debes tener en cuenta tambi\u00e9n las desventajas asociadas a este enfoque y, tal vez, otra soluci\u00f3n sea m\u00e1s adecuada para tu red.<\/p>\n<h3>Facilidad de gesti\u00f3n<\/h3>\n<p>\nEn esencia, HA tambi\u00e9n se relaciona con la gesti\u00f3n. En vez de configurar 2 cajas por separado y resolver el problema de la sincronizaci\u00f3n de configuraciones, las gestionas en gran medida como si tuvieras un \u00fanico dispositivo. <\/p>\n<p>Pero, quiz\u00e1s, tengas muchos centros de datos y muchos firewalls, entonces esta cuesti\u00f3n adquiere un nuevo nivel. Y la cuesti\u00f3n no es solo sobre la configuraci\u00f3n, sino tambi\u00e9n sobre<\/p>\n<ul>\n<li>la copia de seguridad de configuraciones<\/li>\n<li>actualizaciones<\/li>\n<li>mejoras<\/li>\n<li>monitoreo<\/li>\n<li>registro<\/li>\n<\/ul>\n<p>\nY todo esto puede ser resuelto por sistemas de gesti\u00f3n centralizados. <\/p>\n<blockquote><p>Por ejemplo, si utilizas firewalls de Palo Alto, entonces <noindex><a rel=\"nofollow\" href=\"https:\/\/www.paloaltonetworks.com\/products\/management\/panorama\">Panorama<\/a><\/noindex> es una de estas soluciones.\n<\/p><\/blockquote>\n<p>\n<i>Continuar\u00e1.<\/i><br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435138\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb. \u0421\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0432\u0441\u0435\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0446\u0438\u043a\u043b\u0430 \u0438 \u0441\u0441\u044b\u043b\u043a\u0438 \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0437\u0434\u0435\u0441\u044c. \u041d\u0435\u0442 \u0441\u043c\u044b\u0441\u043b\u0430 \u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044c \u043e \u043f\u043e\u043b\u043d\u043e\u043c \u0443\u0441\u0442\u0440\u0430\u043d\u0435\u043d\u0438\u0438 security \u0440\u0438\u0441\u043a\u043e\u0432. \u041c\u044b \u0432 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0435 \u043d\u0435 \u043c\u043e\u0436\u0435\u043c \u0441\u043d\u0438\u0437\u0438\u0442\u044c \u0438\u0445 \u0434\u043e \u043d\u0443\u043b\u044f. \u0422\u0430\u043a\u0436\u0435 \u043d\u0443\u0436\u043d\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u0447\u0442\u043e \u043f\u0440\u0438 \u0441\u0442\u0440\u0435\u043c\u043b\u0435\u043d\u0438\u0438 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0441\u0435\u0442\u044c \u0431\u043e\u043b\u0435\u0435 \u0438 \u0431\u043e\u043b\u0435\u0435 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0439 \u043d\u0430\u0448\u0438 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u0442\u0430\u043d\u043e\u0432\u044f\u0442\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23033,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31058","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0442\u0440\u0435\u0442\u044c\u044f. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c \u043f\u0435\u0440\u0432\u0430\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:39:12+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:39:12+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47C\u00f3mo tomar el control de la infraestructura de red. Cap\u00edtulo tres. Seguridad de red. Parte uno | ProHoster","description":"Este art\u00edculo es el tercero de un ciclo de art\u00edculos titulado \u00abC\u00f3mo tomar el control de la infraestructura de red\u00bb.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u0442\u0440\u0435\u0442\u044c\u044f. \u0421\u0435\u0442\u0435\u0432\u0430\u044f \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c. \u0427\u0430\u0441\u0442\u044c \u043f\u0435\u0440\u0432\u0430\u044f | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-tretya-setevaya-bezopasnost-chast-pervaya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:39:12+00:00","article:modified_time":"2019-10-31T18:39:12+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31058","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 04:20:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:24:14","updated":"2026-01-21 04:20:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/31058","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=31058"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/31058\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/23033"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=31058"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=31058"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=31058"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}