Podcast – 30 – Firewall

En el trigésimo capítulo de un podcast de seguridad informática aún no he dedicado un capítulo específico a unos de los sistemas de seguridad más clásicos y aún más usados: el firewall.

Micro con feed

Fuente imagen:PerfectYourPodcast

En general, ya digo que hay otras posibilidades de comunicación, una conexión por Internet tiene esta tupla de valores: dirección IP y puerto de origen; dirección IP y puerto de destino; y el identificador del protocolo usado.

Los firewalls tradicionales utilizan estos 5 valores para determinar si una conexión es legítima o no y actuar en consecuencia. Cuando llegue un nuevo paquete a nuestro cortafuegos comprobará si se cumplen las 5 características y en tal caso, y sólo en tal caso, permitirá que el tráfico siga su camino hasta el servidor. Si alguna de los cinco valores no se cumple simplemente se eliminaría ese paquete.

Las reglas de funcionamiento del firewall tradicional deben usar cualquier combinación de estos 5 parámetros: pueden fijarse los 5, o sólo 3 dejando los otros 2 abiertos a cualquier opción, etc.

Así pues, habiendo explicado, grosso modo, el funcionamiento de un cortafuegos de red tradicional veamos cómo ha evolucionado y se ha perfeccionado el concepto:

Tras el primer sistema de filtrado de paquetes, el siguiente paso en los firewall fue el conocido como “cortafuegos de estado”. En este punto el sistema ha evolucionado para, además de ver si el tráfico cumple con las cinco condiciones, además tiene sentido. Cuando se realiza una conexión TCP se establece una negociación de parámetros previa. Así un firewall de estado puede revisar si el tráfico recibido, que sí cumple las cinco condiciones de acceso, además tiene sentido en el flujo de tráfico: si se trata de un paquete de tráfico, pero no se ha negociado antes la conexión entonces lo descarta. Este sistema de control de estado permitiría una primera protección frente a ataques de denegación de servicio.

El siguiente paso en la evolución de los sistemas cortafuegos analizaría no solo el estado de la conexión sino el funcionamiento de la aplicación. Aquí el sistema analiza el tráfico y comprueba que siga las reglas del protocolo de aplicación. Así pues, si para enviar un correo electrónico existe un orden específico en las instrucciones a ejecutar para que el envío funcione: es de suponer que el tráfico legítimo seguirá las reglas marcadas por el propio protocolo por lo que cualquier tráfico que no las siga puede ser descartado. Hay que aclarar que no se trata de un IPS: Aquí el firewall analiza el correcto seguimiento del protocolo de comunicaciones pero no analiza las peticiones específicas en busca de patrones, como sí haría un IPS, como explicamos en el capítulo 4.

Podcast – 30 – Firewall

Podcast – 29 – WAF

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 específicamente 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.

Descarga directa.

Podcast – 28 – Proteger la red local

En diferentes programas hemos visto estrategias lógicas, tanto de ataque como de defensa, pero hoy bajaremos a una defensa más física: cómo podemos proteger nuestras redes locales para que no sean alteradas sin el consentimiento de su administrador.

Micro con feed

Fuente imagen:PerfectYourPodcast

Cuando una empresa tiene diferentes sedes es muy común que la gestión de la red local esté centralizada en un equipo administradores (según el tamaño de empresa el “equipo” puede ser una única persona, y puede que no sea su única labor…) que trabaja desde una oficina a cientos o miles de kilómetros de las otras bases. Así, ¿cómo puede el administrador de red minimizar problemas de red física local en ubicaciones tan lejanas donde, generalmente, otras personas pueden acceder y trastear sin ser vistas?

