Este artículo es el cuarto de una serie titulada 'Cómo tomar el control de la infraestructura de red'. El contenido de todos los artículos de la serie y los enlaces se pueden encontrar aquí.

En parte anterior en este capítulo hemos revisado algunos aspectos de la seguridad de red del segmento 'Centro de Datos'. Esta parte se dedicará al segmento de 'Acceso a Internet'.

Acceso a Internet

El tema de la seguridad es, sin duda, uno de los más complejos en el mundo de las redes de transmisión de datos. Al igual que en casos anteriores, sin pretender profundidad ni exhaustividad, aquí examinaré cuestiones bastante simples, pero que a mi juicio son importantes, cuyas respuestas espero que contribuyan a mejorar la seguridad de su red.

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

design
configuraciones de BGP
protección DOS/DDOS
filtración de tráfico en el firewall

Diseño

Como ejemplo de diseño de este segmento para la red empresarial, recomendaría la guía de Cisco dentro del modelo SAFE.

Por supuesto, es posible que otras soluciones de proveedores le parezcan más atractivas (vea el cuadrante de Gartner de 2018), pero sin instarle a que siga este diseño al detalle, sigo considerando útil entender los principios e ideas que lo sustentan.

Nota
En el modelo SAFE, el segmento 'Acceso Remoto' es parte del 'Acceso a Internet'. Pero en esta serie de artículos lo abordaremos por separado.

El equipo estándar en este segmento para la red empresarial consiste en

rutinas de frontera (border routers)
firewalls

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

Nota 2
No abordaré diferentes soluciones L2/L1 o sobrelays L2 sobre L3 necesarias para garantizar la conectividad L1/L2 y me limitaré únicamente a cuestiones del nivel L3 y superiores. En parte, las cuestiones de L1/L2 fueron tratadas en el capítulo 'Limpieza y documentación«.

Si no encontró un firewall en este segmento, no se apresure a sacar conclusiones.

Al igual que en la parte anterior, comencemos la pregunta de si es necesario utilizar un firewall en este segmento en su caso.

Puedo decir que parece ser el lugar más justificado para el uso de firewalls y la aplicación de algoritmos de filtración de tráfico complejos. En la parte 1 mencionamos 4 factores que pueden obstaculizar el uso de firewalls en el segmento de centros de datos. Pero aquí ya no son tan significativos.

Ejemplo 1. Retraso
En lo que respecta a Internet, no tiene sentido hablar de latencias incluso del orden de 1 milisegundo. Por lo tanto, la latencia en este segmento no puede considerarse un factor limitante para el uso del firewall.

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

Ejemplo 3. Fiabilidad
Este factor aún debe tenerse en cuenta, pero considerando la inestabilidad del propio Internet, su importancia para este segmento no es tan significativa como para el centro de datos.
Supongamos que su servicio opera sobre http/https (con sesiones cortas). En este caso, puede utilizar dos cajas independientes (sin HA) y, en caso de problemas con una de ellas, redirigir todo el tráfico a la segunda a través del enrutamiento.
O puede usar firewalls en modo transparente y, si dejan de funcionar, durante el tiempo necesario para resolver el problema, desviar el tráfico alrededor de los firewalls.

Por lo tanto, probablemente solo precio puede ser ese factor que le lleve a renunciar al uso de firewalls en este segmento.

¡Importante!
Surge la tentación de combinar este firewall con el del centro de datos (usar un solo firewall para estos segmentos). En principio, es una solución posible, pero hay que entender que, dado que el firewall de «Acceso a Internet» se encuentra efectivamente en la primera línea de defensa y, al menos, recibe parte del tráfico malicioso, por supuesto, se debe tener en cuenta el riesgo incrementado de que dicho firewall falle. Es decir, al usar los mismos dispositivos en estos dos segmentos, se reducirá significativamente la disponibilidad de su segmento de centro de datos.

Como suele ser, es importante entender que dependiendo del servicio que la empresa proporciona, el diseño de este segmento puede variar considerablemente. Como de costumbre, puede elegir diferentes enfoques según los requisitos.

