Tag Archive for proxy

Convirtiendo un Proxy en Transparent Proxy

En algunas ocasiones queremos utilizar de manera transparente un servidor proxy, ya sea para saltar un firewall o, simplemente, para enrutar por él determinadas conexiones o las conexiones de determinados usuarios o grupos. Pero no siempre es posible, porque no todos contemplan la posibilidad de Transparent Proxy.

Si utilizamos Privoxy con la opción accept-intercepted-requests, nos sirve para redirigir el tráfico vía firewall. Sin embargo, no podremos redirigir el tráfico https. Además, una vez que activemos la opción accept-intercepted-requests, no podremos utilizarlo manualmente desde la aplicación deseada.

También se puede utilizar un proxy Socks5 creado con ssh. A él no podremos redirigir el tráfico directamente vía firewall.

Si queremos redirigir el tráfico con nuestro firewall a un proxy como los anteriores, podemos utilizar RedSocks. Esta herramienta nos permite crear un proxy transparente http, http-connect, socks4 o socks5 y actuará de túnel con el proxy real. De esta manera, podremos “convertir” un proxy que no es Trasnparent Proxy, en uno, y dirigir a él el tráfico que necesitemos.

Una ventaja adicional es que puede enrutar también el tráfico DNS. Si disponemos un proxy Socks5, que no sea creado con ssh, también podremos redirigir por él el tráfico UDP.

Vamos a ver un ejemplo de uso. Para ello, vamos a enviar todo el tráfico http y https a Privoxy.

Privoxy, en principio, enrutará todo el tráfico a través de TOR. La ventaja de pasar previamente por Privoxy es poder aprovechar los filtrados que proporciona, como publicidad, etc., además de poder decidir desde él qué hacer con cada URL. El resto del tráfico, lo enrutaremos por TOR. Todo esto se realizará siempre que la aplicación/herramienta se haya lanzado con un grupo de usuarios concreto.

Nos va a permitir utilizar estos proxys sólo cuando la aplicación se lance con un determinado grupo, de manera que no vamos a “Torificar” todas las salidas, solo aquellas que nos interesan.

La instalación la vamos a realizar sobre Kali. En el resto de distribuciones basadas en Debian será similar. En ArchLinux, podemos encontrar Redsocks en el AUR o, si hemos añadido a los repositorios BlackArch, lo tendremos ya disponible, dado que forma parte de esta distribución.

Empezamos instalando:

apt-get update && apt-get install redsocks privoxy tor

Una vez instalados los paquetes, vamos a configurarlos. Primero, editamos el fichero /etc/tor/torrc. Necesitaremos mapear los dominios onion, activar el servicio de DNS de TOR y el TProxy. Para ello, al final del archivo añadimos:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

DNSPort 53
TransPort 9040
SocksPort 9050

Con esto tenemos que, el servidor de DNS estará escuchado en localhost:53, los dominios onion los mapeará con una ip aleatoria del rango 10.192.0.0/10 y tendremos el TProxy en el 9040, además del proxy socks habitual en el 9050.

Ahora vamos a editar la configuración de Privoxy y añadir al final de la misma:

forward-socks5 / 127.0.0.1:9050 .
forward localhost/ .
forward 127.*.*.*/ .
forward 192.168.*.*/ .

Bien, ya tenemos Tor y Privoxy configurados, pasemos a RedSocks. Primero sacamos un backup del fichero /etc/redsocks.conf. En él tenemos todas las opciones disponibles, con sus respectivos comentarios. Hecho esto, lo editamos y le añadimos el siguiente contenido:

base {
 log_debug = off;
 log_info = on;
 log = "syslog:daemon";
 daemon = on;
 user = redsocks;
 group = redsocks;
 redirector = iptables;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8218;

ip = 127.0.0.1;
 port = 8118;


 // known types: socks4, socks5, http-connect, http-relay
 type = http-relay;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8318;

ip = 127.0.0.1;
 port = 8118;

type = http-connect;
}

Básicamente, hemos creado un TProxy en el puerto 8218 que apunta al 8118 (Privoxy), de tipo http-relay y otro en el 8312, de tipo http-connect (https), que también apunta a Privoxy.

Ya tenemos la configuración inicial, vamos a arrancar los servicios:

