Va una no tan obvia y que me llevó su buen rato investigar: Como enviar (y recibir también, no sean pelotudos, es tráfico bi-direccional) todo el tráfico que genera tu iPhone o iPad -o cualquier otro dispositivo que exista en el futuro y corra iOS- por un tunnel SSH para que aparezca como tráfico generado por el servidor donde corre el SSH Server en Linux. Lo que también se conoce como proxy tipo socks.

 

Ya en el pasado le he dedicado diversos artículos a esta técnica que usé y uso hasta varias veces por semana según se me va presentando cada escenario, por ejemplo:

Si no están familiarizados con las tecnologías y protocolos implicados puede que quieran ir a leer primero alguno de los artículos anteriores.

 

Configurando un tunnel SSH que puedas utilizar luego desde tu iphone o ipad para acceder a ese servicio de streaming bloqueado en tu país, ciudad o empresa o como cagarte en todos los firewalls poniendo el servicio SSH de tu servidor a escuchar en el puerto 53 TCP.

Configurando un tunnel SSH que puedas utilizar luego desde tu iphone o ipad para acceder a ese servicio de streaming bloqueado en tu país, ciudad o empresa o como cagarte en todos los firewalls poniendo el servicio SSH de tu servidor a escuchar en el puerto 53 TCP.

 

Ingredientes:

  1. Un servidor corriendo Linux en algún lado.
  2. Un web server en algún lado donde se pueda escribir un archivo. No es estrictamente necesario.
  3. Una PC con Windows o Linux que hará las veces de socks proxy y puede ser el mismo servidor que corre el Linux
  4. Putty, si la PC socks proxy corre Windows. Bajalo de acá.

Continúa leyendo

Otro título sugerido: Como hacerle la vida imposible a tu sysadmin – parte 2

Si no leyeron el artículo anterior: Como hacerle la vida imposible a tu sysadmin deberían empezar por ahí para entender de que estoy hablando. Para los cortos de tiempo resumo brevemente:

Por un lado: Tenés acceso a una PC que remotamente corre Linux, puede ser un servidor que administres o la PC de tu casa, da lo mismo. No hace falta disponer de privilegios de super-usuario en la PC remota. Esta PC remota corre un servidor SSH que te permite login remoto.

Por el otro: La persona que administra la red de tu trabajo te tiene impedido, no te permite chatear, usar Facebook o Twitter, no podés navegar por ciertas páginas o usar ciertos servicios.

Otra posibilidad: Estas conectado desde una red «pública» en un bar, aeropuerto o simplemente robándole internet el vecino y no tenés ninguna manera de saber quien podría estar olfateando los paquetes de datos que van y vienen, sobre todo ahora, que herramientas como Firesheep hacen que un ataque man-in-the-middle que siempre fue cosa reservada para unos pocos elegidos sea coser y cantar.

También podrías usar este sistema (o un buen tunel SSH por cada servicio a rutear haciendo las veces de Socks Proxy con todas las incomodidades que conllevaría) si estás conectado desde un enlace poco fiable en donde la pérdida de paquetes está fuera de discusión.

O si ninguna de las anteriores te convence: Simplemente por que nunca se es lo suficientemente paranoico, otro mini tutorial: Como encriptar TODO el tráfico que genera tu PC y rutearlo remotamente para evitar cualquiera de los escenarios anteriores.

Usando SSH para rutear todo el tráfico TCP que se genere en tu PC hasta un host remoto.

Usando SSH para rutear todo el tráfico TCP que se genere en tu PC hasta un host remoto.

Continúa leyendo

Y no naufragar en el intento

¿Se entendió el chiste? Lo opuesto de navegar = naufragar, hoy estoy iluminado.

El caso mas típico: El administrador de la red de tu trabajo te bloqueó twitter, facebook, msn messenger y cuanta otra página adicional pudiera dar por tierra con tu productividad.

¿Se entendió el chiste? Lo opuesto a navegar = por tierra, hoy estoy realmente iluminado.

