Cómo tomar el control de su infraestructura de red. Capítulo tres. Seguridad de la red. La segunda parte

Este artículo es el cuarto de la serie "Cómo tomar el control de su infraestructura de red". Se pueden encontrar los contenidos de todos los artículos de la serie y los enlaces. aquí.

В la primera parte En este capítulo, analizamos algunos aspectos de la seguridad de la red en el segmento del centro de datos. Esta parte estará dedicada al segmento “Acceso a Internet”.

Cómo tomar el control de su infraestructura de red. Capítulo tres. Seguridad de la red. La segunda parte

acceso a Internet

El tema de la seguridad es sin duda uno de los temas más complejos en el mundo de las redes de datos. Como en casos anteriores, sin pretender profundidad ni exhaustividad, consideraré aquí preguntas bastante simples, pero, en mi opinión, importantes, cuyas respuestas, espero, ayudarán a elevar el nivel de seguridad de su red.

Al auditar este segmento, preste atención a los siguientes aspectos:

  • diseño
  • configuración BGP
  • Protección DOS/DDOS
  • filtrado de tráfico en el firewall

diseño

Como ejemplo del diseño de este segmento para una red empresarial, recomendaría руководство de Cisco dentro Modelos SEGUROS.

Por supuesto, quizás la solución de otros proveedores le parezca más atractiva (ver. Cuadrante Gartner 2018), pero sin animarte a seguir este diseño en detalle, todavía lo encuentro útil para comprender los principios e ideas detrás de él.

Nota

En SAFE, el segmento "Acceso remoto" es parte del segmento "Acceso a Internet". Pero en esta serie de artículos lo consideraremos por separado.

El conjunto estándar de equipos en este segmento para una red empresarial es

  • enrutadores fronterizos
  • cortafuegos

Observación 1

En esta serie de artículos, cuando hablo de firewalls, me refiero NGFW.

Observación 2

Omito la consideración de varios tipos de soluciones L2/L1 o superposición de L2 sobre L3 necesarias para garantizar la conectividad L1/L2 y me limito solo a problemas en el nivel L3 y superiores. Parcialmente, las cuestiones de L1/L2 se discutieron en el capítulo “Limpieza y Documentación«.

Si no ha encontrado un firewall en este segmento, no debe apresurarse a sacar conclusiones.

Hagamos lo mismo que en parte anteriorEmpecemos con la pregunta: ¿es necesario utilizar un firewall en este segmento en tu caso?

Puedo decir que este parece ser el lugar más justificado para utilizar cortafuegos y aplicar complejos algoritmos de filtrado de tráfico. EN partes de 1 Mencionamos 4 factores que pueden interferir con el uso de firewalls en el segmento de centros de datos. Pero aquí ya no son tan significativos.

Ejemplo 1. Retrasado

En lo que respecta a Internet, no tiene sentido hablar de retrasos de siquiera 1 milisegundo. Por tanto, el retraso en este segmento no puede ser un factor que limite el uso del firewall.

Ejemplo 2. Rendimiento

En algunos casos, este factor aún puede ser significativo. Por lo tanto, es posible que deba permitir que parte del tráfico (por ejemplo, el tráfico de los balanceadores de carga) evite el firewall.

Ejemplo 3. Confiabilidad

Este factor aún debe tenerse en cuenta, pero aún así, dada la falta de confiabilidad de Internet, su importancia para este segmento no es tan significativa como para el centro de datos.

Entonces, supongamos que su servicio se encuentra encima de http/https (con sesiones cortas). En este caso, puedes utilizar dos cajas independientes (sin HA) y si hay un problema de enrutamiento con una de ellas, transferir todo el tráfico a la segunda.

O puede utilizar firewalls en modo transparente y, si fallan, permitir que el tráfico pase por alto el firewall mientras se resuelve el problema.

Por lo tanto, lo más probable es que simplemente precio puede ser el factor que le obligue a abandonar el uso de firewalls en este segmento.

¡Importante!

Existe la tentación de combinar este firewall con el firewall del centro de datos (use un firewall para estos segmentos). La solución es, en principio, posible, pero hay que entenderlo porque Un firewall de acceso a Internet está en realidad a la vanguardia de su defensa y "acepta" al menos parte del tráfico malicioso; luego, por supuesto, debe tener en cuenta el mayor riesgo de que este firewall sea desactivado. Es decir, al utilizar los mismos dispositivos en estos dos segmentos, reducirá significativamente la disponibilidad de su segmento de centro de datos.

