¿TOR?, ¡ No en mi servidor !

Sin duda las redes TOR han adquirido un protagonismo considerable en estos últimos años. Ya debemos saber que no siempre TOR, se usa para realizar actos delictivos sino también para evadir censuras en países autoritarios y dónde la democracia y libertad de expresión es un lujo escaso.

No obstante, nosotros siempre nos centramos en las posibilidades que puedan dar las redes TOR, tanto ofensivamente como defensivamente.

Hoy toca ser defensivos, y vamos a ver como poder parar de forma simple, visitas desde redes TOR a un servicio apache nuestro, publicado en Internet. Las reglas pararán cualquier intento de conexión pero utilizaremos apache como sonda de prueba.

La idea me surgió hace tiempo pero hoy he podido plasmarla en el artículo. Y es que entrando en pequeños debates de como mejorar servicios de Firewalls conocidos, con un gran profesional al que aprovecho y le mando saludos, me propuse hacer algo básico para trasladar mi idea y/o ponerla en práctica.

Empecemos pues.

La idea: No permitir accesos desde redes TOR a nuestro servidor y de paso, bloquear IPs que hayan sido reportadas o estén listadas en repositorios dedicados a recopilar esto.

¿Qué vamos a usar?

• IPTables
• IPSet
• Feeds de IPs/Maliciosas y TOR
• Script base de trick77(Github: You are not allowed to view links. Register or Login)

Lo primero que haremos será instalarnos IPSet. IPSet es un “añadido” del kernel de Linux. Permite configurar diferentes IPs, MACs, puertos, etc… para cargarlas desde IPTables. El por qué de usarlo es porque permite cargar miles de direcciones IP y solamente cargarla con una línea de IPTables. Sino usáramos esto, tendría que ser el proceso a “manopla” y es inviable a no ser que tengáis mucho tiempo u os montéis un script, que es lo que hacemos nosotros.

El proceso es el de siempre para instalar en Debian/Kali:
apt-get install ipset
Una vez hecho esto, procederemos a la descarga de un script que funciona a las mil maravillas, además de completo, de trick77. Con este programita solucionaremos gran parte del “problema” por lo que seguiremos parte del README aunque haremos algunas aclaraciones para que sea todo 100% operativo así como alguna modificación del código inicial.

Código: You are not allowed to view links. Register or Login

Guardamos en una ruta “popular” de nuestro equipo o VM aunque lo ideal para ponerlo en producción es meterlo en la ruta /usr/local/sbin/.Es un script de Shell de Bash por lo que la extesión será .sh.

Una vez decidido dónde queremos tener alojado nuestro script vamos a otorgarle permisos de ejecución con:
chmod +x /ruta/torblock/script.sh
Creamos una carpeta nueva dónde alojaremos la carpeta principal de IPSet:
mkdir -p /etc/ipset-blacklist
A continuación procedemos a descargar el fichero de configuración que contiene las premisas en las que se basarán nuestros bloqueos.

Podemos descargarlo de: You are not allowed to view links. Register or Login y lo situaremos en /etc/ipset-blacklist/

Decir que el fichero de configuración ipset-blacklist.conf contendrá feeds de diferentes tipos de IPs (maliciosas, TOR, spam, etc…)



Estas líneas pueden comentarse para que no realicen la descarga del listado de IPs que queramos excluir. Personalmente, creo que no está de más tener toda la lista en funcionamiento para bloquear la mayoría de IPs que su origen sea dudoso. Nosotros vamos a dejarlo como está, aunque si queréis cambiar o añadir otros servicios, también es válido.

Hecho esto, procederemos a ejecutar el script para que empiece a descargar listados de IPs y trasladarlos a nuestro fichero ipset-blacklist.restore

Usaremos:
./torblock.sh /etc/ipset-blacklist/ipset-blacklist.conf


En la anterior captura se aprecia la ejecución del script que, como decimos, descarga listados de IPs tanto TOR, maliciosas, de SPAM, etcétera… También se ocupa automáticamente de crear el contenedor IPSet, que es un almacenamiento que albergará dichas IPs. Básicamente emplea un comando para crear este contenedor parecido a:
ipset create blacklist hash:net hashsize 4096
También el script si analizáis el código, añade automáticamente esto:
iptables -I INPUT 1 -m set –match-set blacklist src -j DROP
Qué es la regla IPTables que llama al contenedor “blacklist” y hace un bloqueo total del contenedor, el cual, como venimos diciendo, contiene las miles de IPs maliciosas.



En esta captura se aprecia una pequeña muestra de la cabecera del fichero que contiene las IPs que hemos descargado de los repositorios.

Hemos llamado el script de trick77 como torblock.sh para que sea más identificativo a la hora de identificarlo y/o configurarlo de forma automática. No obstante hemos modificado algunas premisas para adaptarse mejor a los aplicativos en dónde tenemos esto testeando. La siguiente ruta que aparece junto a la llamada del script, es indicarle la configuración que tomará el script para su ejecución.

Importante: Una de las modificaciones que hemos hecho en el código es añadir una simple línea llamada:
    ipset restore < /etc/ipset-blacklist/ip-blacklist.restore
¿Por qué?¿Qué hace esto?

Por la sencilla razón de que si lo integramos, al cronearlo, automáticamente también se actualiza el “contenedor” IPSet. Lo que hace esta línea de código es coger del fichero .restore las nuevas IPs y refrescar la lista.

¿Y si quiero anular el efecto de bloqueo?

iptables –D INPUT X donde X es el número del listado de las reglas que tengas. Nosotros en el servidor de pruebas tenemos 1, pues sería 1 solo. Otros servidores pueden tener cientos.


Recopilemos:

Tenemos un script llamado torblock.sh que nos actualiza las IPs maliciosas (TOR, Spam, etc…) nos genera el contenedor IPSet donde irán dichas IPs y generará una regla IPTables para bloquear.


Mejoras:

• Meter el script de actualización en /etc/rc.local para asegurar su ejecución al inicio del sistema.
• Crontab: Meterle una línea al Cron para que cada X tiempo se ejecute y tenga actualizadas las listas de IPs

Directorio de pruebas:




Visitando el sitio con Firefox con IP Pública:




Visitando el sitio con TorBrowser:




Con esto ya no hay excusa para impedir accesos a nuestros servidores o sitios publicados en Internet. Si no necesitamos/interesa visitas desde redes de anonimato ¿por qué permitirle el acceso?

Estamos, de paso, realizando uno de los pasos importantes a la hora de securizar cualquier dispositivo/servidor, que es reducir la superficie de exposición de ataques.

Espero que os haya gustado y sobre todo, espero que podáis utilizar este artículo para consultas si os interesa tener algo así.



Autor:ManoloGaritmo
Fuente:hacking-etico.com

Se agradece la información, excelente post.
Saludos

Muy buen post, solo un comentario a tener en cuenta, que habria que tener un control de los feedbacks de esas ips que se reciben, las fuentes, como tambien la posibilidad de evitar un falso positivo, o que una persona malintencionada no intente generar una entrada falsa del mismo rango que el servidor a la fuente de alimentacion de ips.

Saludos, buen post.