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.
Algunos activistas están motivados por la política o la religión, mientras que otros pueden querer denunciar los abusos, o la venganza, o simplemente acosar a su objetivo para su propio entretenimiento.
Vistas de página en total
Mostrando entradas con la etiqueta bloquear tor. Mostrar todas las entradas
Mostrando entradas con la etiqueta bloquear tor. Mostrar todas las entradas
miércoles, 17 de febrero de 2016
martes, 16 de febrero de 2016
¿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
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.
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:
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.
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
Suscribirse a:
Entradas (Atom)