Como siempre, hay que entender que dependiendo del servicio que brinde la empresa, el diseño de este segmento puede variar mucho. Como siempre, puede elegir diferentes enfoques según sus necesidades.

ejemplo

Si es un proveedor de contenidos, con una red CDN (consulte, por ejemplo, serie de artículos), entonces es posible que no desee crear una infraestructura en docenas o incluso cientos de puntos de presencia utilizando dispositivos separados para enrutar y filtrar el tráfico. Será costoso y puede que simplemente sea innecesario.

Para BGP no es necesario tener enrutadores dedicados, puede usar herramientas de código abierto como quagga. Entonces, quizás todo lo que necesite sea un servidor o varios servidores, un conmutador y BGP.

En este caso, su servidor o varios servidores pueden desempeñar el papel no solo de servidor CDN, sino también de enrutador. Por supuesto, aún quedan muchos detalles (como cómo garantizar el equilibrio), pero es factible y es un enfoque que hemos utilizado con éxito para uno de nuestros socios.

Puede tener varios centros de datos con protección total (firewalls, servicios de protección DDOS proporcionados por sus proveedores de Internet) y decenas o cientos de puntos de presencia “simplificados” con sólo conmutadores y servidores L2.

Pero ¿qué pasa con la protección en este caso?

Miremos, por ejemplo, el recientemente popular Ataque DDOS de amplificación de DNS. Su peligro radica en el hecho de que se genera una gran cantidad de tráfico, que simplemente "obstruye" el 100% de todos sus enlaces ascendentes.

¿Qué tenemos en el caso de nuestro diseño?

  • Si utiliza AnyCast, el tráfico se distribuye entre sus puntos de presencia. Si su ancho de banda total es de terabits, entonces esto en sí mismo (sin embargo, recientemente ha habido varios ataques con tráfico malicioso del orden de terabits) lo protege de enlaces ascendentes "desbordados".
  • Sin embargo, si algunos enlaces ascendentes se obstruyen, simplemente elimine este sitio del servicio (deje de anunciar el prefijo).
  • También puede aumentar la proporción de tráfico enviado desde sus centros de datos "completos" (y, en consecuencia, protegidos), eliminando así una parte importante del tráfico malicioso de puntos de presencia desprotegidos.

Y una pequeña nota más a este ejemplo. Si envía suficiente tráfico a través de IX, esto también reduce su vulnerabilidad a este tipo de ataques.

Configurando BGP

Hay dos temas aquí.

  • Conectividad
  • Configurando BGP

Ya hemos hablado un poco de conectividad en partes de 1. El objetivo es garantizar que el tráfico hacia sus clientes siga el camino óptimo. Aunque la optimización no siempre se trata solo de latencia, la latencia baja suele ser el principal indicador de optimización. Para algunas empresas esto es más importante, para otras es menos. Todo depende del servicio que brindes.

ejemplo 1

Si usted es una casa de cambio y los intervalos de tiempo de menos de milisegundos son importantes para sus clientes, entonces, por supuesto, no se puede hablar de ningún tipo de Internet.

ejemplo 2

Si es una empresa de juegos y decenas de milisegundos son importantes para usted, entonces, por supuesto, la conectividad es muy importante para usted.

ejemplo 3

También debe comprender que, debido a las propiedades del protocolo TCP, la velocidad de transferencia de datos dentro de una sesión TCP también depende del RTT (tiempo de ida y vuelta). También se están construyendo redes CDN para resolver este problema acercando los servidores de distribución de contenido al consumidor de este contenido.

El estudio de la conectividad es un tema interesante en sí mismo, digno de su propio artículo o serie de artículos, y requiere una buena comprensión de cómo “funciona” Internet.

Recursos útiles:

ripe.net
bgp.he.net

ejemplo

Daré sólo un pequeño ejemplo.

Supongamos que su centro de datos está ubicado en Moscú y que tiene un único enlace ascendente: Rostelecom (AS12389). En este caso (de un solo hogar), no necesita BGP y lo más probable es que utilice el grupo de direcciones de Rostelecom como direcciones públicas.

Supongamos que usted proporciona un determinado servicio, tiene un número suficiente de clientes de Ucrania y se quejan de grandes retrasos. Durante su investigación, descubrió que las direcciones IP de algunos de ellos están en la cuadrícula 37.52.0.0/21.

