Archivo de la etiqueta: IPS

Podcast – 34 – Port Knocking

Podcast – 34 – Port Knocking

 
 
00:00 /
 
1X
 

Hoy hablaremos sobre una técnica de ‘seguridad por oscuridad’: el Port Knocking. Podéis encontrar una entrada en la Wikipedia española con el nombre de “Golpeo de puertos”. Ciertamente es una traducción literal de la expresión inglesa y es el único sitio donde la he visto, por lo que si me lo permitís me quedaré con Port Knocking.

Micro con feed

Fuente imagen:PerfectYourPodcast

Según algunas fuentes esta técnica apareció por primera vez en 2003 en un artículo de la revista “SysAdmin Magazine” como un mecanismo de autenticación ante un cortafuegos. La idea es permitir el acceso a un servicio a través de un firewall que tiene los puertos cerrados por defecto.

Recordemos que los firewall tradicionales permiten o deniegan el tráfico en función de las direcciones IP origen/destino y de los puertos usados.

La idea básica del Port Knocking es simple: el cliente realiza una serie de intentos de conexión a una secuencia de puertos concreta. Si esta secuencia es correcta, el firewall habilitará el acceso al puerto para acceder al servicio protegido. Así pues, la “contraseña de acceso” al servicio sería la secuencia de puertos que debe ejecutarse antes de conectar con el servicio protegido.

Port Knoking

Ejemplo de Port Knocking. Fuente imagen: CyberVault

Veamos el ejemplo más sencillo de esta técnica: Supongamos que tenemos una página web oculta mediante esta técnica. Para acceder a esa página primero hay que ‘tocar’ los puertos 55, 34034 y 24124.

  1. Cuando cualquier usuario quiera conectar al servidor web protegido el firewall denegará la conexión como si no existiera ningún servicio web operativo. Así se consigue ocultar el servicio de miradas ajenas.
  2. Cuando queremos acceder a nuestra web oculta lanzamos tres peticiones de conexión TCP en el orden correcto: a cada petición recibiremos respuesta de que el puerto está cerrado (igual que recibiría cualquier intento de acceso a un puerto cerrado). Es decir, el Port Knocking no daría pistas de su existencia.
  3. Una vez realizada la secuencia en el orden correcto, en nuestra cuarta conexión accederíamos a nuestra página web y el firewall nos permitiría el paso. A partir de ese momento podemos trabajar con neustra web oculta sin problemas.

Así pues, la clave para acceder al servicio oculto es la secuencia exacta de peticiones que debemos realizar antes de acceder a la web.

Obviamente una vez abierto el acceso, el propio servicio puede (y debe) tener sus propias medidas de seguridad. El Port Knocking dificulta el descubrimiento del servicio, pero en su versión más sencilla (que es la que hemos explicado) no protege al propio servicio. En nuestro ejemplo una vez revelado un servicio web, la propia aplicación web debería tener un control de acceso, por ejemplo, con usuario/contraseña.

Esta técnica puede ser útil para proteger un servicio de miradas indiscretas, pero dónde no podemos saber con antelación desde dónde se conectarán nuestros clientes (servicios en itinerancia, redes móviles, direccionamiento IP dinámico etc.). Si nuestros clientes siempre tienen la misma IP es más sencillo configurar el firewall para que habilite el acceso normal únicamente a una serie de direcciones específicas y bloquee el del resto del mundo.

El principal problema de este modelo más sencillo de Port Knocking es que es débil frente ataques de repetición: si un atacante consigue capturar el tráfico de red (o los logs del propio firewall) podrá darse cuenta de esta secuencia repetida aparentemente sin sentido y averiguar la existencia del servicio secreto simplemente enviando la misma secuencia de peticiones. Una manera de dificultar esta detección sería el uso de puertos comúnmente comprobados por escaneadores de vulnerabilidades, aunque, obviamente, en una secuencia distinta a la habitual: a nadie extraña ver intentos de peticiones a puertos comunes (SMTP, FTP, telnet, ssh, etc.) por lo que se dificultaría que, entre todas las peticiones que hay en cualquier firewall, se detectase el patrón de acceso.

