4.6. Conexiones ICMP
Los paquetes ICMP no pueden estar más lejos de ser conexiones de flujo (o "stateful connections"), ya que sólo se usan para el control de las conexiones y nunca deberían establecer ninguna conexión por sí mismos. Sin embargo, hay cuatro tipos ICMP que generarán paquetes de retorno y que presentan 2 estados diferentes: estos mensajes ICMP pueden tomar los estados NEW (nuevo) y ESTABLISHED (establecido). Los tipos ICMP de los que hablamos son: Echo request (petición de eco) y su reply (respuesta o Echo reply), Timestamp request (petición de "marca de tiempo", el valor del momento exacto en que se envía el paquete) y su reply, Information request (petición de información) y su reply, y por último Address mask request (petición de máscara de subred) y su reply. De éstos, los tipos timestamp request e information request están obsoletos y lo más probable es que simplemente se puedan desechar. Sin embargo, los mensajes de Echo se emplean en varias configuraciones, como hacer "pings" a los hosts. Las peticiones de máscara de subred (Address mask requests) no se suelen utilizar, pero pueden ser útiles en ocasiones y vale la pena permitirles que atraviesen el cortafuegos. Para tener una idea de cómo funciona una conexión de este tipo, veamos la siguiente imagen:
Como puedes observar, el host envía una petición de eco (echo request) al destinatario y el cortafuegos considera el paquete como nuevo (NEW). El destinatario responde con una respuesta de eco (echo reply) que el cortafuegos considera mediante el estado "establecido" (ESTABLISHED). Cuando ya se ha visto la primera petición de eco, se crea la siguiente entrada en el ip_conntrack.
icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
type=0 code=0 id=33029 use=1
Como ya te habrás dado cuenta, esta entrada es un poco diferente a las entradas estándar para los paquetes TCP y UDP. Vemos el protocolo, su número, el tiempo de vida que le queda a la entrada, así como las direcciones de origen y destino. La diferencia viene después: tenemos 3 campos nuevos llamados type (tipo), code (código) e id (identidad/identificación). En realidad no son nada especiales: el valor type indica el tipo ICMP y el valor code indica el código ICMP. Todos éllos están disponibles en el apéndice Tipos ICMP. El valor de id indica el ICMP ID: cada paquete ICMP toma un valor ID (de identificación) cuando se envía y al responder el receptor también establece este mismo ID; de esta forma al llegar la respuesta al host que envió la petición se puede unir esa respuesta a la petición ICMP correcta.
En el siguiente campo volvemos a encontrar la bandera [UNREPLIED] que hemos visto anteriormente. Como entonces, la entrada del seguimiento de conexiones que estamos viendo implica que sólo se ha visto tráfico en una dirección. Por último vemos los datos que se esperan en el paquete de respuesta ICMP, que obviamente son los valores iniciales pero invertidos. Por lo que respecta al tipo y al código, se cambian por los valores adecuados al paquete de retorno, de forma que una petición de eco se transforma en una respuesta de eco, etc. El ICMP ID, lógicamente, se mantiene idéntico al paquete de petición.
El paquete de respuesta se considera como ESTABLISHED, tal como ya se ha explicado. Sin embargo, sabemos con seguridad que tras la respuesta ICMP no habrá absolutamente ningún tráfico legal en la misma conexión. Por esta razón la entrada del seguimiento de conexiones es destruida en cuanto la respuesta ha atravesado la estructura de Netfilter.
En cada uno de los casos anteriores la petición se considera como nueva (NEW), mientras que la respuesta se considera como establecida (ESTABLISHED). Más exactamente, cuando el cortafuegos ve un paquete de petición lo considera como nuevo, mientras que cuando el host envía un paquete de respuesta a la petición, se considera como establecido.
 | Ésto implica que el paquete de respuesta debe seguir el criterio fijado en la entrada del seguimiento de conexiones, para poder ser considerado como establecido, de la misma manera que ocurre en el resto de tipos de tráfico. |
Las peticiones ICMP tienen un tiempo de vida por defecto de 30 segundos, que puedes cambiar en la entrada /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout. En general éste es un buen valor, ya que permitirá captar la mayoría de paquetes en tránsito.
Otra parte importantísima de ICMP es el hecho de que se emplea para indicarle a los hosts qué ha pasado con las conexiones UDP y TCP o con los intentos de conexión. Por este motivo las respuestas ICMP muy a menudo serán reconocidas como relacionadas (RELATED) con conexiones o intentos de conexión. Un ejemplo sencillo sería el de los mensajes ICMP Host unreachable (mensaje de host inalcanzable, no se puede llegar al host) e ICMP Network unreachable (mensaje de red inalcanzable, no se puede llegar hasta la red). Este tipo de mensajes se envían automáticamente de vuelta a nuestro host cuando el paquete no consigue efectuar la conexión con un host porque la red o el host de destino están fuera de servicio, de manera que el último enrutador (router) que intente conectar con el destino nos contestará con un mensaje ICMP diciéndonos lo que ocurre. En este caso la respuesta ICMP se considera como un paquete relacionado (RELATED). El siguiente gráfico debería aclarar lo que ocurre:
En el ejemplo enviamos un paquete SYN a una dirección concreta: ésto es considerado como una nueva conexión (NEW) por el cortafuegos. Sin embargo no se puede llegar a la red a la que se está intentando enviar el paquete, por lo que un router (el último) nos devuelve un error ICMP de red inalcanzable. El código de seguimiento de conexiones puede reconocer este paquete como relacionado (RELATED) gracias a la entrada ya existente, por lo que la respuesta ICMP es correctamente enviada al cliente que generó el paquete inicial y, si todo va bien, éste abortará la conexión. Mientras tanto el cortafuegos ya habrá eliminado la entrada del seguimiento de conexiones, puesto que sabe que se trata de un mensaje de error.
El mismo comportamiento se experimenta con las conexiones UDP si tienen problemas como en el caso anterior. Todo mensaje ICMP devuelto como respuesta a conexiones UDP es considerado como relacionado (RELATED). Observa el siguiente gráfico:
En esta ocasión se envía un paquete UDP al host. Esta conexión UDP se considera como nueva NEW. Sin embargo la red está prohibida administrativamente por algún cortafuegos o router antes de llegar a destino y por éllo nuestro cortafuegos recibe un mensaje ICMP Network Prohibited (red prohibida). El cortafuegos sabe que este mensaje ICMP de error está relacionado con la conexión UDP abierta y lo envía como un paquete RELATED (relacionado) al cliente. Acto seguido, elimina la entrada del seguimiento de conexiones mientras el cliente recibe el mensaje y aborta la conexión.