Álvaro González Sotillo

Pihole y monitorización de red

Hace tiempo que la ONT de la red de mi instituto se colapsaba periódicamente. Para intentar descargarla, instalamos Pihole para reducir las peticiones de DNS, y por tanto la memoria destinada a las conexiones UDP.

A pesar de ello, volvimos a tener una conexión a Internet inestable: unas aulas podían conectarse y otras no, e incluso llegaba a haber diferencias dentro de la misma aula. En mi caso, todos los ordenadores funcionaban excepto el del puesto del profesor.

Descubriendo el ataque

Utilizando la función de network de Pihole encontramos algo anormal: la dirección IP del router se utilizaba por dos equipos de la red con dirección MAC distintas: la propia de la ONT y 1c:6f:65:a7:4d:79. De hecho, la MAC sospechosa se había anunciado en apenas dos horas como 7 direcciones IP distintas.

/assets/blog/pihole-monitorizacion-red/mac-con-siete-ips.png

Figura 1: Listado de direcciónes MAC e IP conocidas por pihole

Empezaba a parecer un caso de ARP Spoofing, quizás como paso previo para un man in the middle. Con tcpdump confirmamos nuestras sospechas.

/assets/blog/pihole-monitorizacion-red/arp-en-tcpdump.png

Figura 2: Comprobación de tráfico ARP con tcpdump

El ordenador con MAC 1c:6f:65:a7:4d:79 enviaba cada dos segundos una respuesta ARP suplantando la identidad del router. En ese momento dicho ordenador consideraba su dirección IP principal como 10.1.0.201.

El contraataque

Utilizando Nmap descubrimos que el ordenador atacante tenía abiertos los puertos típicos de un ordenador Linux, entre ellos el puerto 22 de SSH. Ante la posibilidad de que fuera uno de los ordenadores del centro intentamos acceder por SSH con los usuarios y contraseñas que dejamos en las maquetas de los PC's de aula. Conseguimos entrar sin problemas, lo que nos permitió localizar el aula y puesto del PC. A partir de aquí solo quedaba recuperar información forense para saber exactamente qué había pasado.

Nos desplazamos físicamente hasta el ordenador en un momento en el que los alumnos estaban en otro aula. Utilizando el tty4 observamos que el alumno había utilizado el tty3 para ser superusuario y arrancar un script de python que realizaba las acciones maliciosas de red. Por lo visto, el script no servía para realizar MIM sino para limitar la velocidad del tráfico de algunos ordenadores (una denegación de servicio).

/assets/blog/pihole-monitorizacion-red/tty4.png

Figura 3: Reconstrucción del tty4 (a partir de /dev/vcs4)

Creemos que consiguió ser superusuario arrancando linux en modo singleuser, ya que el arranque GRUB no está protegido por contraseña.

Medidas a tomar en un futuro

En nuestro centro todas las aulas comparten la misma VLAN, y la asignación de IP se hace dinámicamente por DHCP, por lo que la localización del PC atacante fue cuestión de suerte. Si el alumno hubiera utilizado una máquina virtual en modo bridged, tendríamos que haber localizado el aula desconectando poco a poco los switches.

Para que esto no vuelva a suceder tendríamos que tomar las siguientes medidas:

  • Realizar un inventario de direcciones MAC.
  • Definir una VLAN para cada aula, o separar cada aula detrás de un NAT, de forma que el tráfico ARP no se extienda por todo el instituto.
  • Instalar switches gestionables en todas las aulas, que nos permitan localizar de forma fácil las tramas con determinada dirección MAC de origen.
  • Securizar el arranque de los ordenadores de los alumnos: no se debería poder arrancar desde un disco externo ni desde la red, y la BIOS debería estar protegida con contraseña. También debería tener contraseña el gestor de arranque GRUB, y la cuenta de root debería tener una contraseña en vez de estar deshabilitada.