Otras técnicas para evitar los ataques de repetición implican el conocimiento de una clave previa:

  1. Codificaremos la información de nuestra dirección IP origen y el puerto destino al que queremos acceder (donde está el servicio oculto). Por ejemplo: IPPUERTO = 6 bytes.
  2. Ciframos esta cadena de caracteres con la clave adecuada
  3. Cogemos el valor del cifrado y lo separamos en bytes. Cada byte puede tener un valor entre 0 y 255. Así obtenemos una secuencia de valores del 0 al 255
  4. Sumamos a estos valores obtenidos un valor base (por ejemplo 23000). Y enviamos una conexión nueva al puerto resultante de esta operación.
  5. El firewall que recibe las peticiones puede restar el valor base (conocido de antemano) y obtener así los valores de bytes resultantes del cifrado
  6. Como el firewall conoce la clave de cifrado puede obtener el mensaje inicial y así puede abrir el acceso desde la IP origen al puerto solicitado.

Este sistema tiene la ventaja que ante un ataque de repetición (donde se enviasen los mismos paquetes) simplemente se abriría el firewall para la IP origen cifrada en el paquete y no para la IP del atacante. La elección de un valor base al que sumar a los puertos puede ser fija o realizarse de forma dinámica (en función de la hora, día del mes, etc.) permitiendo así dificultar los ataques de repetición y generar una alerta en el sistema en caso de detectar intentos de conexiones en puertos no adecuados a la franja temporal).

Una funcionalidad de este sistema es que permite abrir accesos a diferentes servicios sin cambiar el esquema, o bien incluso enviar los mensajes de Port Knocking desde direcciones IP diferentes a las que se usarán después para conectar al servicio protegido.

Un caso de control de acceso, que de forma irónica se incluye en la categoría de Port Knocking, son los sistemas Single Packet Authorization: es decir autenticación en un único paquete. A modo resumen se enviaría en un único paquete toda la información de IP origen y servicio al que se quiere acceder de forma cifrada en un único paquete. El firewall lo interpretaría y actuaría en consecuencia. Con este esquema se dificulta en gran medida la detección del sistema de ocultación, si bien al enviar un único paquete no parece que caiga en la categoría de Port Knocking 😉

Este método de protección, aunque parece sacado de una película de espías, podría ser una capa de seguridad adicional útil en algunas ocasiones. No es una configuración habitual en empresas (al menos no en las no tecnológicas), pero puede ser interesante que busquéis este tipo de patrones en los logs de firewall con las herramientas SIEM… quizás os llevéis alguna sorpresa.

Podcast – 34 – Port Knocking

Podcast – 32 – Protección ante ataques DDoS

Podcast – 32 – Protección ante ataques DDoS

 
 
00:00 /
 
1X
 

Bienvenidos al trigésimo-segundo capítulo del podcast de seguridad informática «Securizando.com»

Soy Andreu Adrover y hoy es viernes 19 de enero de 2018.