Ejemplo
Si usted es un proveedor de contenido, con una red CDN (ver, por ejemplo, una serie de artículos), entonces es posible que no desee crear infraestructura con decenas o incluso cientos de puntos de presencia utilizando dispositivos separados para el enrutamiento y filtrado del tráfico. Esto resultaría costoso y podría ser simplemente excesivo.
Para BGP, no es absolutamente necesario tener routers dedicados; puedes utilizar herramientas de código abierto, por ejemplo, Quagga. Por lo tanto, es posible que todo lo que necesites sea un servidor o varios servidores, un switch y BGP.
En este caso, tu servidor o varios servidores pueden funcionar no solo como servidores CDN, sino también como routers. Por supuesto, hay muchos detalles a considerar (por ejemplo, cómo asegurar el balanceo), pero es viable, y este enfoque lo hemos aplicado con éxito para uno de nuestros socios.
Puedes tener varios centros de datos con protección completa (firewalls, servicios de protección DDoS proporcionados por tus proveedores de Internet) y decenas o cientos de "puntos de presencia simplificados" solo con switches L2 y servidores.
¿Y qué pasa con la protección en este caso?
Consideremos, por ejemplo, el popular ataque DDoS de amplificación DNS . Su peligro radica en que se genera una gran cantidad de tráfico que simplemente "satura" al 100% todos tus uplinks.Lo que tenemos en nuestro diseño.
si utilizas AnyCast, el tráfico se distribuye entre tus puntos de presencia. Si tu ancho de banda total es de terabits, esto, en sí mismo, te protege de un "desbordamiento" de uplinks (aunque, últimamente, ha habido varios ataques con tráfico malicioso del orden de terabits)

si, aún así, algunos uplinks "se saturan", simplemente retiras esa ubicación del servicio (dejas de anunciar el prefijo)

también puedes aumentar la proporción de tráfico que proviene de tus centros de datos "completos" (y, por lo tanto, protegidos), eliminando así una parte significativa del tráfico malicioso de los puntos de presencia no protegidos

Y un pequeño comentario sobre este ejemplo. Si entregas una cantidad suficiente de tráfico a través de los IX, eso también reduce tu exposición a tales ataques
Aquí hay dos temas.

Configuración de BGP

Ya hemos hablado un poco sobre la conectividad en

Conectividad
Configuración de BGP

. La esencia es que el tráfico hacia tus clientes siga el camino óptimo. Aunque la optimización no se trata solo de latencia, generalmente, la baja latencia es el principal indicador de optimización. Para algunas empresas es más importante, para otras menos. Todo depende del servicio que ofreces. parte 1El objetivo es que el tráfico hacia sus clientes fluya de la manera más óptima. Sin embargo, la optimización no siempre se trata sólo de la latencia, aunque generalmente una baja latencia es el principal indicador de optimización. Para algunas empresas esto es más importante, para otras, menos. Todo depende del servicio que ofrezca.

Ejemplo 1
Si usted es un intercambio y los intervalos de tiempo de sus clientes son importantes, menos de milisegundos, entonces, por supuesto, no se puede hablar de Internet en absoluto.

Ejemplo 2
Si usted es una empresa de juegos y le importan decenas de milisegundos, entonces, por supuesto, la conectividad es muy importante para usted.

Ejemplo 3
También hay que entender que, debido a las características del protocolo TCP, la velocidad de transmisión de datos dentro de una sesión TCP también depende del RTT (Round Trip Time). Las redes CDN se construyen, entre otras cosas, para resolver este problema, acercando los servidores de distribución de contenido al consumidor de este contenido.

La investigación sobre conectividad es un tema interesante por sí mismo, digno de un artículo o una serie de artículos, y requiere un buen entendimiento de cómo está «estructurado» Internet.

Recursos útiles:

ripe.net
bgp.he.net