Al ejecutar un traceroute, vio que el tráfico pasaba por AS1299 (Telia) y al ejecutar un ping, obtuvo un RTT promedio de 70 a 80 milisegundos. También puedes ver esto en espejo Rostelecom.

Usando la utilidad whois (en rip.net o una utilidad local), puede determinar fácilmente que el bloque 37.52.0.0/21 pertenece a AS6849 (Ukrtelecom).

A continuación, yendo a bgp.he.net verá que AS6849 no tiene relación con AS12389 (no son clientes ni enlaces ascendentes entre sí, ni tienen peering). Pero si miras lista de compañeros para AS6849, verá, por ejemplo, AS29226 (Mastertel) y AS31133 (Megafon).

Una vez que encuentre el espejo de estos proveedores, podrá comparar la ruta y el RTT. Por ejemplo, para Mastertel el RTT será de unos 30 milisegundos.

Entonces, si la diferencia entre 80 y 30 milisegundos es significativa para su servicio, entonces tal vez deba pensar en la conectividad, obtener su número de AS, su grupo de direcciones de RIPE y conectar enlaces ascendentes adicionales y/o crear puntos de presencia en IX.

Cuando utiliza BGP, no sólo tiene la oportunidad de mejorar la conectividad, sino que también mantiene su conexión a Internet de forma redundante.

Este documento contiene recomendaciones para configurar BGP. A pesar de que estas recomendaciones se desarrollaron basándose en las “mejores prácticas” de los proveedores, aun así (si su configuración de BGP no es del todo básica) son indudablemente útiles y, de hecho, deberían ser parte del fortalecimiento que analizamos en la primera parte.

Protección DOS/DDOS

Ahora los ataques DOS/DDOS se han convertido en una realidad cotidiana para muchas empresas. De hecho, te atacan con bastante frecuencia de una forma u otra. El hecho de que todavía no lo hayas notado sólo significa que todavía no se ha organizado un ataque dirigido contra ti y que las medidas de protección que utilizas, incluso quizás sin saberlo (varias protecciones integradas en los sistemas operativos), son suficientes para garantizar que la degradación del servicio prestado se minimice para usted y sus clientes.

Hay recursos en Internet que, basándose en los registros de los equipos, dibujan hermosos mapas de ataque en tiempo real.

es puedes encontrar enlaces a ellos.

Mi favorito mapa desde Punto de control.

La protección contra DDOS/DOS suele ser por capas. Para entender por qué, es necesario comprender qué tipos de ataques DOS/DDOS existen (consulte, por ejemplo, aquí o aquí)

Es decir, tenemos tres tipos de ataques:

  • ataques volumétricos
  • ataques de protocolo
  • ataques a aplicaciones

Si puede protegerse de los dos últimos tipos de ataques utilizando, por ejemplo, firewalls, entonces no podrá protegerse de ataques destinados a "abrumar" sus enlaces ascendentes (por supuesto, si su capacidad total de canales de Internet no se calcula en terabits, o mejor aún, en decenas de terabit).

Por lo tanto, la primera línea de defensa es la protección contra ataques "volumétricos", y su proveedor o proveedores deben brindarle esta protección. Si aún no te has dado cuenta de esto, por ahora estás de suerte.

ejemplo

Digamos que tiene varios enlaces ascendentes, pero solo uno de los proveedores puede brindarle esta protección. Pero si todo el tráfico pasa por un proveedor, ¿qué pasa con la conectividad que analizamos brevemente antes?

En este caso, tendrás que sacrificar parcialmente la conectividad durante el ataque. Pero

  • esto es sólo durante la duración del ataque. En caso de un ataque, puede reconfigurar BGP manual o automáticamente para que el tráfico pase únicamente a través del proveedor que le proporciona el "paraguas". Una vez finalizado el ataque, puede devolver la ruta a su estado anterior.
  • No es necesario transferir todo el tráfico. Si, por ejemplo, ve que no hay ataques a través de algunos enlaces ascendentes o peerings (o el tráfico no es significativo), puede continuar anunciando prefijos con atributos competitivos hacia estos vecinos BGP.

También puede delegar la protección contra "ataques de protocolo" y "ataques de aplicaciones" a sus socios.
aquí está aquí puedes leer un buen estudio (traducción). Es cierto que el artículo tiene dos años, pero le dará una idea de cómo protegerse de los ataques DDOS.

