Vistas de página en total

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

miércoles, 17 de febrero de 2016

Creando un túnel SSH con Nessus

Muchas veces a la hora de hacer una auditoría externa y tener algún sistema de protección exterior (Firewall, IDS…), se nos habilitan diferentes mecanismos para poder acceder dentro de la red que queremos auditar sin que su seguridad exterior se vea comprometida. Es muy común habilitar un túnel SSH para acceder al interior de la red local.
Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.

Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.

En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:
La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:

Creación del túnel SSH con el nodo B.

Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).

Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:

sudo ssh –p 22 –N –D 8081 user@direccionIP_B

Tras introducir las credenciales oportunas podemos ver desde otra terminal como ya tenemos el puerto 8081 a la escucha en la máquina local A:
Instalación y configuración de Proxychains.

Para la instalacción de Proxychains simplemente ponemos:

sudo apt-get install proxychains

y nos vamos a editar su fichero de configuración /etc/proxychains.conf. Pondremos que todas las peticiones de los programas/servicios abiertos con Proxychains vayan al puerto 8081 de autobucle (127.0.0.1) donde está el túnel.
Comprobación del funcionamiento del túnel.

Pasamos ahora a comprobar si funciona nuestro túnel, para ello vamos a solicitar desde nuestra máquina local A la IP pública que tenemos. Vemos como aparece nuestra IP 95.x.x.x.
Sin embargo cuando pasamos la petición a través del túnel mediante proxychains vemos que nos da la IP del nodo B, por tanto nuestro túnel funciona correctamente.
,
Iniciando Nessus a través del túnel.

Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:

/etc/init.d/nessus stop

y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.
Una vez que tenemos todo funcionando ya podemos arrancar Nessus y llevar a cabo el escaneo de la máquina C en cuestión, sin necesidad de desplazarnos a la ubicación del nodo
Dejar claro que todas las pruebas se han llevado a cabo sobre dos redes propietarias y que como comentábamos en la nota legal, se hace con fines educativos.
Iniciando Nessus a través del túnel.
Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:
/etc/init.d/nessus stop
y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.
- See more at: http://hacking-etico.com/2015/06/12/creando-un-tunel-ssh-con-nessus/#more-4509

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