Para asegurar el comportamiento esperado de la red local, un administrador de redes se asegurará de, al menos, estos tres puntos:

  1. Los equipos de red (switches, routers…) deben estar en un cuarto cerrado bajo llave donde sólo una o dos personas puedan acceder. Si los equipos están en una sala común al alcance de cualquier trabajador o visitante es mucho más probable que alguien los toque y acabe generando problemas. Así pues hay una primera seguridad física: hay que evitar que sean alcanzables físicamente.
  2. El segundo punto sería una seguridad lógica que impida que la gestión del equipo sea accesible desde la propia red local. Por norma general un administrador de redes controlará y administrará sus equipos utilizando una red lógica diferente a la de los usuarios. Así pues, siempre que sea posible, se creará una VLAN específica para la gestión de los propios equipos de red. Esta VLAN será diferente a la red donde están conectados los equipos de usuario (ordenadores, impresoras, puntos Wifi, etc.). Además se aplicará una política de acceso de tal forma que únicamente los administradores puedan acceder a esta red de gestión específica: nadie de la oficina remota debe poderse conectar a la consola de gestión de los equipos de red. Lo ideal es que cualquier intento genere una alarma que avise al administrador para que pueda actuar en consecuencia (y darle un tirón de orejas al usuario cotilla).
  3. Nos falta el tercer punto: proteger a la red en su conjunto. No es nada raro que ya sea por ampliaciones no previstas o porque alguien considera que necesita más tomas de red en una sala de reuniones conecten switches o hubs a la propia red. Generalmente estos equipos vienen configurado para que funcionen a la primera sin más preparación (Plug&Play), pero en manos de una persona no técnica estos añadidos pueden acabar con un espagueti de cables y una red con una gran cantidad de interconexiones que la haga lenta e incluso que provoque pérdidas de servicio: No sería la primera oficina que se queda sin red porque alguien conectó los dos lados del cable al mismo equipo generando un bucle físico que acaba en tormentas de tráfico que inundan la red y la inutilizan. Así pues para proteger el correcto funcionamiento de la red local, un administrador debe hacer lo posible para evitar que conecten equipamiento de red no previsto que pueda generar problemas. Para ello hay dos estrategias básicas en función de los equipos de red que se pueden conectar:
      1. Los hubs (o concentradores) son equipos tontos que simplemente multiplican el número de equipos que se pueden conectar a la red. No tienen inteligencia alguna y cualquier cosa que reciben por un puerto de red lo envían por el resto. Son poco eficientes y propensos a generar tormentas de broadcast, pero son baratos. ¿Cómo evitamos que conecten un hub a nuestros equipos de red? Limitando el número máximo de equipos que pueden conectarse a cada una de nuestras tomas de red. Así si en una boca de red donde sólo debería haber un ordenador de usuario, nuestro equipo detecta dos o más sabremos que pasa algo raro. La estrategia más común es inhabilitar dicha toma (dejando sin servicio a esos ordenadores) para proteger la red en su conjunto.
      2. Como hemos dichos los hubs son equipos poco eficientes por lo que tienden a ser sustituidos por los switches (o conmutadores). Una de las grandes ventajas de los switches es su capacidad para detectar bucles de red y permitir la redundancia de caminos: así si cae una conexión pueden activar otra que tuvieran reconocida previamente para que los usuarios sigan teniendo servicios. Este capacidad de redundancia se consigue mediante el protocolo de spanning tree (o sus variantes más modernas). Este protocolo intercambia mensajes BPDU entre los switches de tal forma que todos aprenden una topología de red y detectan aquellos caminos redundantes que pueden usar en caso de problemas con la topología inicial. Los ordenadores o impresoras no utilizan este protocolo, ya que es algo propio de los switches, por lo que si nuestros equipos de red detecta tráfico BPDU desde una toma de red que debería ser de equipo final (el PC de un usuario) puede asumir que alguien ha conectado un switch y bloquear dicha toma de red para proteger al resto.

Descarga directa.

Podcast – 27 – Pentesting

El pentesting es un tipo de ataques a un sistema en búsqueda de localizar, y explotar, vulnerabilidades de un sistema informático. Así pues los pentester buscan debilidades para ‘penetrar en el sistema’ (de ahí el nombre).

pentesting

PENTESTING. Fuente imagen:Cuculmeca

