Bloqueando accesos desde TOR

Muchas o mejor dicho miles de veces oímos hablar de la red TOR. Ya no es un término usado por gurús de la seguridad sino que más o menos es conocido por los aficionados a la informática.

Hay mucha suspicacia en el tema del anonimato en la red y obviamente esto tiene sus motivos. Pero tanto positivos como negativos.

Cuando hablamos de anonimizar tu conexión para que no te “espíen” podemos suponer que ya de hecho vamos a cometer un delito o vamos a practicar actividades de dudosa legalidad. Esto es muy relativo.

Pero como primera premisa, indiscutible (e “impepinable” como se dice por Córdoba :P) es que nadie tiene porque espiar tu actividad en la red. Podemos entrar en el debate de que se sospecha o se tiene indicios de que “tal” y “cual” pero un usuario de “a pie” no tiene por qué ser rastreado.

Con eso, se podría justificar el uso de TOR. Evitar que nadie te rastree o al menos ponérselo difícil.

Otro punto positivo y útil es evitar la censura en determinados países tanto dictatoriales como falsas democracias que atentan sin pudor ninguno, contra la privacidad y la libertad de expresión de sus ciudadanos.

Visto así podemos dilucidar un aspecto muy positivo del uso de TOR. Pero ¿Y si es para cometer delitos premeditados?

Obviamente es su parte mala. El símil de la navaja es muy gráfico. Todos tenemos acceso a navajas y podemos usarla para pelar naranjas, cortar alimentos, etcétera…pero también puede ser usada para hurtos, agresiones, etcétera…

TOR es lo mismo aplicado al anonimato.

Aspectos de seguridad.

Muchas veces nos centramos en proteger nuestra Web de ataques SQLi, cerrar puertos, etcétera… pero olvidamos acciones básicas que pueden evitarnos muchos dolores de cabeza al igual que MB en los logs de nuestros servidores.

La mayoría de sitios Webs y servidores que auditamos son accesibles desde la red TOR, ¿en serio queremos que accedan desde la red TOR?¿Es necesario?

Evidentemente si somos una Web de derechos humanos o relacionada con las libertades y derechos de las personas esto no sería recomendado puesto que estaríamos “taponando” la comunicación con seres humanos represaliados.

Bloqueando accesos desde TOR

Si tienes un sistema WAF (Web Access Firewall) o Firewall o cualquier sistema de seguridad perimetral puedes añadir reglas de tipo “blacklist” para bloquear estos accesos.

Esta lista, que se actualiza cada 30 minutos, puedes tomarla de https://www.dan.me.uk/torlist/ y dar un “toque” extra de seguridad a tu sitio.

De igual forma, es conveniente el bloqueo de IP’s que procedan de países del Este o Chinos que en un porcentaje bastante alto, tienen intenciones poco benignas.

En un sitio Web puedes hacerlo fácilmente usando .htaccess utilizando estos comandos por ejemplo:

    GeoIPEnable On

    SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry

    Deny from env=BlockCountry

Con estas órdenes anteriores bloqueamos acceso de IPs de países como Rusia o China.

A continuación una opción muy contundente que penaliza en visitas eso si, es usar una lista blanca de países que se permite el acceso a tu sitio:



    GeoIPEnable On
    SetEnvIf GEOIP_COUNTRY_CODE AR AllowCountry
    SetEnvIf GEOIP_COUNTRY_CODE PO AllowCountry
    SetEnvIf GEOIP_COUNTRY_CODE ES AllowCountry
    SetEnvIf GEOIP_COUNTRY_CODE VE AllowCountry

    Deny from all
    Allow from env=AllowCountry

Podemos usar .htaccess para bloquear IPs de nodos TOR pero es poco práctico. La síntaxis sería añadir línea por cada IP.

Por ejemplo:

deny from 217.13.197.5
deny from 217.40.254.177
deny from 217.70.191.13
deny from 217.115.10.131
deny from 217.115.10.133
deny from 217.115.10.134
deny from 217.123.236.30
deny from 217.160.24.166
deny from 217.173.74.91
deny from 217.210.165.43
deny from 217.245.151.118
deny from 218.191.130.126
deny from 219.78.40.173



Si tenemos 10, 20 o incluso 100 puede bastar pero estos listados son muy extensos como para añadir a “manopla” esto.

No obstante, existen un plugin para WordPress “Maltor” que sincroniza las listas de IPs TOR que hemos comentado anteriormente con tu WordPress y evita y las bloquea.

Esto sirve como noción básica para al menos aprender como podemos dificultar visitas indeseadas en nuestras infraestructuras en Internet.

Sin más, espero que te haya gustado el artículo y no dudes en compartilo si lo crees conveniente.

Anonimato en la red con I2P

Siempre que hablamos de anonimato en Internet, lo primero que se nos viene a la cabeza es TOR. Sin embargo, no es la única iniciativa existente, que pretenda proporcionarnos el mayor nivel de anonimato y seguridad en nuestras comuniciaciones.

En 2002, nace TOR, con la idea de construir una red distribuida, dentro de Internet, que permita una comunicación anónima y segura. En 2003, nace I2P (Invisible Internet Project)Siempre que hablamos de anonimato en Internet, lo primero que se nos viene a la cabeza es TOR. Sin embargo, no es la única iniciativa existente, que pretenda proporcionarnos el mayor nivel de anonimato y seguridad en nuestras comuniciaciones.

