Cómo identificar y combatir un ataque de caducidad TTL.

144 0 0 0

Hola todos,

 

Estoy seguro de que todos ustedes saben cómo se ve un encabezado IPv4 y cuál es el rol de cada uno de los archivados allí, pero por el bien de la conversación, me tomaré la libertad de describir el único campo que nos interesa en este tema: el TTL campo

164037oxqi3gxq2iq02dzx.jpg

El campo Tiempo de vida indica el tiempo máximo que el datagrama puede permanecer en el sistema de Internet. El valor de TTL lo llena el remitente y se reduce en cada punto en que se procesa el encabezado de Internet para reflejar el tiempo empleado en procesar el datagrama. Incluso si no hay información local disponible sobre el tiempo realmente empleado, el campo debe disminuirse en 1. En realidad, cada módulo que procesa el datagrama específico, reduce el campo TTL en 1, ya que un datagrama hoy en día no se procesa en un segundo completo.

Cuando el campo alcanza el valor cero, el datagrama se descarta. "La intención es hacer que se eliminen los datagramas que no se pueden entregar, y limitar la vida útil máxima de los datagramas".

Por lo tanto, siguiendo la lógica descrita anteriormente, si un dispositivo de red (por ejemplo, router) detecta que el valor TTL de un paquete es 0, el dispositivo descarta el paquete y s un mensaje ICMPv4 Tipo 11, Código 0 al remitente inicial resultando en un impacto correspondiente en la CPU. Era sólo cuestión de tiempo para que una mente malvada pensara en enviar intencionadamente a un dispositivo una gran cantidad de paquetes con el valor TTL menos de 1. Al recibir estos paquetes IP, las CPU de los dispositivos atacados se vuelven ocupados procesando los paquetes y enviando respuestas. De esta manera el uso de la CPU aumenta y todos los servicios de red se ven afectados.

 

¿Ahora qué podemos hacer para descubrir y proteger la CPU?

Una señal de alarma debe ser la aparición de logs que describen que el límite de CPCAR para los paquetes ttl-expired alcanzó el límite:

Oct 10 2014 08:01:01+01:00 Huawei %%01DEFD/4/CPCAR_DROP_MPU(l)[6]:Rate of packets to cpu exceeded the CPCAR limit on the MPU. (Protocol=ttl-expired, CIR/CBS=64/10000, ExceededPacketCount=3594)

 

Sin ninguna configuración especial, el dispositivo generará estas alarmas cuando se alcance el límite CPCAR descrito por la política de cpu-defend predeterminada.

Después de recibir este tipo de registros, debe comprobar cuántos paquetes se envían al cpu o cuántos son descartados. También debe ver si el uso de cpu se ve afectado por ellos.

Aquí los comandos display cpu-usage y display cpu-defend statistics vienen en mano. Si el cpu-usage se ve afectado y el dispositivo está recibiendo un gran número de paquetes ttl-expired deberíamos considerar tomar algunas medidas para reducir el impacto en el cpu e implícitamente en nuestra red.

<Huawei>display cpu-defend statistics all

Statistics on slot 0:

--------------------------------------------------------------------------------

Packet Type          Pass(Packet/Byte)   Drop(Packet/Byte)  Last-dropping-time

ttl-expired                  190434811            61115743  2014-10-09 18:21

                           16574498088          6089746250

--------------------------------------------------------------------------------

 

Soluciones:

Otra razón del alto uso de cpu podría ser el gran número de paquetes ttl-expired que están alcanzando el switch. Vi que ya ha configurado y aplicado una política de defensa cpu para monitorear los paquetes ttl-expired y verificar la fuente del ataque, pero no ha tomado ninguna acción en su contra.

El primer paso debe ser averiguar la fuente del ataque. Para ello podemos configurar una política de cpu-defend para utilizar la función de rastreo de fuentes de ataque para encontrar la fuente ip de la mayoría de los paquetes ttl-expired.

 

        cpu-defend policy p1

auto-defend enable

auto-defend attack-packet sample 4

auto-defend threshold 30////

Cuando el número de paquetes enviados desde una fuente en un período especificado es mayor que el umbral que el dispositivo rastrea y registra la fuente.

auto-defend alarm enable // an alarm is generated when the threshold for packets is reached

auto-defend alarm threshold 30

auto-defend trace-type source-mac source-ip source-portvlan //

Traza las MAC Fuente y las Vlan.

auto-defend protocol ttl-expired 

Identifica los paquetes TTL expirados

 

Cuando haga esta configuración, también debe prestar atención a la tasa de muestreo. Esto también puede afectar el uso de cpu si se utiliza durante mucho tiempo. Una pequeña proporción de muestreo hace que el resultado del rastreo de la fuente de ataque sea preciso, pero aumenta el uso de la CPU.

 

Una vez realizada esta configuración, recibirá mensajes de alarma para informarle cuando se haya pasado el umbral y también podrá verificar el origen con el comando:

display auto-defend attack-source 

 

Ejemplo:

Oct 10 2014 08:02:07+01:00 Huawei %%01SECE/4/PORT_ATTACK(l)[4]:Port attack occurred.(Slot=MPU, SourceAttackInterface=XGigabitEthernet0/0/1, OuterVlan/InnerVlan=200/0, AttackProtocol=TTL_EXPIRED, AttackPackets=36 packets per second)

 

<Huawei>display auto-defend attack-source

  Attack Source User Table (MPU):

  -----------------------------------------------------------------------------

  MacAddress       InterfaceName               Vlan:Outer/Inner    TotalPackets

  -----------------------------------------------------------------------------

 aaaa-bbbb-cccc   XGigabitEthernet0/0/1       200              7696

  -----------------------------------------------------------------------------

  Total: 1

 

  Attack Source IP Table (MPU):

  -----------------------------

  IPAddress        TotalPackets

  -----------------------------

  100.100.160.91   464

  -----------------------------

  Total: 1

 

Podemos ver que muchos de los paquetes vienen del aaaa-bbbb-cccc mac address y creo que podemos poner esta dirección mac en una lista negra para filtrar los paquetes con esa fuente.

La otra cosa que podemos hacer es limitar el ataque es aplicar una política de castigo para descartar paquetes de la fuente de ataque identificada por un período de tiempo. Para ello tiene que modificar la política de defensa de cpu y ejecutar el comando auto-defend action deny timer [time] que descartará paquetes de la fuente de ataque durante un período de tiempo.

 

 

 

 

 

 

  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente
¡Ingresa y disfruta de todos los beneficios para los miembros!

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje