martes, abril 11, 2006

Es habitual encontrar administradores de red, que en un rapto de paranoia o por desconocimiento de las funciones de ICMP, filtran todo el protocolo sin reparar en las consecuencias de esto. Bloquear todo icmp puede traer bastantes molestias, cuando no, serios problemas; por otro lado, no bloquear cierto tipo de mensajes ICMP puede conllevar el riesgo de sufrir algunos ataques basados en las debilidades del protocolo.
En este artículo repaso qué es ICMP, qué permitir y qué denegar de este maravilloso protocolo.

Wikipedia define ICMP como:
"ICMP (Internet Control Message Protocol)
El Protocolo de Control de Mensajes de Internet (ICMP por sus siglas en inglés) es uno de los protocolos centrales de la suite de protocolos de Internet. Es usado principalmente por los Sistemas operativos de las computadoras en una red para enviar mensajes de error, indicando por ejemplo que un servicio determinado no está disponible o que un router o host no puede ser localizado."

Según el modelo OSI ICMP es un protocolo de capa 4, la denominada capa de transporte, esto se debe a que ICMP es encapsulado en paquetes IP.
Ahora ¿qué transporta ICMP? Para empezar, no transporta datos de las aplicaciones de usuario, sino información de control. Esta información de control es usada como soporte de los otros protocolos de transporte.
ICMP está definido por las primeras RFCs (rfc792 y rfc1122.txt), la primera data de 1981. Podemos encontrar una lista de los tipos de mensajes ICMP en:
http://www.iana.org/assignments/icmp-parameters

Usos útiles de ICMP
(lo que no se debe filtrar sin razón)

Destination Unreachable - Para indicar el fracaso de muchos protocolos (como TCP, UDP, GRE, etc.) se usan paquetes de icmp, en particular de tipo 3 "Destination Unreachable" (destino-inalcanzable). Bloquear estos paquetes significa que nunca obtendrá errores como `Host unreachable' o `No route lo host'. Cualquier conexión a un destino inalcanzable esperará hasta el timeout, esto es irritante, pero difícilmente fatal.

Fragmentation needed - Un problema peor se puede generar si filtramos los paquetes de ICMP que participan en el descubrimiento del MTU "Max Transfer Unit". Todas las buenas implementaciones de TCP/IP intentan utilizar el tamaño de paquete más grande que se pueda, esto reduce drásticamente la sobrecarga causada por los encabezados.
Para descubrir el MTU hasta algún destino, se utiliza una técnica conocida como PMTU-D "Path MTU - Discovery", la cual depende de un paquete icmp de tipo "destination-unreachable" con código "Fragmentation needed but DF set" (tipo 3, código 4).
Si filtramos este tipo de paquetes ICMP, se reducirá el rendimiento de TCP para sitios que tengan un MTU pequeño y en algunos casos estos sitios se harán inalcanzables.
Más información en:
- http://www.netheaven.com/pmtu.html
- http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-06.txt
- http://www.lartc.org/howto/lartc.cookbook.mtu-mss.html

Security Failures - IPSec, el protocolo más usado para realizar VPNs, utiliza un tipo especial de mensajes icmp para informar errores de autenticación, si los filtramos desconoceremos de las causas por las que fallan nuestros túneles.
Más en: http://www.ietf.org/rfc/rfc2521.txt

Time to Live exceeded in Transit - El comando traceroute o tracert, está implementado transmitiendo datagramas UDP con distintos valores en el campo TTL "Time To Live" de la cabecera IP.
El campo TTL es reducido en cada salto (cada vez que pasa por un router); cuando un router reduce el campo TTL de un paquete a cero, lo descarta y genera un paquete ICMP con código "Time to Live exceeded in Transit" - "Tiempo de Vida Excedido en tránsito".
Volviendo al comando traceroute, dijimos que éste genera paquetes UDP con distintos TTL, luego espera por los paquetes icmp con código "Time to Live exceeded in Transit" o "port unreachable", los cuales tienen como ip de origen la ip del router que los originó, con esta información genera la ruta que le solicitamos.