Aunque la idea inicial de este capítulo era ser la continuación del podcast 31 y hablar sobre las defensas específicas para los ataques DDoS vía el protocolo HTTP, creo que lo preferible será hacer un capítulo explicando las defensas generales que podemos activar ante ataques DDoS para posteriormente ya centrarme, en otro capítulo, en las técnicas de defensa específicas de HTTP, DNS y demás protocolos. Así pues hoy hablaremos de técnicas genéricas de defensa frente ataques de denegación de servicio. Hay que tener en cuenta que todas estas técnicas (y cualquier en la seguridad informática en general) requieren de una preparación previa: improvisar durante un incidente (un ataque de denegación en este caso) suele ser la receta perfecta para liar más la situación.

  1. Capacidad de crecimiento

    Con el desarrollo de los entornos virtuales las posibilidades de adaptación de los sistemas a los requerimientos de los usuarios se ha visto potenciada. Ahora es normal que las aplicaciones modifiquen sus capacidades en función de la necesidad y del coste asociado: ya no es extraño que durante las horas valle de uso se reduzca el número de servidores mientras que en las horas punta la capacidad del sistema aumente. El hecho de que los entornos virtuales en la nube tenga un coste por uso, ha fomentando en gran medida esta variabilidad del entorno.

    1. Número servidores (crecimiento horizontal)

      Actualmente, la primera opción que nos suele venir a la cabeza en caso de necesitar tratar más conexiones de las habituales es ampliar el número de servidores. Los sistemas virtuales permiten añadir nuevos servidores a la granja de forma rápida y relativamente sencilla. Aumentando el número de servidores se consigue dar servicio a más conexiones, aunque como todo en la vida, siempre hay un límite que no podremos superar (capacidad de transacciones de la base de datos, capacidad de escritora en discos, capacidad de ancho de banda, etc…). Esta crecimiento se denomina horizontal ya que lo que se hace ganar capacidades añadiendo nuevos servidores a la granja y es ampliamente utilizada en las aplicaciones web o distribuidas.

    2. Capacidad sistema (crecimiento vertical)

      En contraposición al sistema anterior, el crecimiento vertical consiste en aumentar la capacidad de los propios nodos del sistema: aumentar la memoria o velocidad de CPU, aumentar la capacidad de disco (ya sea ampliando los filesystems o creando nuevos). Esta estrategia suele tener un mayor coste de aplicación (muchas veces implica reiniciar el servidor para que el sistema operativo tome en cuenta las nuevas capacidades). Así pues se trata de una estrategia más pesada, pero que sería necesaria cuando el cuello de botella se encuentra en sistemas únicos (bases de datos, aplicaciones mainframe, etc.).

    3. Capacidad línea comunicaciones

      Otro punto donde un ataque de denegación de servicio suele ser las propias líneas de comunicaciones. Así aunque el servicio esté operativo si los clientes no pueden llegar a él ya se ha conseguido la denegación de servicio. En los grandes servicios en la nube (AKAMAI, Amazon, Azure, etc.) es un punto que ya está resuelto en su infraestructura propia, pero para aquellos servicios de hosting más pequeños es algo a tener en cuenta. Para aquellas empresas que tienen sus servicios alojados en su propio centro, las operadoras ofrecen líneas de comunicaciones con diferentes capacidades de crecimiento que hay que evaluar: no es extraño contratar una línea de fibra óptica con capacidad de de 1Gbps pero de los que se usan (y pagan) 400Mbps. Así en caso de problemas, simplemente se amplía la capacidad de la línea. Obviamente esta ampliación rápida debe estar acordada previamente con la operadora (cómo se solicita la ampliación, quién está autorizado a solicitarla, y cómo se pagará después ;))

  2. Sistemas IPS – WAF

    Como ya vimos en los capítulos 4 y 29 los sistemas IPS y WAF permiten detectar y bloquear tráfico anómalo mediante el análisis del tráfico que pasa por sus interfaces. Las firmas de detección pueden ser múltiples y dependerán del protocolo utilizado para el ataque: por ejemplo si suponemos un ataque web donde se envía a través de formulario un archivo adjunto grande para saturar las capacidades del sistema, un WAF podría detectar que los usuarios no han seguido el camino normal (acceso a portada, clic en opción de envío, etc.) y que sólo envían directamente el formulario. En este caso el sistema podría descartar el tráfico que no haya seguido el cauce habitual con lo que se descartarían los ataques con mínima afectación a los usuarios habituales.

  3. Listas negras (Direcciones IP de botnet, nodos Tor…)

    Actualmente muchos proveedores de sistemas de seguridad mantienen una serie de listas con direcciones IP de baja o mala reputación que pueden utilizarse para descartar tráfico proveniente de ellas. Estas listas de direcciones IP incluyen equipos que se ha descubierto que pertenece a una botnet (y por ello es probable que en caso de ataque de denegación de servicio sean una de las causantes), que han sido utilizadas en ataques previos o, por ejemplo que son nodos de salida de la red Tor. La red Tor no es intrísicamente maliciosa, pero hay que entender que utilizar este servicio de anonimato para acceder a una aplicación web que debe autenticarse (pago con tarjeta, acceso mediante usuario/contraseña…) no parece una opción muy lógica. Así pues si estamos ante un ataque de denegación de servicio una opción rápida es bloquear el tráfico proveniente de estas direcciones IP de dudosa reputación. Es posible que perdamos algún cliente (porque desconoce que sus equipos formen parte de una botnet), así que no siempre es aconsejable tener estos filtros activados siempre.

  4. Bloqueo por ubicación geográfica

    Los rangos de direcciones IP son asignados por la IANA (Internet Assigned Numbers Authority), en base a unos cálculos de necesidades previstas, de forma distribuida por países. Así pues es posible conocer el supuesto país de origen de una conexión por Internet por esta asociación. Si bien hay un cierto mercadeo de direcciones donde una empresa multinacional compra direcciones de un país donde tengan libres (actualmente principalmente de países africanos) para luego utilizarlas en otras ubicaciones, esta ubicación geográfica es aún bastante correcta.

    Por ello una posible estrategia en caso de sufrir un ataque de denegación de servicio sería bloquear el tráfico proveniente de países donde nuestra empresa no tenga mercado. Por ejemplo si nuestra empresa alquila coches en España es poco probable que nuestro servicio reciba demasiadas peticiones legítimas desde Laos o Tanzania, mientras que sí es muy probable que reciba peticiones desde los principales clientes turísticos (Alemania, Reino Unido…). En cambio si nuestra empresa se dedica al transporte internacional por carretera no será extraño recibir peticiones desde Polonia o Ucrania. En caso de ataque el hecho de descartar todo el tráfico salvo el que provenga de los principales mercados de nuestra empresa mitigará en gran medida el ataque con una afectación mínima a nuestros principales clientes.

  5. Modificación parámetros de protocolos

    Casi los primeros ataques de denegación de servicio que aparecieron tratan de aprovechar los tiempos de espera entre transacciones definidos en los distintos protocolos. Así cuando, por ejemplo, establecemos una conexión TCP (que son necesarias para la mayoría de protocolos usados para navegar, enviar correos electrónicos, etc.), los estándares indican un tiempo máximo en la negociación de dicha conexión. Un usuario malicioso pueden intentar alargar al máximo el tiempo de envío entre paquetes para asegurar así que el receptor reserva durante el máximo tiempo posible sus capacidades (espacio de memoria, tiempo procesador…). Igualmente puede iniciar una conexión pero sin finalizar el proceso de establecimiento por lo que nuestro servidor se quedaría a la escucha (usando recursos) para, pasado el tiempo, descartar ese paquete inicial. Una estrategia para liberar recursos rápidamente es acortar estos tiempos de espera y descartar tráfico posiblemente malicioso antes, de tal forma que se pueda seguir recibiendo nuevas peticiones. Igualmente el sistema podría simplemente descartar paquetes malformados, con errores de transmisión, con un excesivo desorden, etc. en vez de solicitar retransmisiones, evitando así tener que realizar reservas de recursos.

    Actualmente estos ataques no suelen verse de forma independiente sino que suelen acompañar a otros ataques usando protocolos de mayor nivel, pero aún así el hecho de mitigarlos permite a la infraestructura liberar recursos más rápidamente.

    Aunque como teleco ‘me duela’ romper los estándares, hay que tener en cuenta que se trataría de una medida de mitigación de un ataque. El hecho de reducir estos tiempo podría influir negativamente a nuestros clientes con menores capacidades (ancho de banda más limitado, etc.) pero claro, ante un ataque de denegación de servicio hay que elegir el mal menor.

  6. Servicios anti DDoS:

    Actualmente se pueden contratar servicios “en la nube” que mitiguen estos ataques de denegación de servicio gracias a sus mayores capacidades. En este punto existen dos enfoques principales: tener el servicio activo siempre de forma que todo el tráfico pasa por los sistemas del proveedor o bien activarlo únicamente en caso de necesidad. Por obvios motivos esta activación según necesidad requiere de una planificación y acuerdo previo, ya que no se puede improvisar sobre la marcha durante un ataque (aunque los comerciales de estas empresas estarán encantados de decirte que sí que es posible).

    Aunque más adelante le dedicaremos un capítulo a qué ofrecen estos servicios, cómo funcionan, cómo puede realizarse la derivación del tráfico, etc. podemos resumir su función como una de estas dos opciones:

    1. Filtrado de paquetes (firewall): permiten que sólo el tráfico del protocolo elegido llegue a nuestros servidores. Así nuestra infraestructura no recibe los ataques siplementarios (tráfico UDP, inundaciones SYN, malformación de paquetes, etc.).

    2. Actúan como proxy: Los clientes se conectan a su infraestructura y es ésta la que se conecta a nuestros servidores. Así todas aquellas conexiones fraudulentas son descartadas por el proveedor y no llegan a nuestros servidores (evitando la denegación de servicio).

Micro con feed

Fuente imagen: PerfectYourPodcast

Como podéis observar muchas de estas protecciones (tener capacidades de crecimiento no usadas, contratar los servicios de anti-DDoS, mantenimiento de sistemas IPS o WAF,…) implican un coste económico, por lo que una empresa debe evaluar hasta que punto quiere llevar la protección de sus sistemas. Teniendo en cuenta que por temas legales hay una serie de sistemas defensivos que deben estar activos, desde el punto de vista económico hay que evaluar los riesgos y actuar en consecuencia: no sería lógico gastarse miles de euros al mes en un sistema para defender una pequeña tienda de camisetas online cuya caída durante un día completo implique unas pérdidas menores al coste del sistema de defensa. Las grandes empresas deben tener en cuenta los costes intangibles (daño a la imagen de marca, cumplimiento de SLA con proveedores, etc.).

Podcast – 32 – Protección ante ataques DDoS

Podcast – 29 – WAF

Podcast – 29 – WAF

 
 
00:00 /
 
1X
 

En el capítulo de hoy hablaremos sobre los Web Applicaton Firewall (o simplemente WAF). La traducción al castellano podría ser «Cortafuegos para aplicaciones web», si bien este nombre no lo he visto nunca… y como en la gran mayoría de conceptos tecnológicos se usa el nombre o acrónimo inglés.