Ejemplo
Voy a dar solo un pequeño ejemplo.
Supongamos que su centro de datos está en Moscú y tiene un único uplink: Rostelecom (AS12389). En este caso (single homed), BGP no es necesario y, como direcciones públicas, probablemente esté utilizando un bloque de direcciones de Rostelecom.
Supongamos que usted ofrece algún servicio y tiene un número suficiente de clientes de Ucrania, quienes se quejan de grandes latencias. Al investigar, descubre que las direcciones IP de algunos de ellos están en la red 37.52.0.0/21.
Al realizar un traceroute, vio que el tráfico pasa por AS1299 (Telia), y al hacer ping, recibió un RTT promedio de 70 a 80 milisegundos. Puede ver esto también en el looking glass de Rostelecom.
Utilizando la herramienta whois (en el sitio ripe.net o una herramienta local), puede determinar fácilmente que el bloque 37.52.0.0/21 pertenece a AS6849 (Ukrtelecom).
Luego, al entrar en bgp.he.net verá que AS6849 no tiene relaciones con AS12389 (no son clientes ni uplinks entre sí, y tampoco tienen peering). Pero si observa la lista de pares para AS6849, verá, por ejemplo, AS29226 (Mastertel) y AS31133 (Megafon).
Encontrando el looking glass de estos proveedores, puede comparar la ruta y el RTT. Por ejemplo, para Mastertel, el RTT será de aproximadamente 30 milisegundos.
Entonces, si la diferencia entre 80 y 30 milisegundos es significativa para su servicio, quizás deba considerar la conectividad, obtener su número AS en RIPE, su bloque de direcciones y conectar uplinks adicionales y/o crear puntos de presencia en IX.

Al utilizar BGP, no solo mejoras la conectividad, sino que también reservas tu conexión a Internet.

Este documento contiene recomendaciones para la configuración de BGP. Aunque estas recomendaciones se han desarrollado basándose en las mejores prácticas de los proveedores, siguen siendo indiscutiblemente útiles y deben formar parte del endurecimiento que discutimos en parte anterior.

protección DOS/DDOS

Hoy en día, los ataques DOS/DDOS son una realidad cotidiana para muchas empresas. De hecho, de una forma u otra, eres atacado con bastante frecuencia. El hecho de que no lo notes en este momento solo significa que aún no se ha organizado un ataque dirigido contra ti, y que las medidas de protección que estás utilizando, incluso sin saberlo (las diversas protecciones integradas de los sistemas operativos), son probablemente suficientes para minimizar la degradación del servicio para ti y tus clientes.

Existen recursos en Internet que, basándose en los registros de hardware, dibujan en tiempo real mapas atractivos de los ataques.

Aquí Puedes encontrar enlaces a ellos.

Mi mapa favorito de CheckPoint. La protección contra DDOS/DOS suele ser en capas. Para entender por qué, es necesario conocer qué tipos de ataques DOS/DDOS existen (ver por ejemplo,

Es decir, tenemos tres tipos de ataques: aquí o aquí)

ataques volumétricos

ataques de protocolo
ataques de aplicación
Si puedes protegerte de los dos últimos tipos de ataques utilizando, por ejemplo, firewalls, no podrás protegerte de los ataques dirigidos a 'sobrecargar' tus enlaces ascendente (por supuesto, a menos que tu capacidad total de los canales de Internet se cuente en terabits, mejor aún, en decenas de terabits).

Por lo tanto, la primera línea de defensa es protegerse contra los ataques 'volumétricos', y esta protección debe proporcionártela tu proveedor o proveedores. Si aún no te has dado cuenta de esto, simplemente tienes suerte por ahora.

Supongamos que tienes varios enlaces ascendentes, pero solo uno de los proveedores puede ofrecerte esta protección. Pero si todo el tráfico pasa a través de un solo proveedor, ¿qué pasa con la conectividad que discutimos brevemente antes?

Ejemplo
Durante un ataque, en este caso tendrás que sacrificar en parte la conectividad. Pero
Durante el ataque, en este caso, tendrá que sacrificar en parte la conectividad.

esto es solo durante un ataque. Puede reconfigurar el BGP manual o automáticamente, de modo que el tráfico fluya solo a través del proveedor que le ofrece "cobertura". Al finalizar el ataque, puede restablecer el enrutamiento al estado anterior.

no es necesario traducir todo el tráfico. Si, por ejemplo, ve que a través de ciertos uplinks o peering no hay ataques (o el tráfico no es significativo), puede continuar anunciando prefijos con atributos competitivos hacia esos vecinos BGP.