systemctl start tor privoxy redsocks

Ahora vamos a añadir un grupo. Será el que utilicemos para enrutar de manera transparente sus conexiones:

groupadd socksified

Hecho esto, añadimos los usuarios que necesitemos al grupo:

usermod --append --groups socksified USUARIO

Con esto ya tenemos casi todo lo necesario. Toca configurar el firewall. Editamos/creamos el fichero /etc/network/iptables.rules y añadimos lo siguiente:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:REDSOCKS - [0:0]

# Los DNS se los dejamos a TOR
-A OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 53
-A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53

# El grupo socksified se redirige a REDSOCKS
-A OUTPUT -p tcp -m owner --gid-owner "socksified" -j REDSOCKS

## Redes internas
-A REDSOCKS -d 0.0.0.0/8 -j RETURN

# Usamos parte de 10.0.0.0/8 para onion, entonces:
-A REDSOCKS -d 10.0.0.0/9 -j RETURN
-A REDSOCKS -d 10.128.0.0/10 -j RETURN

-A REDSOCKS -d 127.0.0.0/8 -j RETURN
-A REDSOCKS -d 169.254.0.0/16 -j RETURN
-A REDSOCKS -d 172.16.0.0/12 -j RETURN
-A REDSOCKS -d 192.168.0.0/16 -j RETURN
-A REDSOCKS -d 224.0.0.0/4 -j RETURN
-A REDSOCKS -d 240.0.0.0/4 -j RETURN

## Redirecciones
# Privoxy, peticiones http
-A REDSOCKS -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8218

#Privoxy, peticiones "Connect" (https)
-A REDSOCKS -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8318

#Direcciones onion
-A REDSOCKS -d 10.192.0.0/10 -p tcp -j REDIRECT --to-ports 9040

COMMIT

Una vez tenemos las reglas, ejecutamos:

iptables-restore < /etc/network/iptables.rules

Y ya solo nos queda probar si todo es correcto:

# No sale por privoxy
curl https://check.torproject.org | grep -i congra
#ahora, como lanzamos curl con el grupo socksified, sí que lo hace
 sg socksified 'curl https://check.torproject.org |grep -i congratulation'

Como puede observarse, este mecanismo nos puede ser muy útil para dirigir el tráfico a uno u otro proxy, dependiendo, por ejemplo, del grupo con el que se lance la aplicación. También podría hacerse por usuarios. Además, podemos añadir tantas secciones Redsocks como necesitemos, permitiéndonos “jugar” bastante con nuestro sistema, para adecuarlo correctamente a nuestras necesidades.

¡¡Espero que os haya gustado !!

Anonimizando la Kali con anonym8

En determinadas ocasiones, necesitamos utilizar nuestra máquina de auditorías de manera anónima. La mayor parte de herramientas cuentan con una opción para configurar un proxy, ya sea http o sock, con lo que puede configurarse para utilizar TOR.

Sin embargo, no todas tienen esta característica, con lo que nos vemos obligados a utilizar herramientas adicionales como proxychains. Además, en muchas ocasiones queremos también comprobar el tráfico UDP, y esto no es posible hacerlo con TOR.

También es posible que queramos suplantar la MAC de la tarjeta de red, cambiar el nombre del host, no tener fugas de DNSs y, una vez terminada la auditoría, dejar todo como estaba, eliminando, por supuesto, los rastros que hayamos dejado en SWAP, cachés, etc.

privacy

Bien, para hacer todo esto, disponemos de un script que nos va a facilitar todo el trabajo. Lo podéis encontrar en https://github.com/HiroshiManRise/anonym8, y es válido para distribuciones basadas en Debian, por ejemplo, Kali.

Read more

Bypasseando firewalls con Shadowsocks

En shaalgunas ocasiones queremos ocultar nuestro tráfico en la red en la que nos encontramos.

Por ejemplo cuando nos conectamos a redes wifi públicas o no fiables. En otras ocasiones, simplemente, queremos eludir un firewall.

Para esto hay diferentes opciones. Una muy utilizada es usar TOR. Sin embargo, es posible que no queramos utilizarla. Sencillamente queremos usar una conexión a Internet y usar nuestro propia red para navegar. Para ello es para lo que nos sirven los proxys.

