Existen discrepancias entre administradores de equipos en red sobre la conveniencia o no de bloquear el tráfico proveniente con protocolo ICMP como motivo de seguridad. Pero, ¿en qué se basan estas discrepancias? ¿es conveniente o no?
Comando PING
Como conoces, el comando PING, es utilizado como utilidad de diagnóstico, sobre el estado de comunicación entre uno o varios equipos remotos conectados a una misma red. El comando PING utiliza un protocolo de envío de paquetes conocido como ICMP, por sus siglas en inglés Internet Control Message Protocol; Enviando a un equipo receptor un mensaje de petición de eco o Echo en inglés, determinando así si un host o equipo de destino está disponible; Y si es así el tiempo que le toma a los paquetes en ir y regresar.
Ataque tipo DoS
Si bien, es un comando muy beneficioso para conocer el estado de la red y de los hosts de la misma; Como ocurre con otras herramientas, este puede utilizarse con fines perniciosos. Por ejemplo, realizando un ataque conocido como ICMP FLOOD, este ataque forma parte de los ataques tipo DoS, también de sus siglas en inglés Denial of Service, o denegación de servicio. Este ataque consiste básicamente en colapsar el ancho de banda de la víctima, enviando de forma continuada un elevado número de paquetes ICMP de tamaño considerable, de forma que este, al tener que responder a los paquetes, le produce un elevado grado de sobrecarga, pudiendo llegar incluso a colapsarlo.
También podría ocurrir, que al responder nuestro ordenador a un ping externo, este podría ver descubierta su dirección IP y un atacante, utilizando programas de tipo «sniffer», analizara nuestras tramas y encontrara nuestras posibles vulnerabilidades al sistema.
Por todo ello, es aconsejable deshabilitar respuesta al ping entrante, si nuestro ordenador esta expuesto directamente a una conexión externa. Salvo, evidentemente que nuestro ordenador sea un servidor web, pues en este caso, tendríamos abierto el puerto 80 y de nada nos serviría deshabilitar el ping ya que el propio servicio web muestra nuestra ubicación. Por lo tanto de nada nos serviría el deshabilitarlo.
Desactivación ignorando toda trama ICMP
Si bien este es el método más sencillo para ignorar la respuesta al eco entrante, también es el menos aconsejable.
Este método consiste en la modificación de un archivo en el directorio /proc del estado del kernel del sistema. En concreto, el archivo es:
/proc/sys/net/ipv4/icmp_echo_ignore_all
El contenido de este archivo por defecto es un 0 (cero), lo que en informática, se puede interpretar como un falso. Por ello al tener un cero, nos indica que es falso el que ignore las tramas icmp_echo. Por lo tanto, para ignorar dichas tramas tendremos que cambiar el 0 por un 1 (uno) en dicho archivo. Realizandose a partir de ese momento un ignorado completo de ese tipo de tráfico.
Para la modificación del archivo podemos utilizar la orden:
sudo su
Para acceder como superusuario root, y a continuación el comando:
nano /proc/sys/net/ipv4/icmp_echo_ignore_all
y modificamos el 0 por un 1. A continuación presionaremos [Ctrl] + [O], seguido de Enter, para guardar las modificaciones, y luego presionaremos [Ctrl] + [X] para salir del editor de archivos.
Otro método igualmente efectivo consistiría en escribir los comandos:
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
Tal y como se puede comprobar la modificación del archivo tiene un efecto inmediato, y nuestro host dejara de responder a cualquier ping desde ese mismo momento.
La problemática de este sistema es variada, pues se puede comprobar que este método no es permanente, ya que al reiniciar el sistema, el valor del archivo regresa a 0. Eliminando los cambios producidos. Si lo que queremos es que este cambio perdure a los reinicios del sistema se debería de incluir la sentencia:
net.ipv4.icmp_echo_ignore_all = 1
En el archivo de configuración /etc/sysctl.conf. Quedando su aspecto al indicado a continuación:
Este archivo es utilizado para asignar parámetros de configuración al kernel en tiempo de ejecución. Por lo tanto es equivalente a cambiar los valores en los archivos del directorio virtual /proc/sys.
Este sistema, no impediría, de cualquier modo, la realización de un ping utilizando el protocolo ipv6. Si deseáramos que la respuesta al ping utilizando el protocolo ipv6, también fuera ignorado. Se debería de incluir en el archivo de configuración anterior la siguiente linea mostrada:
Si bien, este método se puede considerar como efectivo. No se puede considerar como adecuado, ya que existen determinadas circunstancias en las que el protocolo ICMP puede ser útil para la resolución de problemas de conexión, o también para aspectos muy importantes para la transmisión de datos. Como puede ser el caso de la «Fragmentation Required» o requisito de fragmentación. La fragmentación es un procedimiento por el cual el emisor divide los datagramas en piezas más pequeñas para que puedan pasar a través de un enlace con una unidad de transmisión máxima o MTU más pequeña. Si se produce un error de transmisión de datos por desborde del MTU, el host emisor, no podrá detectar estos bloqueos ya que las modifiaciones del MTU se envían por protocolo ICMP, el cual tenemos bloqueado su acceso.
Una prueba clara, de que estamos ignorando todo tipo de comunicación que utiliza el protoco ICMP es realizar un PING al loopback de la máquina.
El dispositivo de loopback, es una interfaz de red virtual, usualmente utilizada para probar la capacidad de la tarjeta interna de enviar o recibir datos con protocolo de puerta de enlace de frontera o BGP.
Para ello, realizaremos el comando:
ping 127.0.0.1
y comprobaremos que no existe respuesta al ping.
Deshabilitación por IPtables
Para evitar toda la problemática explicada con anterioridad, es mucho más selectiva y adecuada, la utilización del firewall IPtables, el cual viene integrado en el kernel de linux desde la versión 2.4; Y como forma parte del sistema operativo, puede ser programado aplicando reglas. Las cuales realizan filtrado de los paquetes.
Por tanto, si lo que queremos es evitar la respuesta a ping entrante la orden a introducir sería:
iptables -A INPUT -p icmp –icmp-type echo-request -j DROP
Es importante señalar, la importancia de respetar las mayúsculas y minúsculas en el comando, pues el caso contrario, el comando no se realizaría correctamente.
Por tanto, según el siguiente comando estamos señalando:
| • iptables: | Llamamos al comando que gestiona el firewall. |
| • -A: | Agregar una nueva regla al final de la cadena. |
| • INPUT: | Se gestionará únicamente los paquetes cuyo destino sea el sistema, es decir, nuestro trafico de entrada. |
| • -p: | El protocolo del paquete a comprobar. |
| • icmp: | Indica que es ICMP el protocolo que debe comprobar. |
| • — icmp-type: | Indica, dentro del protocolo ICMP cuál debe analizar. Puede ser: host-unknown, host-redirect, echo-request, etc. |
| • echo-request: | Indica que el echo-request o petición de eco, es el tipo de mensaje que debe rechazar. |
| • -j: | Especifica el objetivo de la cadena de reglas, es decir, la acción a realizar. |
| • DROP: | Indica que el paquete será rechazado, sin enviar notificación al emisor. |
Una vez introducido el comando, podemos comprobar su inclusión en la tabla por medio del comando:
iptables -nL
Con él nos mostrará un listado de las reglas que actualmente se aplican a nuestro sistema.
Como se puede observar en la imagen adjunta, la nueva regla se ha incluido en las políticas o cadenas de entradas o chain INPUT.
Indicando que serán rechazadas, o DROP, las tramas con protocolo icmp de typo 8 o echo-request, cuya procedencia sea cualquiera o 0.0.0.0/0 y su destino sea cualquiera o 0.0.0.0/0.
Como podemos comprobar, de momento no existen políticas ni para cadenas de salida o chain OUTPUT, ni para cadenas de redireccionamiento o chain FORWARD.
Incorporar excepciones al filtrado
Como podemos comprobar, con la anterior regla incorporada a IPtables, la respuesta al ping es ignorada, el problema radica en que si queremos realizar, por ejemplo un ping a nuestra loopback como en el proceso anterior, en este caso tampoco responde. Sin embargo con este sistema, este problema tiene solución.
Es importante señalar que IPtables comprueba de manera secuencial las cadenas de reglas realizadas, empezando por la primera regla y si esta se cumple la ejecuta sin verificar las siguientes reglas. Por lo tanto, si insertamos una regla, que se verifique antes, que la anteriormente ingresada, y esta permite realizar respuesta al ping desde el loopback, esta se producirá.
Para ello podremos introducir el siguiente comando:
iptables -I INPUT 1 -d 127.0.0.1 -j ACCEPT
Con ello estaremos indicando:
| • iptables: | Llamamos al comando que gestiona el firewall. |
| • -I: | Insertar una nueva regla antes de la regla número en la cadena especificada |
| • INPUT: | Se gestionará únicamente los paquetes cuyo destino sea el sistema, es decir, nuestro trafico de entrada. |
| • 1: | Posición en la que queremos insertar nuestra regla. |
| • -d: | Se especifica un destino IP o nombre DNS al que se le aplicará la regla |
| • 127.0.0.1 | Dirección de loopback |
| • -j: | Especifica el objetivo de la cadena de reglas, es decir, la acción a realizar. |
| • ACCEPT: | Indica que el paquete será aceptado. |
En cuyo caso, si volvemos a introducir la orden iptables -nL, el aspecto, sería el indicado:
Como se puede observar, la nueva regla se ha insertado en las políticas o cadenas de entradas o chain INPUT, en la posición 1, juto por delante de la anterior.
Indicando que serán aceptadas, o ACCEPT, todas las tramas, sin distinguir protocolo, cuya procedencia sea cualquiera o 0.0.0.0/0 y su destino sea 127.0.0.1.
Por lo tanto, al haber una cadena de entrada que acepta la comunicación con el loopback y esta es anterior a la de rechazo del ping, todas estas tramas, serán aceptadas por nuestro kernel.
¿Y si quiero aceptar solicitudes de eco desde mi red?
Si se diera el caso, de que quisieramos comprobar el correcto funcionamiento de nuestra red de ordenadores, enviando solicitudes de ping para comprobar su funcionamiento. Sería necesaria la inclusión de una nueva regla que aceptara dicha solicitud.
Si por ejemplo nuestro host se encuentra dentro de una red ordenadores cuyo rango de direcciones esta entre la 192.168.1.0/24. Podríamos indicar que el trafico entrante de solicitud de eco entrante desde cualquier ordenador procedente de esa red fuera también aceptado. Para ello podríamos realizar el siguiente comando.
iptables -I INPUT 2 -s 192.168.1.0/24 -p icmp –icmp-type echo-request -j ACCEPT
Con ello indicaríamos:
| • iptables: | Llamamos al comando que gestiona el firewall. |
| • -I: | Insertar una nueva regla antes de la regla número en la cadena especificada |
| • INPUT: | Se gestionará únicamente los paquetes cuyo destino sea el sistema, es decir, nuestro trafico de entrada. |
| • 2 | Posición en la que queremos insertar nuestra regla |
| • -s: | Se especifica una fuente IP o nombre DNS al que se le aplicará la regla |
| • 192.168.1.0/24 | Rango de direcciones IP con mascara de subred 255.255.255.0 que será aplicada la regla. |
| • -j: | Especifica el objetivo de la cadena de reglas, es decir, la acción a realizar. |
| • ACCEPT: | Indica que el paquete será aceptado. |
Quedando la tabla de políticas del siguiente modo:
Guardar y conservar reglas IPtables
Una de las problemáticas que también tiene este método, es que las reglas de filtrado aplicadas por IPtables, únicamente se aplican durante el tiempo que dure la sesión iniciada. En caso de realizar un reinicio, o un apagado del sistema, dichas reglas se perderán.
Si queremos mantener dichas reglas ante posibles caídas del sistema, deberemos de realizar inicialmente un archivo con la configuración actual de las reglas. Para ello realizaremos como superusuario el comando:
iptables-save > /root/iptables.backup
Con ello, habremos realizado un archivo, denominado iptables.backup con la combinación de reglas actual.
Si quisiéramos restaurarlas de manera manual, la orden a ejecutar sería:
iptables-restore < /root/iptables.backup
Pero si lo que queremos, es que se apliquen al inicio de cada arranque del sistema, será necesario crear un script que ejecutaremos al inicio del servicio de red network.
Para ello generamos un archivo en el directorio /etc/network/if-up.d denominado por ejemplo iptables. Para ello podemos realizar el comando:
touch /etc/network/if-up.d/iptables
Una vez creado, asignaremos a dicho archivo permisos de ejecución. Por tanto, escribiremos el comando:
chmod a+x /etc/network/if-up.d/iptables
Una vez realizado el comando, escribiremos dentro del archivo el siguiente contenido:
#!/bin/sh
iptables-restore < /root/iptables.backup
exit 0
Con todo ello, y si el proceso se ha realizado correctamente, al inicio del sistema, se restaurarán todas las reglas almacenadas en la backup del archivo.
Utilización de firewall UFW
Otra posibilidad que tenemos para deshabilitar el ping en linux es utilizar el firewall UFW acronimo del inglés Uncomplicated Firewall. El cual es un cortafuegos diseñado por Ubuntu para ser de fácil uso. Su utilización es muy similar al iptables, el cual, por medio de una serie de comandos simples añades, modificas o eliminas distintas reglas de aplicación en el sistema.
Inicialmente el firewal ufw está deshabilitado, podemos conocer su estado mediante el comando como root:
ufw status
Para deshabilitar la respuesta al eco entrante, deberemos de entrar en el archivo de configuración del firewall en /etc/ufw/before.rules, mediante el comando:
nano /etc/ufw/before.rules
En él, buscaremos la línea con el siguiente contenido:
-A ufw-before-input -p icmp –icmp-type echo-request -j ACCEPT
En dicha línea, tendremos dos posibilidades de modificación, o comentamos la línea, añadiendo al inicio de la misma una almohadilla o pound (#). O modificamos la palabra ACCEPT por DROP. Si bien el resultado es el mismo, la diferencia radica en que con el primer método obviaremos dicha regla y por tanto no se aplicará, mientras que con el segundo, si se aplica la regla y el resultado es rechazar.
El formato final sería similar al indicado en la figura:
Una vez realizada la modificación, guardaremos y cerraremos el archivo, y a continuación escribiremos el comando:
ufw enable
para iniciar el cortafuegos y comprobar que el funcionamiento es correcto. Una ventaja de este método, es que podemos comprobar que tanto el ping al loopback como el ping a la propia dirección ip del sistema funciona, mientras que no funcionará desde el exterior de la misma.
Si queremos que el firewall, se inicie junto con el sistema en el arranque del mismo. Deberemos de modificar en el archivo /etc/ufw/ufw.conf y poner en:
# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: ‘ufw allow 22/tcp’
ENABLED=yes
También podríamos utilizar la interfaz gráfica de Gufw, la cual, nos facilita su uso, para la aplicación de reglas, así como su inicio o no con el sistema. Si deseas instalar la aplicación gráfica la orden es:
sudo apt-get install gufw
Conclusión
Se podría decir, que la desactivación de la respuesta a ping de una máquina conectada a una red pública, podría ser una buena solución como medida de protección ante posibles ataques. Aunque habría que tener en cuenta, que la desactivación total de la respuesta, en muchos casos nos acarrearía muchos más problemas que beneficios en post de la seguridad.