La protección contra "protocol attacks" y "application attacks" también puede ser externalizada a socios.
Aquí aquí puede leer un buen estudio (la traducción). En verdad, el artículo es de hace dos años, pero le dará una idea de los enfoques para protegerse contra ataques DDoS.

En principio, puede limitarse a esto, delegando completamente su protección a terceros. Esta solución tiene sus ventajas, pero también un inconveniente evidente. Se trata, nuevamente dependiendo de la actividad de su empresa, de la supervivencia del negocio. Y confiar tales cosas a organizaciones externas…

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

Así que, la segunda línea de defensa es la filtración y los limitadores de tráfico (policers) a la entrada de su red.

Ejemplo 1
Supongamos que usted se "ha cubierto" de DDoS con uno de los proveedores. Supongamos que este proveedor usa Arbor para filtrar el tráfico y tiene filtros en el límite de su red.
El ancho de banda que Arbor puede "manejar" es limitado, y el proveedor, por supuesto, no puede permitir constantemente que pase el tráfico de todos sus socios que han contratado este servicio a través del equipo de filtrado. Por lo tanto, en condiciones normales, el tráfico no se filtra.
Supongamos que se está llevando a cabo un ataque de inundación SYN. Incluso si ha solicitado un servicio en el que, en caso de ataque, el tráfico se redirige automáticamente a filtrado, esto no ocurre de inmediato. Durante un minuto o más, seguirá estando bajo ataque. Y esto puede llevar a la falla de su equipo o degradación del servicio. En este caso, la limitación de tráfico en el enrutamiento de borde, aunque llevará a que algunas sesiones TCP no se establezcan durante este tiempo, salvará su infraestructura de problemas más amplios.

Ejemplo 2
Una cantidad anómala de paquetes SYN puede no ser solo el resultado de un ataque de inundación SYN. Supongamos que ofrece un servicio en el que puede haber alrededor de 100,000 conexiones TCP simultáneamente (en un solo centro de datos).
Supongamos que, como resultado de un problema temporal con uno de sus principales proveedores, la mitad de las sesiones se interrumpieron. Si su aplicación está diseñada de tal manera que, sin pensarlo, intenta restablecer la conexión de inmediato (o dentro de algún intervalo de tiempo igual para todas las sesiones), entonces aproximadamente al mismo tiempo recibirá al menos 50,000 paquetes SYN.
Sin embargo, si sobre estas sesiones, por ejemplo, se debe llevar a cabo el handshake ssl/tls, que implica un intercambio de certificados, desde el punto de vista del agotamiento de recursos para su balanceador de carga, esto será un 'DDOS' mucho más fuerte que una simple inundación SYN. Aparentemente, los balanceadores deberían manejar tales eventos, pero... lamentablemente, nos hemos enfrentado a este problema de manera frontal.
Y, por supuesto, un policer en el enrutador de borde salvará su equipo en este caso.

El tercer nivel de protección contra DDOS/DOS son las configuraciones de su firewall.

Aquí puede detener tanto ataques de segundo como de tercer tipo. En general, todo lo que llegue al firewall puede ser filtrado aquí.

Consejo
Intente darle al firewall el menor trabajo posible, filtrando tanto como sea posible en las dos primeras líneas de defensa. Y aquí está el porqué.
¿Alguna vez les ha ocurrido que, al generar tráfico para comprobar, por ejemplo, cuán resistente es su sistema operativo ante ataques DDoS, han "abatido" su firewall, cargándolo al 100% con tráfico de intensidad normal? Si no, ¿tal vez simplemente porque no lo han intentado?
En general, un firewall, como ya mencioné, es algo complicado y funciona bien con vulnerabilidades conocidas y soluciones probadas, pero si envían algo inusual, simplemente algún tipo de basura o paquetes con encabezados incorrectos, es bastante probable (basándome en mi experiencia) que puedan confundir incluso el equipo de gama alta. Por lo tanto, en la etapa 2, utilizando ACL normales (a nivel L3/L4), dejen entrar a su red solo el tráfico que realmente debe ingresar.