Archivo de la categoría: Defensas

Podcast – 36 – Entrevista con Bernat Mut sobre los antibots

En este capítulo hablaremos de los sistemas antibot con Bernat Mut, de la web BitsDeLocos. Repasaremos su funcionamiento, su diseño y veremos cómo protegen a las webs de venta on-line frente a los rastreadores de tarifas.

Micro con feed
Fuente imagen:PerfectYourPodcast

Daremos un repaso a las diferentes generaciones de sistemas bot rastreadores de tarifas, sus características y cómo las empresas han evolucionado sus sistemas defensivos para detectarlos y bloquearlos.

Como vemos se trata de una función muy específica que va más allá de las posibilidades de los cortafuegos o de los IPS. Aunque los IPS pueden adoptar algunas de las medidas básicas de los sistemas antibots no pueden cubrir todas las protecciones incorporadas en los sistemas antibot.

No dudéis en seguir a Bernat en el propio blog o en su cuenta de Twitter.


Podcast – 32 – Protección ante ataques DDoS

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 – 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.

Podcast – 28 – Proteger la red local