Análisis y medidas de defensa en una red local. Parte I

Recientemente he hablado sobre el ARP spoofing, y los peligros que poseen este tipo de ataques y ,en base a ello, en esta ocasión hablaré sobre los diferente métodos de detección y protección en una red local (LAN). Para todas las pruebas usaré el sistema operativo Debian, en concreto la versión Wheezy, pero cualquier sistema basado en Debian debería de ser capaz de hacer prácticamente lo mismo que voy a explicar aquí. Para evitar que esto quede demasiado extenso, este post quedará divido en dos partes:

Preparando el entorno para analizar la red

Lo ideal es que los ataques nunca se lleguen a producir gracias las diferentes medidas de seguridad, tales cómo el cortafuegos, mínima exposición de los elementos, switches robustos, etc... Pero no siempre se puede y hay veces en las que si uno protege su entorno en demasía, éste sea engorroso de utilizar o que bloquee más cosas de las que uno realmente desea. Por ello es recomendable tener siempre un ordenador monitorizando la red. Para ello existen varios métodos. Uno de ellos es el método del ARP spoofing, pero no es el más adecuado en caso de ser el dueño de la red, especialmente debido a que es un método muy agresivo y porque en caso de ser el administrador de la red, lo normal es usar métodos que no sean perjudiciales para el rendimiento de ésta. Lo normal es tener controlado todo el tráfico que vaya al servidor, para lo que, a menos que se tenga acceso directo con privilegios de administrador al servidor, se usaría uno de estos métodos.

1. Uso de un hub: Este método es el más sencillo de todos, pero requiere tener un hub cerca, cosa que no siempre es posible. A dicho hub se conectarían 3 cables de red. Uno a el PC que va a realizar la monitorización, uno al servidor que queremos vigilar y otro al switch. Alguno se preguntará por qué no se puede uno conectar directamente al switch; el motivo es que si se hiciese, sólo se vería el tráfico entre el switch y el PC, sin ver nada del tráfico del resto de dispositivos.

2. Port mirroring: Este es el método más cómodo si se dispone de esta funcionalidad en el switch. No todos soportan esta funcionalidad, pero en caso de tenerla puede resultar muy útil. El objetivo de esa funcionalidad es duplicar el tráfico de un puerto del switch a otro. Para ello ambos puertos tienen que tener la misma capacidad (suele ser lo normal pero por aclarar).

3. Modo bridge (puente): Imaginemos que por la razón que sea no se tiene acceso al switch (switch comprado a un proveedor que por política de empresa no permite acceso, firewall, etc...)y tampoco se tiene un hub; Un método que se puede usar es el "machine in the middle" que usa el mismo concepto que el man in the middle, con la diferencia de que la intercepción se hace a nivel físico. Este método requiere que el PC que va a analizar la red, tenga instaladas dos tarjetas de red. Una se conectaría al switch y otra al servidor; pero con eso no basta, hay que crear un puente para que el tráfico fluya de una tarjeta a otra. Para ello se necesita tener instalado bridge-utils mediante apt-get install bridge-utils.

Al finalizar la instalación, la máquina poseería los recursos necesarios para realizar el puente, pero todavía no estaría realizado. Para crear el puente en cuestión habría que escribir en la terminal lo siguiente:

brctl addr puente

brctl addif puente eth1

brctl addif puente eth0

ifconfig puente up

Y con ello ya estaría el puente hecho; El poner este puente no debería de hacer que aquellos que quieran acceder al servidor perciban nada, siempre y cuando la capacidad de las tarjetas de red sean equivalentes a las del switch y las de servidor.

Estos serían los métodos que se pueden usar para controlar el tráfico que fluye entre el servidor y el switch; El más recomendable suele ser el port mirroring, pero cada uno debe de ver que elementos tiene a su disposición y qué es lo que más se adapta a sus posibilidades.

Detectando y bloqueando el ARP spoofing

Uno de los ataques más comunes y extendidos es el ARP spoofing, pero por suerte se puede detectar con relativa facilidad si se está revisando la red. Para ello hay varios métodos; Uno de ellos es mediante arpwatch. Arpwatch puede detectar la actividad en las tablas ARP, con lo que en caso de toparse con cualquier actividad sospechosa lo reportaría; al no estar instalado por defecto, habría que instalarlo en caso de no haberlo hecho previamente. Por suerte los repositorios de la mayoría de las distribuciones de Linux incluyen dicho software con lo que sólo habría que escribir:

apt-get install arpwatch

El paquete a descargar es muy ligero y no causará ningún problema en el sistema operativo. Ahora sólo habría que arrancar arpwatch o reiniciar el PC para poner en marcha el servicio que funcionará de forma transparente en el sistema y que a primera vista parecerá que no hace nada. Sin embargo, si se revisa el fichero "syslog", se verá que arpwatch detectará cualquier cambio en la red. Probemos el siguiente comando:

tail -n 100 -f  /var/log/syslog |grep arpwatch