Otro ejemplo, estás navegando desde una red pública accediendo a contenido sensible sin saber quien pudiera estar a la escucha del tráfico entrante o saliente. O peor aún, estás navegando desde una red inalámbrica sin cifrar, donde cualquiera en varios metros a la redonda podría estar jugando con su placa de red wi-fi en modo monitor.

Ya sea que te bloquearon el MSN messenger y no podes chatear o que te vino el ataque mensual de paranoia y no te animás a usar Home Banking desde esa red de dudosa procedencia, he aquí una de las tantas alternativas viables para solventar el problema.

Ingredientes:

  1. Linux con el servicio SSH corriendo.
  2. Si la PC con facebook bloqueado corre windows, entonces necesitarás además de PuTTY

Si, solo eso. Nada como un buen Linux en casa para pasarse por el ***** el sistema de filtrado de contenidos del 90% de los servidores corporativos, así que si todavía no lo hiciste, ya tenés otro motivo mas para ir instalando Linux en esa PC viejita y en desuso que quedó tirada por ahí.

¿Como funciona?

Se trata de establecer el famoso tunel SSH entre la PC bloqueada y la PC de afuera corriendo Linux.

Si bien hay varias formas de traspasar un firewall restrictivo, la mas eficiente y la única que encontré –la única que conozco, por que seguro habrá unas cuantas formas mas de hacerlo– que permite acceder al contenido de varias páginas web de forma dinámica sin tener que andar retocando la configuración de ningún servicio o conectar y desconectar nada, es llegando hasta el servidor por SSH por un túnel haciendo de socks proxy.

Si llegaste a leer hasta este punto, es por que realmente te interesa el artículo y sabés mas o menos de que estoy hablando, así que voy a presuponer que ya tenés una distribución de Linux instalada y que esta distribución tiene OpenSSH instalado y en ejecución como servicio.

De no ser así, hay miles de guías al respecto por ahí, no voy a detallar la configuración desde el principio por que no viene al caso.

Puesta en marcha:

En Linux:

ssh –D 3128 usuario@servidor 

En windows, con PuTTY en ejecución toda la ciencia radica en agregar el puerto 3128 como dinámico en la sección Connections / SSH / Tunnels y luego loguearse en la PC remota:

eseesehache

Por último, configurar el navegador.

Una vez establecido el túnel, solo es cuestión de especificarle al navegador de cabecera que use como servidor de socks (normalmente en la sección “proxy” de las opciones del mismo) a 127.0.0.1 en el puerto 3128 o cualquiera sea el número de puerto arbitrario que se hubiera especificado. (Usé 3128 por costumbre, por ser el puerto por defecto en donde corre Squid pero se puede usar cualquier número de puerto).

proxy

Desde ese momento y hasta tanto se le indique otra cosa al navegador o se cierre el túnel, todo el tráfico será enviado a través de este último hasta la PC que corre Linux, que será la encargada de establecer y gestionar la sesión HTTP. De paso se cifra por completo la conexión, por otro lado además se saltea cualquier restricción que hubiera respecto a este tipo de tráfico.

Para el webserver que recibe la petición, todo el tráfico aparentará estar originado en la PC que corre Linux.

Bajo la premisa: «No es que yo sea paranoico, es que me están siguiendo…» alguien ha creado un par de scripts que hacen a tu pc ridículamente segura y hasta le ha dado nombre (y apellido); Crypto Port Knocking 0 Single packet authentication. –o ambas cosas juntas, en realidad

Sencillamente genial.

¿Creíste que tu Linux con SELinux, ACL, Port knocking, Fail2ban, Snort, OSSEC, sin puertos abiertos, con autenticación SSH basada en llaves, con el usuario root deshabilitado y todos los servicios enjaulados, los DNS y la tabla ARP estática era seguro?

No… No es seguro. Al menos no para el creador de esta obra maestra de la seguridad que ha llevado la cosa a tal extremo que raya con el absurdo.

Si te interesan estos temas, después del salto viene lo bueno. Es fundamental tener una noción básica de bash y entender un poco de inglés para echarlo a andar:  Continúa leyendo