En 2002, nace TOR, con la idea de construir una red distribuida, dentro de Internet, que permita una comunicación anónima y segura. En 2003, nace I2P (Invisible Internet Project)con la misma idea. La primera utiliza “onion routing” y, la segunda, “garlic routing” para intentar conseguir este objetivo. En realidad, ambos tipos de enrutamiento presentan muchas similitudes.
¿Cómo funciona I2P?

En esta red, para conseguir anonimizar los mensajes enviados, necesitamos un router I2P. Este router, creará unos túneles de entrada y, otros tantos, de salida, unidireccionales. Si queremos enviar un mensaje a un cliente, será enviado por un túnel de salida, hacia un túnel de entrada del mismo.

Para encontrar los túneles hacia el cliente que queremos conectar, se hace una búsqueda en la base de datos distribuida, utilizando una adaptación del algoritmo   Estos túneles serían algo parecido a los circuitos que se utilizan en TOR, con una diferencia: Tienen una corta duración. Esto, en principio, permitiría, en caso de un ataque, complicar la captura de datos por parte del atacante.

Las apliciones y webs están alojadas bajo un dominio, .i2p, similar a los dominios .onion. Para acceder a ellos, necesitamos hacerlo a través del router I2P. También podremos navegar fuera de I2P, quedando nuestra IP oculta, al igual que ocurre con TOR.

Podemos utilizar cualquier aplicación web que queramos. Dentro de nuestro router, apuntaríamos a ella, para poder utilizarla. En principio, disponemos de varias aplicaciones preconfiguradas, como un servidor web, correo electrónico, cliente bittorrent, irc, etc.

Debemos tener en cuenta que I2P está todavía en fase beta, aunque ya va por la versión 0.9.14. Sus desarrolladores hacen incapié en esto, pero, a su vez, consideran que es suficientemente estable para poder ser usada.

Por otra parte, cuanto más grande sea la red, mayor será el anonimato de sus usuarios. En este sentido, comparando con TOR, I2P es una red muy pequeña. Sin embargo, este hecho hace que no tenga todavía demasiados ojos encima de ella, intentando romperla: Éstos están puestos en TOR, lo que supone un balón de oxígeno, para ir solventando problemas de escalabilidad, rendimiento, corrección de bugs, etc, y,  por supuesto, para crecer y poder aumentar la capacidad de anonimato.
Instalando en 3,2,1…

Tal y como podemos ver en la zona de descargas está disponible para sistemas Windows, OS X, FreeBSD, GNU/Linux y, en desarrollo, Android. Dado que software libre, también está diponible el código fuente.

Necesitamos tener Java instalado, pues el router está desarrollado en este lenguaje. Hay en marcha un router I2P, escrito en C++, en https://github.com/PrivacySolutions/i2pd.

Para sistemas Debian y derivadas, disponemos de repositoriospara las distribuciones basadas en ArchLinux, está disponible en el AUR.  En el caso de ArchLinux, disponemos de dos opciones: i2p o i2p-bin. El primero instalará compilando, y, el segundo, está precompilado. En mi caso, opté por i2p. Una vez instalado, tan solo hace falta levantar el servicio:

# Instalamos

wget https://aur.archlinux.org/packages/i2/i2p/i2p.tar.gz

tar -zxvf i2p.tar.gz

makepkg -si

# levantamos el servicio:

sudo systemctl start i2prouter.service

Una vez hecho esto, ya tenemos nuestro router I2P funcionando. Para acceder al panel de control, debemos ir a http://localhost:7657. Lo primero que debemos hacer hacer es configurar nuestro ancho de banda. Esto se hace en http://localhost:7657/config.

Hecho esto, debemos configurar el navegador. Nos dirigimos a la configuración del proxy y establecemos el http a localhost:4444 y https a localhost:4445. Por ejemplo, en Firefox, nos dirigimos a Editar -> Preferencias -> Avanzado y, en Conexión, pinchamos en Configuración:

Hecho esto, ya podemos navegar por la red I2P. Si queremos disponer de un correo electrónico que garantice nuestro anonimato, disponemos de la aplicación SuSiMail, ya configurada, para poder utilizar el servicio Postman’s anonymous email service Otra característica, es que podemos actualizar el router desde la consola, además de instalar pulgins desde la misma. Para ello, debermos establecer las siguientes opciones en el fichero /opt/i2p/.i2p/router.config:

router.updateDisabled=false

routerconsole.enablePluginInstall=true

Conclusión

Cómo puede verse, la instalación y uso es muy sencilla. La aplicación viene preconfigurada para poder crear nuestra propia web, además de otras aplicaciones. Su panel de control es muy fácil de administrar y muy completo.

Aunque aún no pueda considerarse una alternativa real a TOR (todavía no se ha liberado la versión 1.0, estable, el tamaño de la red no es tan grande, hay pocos proxys de salida a internet, provocando cuellos de botella, etc), es un proyecto a tener en cuenta.

Si nos decantamos por utilizar esta red, es recomendable seguir su cuenta en Twitter, para estar informados de cómo va el proyecto. De todas formas, en el panel de control, nos muestra también las noticias actualizadas.

¿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: https://github.com/trick77/ipset-blacklist)

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: https://raw.githubusercontent.com/trick77/ipset-blacklist/master/ipset-blacklist.conf 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.

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:

- See more at: http://hacking-etico.com/2016/01/21/tor-no-gracias/#more-4929

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:

- See more at: http://hacking-etico.com/2016/01/21/tor-no-gracias/#more-4929

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:

- See more at: http://hacking-etico.com/2016/01/21/tor-no-gracias/#more-4929

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.

- See more at: http://hacking-etico.com/2016/01/21/tor-no-gracias/#more-4929