Este comando analizaría las 100 últimas líneas del fichero syslog y mostraría sólo aquellas que mencionen la palabra "arpwatch". El añadido "-f" hace que el contenido mostrado se actualice dinámicamente. Las líneas en cuestión mostrarían toda la actividad arp que vean en la red, incluyendo los conflictos que se generarían debido al ARP spoofing. Mostrarían algo como esto:

Aquí lo que aparece es que la mac 00:0c:29:78:fb:f1 está intentando usurpar la mac 00:0c:29:85:cd:a0, mediante ARP spoofing.

Con dicha detección se puede reaccionar de distintas maneras. Una de ellas es tener a alguien vigilando la pantalla constantemente y que cuando vea una alerta la bloquee a mano, otra opción es realizar un programa o script que automatice dicha tarea ¿Pero qué habría que hacer para bloquear dicha agresión? Lo ideal sería bloquear el puerto del switch que esté conectado al atacante y ejecutar el siguiente comando en el servidor (evidentemente hay que tener acceso a éste o pedir que lo ejecuten por ti).

iptables -A INPUT -m mac --mac-source ${MAC} -j DROP

Allí donde he puesto ${MAC} iría la mac del atacante.  Esta línea que acabo de escribir sirve para bloquear todo el tráfico entrante cuyo origen sea la mac introducida.

En caso de estar en modo bridge, al hacer de puente entre ambos puntos, si se escribiese dicho comando en el PC también sería efectivo, al menos cómo parche temporal hasta que el administrador del servidor ejecutase el comando en su máquina.

En caso de querer automatizar la tarea de detección sin recurrir a programas de terceros, se podría hacer algo cómo lo siguiente. Obviamente este proceso es mejorable, pero es una muestra de lo que se podría hacer. Esta automatización constaría de tres ficheros:

El primero sería un fichero capaz de manipular al segundo que pondré después. La función de este fichero es poder arrancar, parar, reiniciar y comprobar el estado del segundo fichero. En mi caso lo he llamado antiarpspoofing.sh y lo ideal sería que fuese en /etc/init.d/ para que arranque tan pronto cómo se encienda el equipo:

1. #!/bin/bash
3. PIDFILE=/tmp/arpantispoof.pid
4. SRV="arpantispoof"
5. function status()
6. if [ -f ${PIDFILE} ]; then
7.         echo "${SRV} esta en marcha"
8. else
9.         echo "${SRV} esta parado"
10. fi
11. function start(){
12.  echo -n $"Iniciando servicio: "
13.  /usr/bin/arpantispoof >/dev/null 2>&1 &
14.  RETVAL=$?
15.  echo $! > $PIDFILE
16.  if [ $RETVAL -eq 0 ];
17.  then
18.         echo "Se ha iniciado $SRV"
19.  else
20.         echo "No se ha podido iniciar $SRV"
21.  fi
22.  echo
23. }
24. function stop(){
25.  echo -n $"Parando servicio: "
26.  SERV=$(ps -e |grep ${SRV} |awk '{print $1}')
27.  kill -9 ${SERV}
28.  echo
29. }
30. function restart(){
31.  stop
32.  sleep 10
33.  start
34. }
35. # Dependiento del parametro que se le pase start - stop - restart ejecuta la funcion correspondiente.
36. case "$1" in start)
37.  start;;
38.  stop)
39.  stop;;
40.  restart)
41.  restart;;
42.  status)
43.  status ;;
44.  *)
45.  echo $"Usar: $0 {status|start|stop|restart}"
46.  exit 1
47. esac
49. exit 0

Ahora habría que crear script arpantispoof tal y cómo dice el primer script. Dicho script se almacenaría en /usr/bin y sería algo cómo lo siguiente. Repito que siempre es mejorable y que esta automatización es a modo de ejemplo:

1. 1. #!/bin/bash
   2. if [ -f /etc/init.d/iptablesarpspoof.sh ]; #EN CASO DE NO EXISTIR IPTABLESARPSPOOF SE CREA
   3. then
   4.         echo '' >/dev/null
   5. else
   6.         touch /etc/init.d/iptablesarpspoof.sh
   7.         chmod +x /etc/init.d/iptablesarpspoof.sh
   8.         echo '#!/bin/bash' > /etc/init.d/iptablesarpspoof.sh
   9. fi
   10. i=1
   11. while [ ${i} -eq 1 ];
   12. do
   13.         touch /tmp/arplogs.txt
   14.         tail -n 100 /var/log/syslog |grep "arpwatch" |grep "ethernet mismatch" |awk '{print $10}' |cut -d "(" -f 2 |cut -d ")" -f 1>/tmp/arplogs.txt #COGEMOS LAS MACS ATACANTES
   15.         COUNT= $(cat /tmp/arplogs.txt |awk '{print $1}' |wc -l) #SE CUENTA EL NUMERO DE LINEAS
   16.         if [ "${COUNT}" != "0" ]; #SE VERIFICAN QUE HAY MACS ATACANTES
   17.         then
   18.                 while read LOG;
   19.                 do
   20.                         exist=0
   21.                         touch /tmp/macs.txt
   22.                         cat /etc/init.d/iptablesarpspoof.sh |awk '{print $7}' > /tmp/macs.txt
   23.                         while read TABLES;
   24.                         do
   25.                                 if [ ${LOG} == ${TABLES} ]; #COMPROBAMOS SI YA HA SIDO FILTRADA ESA MAC ANTES PARA EVITAR REGLAS DUPLICADAS
   26.                                 then
   27.                                         exist=1
   28.                                 fi
   29.                         done < /tmp/macs.txt
   30.                         if [ ${exist} -eq 0 ];
   31.                         then
   32.                                 echo "iptables -A INPUT -m mac --mac-source ${LOG} -j DROP" >> /etc/init.d/iptablesarpspoof.sh # SE AÑADE LA REGLA
   33.                                 /etc/init.d/iptablesarpspoof.sh # SE REINICIA EL CORTAFUEGOS
   34.                                 sendmail -f origen@gmail.com -destino@gmail.com -xp mipassword -m "ARP spoof desde ${MAC}" -ssmtp.gmail.com:587 -o tls=yes -xu miusuario -u "ARP spoof" -a /root/arpspoof.txt # SE ENVIA NOTIFICCACION AL ADMINISTRADOR DE RED
   35.                         fi
   36.                 done < /tmp/arplogs.txt
   37.         fi
   38. done