Micro con feed

Fuente imagen:PerfectYourPodcast

Los firewall (cortafuegos) permiten o bloquean el tráfico en función de su origen, destino o protocolo utilizado, mientras que un IDS/IPS realiza un análisis de la información transmitida para ver su es legítima o un posible ataque. Así vemos que como la función del WAF es precisamente analizar tráfico web, habría que identificar los sistemas WAF como una subcategoría de los sistemas IDS/IPS. Por esto podemos indicar que la palabra Firewall en el nombre de este sistema no es muy adecuada.

Los WAF analizan las peticiones y respuestas HTTP que gestiona una aplicación web. Así es posible buscar patrones de posibles
ataques que busquen aprovecharse de una vulnerabilidad de nuestro sistema web. Generalmente los fabricantes incorporan firmas genéricas para detectar los tipos de ataque más genéricos (inyecciones SQL, ataques XSS, etc.) En general aquellas amenazas que siempre salen en los informes OWASP. Aunque estas firmas genéricas suelen funcionar bastante bien, la potencia de un WAF se demuestra cuando su administrador adapta o crea nuevas firmas especificamente pensadas para los sistemas web a los que da servicio. La gran adaptabilidad es, simultáneamente, su fuerza y su punto débil ya que afinar un WAF implica un conocimiento importante de los servicios web a los que protege de tal forma que se puedan crear las firmas de patrones necesarias para detectar un posible ataque específicamente en nuestra web, usando las variables de la aplicación, etc.

Podcast – 29 – WAF