En principio, puedes limitarte a esto, subcontratando completamente tu protección. Esta decisión tiene ventajas, pero también una desventaja obvia. El caso es que podemos hablar (de nuevo, dependiendo de a qué se dedique tu empresa) de la supervivencia del negocio. Y confiar esas cosas a terceros...

Por lo tanto, veamos cómo organizar la segunda y tercera línea de defensa (como complemento a la protección del proveedor).

Entonces, la segunda línea de defensa son los filtros y limitadores de tráfico (policías) en la entrada de su red.

ejemplo 1

Supongamos que se ha protegido contra DDOS con la ayuda de uno de los proveedores. Supongamos que este proveedor utiliza Arbor para filtrar el tráfico y filtrar en el borde de su red.

El ancho de banda que Arbor puede "procesar" es limitado y el proveedor, por supuesto, no puede pasar constantemente el tráfico de todos sus socios que solicitan este servicio a través de equipos de filtrado. Por tanto, en condiciones normales, el tráfico no se filtra.

Supongamos que hay un ataque de inundación SYN. Incluso si solicitó un servicio que cambia automáticamente el tráfico a filtrado en caso de un ataque, esto no sucede instantáneamente. Durante un minuto o más permaneces bajo ataque. Y esto puede provocar fallos en su equipo o degradación del servicio. En este caso, limitar el tráfico en el enrutamiento perimetral, aunque provocará que algunas sesiones TCP no se establezcan durante este tiempo, salvará su infraestructura de problemas de mayor escala.

ejemplo 2

Una cantidad anormalmente grande de paquetes SYN puede no ser solo el resultado de un ataque de inundación SYN. Supongamos que proporciona un servicio en el que puede tener simultáneamente alrededor de 100 mil conexiones TCP (a un centro de datos).

Digamos que como resultado de un problema a corto plazo con uno de sus principales proveedores, la mitad de sus sesiones son canceladas. Si su aplicación está diseñada de tal manera que, sin pensarlo dos veces, inmediatamente (o después de un intervalo de tiempo igual para todas las sesiones) intenta restablecer la conexión, entonces recibirá al menos 50 mil paquetes SYN aproximadamente. simultáneamente.

Si, por ejemplo, tiene que ejecutar el protocolo de enlace ssl/tls además de estas sesiones, lo que implica el intercambio de certificados, entonces, desde el punto de vista del agotamiento de recursos para su balanceador de carga, este será un "DDOS" mucho más potente que un simple Inundación SYN. Parecería que los equilibradores deberían encargarse de tales eventos, pero... desafortunadamente, nos enfrentamos a ese problema.

Y, por supuesto, un policía en el enrutador perimetral también salvará su equipo en este caso.

El tercer nivel de protección contra DDOS/DOS es la configuración del firewall.

Aquí puedes detener tanto los ataques del segundo como del tercer tipo. Por lo general, aquí se puede filtrar todo lo que llega al firewall.

Consejo

Intente darle al firewall el menor trabajo posible, filtrando tanto como sea posible en las dos primeras líneas de defensa. Y es por eso.

¿Te ha pasado que por casualidad, mientras generabas tráfico para comprobar, por ejemplo, qué tan resistente es el sistema operativo de tus servidores a ataques DDOS, “mataste” tu firewall, cargándolo al 100 por ciento, con tráfico a intensidad normal? ? Si no es así, ¿tal vez sea simplemente porque no lo has intentado?

En general, un firewall, como dije, es algo complejo y funciona bien con vulnerabilidades conocidas y soluciones probadas, pero si envía algo inusual, solo algo de basura o paquetes con encabezados incorrectos, entonces está con algunos, no con Con una probabilidad tan pequeña (según mi experiencia), puedes dejar estupefactos incluso a los equipos de gama alta. Por lo tanto, en la etapa 2, utilizando ACL regulares (en el nivel L3/L4), solo permita el tráfico en su red que debería ingresar allí.

Filtrar el tráfico en el firewall

Continuamos la conversación sobre el firewall. Debe comprender que los ataques DOS/DDOS son sólo un tipo de ciberataque.

Además de la protección DOS/DDOS, también podemos tener algo como la siguiente lista de características:

  • firewall de aplicaciones
  • prevención de amenazas (antivirus, antispyware y vulnerabilidad)
  • Filtrado de URL
  • filtrado de datos (filtrado de contenidos)
  • bloqueo de archivos (bloqueo de tipos de archivos)

Depende de usted decidir qué necesita de esta lista.

To be continued

Fuente: habr.com

Añadir un comentario