Este script se encargaría de crear las reglas de filtrado según va detectando intrusiones en ARP y las añadiría a /etc/init.d/iptablesarpspoof.sh, el cual se puede añadir al arranque si se quiere, pero es algo opcional. Además enviaría un correo al administrador de red con la MAC del atacante para que la bloquease lo más rápido posible en el switch,

Con la conjunción de esos tres ficheros se tendría un entorno mucho más automatizado y si en cualquier momento uno quisiese ver que MACs han estado intentando contaminar la tabla ARP de alguien, sólo habría que escribir en la consola:

iptables -nvL

Mostrando así el listado de todas las MACs filtradas hasta el momento.

Detectando y mitigando el port flooding

Este ataque es más brusco y directo que el ARP spoofing; Más fácil de detectar aunque más complicado de detener. El port flooding tiene cómo objetivo atacar al switch en vez de a los equipos, y consiste en lo siguiente:

Todos los switches contienen una memoria interna llamada CAM (Content-Addressable-Memory) que asigna puertos a direcciones MAC; gracias a dicha memoria el switch sabe por qué puerto tiene que enviar cualquier paquete que vaya a un destino en concreto y en caso de que fuese una MAC nueva que el switch desconociese (debido a que este equipo no hubiese generado tráfico o debido a que la asociación que tenía el switch ha expirado), el switch mandaría el paquete por todas las bocas de red excepto por la que ha recibido el paquete y sólo el equipo que tuviese la MAC nuevas respondería; añadiendo una nueva entrada a la CAM.

Puede sonar un poco lioso pero digamos que el objetivo de la CAM es que sólo tenga que enviar el paquete por todos los puertos una sola vez y que a partir de ahí, gracias a la CAM el paquete sepa por donde ir, evitando así que inunde todos los puertos para cada paquete que se envíe por el switch. Los predecesores de los switches, los hub, carecían de CAM y por cada paquete que recibían iba a preguntando a todos los que estaban conectados a éste si eran los destinatarios de dicho paquete, haciendo que la comunicación fuese ineficiente.

Cómo toda memoria, la CAM posee un límite... ¿Con lo que que pasaría si la CAM se llenase? La memoria tiene la capacidad de aceptar un gran número de macs, pero no es infinita, con lo que en caso de llenarse la CAM, desgraciadamente ninguna MAC nueva podría registrarse y todas las MACs nuevas que generasen cualquier tipo de tráfico en el switch, inundarían los puertos del switch y lo saturarían, cosa que no se desea.

Lamentablemente existen métodos para enviar macs falsas por la red e inundar el switch con dichas macs; No voy a explicar el procedimiento porque no es el objetivo de esta publicación, pero basta con decir que el ataque es muy agresivo y que cualquiera que esté en la red notará una gran lentitud en la red. Para poder detectar que efectivamente se está realizando dicho ataque, es tan simple cómo poner en marcha un sniffer en el PC que se está usando para monitorizar la red. Cualquier valdría (wireshark, tcpdump...) y se vería una enorme cantidad de paquetes con valores aleatorios que además aparecerían cómo paquetes "mal formados"; algo cómo esto:

No es necesario buscar muy a fondo en wireshark ni utilizar filtros, el tráfico será tan basto que se podrá ver este tipo de tráfico a la primera; ¿Ahora bien, cómo evitarlo?

Desgraciadamente el ataque no va dirigido a un equipo sino que va al switch, con lo que ya hay un factor extra que no siempre es posible controlar. Un switch de gama media/baja no tiene nada que hacer contra estos ataques porque carece de las herramientas necesarias; En cambio un switch de gama media-alta/alta suele tener los recursos necesarios. Para ello dicho switch puede por ejemplo poner un número máximo de MACs por puerto, la activación y configuración de: "Unicast Flooding Protection" o la configuración de un tiempo de expiración de las macs en la tabla CAM bajo para que se libere el espacio en ésta con rapidez.

Hasta aquí la primera parte del análisis y las defensas de una red local.

Saludos.