Vistas de página en total

Mostrando entradas con la etiqueta tor. Mostrar todas las entradas
Mostrando entradas con la etiqueta tor. Mostrar todas las entradas

miércoles, 17 de febrero de 2016

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.

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
,
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