Request/Reply - La herramienta ping está implementada utilizando los mensajes "Echo request" y "Echo reply" de icmp, si los filtramos no esperemos hacer ping a ningún lado. Es incorrecto pensar que, porque filtremos los "echo request/reply" de/a nuestros hosts, esto los hará invisibles.
Podemos ser objetos de un ataque de Denegación de Servicio "DoS" con estos paquetes, por lo cual es recomendable aplicar un control de ancho de banda sobre ellos.

Parameter Problem - Estos mensajes son usados para indicar que se encontró un problema durante el procesamiento de los parámetros de la cabecera IP, normalmente dado por la mala implementación del Sistema Operativo, origen o destino; estos errores derivan en la pérdida de la conexión. Descubrir dichos errores sin estos mensajes puede ser muy difícil; sin embargo hay quienes bloquean estos mensajes, ya que pueden ser utilizados para hacer "fingerprinting" (Descubrir qué SO estamos corriendo).

Ataques basado en ICMP y Mensajes Obsoletos
(qué filtrar)

Redirect - Existe un tipo de paquete icmp llamado "redirect", que es usado por un router cuando le llega un paquete, para indicarle a otros equipos que existe una ruta alternativa sin pasar por él. Dado este caso, el router genera un mensaje icmp "redirect", con la información de la ruta que él cree mejor, y lo envía al equipo que le entregó el paquete. Si el equipo que recibe el paquete "redirect" tiene "Fé" en lo que le dicen, acepta la nueva ruta.
Este tipo de paquetes icmp debe ser filtrado ya que puede ser utilizado para ejecutar un ataque de "hombre-en-el-medio", por sus siglas en inglés de MITM; y en una red bien mantenida estos mensajes no deberían ser necesarios.

Source Quench - El mensaje source quench es obsoleto y fue pensado originalmente para que un host destino pueda pedir al host origen que baje el ritmo al que está enviando. Actualmente hay mejores mecanismos para manejar el control de ancho de banda. Y este tipo de mensajes puede ser utilizado para implementar un ataque de DoS "Denial Of Service". En la próxima revisión de icmp será declarado obsoleto.

Otros Obsoletos - "Information Request/Reply", "Datagram Conversion", "Domain Name", "Address Mask Request/Reply" y "Address Mask Request/Reply". La mayoría de estos tenían funciones que ahora se cubren con DHCP.


Notas
  • Hay cierto tipo de ataques basados en paquetes icmp que no son tratados en este artículo. Te recomiendo la lectura del borrador de RFC de Fernando Gont, acerca de esto: http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html
  • En la mayoría de las distribuciones de linux podemos deshabilitar que se acepten los icmp redirect, agregando la siguiente línea al archivo /etc/sysctl.conf:

    net.ipv4.conf.all.accept_redirects = 0

    En cisco por interface con el comando:

    router1(config)# interface Ethernet0
    router1(config-if)#no ip redirects

  • Ejemplo de filtrado con iptables:
    Se puede filtrar los paquetes icmp "source quench" con el siguiente comando:
    $ iptables -I FORWARD -p icmp --icmp-type source-quench -j DROP
    y podemos obtener una lista de los tipos de mensajes icmp con:
    $ iptables -p icmp --help

Referencias
  • http://www.ietf.org/rfc/rfc792.txt
  • http://www.ietf.org/rfc/rfc1122.txt
  • http://www.ietf.org/rfc/rfc2521.txt
  • http://www.iana.org/assignments/icmp-parameters
  • http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-06.txt
  • http://www.netheaven.com/pmtu.html
  • http://www.lartc.org/howto/lartc.cookbook.mtu-mss.html
  • http://www.aarnet.edu.au/engineering/networkdesign/qos/icmp.html
  • http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html

2 comentarios:

Anónimo dijo...

Muy bueno tu artículo, claro y conciso.

Unknown dijo...

Muy buenas definiciones de los conceptos técnicos y de ejemplos.