En nuestra red segura, levantamos el servidor proxy. En los dispositivos cliente, sencillamente nos conectamos a ella. En el caso de los proxys socks5, podemos, además enrutar tráfico UDP (en el caso de TOR, aunque sea un proxy socks5, y el los túneles ssh, no se puede usar el tráfico UDP ).

Read more

Hello SECaaS – New age, new look

Parece que ya ha quedado bien claro cuál es el futuro (y presente) de los servicios de seguridad. SECaaS, Security as a Service o Servicios de Seguridad Gestionada es lo que las empresas y administraciones públicas ya están demandando. Era de esperar viendo el crecimiento de los Servicios Cloud, y lo que empresas como SVT Cloud ya están ofreciendo.

SVT Cloud es un CSP (Cloud Services Provider) pionero en nuestro país y uno lo de los ISP más antiguos de España (desde 1989). Su experiencia y visión les ha permitido situarse en una posición favorable a la hora de ofrecer a sus clientes Servicios de Gestión Cloud y Servicios de Seguridad Gestionada. Además, SVT Cloud forma parte del Board del (ISC)2 Spain Chapter y del EurCloud desde el 2012

Para este último área, han decidido incorporar la experiencia y conocimiento de Proxy Servicios y Consulting  para llevar a cabo el ofrecimiento de los servicios de seguridad gestionada. Auditorías de vulnerabilidades Web, Hosting Seguro, SVT Box, Mail Relay ó CloudJacket son algunos de los muchos servicios que se ofrecerán para el año que tenemos a la vuelta de la esquina.

En Proxy y hacking-etico.com no podíamos dejar pasar una oportunidad de este tipo, así que a partir de ya nos integramos al equipo de trabajo de una empresa que cuenta ya con más de 3.000 clientes, 3 CDC (Cloud Data Centers, el último en Barcelona), y que durante los dos últimos años:

2012

  • Entra a formar parte del comité de Cataluña de Itsmf (http://www.itsmf.es/), Asociación dedicada a potenciar las mejores prácticas en gobierno y gestión de servicios IT.
  • Se incorpora al Ismsforum Spain, Asociación que aglutina las principales empresas de Seguridad del mercado (https://www.ismsforum.es), encargada de definir y potenciar la Seguridad de la Información.
  • Se incorpora en varios grupo de trabajo de CSA-ES (Cloud Security Alliance https://cloudsecurityalliance.org/), organización encargada a nivel mundial de la creación de las mejores prácticas en seguridad en entornos Cloud.
  • Firma un acuerdo de exclusividad con el fabricante Rhinosoft (http://www.rhinosoft.com/) para la comercialización en exclusiva en el mercado Español y encargado de la traducción a dicho idioma del producto SERV-U (Transferencia de Archivos segura), base del servicio SVTdocs.

2013

  • Se ha firmado un acuerdo estratégico de exclusividad con SECNAP para Latino América y Europa para la distribución de CloudJacket. La solución de seguridad CloudJacket se enmarca en una nueva generación de tecnologías en Ciberseguridad, orientadas a proteger activamente los datos de los clientes, la propiedad intelectual y los activos en red. SECNAP Network Security, (www.secnap.com).
  • Se ha cerrado un acuerdo con partners como Altco para distribucion en Colombia de SECaaS y ProaXis en todo Latinoamérica, así com diferentes partners en toda España.
  • Ha participado en el Estudio del Estado de Seguridad Cloud en España, 2013. https://www.ismsforum.es/ficheros/descargas/estudio-del-estado-de-la-seguridad-en-cloud.pdf
  • SVT Cloud Services es uno de los 11 Partners en toda España, acreditados como HP Cloud Providers.
  • SVT se incorpora al grupo de trabajo de CSA que se encarga de traducir y adaptar al mercado español el PLA (Privacy Level agreement), acuerdo de nivel de servicio a cumplir por los proveedores de Servicios Cloud en el mercado.

Además de lo que hemos visto hasta ahora, veremos cosas nuevas, muchas de ellas relacionadas con Seguridad Cloud y Seguridad Gestionada. Seguiremos hackeando éticamente!

Comienza una nueva etapa para nosotros, que esperamos compartir con todos vosotros.

Hello SECaaS!