Autor: @elchicodepython
Introducción
Antes de comenzar me gustaría comentar que todos los caminos llevan a Roma y hay mil formas de llegar al mismo punto en un sistema GNU/Linux. Con este manual no estoy diciendo ni que esta sea la manera ideal ni la única para llegar al punto de mitigar estos ataques en redes locales, sino que estoy tratando de explicar detalladamente como defenderte según he aprendido a defenderme yo.
La documentación expuesta a continuación ha sido redactada basándome en libros, foros y experiencias personales. Todo lo que está escrito ha sido probado previamente excepto el protocolo 802.11w expuesto en el punto de Protección ante de-autenticación Wireless que por falta de medios no he podido probarlo.
Las pruebas se han realizado sobre Debian 8
Deshabilitamos IPV6 sino lo estamos usando.
Podemos deshabilitar IPV6 desde el arranque del equipo desde el fichero de configuración/etc/default/grub
Para ello deberemos añadir ipv6.disable=1 en la variable de configuración
GRUB_CMDLINE_LINUX y posteriormente actualizar el grub con la instrucción update-grub
A partir del siguiente reinicio IPV6 estará desactivada.
Podemos comprobar que está desactivada tratando de listar las reglas iptables para IPV6
Protección ante ARP Poisoning
ARP Poisoning es quizá la técnica de MITM más utilizada pues se puede encontrar comúnmente enprogramas de botón gordo. Esta técnica consiste en engañar a dos equipos envenenando sus tablas
ARP para posicionarse en medio de la comunicación entre ellos. Generalmente equipo víctima y
router.
Para establecer entradas ARP estáticas nos podemos valer de la orden
arp -s dirección_IP dirección_MAC
Esta orden deberá ejecutarse en cada inicio de la máquina para que sea efectiva.
También podemos crear una tabla arp en un fichero del estilo
di:re:ci:on:ma:c dire.cio.n.ip
y en cada arranque ejecutar la orden arp -f <ruta/del/fichero>, de no especificar el fichero, al
ejecutar la orden arp -f leerá la información de /etc/ethers
Si no fuera posible la utilización de entradas ARP estáticas podemos utilizar arpwatch.
Arpwatch es un servicio que trata de detectar los ataques de arp-poisoning e ignorarlos. Una vez detectados e ignorados deja registro del correspondiente ataque y manda un correo al administrador informando detalladamente de lo sucedido.
Para instalar arpwatch podemos realizarlo mediante apt-get install arpwatch. Y, sería conveniente reiniciar el equipo para ver que se ejecuta correctamente al bootear.
Deberemos comprobar que el servicio se ha instalado y está funcionando correctamente mediante la orden: service arpwatch status
Este error que podemos ver se debe a que arpwatch se inicia previo a iniciarse los servicios de red.
Véase el hilo: http://forums.fedoraforum.org/showthread.php?t=241779 ó, si nuestro equipo no es
un servidor sino que es un equipo de escritorio, si estamos usando GNOME o KDE, networkmanager
toma el control de la red y hasta que no asigne una dirección de red arpwatch fallará al
iniciarse.
En ese caso una vez nos hayamos logueado y conectado a una red podremos reiniciar el servicio
manualmente y comprobar su estado con:
service arpwatch restart && service arpwatch status
Buscando una forma de automatizar este proceso podemos encontrar esta solución:
NetworkManager dispone de una carpeta donde poder colocar Scripts que se ejecuten al iniciar o
parar el servicio.
Esta carpeta es /etc/NetworkManager/dispatcher.d y la carpeta donde debe ir el Script es la
siguiente:
/etc/NetworkManager/dispatcher.d/pre-up.d/
ejecución y se ejecutaría cada ver que las interfaces se levanten.
Para evitar errores por parte de arpwatch al seguir encendido cuando desconectemos la red.
Podemos crear otro script situado en /etc/NetworkManager/dispatcher.d/pre-down.d/ con el
siguiente contenido:
De esta manera cada vez que nos desconectemos desconectaremos también arpwatch.
Además, ya en este caso que estamos iniciándolo cuando nos conectamos a una red deberemos quitar su inicio del startup del sistema.
update-rc.d -f arpwatch remove
Comprobamos que se ejecuta correctamente desconectándonos y conectándonos con NetworkManager a una red y ejecutando service arpwatch status fijándonos en el tiempo que lleva ejecutándose. Así comprobaremos que si son x segundos ha sido NetworkManager quién ha reiniciado el servicio correctamente.
Por último reiniciamos el equipo y ejecutamos de nuevo service arpwatch status una vez nos conectemos a una red. Si no hay errores la configuración habrá tenido éxito.
Protección ante DNS Spoofing
Generalmente cuando nos conectamos a una red, el servidor DHCP correspondiente nos asigna una dirección IP, una puerta de enlace y unos servidores DNS.Los servidores DNS a utilizar están en /etc/resolv.conf
En principio bastaría con editar ese fichero para poner los servidores DNS que deseamos utilizar.
No obstante, si estamos utilizando NetworkManager este fichero lo sobre-escribe NM con los contenidos ofrecidos por el servidor DHCP
Hay un par de pequeños “hacks” a este pequeño problema de utilidad. Podriamos modificar el Script de dhcp, por ejemplo, pero es más sencillo -a mi opinión- modificar el fichero /etc/resolv.conf y no permitir la modificación del mismo por nadie con el atributo inmutable.
En este caso he puesto los servidores DNS de Google y he añadido el atributo inmutable a
/etc/resolv.conf para que NM no pueda sobre-escribirlo.
Esta solución es válida siempre y cuando nuestro sistema de archivos nos reconozca el atributo de
inmutable como pueden ser ext3 o ext4.
Para modificar el script de DHCP y ver otras soluciones dejo aquí el hipervínculo en el que me he basado para esta parte del artículo: https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/
Comprobamos que la configuración que hemos aplicado no se sobre-escribe reiniciando el equipo y viendo después la información del archivo /etc/resolv.conf
Si la información que hemos puesto prevalece todo se habrá realizado correctamente.
Para asegurarnos de que la resolución de nombres en la que confiamos es correcta. Podemos no confiar en ella y establecer nuestras propias entradas del estilo.
IP Dominio
Estas entradas se establecen en el fichero /etc/hosts y prevalecen sobre las direcciones que ofrezcan los servidores DNS.
Como curiosidad cabe destacar que los primeros servidores DNS utilizaban un archivo Hosts donde
guardaban toda la correspondencia de dirección IP – Dominio
Una vez configurado el archivo /etc/hosts con las correspondencias IP - Dominio de los sitios que queramos asegurar. Al resolver las peticiones se utilizará la correspondencia dada en nuestro archivo antes de la que nos podría brindar el servidor DNS.
Este fichero, además de asegurarnos que accederemos a esas direcciones IP independientemente de la dirección que nos fuera a dar nuestro servidor DNS si se la pidiéramos -que no lo vamos a hacer porque ya la tenemos-. Nos garantiza que en caso de que los servidores DNS que estemos utilizando se caigan podamos seguir realizando la resolución de nombres a los lugares que indiquemos en este fichero.
Protección ante Rogue DHCP
Un Rogue DHCP es un servidor DHCP “falso” o malicioso que no tendría por qué estar en la red. Este tipo de servidores DHCP emiten paquetes con ofertas de configuración a las máquinas cliente. Es muy complicado distinguir cual es el servidor correcto de la red y la configuración a escoger es la primera en llegar. Por lo que en cuanto se emita la petición DISCOVERY será una carrera entre elservidor DHCP legítimo y el malicioso por llegar al cliente.
Un tipo de protección sería no relegar la configuración a un servidor DHCP sino que usar una configuración estática en el caso de que nuestra red no cambiase. Al usar una configuración estática
no hacemos caso de los paquetes enviados por un servidor DHCP y este tipo de ataque deja de tener
sentido.
En el caso de que necesitemos si o si utilizar un servidor DHCP como podría ser en la mayoría de
los casos podríamos filtrar identificando a qué servidores hacemos caso y cuales no.
Si sabemos con certeza la dirección IP del servidor DHCP legítimo, generalmente el router que actúa también como puerta de enlace, podemos crear una regla con ebtables que es el correspondiente a iptables en la capa 2.
Además como ebtables trabaja sobre dispositivos de tipo bridge deberemos deberemos instala la utilidad bride-utils por medio de apt-get install bridge-utils y configurar nuestra interfaz en modo
bridge.
https://wiki.debian.org/BridgeNetworkConnections
Una vez aplicado esto y reiniciados los servicios de red podremos aplicar la siguiente regla
ebtables -A INPUT -p 0x0800 --ip-proto udp –ip-source ! Direccion.ip.del.servidorlegitimo
--ip-source-port 67:68 -j DROP
En el caso de que desconociéramos el servidor a utilizar puesto que tenemos un equipo portátil y
nos movemos de lado a lado en diferentes redes, por ejemplo. No nos queda otra que revisar la
configuración que nos ofrece el servidor DHCP. Los datos más importantes a revisar son la puerta
de enlace o gateway y los servidores DNS a utilizar. Además si hemos seguido los pasos de este
manual deberíamos utilizar nuestros propios servidores DNS independientemente de los que nos
brinde el servidor DHCP por lo que el punto a revisar más importante es el gateway.
En el caso de que desconociéramos la dirección de la puerta de enlace iríamos a ciegas, no obstante
esta suele ser por lo general la primera, o última dirección de la red. Es decir, si la red es
192.168.1.0/24 la dirección IP de la puerta de enlace tienda a ser la primera o última dirección de la
misma, es decir: 192.168.1.1 ó 192.168.1.254. Si la dirección de la puerta de enlace es otra distinta
hmm.. thats suspicius. De todas formas la mejor manera de ver si vamos directos hacia la puerta de
enlace ó, por el contrario tenemos a alguien entre medias y realizar un traceroute y mirar atentamente y con unos conocimientos de redes mínimos si en los saltos vemos algo raro
En la imagen Magnezone está tratando de averiguar si sale directamente a través de la puerta de enlace utilizando la utilidad traceroute pero para su sorpresa tiene una IP desconocida entre medias. (192.168.1.51) Es posible que alguien por medio de alguna técnica de MitM se haya conseguido colocar entre él y la puerta de enlace.
Para simplificar la búsqueda de un rogue DHCP he intentado buscar una herramienta similar a arpwatch pero para este tipo de ataques en Debian pero no he encontrado ninguna. No sé si por inexistencia o por falta de suficiente búsqueda. Así que he creado una herramienta llamada HoneyCheck que emite paquetes DHCP Discover y descubre si hay más de un servidor DHCP dentro de la red. (Cabe destacar que a día de hoy es una ALFA y le queda mucho desarrollo y modificaciones.)
De ser así realiza una acción, si habían más de uno pero ya no, realiza otra y siempre siempre
realiza una tercera acción.
Algo así como
switch(dhcp_maligno)
case SI:
fail_test();
break;
case YA_NO:
pass_test();
break;
finally:
final_exec();
Para no hacer interminablemente larga esta parte del artículo durante esta semana dejaré que mis más cercanos la prueben y comprueben errores que durante el desarrollo no haya tenido en cuenta y en el próximo artículo explicaré detalladamente el funcionamiento de esta aplicación así como como agregarle módulos y personalizarla a medida.
No obstante lo mejor de lo mejor es siempre que se pueda preguntar al administrador de la red por los datos correctos y a partir de ahí crear la regla en ebtables.
La configuración manual es imbatible.
Protección ante ICMP Redirect
Desde iptables podríamos deshabilitar directamente todos los paquetes ICMP lo cual sería un tanto
radical, a no ser, que justo estemos buscando eso. En su lugar podemos deshabilitar o habilitar la
aceptación de redirecciones en tiempo real poniendo a 0 o a 1 el siguiente fichero:
Deshabilitando temporalmente ICMP Redirect:
Para deshabilitarlo permanentemente deberemos editar el fichero de configuración
/etc/sysctl.conf descomentando la línea o creándola net.ipv4.conf.all.accept_redirects = 0
La línea de ipv6 no hará falta des-comentarla pues ya hemos deshabilitado ipv6 previamente
en este caso.
Por último reiniciamos y comprobamos que la configuración ha surgido efecto.
Protección de las conexiones sin cifrar
Hasta este punto hemos controlado ciertos aspectos pero en caso de que nos pinchen la conexión
(que esto sigue pasando, sólo que de formas más chulas que nunca: -véase la famosísima Lan
Turtle-), nos hagan un maravilloso Man In The Router: es decir, el atacante tenga el control del
router, porque ha conseguido acceso a él o porque ha conseguido hacernos creer que es la puerta de
enlace y todo nuestro tráfico pasa a través de él, a nuestro switch le de por actuar en modo Hub,
véase Macof, etc... En caso de que nada de lo que hayamos podido hacer surja efecto nos quedan las
medidas de contingencias. Es decir, si ya lo tienes, por lo menos, que no puedas leerlo.
En un mundo ideal todos los sitios utilizan conexiones HTTPS, SSH, SFTP, etc. Pero
desafortunadamente muy a menudo nos encontramos con conexiones HTTP, Telnet, FTP que van
sin cifrar. En el caso de que nuestros datos vayan sin cifrar si un atacante tuviera acceso a ellos
podría leerlos tranquilamente.
Podemos evitar esto en nuestra red local navegando a través de una VPN preferentemente de
nuestra propiedad. Todo nuestro tráfico pasará a través de la VPN de forma cifrada lo que significa
que el tramo de conexión entre nosotros y la VPN contará con nuestro cifrado y el tramo de
conexión entre la VPN y el resto del mundo estará sin cifrar o con el cifrado que proporcione el
servidor al que estemos accediendo del resto del mundo. -Se da por supuesto que nuestro servidor
VPN sale al exterior de una forma limpia, es decir, sin intermediarios que espíen nuestros datos-.
Como crear nuestro propio servidor VPN y conectarnos a él sería casi la mitad de largo de este
artículo he decidido dejar esa parte a posteriori y enseñar a configurar con pelos y señales un
servicio OpenVPN en una Raspberry Pi en el mismo.
Protección ante de-autenticación Wireless
Utiliza el protocolo 802.11w, o, olvídate del Wireless y realiza la conexión por cable.
El siguiente extracto sacado de http://www.networkworld.es/ explica brevemente el estándar
802.11w.
802.11w extiende la seguridad inalámbrica del estándar 802.11i a las tramas de gestión para evitar
escuchas y falsificaciones. En este ejemplo, un punto de acceso y un cliente se configuran para
utilizar tramas de gestión 802.11w e intercambian todas las claves necesarias.
1- El punto de acceso envía una solicitud de medición 802.11k unicast y el cliente transmite los
resultados. En ambos casos, los contenidos del mensaje se ocultan al agresor.
2- El agresor intenta enviar una solicitud de medición falsificada. Como no conoce la clave, no
puede encriptar adecuadamente la solicitud de medición y el cliente la deshecha sin ningún daño.
3- El punto de acceso utiliza un código de integridad del mensaje para enviar una trama broadcast
a los clientes con el fin de regular su potencia. Los clientes verifican el mensaje con la clave de
integridad. El agresor también ve el mensaje y conoce los contenidos pero no puede crear un nuevo
mensaje falso a partir de éste.
4- El agresor intenta emitir un mensaje de de-autenticación. Los clientes reciben el mensaje y
comparan sus claves de uso único con la del mensaje. Dado que el agresor no conoce la clave del
punto de acceso, las claves no coincidirán y los clientes ignorarán el mensaje de forma segura.
No hay comentarios:
Publicar un comentario