Lo primero indicar que en España realizar este tipo de ataques es ilegal salvo que lo hayas acordado con el propietario del sistema. Así que si cuidado con lo que hacemos… que puede tener consecuencias 😉
Cuando se contrata un pentesting tanto la empresa «víctima» como el analista acuerdan diferentes puntos (qué se puede atacar exactamente, qué técnicas, el horario de los ataques, si se permite tirar el servicio o no se puede provocar DoS), etc. Esto debe aclararse y firmarse por escrito antes de empezar este tipo de consultorías para evitar futuros problemas legales.
Los tipos de ataque de pentesting se categorizan por:

  • De «caja negra» donde el consultor externo no conoce nada del sistema a atacar (sólo la dirección web, ). Se utiliza este tipo de análisis para simular al máximo la situación real en la que un atacante externo quisiera entrar en nuestro sistema. Este tipo de ataque requiere de especialistas más formados y la validez de este resultado depende en gran medida de la capacidad del auditor.
  • De «caja blanca» donde el auditor externo tiene acceso a toda la información sobre la aplicación(arquitectura, servicios usados e incluso el código fuente). El análisis puede ser mucho más profundo y permite preparar y diseñar pruebas específicas de tal forma que se obtenga un resultado más fiable y auditable por un tercero externo.
  • Las de «caja gris» son un punto intermedio entre las dos anteriores donde el atacante recibe parte de la información pero no toda(p.e. tiene el diseño lógico de la aplicación pero desconoce el sistema operativo de los servidores).

Si bien se han desarrollado diferentes metodologías que han buscado unificar y procedimientar este tipo de ataque (sobretodo de cara a la aplicación de normativas y estándares) siendo los más famosos Kill-Chain (una metodología de origen militar), OSSTMM, ISSAF, la guía OWASP (únicamente de aplicaciones web) o la Penetration Testing Framework; la verdad es que el pentesting sigue siendo un proceso manual que depende en gran medida de la experiencia previa, capacidad y pericia del auditor.

Micro con feed

Fuente imagen:PerfectYourPodcast

Aunque todas las metodologías mencionadas antes tienen diferencias podemos decir que en todas tendrían, de una forma u otra, las siguientes fases:

  1. Preparación
    Esta sería una fase teórica de preparar los equipos, tanto hardware como software y equipos humano para realizar el ataque. También se puede incluir en esta fase la negociación del alcance y objetivo de la auditoria con el cliente.
  2. Recopilación de información
    En esta fase el atacante busca obtener la máxima cantidad de información posible del objetivo. Se pueden utilizar métodos pasivos o activos, búsqueda de información pública (dominios, URL, servicios publicados, direcciones físicas, noticias de empresa [si hay una noticia de que la empresa víctima usa Office365 y tenemos una pista para empezar], etc.). El atacante también obtendrá información con acciones activas como pueden ser un escaneo de puertos o consultas DNS.
    Esta fase es probablemente la menos técnica y divertida pero es la base imprescindible para las siguientes fases.
  3. Análisis de vulnerabilidades
    Una vez obtenida toda la información posible toca buscar las debilidades de los sistemas a analizar. Como se puede obtener las técnicas y estrategias usadas serán diferentes en función del objetivo a analizar: no tendrán las mismas vulnerabilidades una aplicación web que los servidores FTP o de correo corporativo. En función del alcance del ataque (que siempre hay que aclarar antes de empezar) los objetivos y estrategias variarán.
    Esta es la fase donde la calidad del auditor destaca especialmente.
  4. Explotación de vulnerabilidades
    En esta fase, una vez localizada la vulnerabilidad se procede a su aprovechamiento de tal forma que se demuestre la viabilidad del ataque y por ende la posibilidad de intrusión exterior. Esta es probablemente la fase más delicada ya que puede implicar la pérdida de servicio por parte del cliente o la extracción de información confidencial (para demostrar que se ha podido acceder). Nuevamente recordar que antes de lanzar un pentest hay que negociar con el cliente qué se puede/debe hacer y cuáles serán las pruebas que demuestren que el atacante ha podido entrar.
  5. Documentación
    El último, e imprescindible paso, es documentar de forma clara y con las pruebas obtenidas en la explotación de las vulnerabilidades de tal forma que se demuestren los problemas y se pueda informar al cliente de cuáles son y qué debe hacer para remediarlos.

Descarga directa.