USBdriveby, el collar USB que hackea cualquier ordenador

Estándar
  • USNdriveby es un dispositivo USB que contiene chips y software parahackear cualquier PC con OS X o Windows en menos de un minuto
  • Desactiva las protecciones y ofrece acceso remoto al hacker
  • No hay protección porque aprovecha agujeros en el diseño de la ROM de un USB, a través de BadUSB

USBdriveby, el collar USB que hackea cualquier ordenador. Continuar leyendo

Anuncios

RPEF: la herramienta para backdoorizar routers domésticos

Estándar

Seguro que todavía resuenan en vuestros oídos noticias sobre la presencia de backdoors en muchos modelos de routers. D-Link, Netis, Netgear, Linksys, Belkin, TRENDnet, MediaLink, Sercomm … la lista es muy larga.

Si tu también quieres hacerte el “chino” y vender en eBay tu viejo router con un regalo sorpresa añadido (es broma, no seais malos), puedes usar RPEF…

En la Defcon 20, Michael Coppola presentó una herramienta en Python llamada RPEF (Router Post-Exploitation Framework) con la que automatiza el proceso para añadir un backdoor en un buen número de firmwares para distintos modelos de routers SOHO:

– Belkin: F5D7230-4_v1xxx
– D-Link: DIR-601_1.01NA y DIR-601_2.01NA
– Linksys: WRT120N_1.0.07_(Build_02)
– NETGEAR: WGR614v10_1.0.2.26NA, WGR614v9_1.2.30NA, WNDR3700v1_1.0.16.98NA, WNDR3700v2_1.0.0.12 y WNR1000v3_1.0.2.26NA
– TRENDnet: TEW-651BR_v2.2R_2.00B12 y  TEW-652BRP_v3.2R_3.00B13

La sintaxis básica del script (python 2.6) es: 

./rpef.py <firmware image> <output file> <payload>
 
Una vez que el firmware malicioso está actualizado/instalado y funcionando en el router, el atacante tendrá a su disposición un sniffer de red desde la línea de comandos o un bot que se puede conectar a un canal IRC especificado para lanzar una herramienta DDoS… interesante ¿verdad?

Página del proyecto: https://github.com/mncoppola/rpef

Capturando credenciales en claro mediante un firewall Fortigate

Estándar

En este mundillo estamos cansados de repetir que se sustituya FTP y telnet por sus respectivos equivalente seguros: SCP, FTPS, SFTP, SSH… pero después de tantos años se siguen utilizando 😦

Hoy vamos a hacer una pequeña demostración de la inseguridad del uso de estos protocolos no cifrados capturando tráfico mediante un firewall y obteniendo las contraseñas en claro.

En la vida real el firewall podría ser la máquina de un atacante, el cuál tendría la misma facilidad para robar credenciales simplemente esnifando el tráfico en un nodo que está en medio del camino de nuestra conexión cliente-servidor. Y no sólo el atacante podría ser una persona hábil que ha envenenado ARP y ha conseguido hacer un MiTM… en este gran entramado que es Internet, un ISP o hasta el administrador de red de una empresa podría estar vigilando…

Para nuestro escenario concreto el firewall será un Fortigate. Estos cacharros tienen una gran variedad de comandos de diagnóstico. Permiten depurar aplicaciones comunes (ike, sslvpn, urlfilter…), el proceso de flujo de paquetes e incluso activar un sniffer bastante decente que arroja una salida muy similar a la de tcpdump (será un fork?). La sintaxis del comando es la siguiente:

# diag sniffer packet <interfaz> <‘filtro’> <verbose> <contador> a

Veamos primero un ejemplo sencillo:

# diag sniffer packet internal 'src host 192.168.0.130 and dst host 192.168.0.1' 1

192.168.0.130.3426 -> 192.168.0.1.80: syn 1325244087
192.168.0.1.80 -> 192.168.0.130.3426: syn 3483111189 ack 1325244088
192.168.0.130.3426 -> 192.168.0.1.80: ack 3483111190
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244088 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244686
192.168.0.130.1035 -> 192.168.0.1.53: udp 26
192.168.0.130.1035 -> 192.168.0.1.53: udp 42
192.168.0.130.1035 -> 192.168.0.1.53: udp 42
192.168.0.130 -> 192.168.0.1: icmp: echo request
192.168.0.130.3426 -> 192.168.0.1.80: psh 1325244686 ack 3483111190
192.168.0.1.80 -> 192.168.0.130.3426: ack 1325244735
192.168.0.130 -> 192.168.0.1: icmp: echo request


Y las opciones que manejamos:

– Interfaz, como su nombre indica, es el interfaz por el que se capturarán los paquetes. Podemos especificar “any” para que capture en todos los interfaces.

– El filtro puede tener también la siguiente sintaxis: ‘[[src|dst] host] [[src|dst] host] [[arp|ip|gre|esp|udp|tcp] [port_no]] [[arp|ip|gre|esp|udp|tcp] [port_no]]’

– Verbose tiene diferentes niveles:
1: muestra la cabecera de los paquetes
2: muestra la cabecera y los datos IP de los paquetes
3: muestra la cabecera y los datos ethernet de los paquetes
4: muestra la cabecera de los paquetes con el nombre de interfaz
5: muestra la cabecera y los datos IP de los paquetes con el nombre de interfaz
6: muestra la cabecera y los datos ethernet de los paquetes con el nombre de interfaz

– El contador indica el número de paquetes que se recogerán antes de parar el sniffer. Si no especificamos nada seguirá recogiendo paquetes hasta que lo paremos con CTRL+C.

– Y por último la opción “A” es para mostrar timestamps

Ahora imaginemos que queremos capturar las credenciales de un acceso FTP. Podríamos capturar las de todas las sesiones en un momento dado filtrando simplemente el puerto TCP; pero para el ejemplo supongamos que queremos capturar sólo las credenciales de un acceso a un servidor FTP específico, ftp.rediris.org con IP 130.206.1.5.

Primero, en Putty, no olvidemos capturar la salida de la sesión a un fichero de log:

Después iniciaremos el sniffer:

# diag sniffer packet any 'dst host 130.206.1.5' 6
interfaces=[any]
filters=[dst host 130.206.1.5]

Y desde un cliente ftp estándar lanzaremos la conexión:


C:\Users\vmotos\Desktop>ftp ftp.rediris.org
Conectado a zeppo.rediris.es.
220-  Bienvenido al FTP an├│nimo de RedIRIS.
220-Welcome to the RedIRIS anonymous FTP server.
220 Only anonymous FTP is allowed here
Usuario (zeppo.rediris.es:(none)): vicente
331-            RedIRIS - Red Acad├®mica y de Investigaci├│n Espa├▒ola
331-                RedIRIS - Spanish National Research Network
331-
331-           ftp://ftp.rediris.es  -=-  http://ftp.rediris.es
331-
331 Any password will work
Contraseña:
230 Any password will work

Ahora comprobareis rápidamente que el sniffer está capturando datos. Si os fijáis en el fichero de log generado aparecerá la contraseña en claro:


7.816069 123.123.123.11.19043 -> 130.206.1.5.21: psh 840580428 ack 3720924021
0x0000   0000 0000 0000 0009 0fd3 bac5 0800 4500        ..............E.
0x0010   0035 1d7b 4000 7c06 5d89 c2e0 3d0b 82ce        .5.{@.|.]...=...
0x0020   0105 4a63 0015 321a 3d4c ddc8 cb75 5018        ..Jc..2.=L...uP.
0x0030   07a1 ba58 0000 5041 5353 2070 7275 6562        ...X..PASS.prueb
0x0040   610d 0a      

Aunque si lo preferís, existe un script en perl fgt2eth.pl para exportar el fichero a formato pcap y analizarlo más claramente con Wireshark.

Primero quitamos la cabecera que nos deja putty:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.12.04 01:35:03 =~=~=~=~=~=~=~=~=~=~=~=

Y luego lo exportamos con esta utilidad:

C:\Users\vmotos\Desktop>fgt2eth.exe
Version : 1.22 (Feb 21 2008)

Assuming OS: windows
Usage : fgt2eth.pl -in <input_file_name>

Mandatory argument are :
   -in  <input_file>     Specify the file to convert (FGT verbose 3 text file)

Optional arguments are :
   -help                 Display help only
   -version              Display script version and date
   -out <output_file>    Specify the output file (Ethereal readable)
                         By default '<input_file>.eth' is used
   -lines <lines>        Only convert the first <lines> lines
   -system <system>      Can be either linux or windows
   -debug                Turns on debug mode
      
C:\Users\vmotos\Desktop>fgt2eth.exe -i putty.log -o putty.pcap
Conversion of file putty.log phase 1 (FGT verbose 3 conversion)
Output written to putty.pcap.
Conversion of file putty.log phase 2 (windows text2pcap)
Ouput file to load in Ethereal is 'putty.pcap'

Y por último lo abrimos con Wireshark. Si queréis afinar más la búsqueda podéis usar el filtro:

(ftp.response.code == 230 || ftp.request.command == “PASS”) || (ftp.request.command == “USER”)

¡Feliz caza!

Informe: Recomendaciones (Parte I)

Estándar

En una auditoria tenemos que tener claro que todo es importante, desde la recolección de información como el desarrollo técnico, como por supuesto la presentación de resultados a través de la generación de los informes. Quizá esto último es lo que más “pereza” pueda dar a la mayoría de auditores, pero hay que tener en cuenta que por muy bueno que sea el trabajo, si no podemos explicarlo o comunicarlo tendremos un problema.

En esta cadena de artículos se pretende mostrar las recomendaciones que los auditores, generalmente, tendrán que tener en cuenta en las auditorias que lleven a cabo. Por ejemplo, para este primer artículo hablaremos de medidas correctoras en auditoria perimetral. En función de la auditoría que se esté llevando a cabo, las recomendaciones siempre cambiarán, aunque algunas de ellas se pueden extrapolar a otros ámbitos, por lo que se pueden enunciar en ambas auditorías.

Las primeras contramedidas o recomendaciones que el auditor debe contar en el informe son las soluciones a las vulnerabilidades que se han podido encontrar en la propia auditoría perimetral. Las podemos clasificar como se muestran a continuación:

  • Acceso
  • Autenticación
  • Sesiones
  • Criptografía
  • Datos sensibles
  • Comunicación y protocolos
  • Entradas, codificación y errores

Por supuesto, podemos utilizar algunas guías, como por ejemplo la de OWASP que nos proporcionan una serie de buenas prácticas. Se recomienda su lectura. La guía se puede encontrar en la siguiente dirección URLhttps://www.owasp.org/index.php/ESAPI_Secure_Coding_Guideline.

Acceso

Los servicios perimetrales disponen de una capa de acceso la cual debería cumplir con unas premisas en cuanto a seguridad se refiere.Los usuarios que acceden a los recursos o datos de las aplicaciones o servicios deben poseer una autorización de acceso, la cual se regirá por la característica de mínimo privilegio posible en todo instante.

En definitiva cualquier entidad que ejecute código en una máquina o servidor deberá ejecutar siempre con el mínimo privilegio posible y controlar los parámetros de entrada. La captura y gestión de excepciones debe estar implementada siempre y de manera segura, por ejemplo no mostrando información de debug hacia el exterior.

La capa de acceso se implementará de manera centralizada para proteger el acceso a cada tipo de recurso. Tener distribuida la capa de acceso puede desembocar en la generación de fallos de configuración o de aplicación de permisos debido a la propagación o replicación que hay que llevar de éstos.

Autenticación

La identificación y autenticación de usuarios es un proceso crítico que debe disponer de unas medidas de seguridad, las cuales deben ser conocidas por los auditores para poder presentar contramedidas en la corrección o implementación de aplicativos web.

Siempre hay que tener en cuenta que el acceso a datos de carácter personal se realiza con una sesión de usuario identificado y autenticado. Cuando una aplicación realiza un cambio de credenciales, éste se deberá llevar a cabo de forma segura, al igual que la gestión de errores.

Se debe utilizar una función hash para almacenar las contraseñas en un fichero o en una base de datos. Es casi imprescindible utilizar un algoritmo de la familia SHA, y ya no utilizar MD5.

Los ataques de fuerza bruta a la autenticación es una de las acciones más comunes. Se debe implementar un mecanismo, como el captcha, con el que superando un número de intentos de accesos consecutivos, se pida al usuario una serie de símbolos a introducir con el fin de comprobar que no es un proceso automatizado quién está realizando la autenticación.

Los token deben generarse para cada petición del usuario en términos de autenticación. Por último, una contramedida que se suele utilizar en el sector de la banca es la utilización de una reautenticación de usuario, o un segundo factor de autenticación para realizar una acción sensible.

El Escritorio Movistar, un servicio con ruta sin comillas más espacios… y hasta dentro (escalado de privilegios local)

Estándar

Hoy vamos a ver una vulnerabilidad que Gjoko ‘LiquidWorm’ Krstic (@zeroscience)reportó a Telefónica el 23 de septiembre y que, después de días de absoluta ignorancia, ha decidido publicar (fuente aquí).

Afecta a la versión 8.7.6.792 del gestor de conexiones ‘Escritorio Movistar‘, aunque yo lo he probado en la versión 8.6.5.594 y también es vulnerable:

En concreto es un fallo en el servicio TGCM_ImportWiFiSvc que no entrecomilla la ruta del ejecutable que llama:

C:\>sc qc TGCM_ImportWiFiSvc
[SC] QueryServiceConfig CORRECTO

NOMBRE_SERVICIO: TGCM_ImportWiFiSvc
        TIPO               : 10  WIN32_OWN_PROCESS
        TIPO_INICIO        : 2   AUTO_START
        CONTROL_ERROR      : 1   NORMAL
        NOMBRE_RUTA_BINARIO: d:\Program Files (x86)2\Movistar\Escritorio Movistar\ImpWiFiSvc.exe
         GRUPO_ORDEN_CARGA  :
        ETIQUETA           : 0
        NOMBRE_MOSTRAR     : TGCM_ImportWiFiSvc
        DEPENDENCIAS       :
        NOMBRE_INICIO_SERVICIO: LocalSystem

C:\>icacls "d:\Program Files (x86)2\Movistar\Escritorio Movistar\ImpWiFiSvc.exe"

d:\Program Files (x86)2\Movistar\Escritorio Movistar\ImpWiFiSvc.exe BUILTIN\Administradores:(I)(F)
                                                                    NT AUTHORITY\SYSTEM:(I)(F)
                                                                    NT AUTHORITY\Usuarios autentificados:(I)(M)
                                                                    BUILTIN\Usuarios:(I)(RX)

Se procesaron correctamente 1 archivos; error al procesar 0 archivos

Es la vulnerabilidad conocida como “Unquoted Service Paths” o también “Trusted Path Privilege Escalation” y puede permitir que un servicio de Windows procese cualquier programa que esté antes de un espacio en su ruta sin entrecomillar. En nuestro caso:

    d:\Program.exe Files (x86)2\Movistar\Escritorio Movistar\ImpWiFiSvc.exe

    d:\Program Files (x86)2\Movistar\Escritorio.exe Movistar\ImpWiFiSvc.exe

Para la prueba de concepto crearemos un fichero batch que luego haremos ejecutable y que llamará silenciosamente al Notepad:

Después simplemente pondremos Escritorio.exe en su ruta correspondiente:

Y al reiniciar el servicio veremos que ejecuta nuestro binario:

D:\Program Files (x86)2\Movistar>net stop TGCM_ImportWiFiSvc
El servicio de TGCM_ImportWiFiSvc está deteniéndose.
El servicio de TGCM_ImportWiFiSvc se detuvo correctamente.


D:\Program Files (x86)2\Movistar>net start TGCM_ImportWiFiSvc
El servicio no está respondiendo a la función de control.

Puede obtener más ayuda con el comando NET HELPMSG 2186.

Si en vez de ser un simple Notepad ponemos un script que cambie la contraseña del administrador local o por ejemplo un payload para una sesión de Meterpreter, cuando reinicie nuestro equipo (con Windows 7) se ejecutará como SYSTEM y habremos primeroescalado privilegios y luego enteramente comprometido la máquina.

Además existe desde hace tiempo un módulo de Metasploit que se aprovecha de este fallo: http://www.rapid7.com/db/modules/exploit/windows/local/trusted_service_path

Como veis este tipo de vulnerabilidades que aparentemente son tan tontas y sencillas de explotar son también muy peligrosas. Además aunque son bastante viejas parece que siguen vigentes en nuestro días… si ejecutáis el siguiente comando seguro que comprobaréis que el servicio del Escritorio Movistar no es el único afectado actualmente:

wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "c:\windows\\" |findstr /i /v """

Acunetix WVS Scheduler v8     AcuWVSSchedulerv8     D:\Program Files (x86)2\Acunetix\Web Vulnerability Scanner 8\WVSScheduler.exe
                                Auto
Intel(R) Dynamic Application Loader Host Interface Service     jhi_service     C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL\jhi_service.exe
                                Auto
Intel(R) Management and Security Application Local Management Service   LMS C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\LMS\LMS.exe
                                Auto    
Privacyware network service     PFNet     C:\Program Files (x86)\Privacyware\Privatefirewall 7.0\pfsvc.exe
                                Auto
TGCM_ImportWiFiSvc     TGCM_ImportWiFiSvc     d:\Program Files (x86)2\Movistar\Escritorio Movistar\ImpWiFiSvc.exe
                                Auto

Por último, si quieres solucionar manualmente esta vulnerabilidad en vez de esperar sentado a que el fabricante publique un parche, edita el registro y busca el servicio en cuestión en HKLM\SYSTEM\CurrentControlSet\services para ¡¡¡poner las malditas comillas!!!.

Liberan el hack para infectar USB de manera indetectable

Estándar

Liberan el hack para infectar USB de manera indetectable

El malware aprovecha un error de hardware que no puede ser parchado

En el mes de julio de este mismo año, dos investigadores anunciaron que habían encontrado un fallo de seguridad crítico en el programa base de los USB. Lo llamaron BadUSB y en su momento no lo publicaron para que así la industria tuviera tiempo de prepararse para un futuro sin este dispositivo, o al menos, con alguna solución para este problema.

Pero esto ya no es así, Adam Caudill y Brandon Wilson, dos investigadores que también descubrieron el fallo, han publicado el código porque piensan que es lo mejor tanto para la industria como para los usuarios. Según ellos, si el mundo no conoce el código, los grandes fabricantes nunca harán nada al respecto. Por eso lo han publicado en GitHub.

¿Y qué es lo que tiene de malo este fallo de seguridad? Pues básicamente todo. Gracias a esta vulnerabilidad presente en el firmware de cualquier dispositivo con conector USB, un hacker podría infectar un chip del propio conector y así infectar y controlar cualquier dispositivo donde el USB sea conectado.


link: https://www.youtube.com/watch?feature=player_embedded&v=xcsxeJz3blI

No hay solución

Actualmente, ante un ataque de estas características no hay ninguna solución, ya que los sistemas de seguridad no son capaces de detectar el malware, por lo que cualquier usuario está indefenso en este sentido.

Y por eso, para forzar una solución han publicado el código. ‘Si las únicas personas que pueden hacer esto son los que tienen presupuestos importantes, los fabricantes nunca van a hacer nada al respecto. Hay que demostrar al mundo que es práctico, que cualquiera puede hacerlo… Eso pone presión sobre los fabricantes para solucionar el problema real’, indica Adam Caudill , uno de los dos investigadores que han hecho público el código.

La semana pasada, durante la conferencia Derbycon en Louisville, Kentucky, Caudill explicó la razón para publicar el código que podría afectar a cientos de millones de usuarios:

Esto fue inspirado en gran parte por el hecho de que SR Labs no publicó su material. Si vas a probar que hay una falla, necesitas liberar el material para que las personas puedan defenderse de ella. (…) Si esto se va a solucionar, necesita ser con más que sólo una plática en Black Hat.

Ambos investigadores concuerdan en que publicar el exploit es la única manera para presionar a los fabricantes de USB a cambiar el esquema de seguridad de estos dispositivos.

Para ellos difundir públicamente el código permitirá pruebas de penetración que actualmente no se pueden realizar. Evidentemente esto también puede suponer un peligro, ya que algún hacker puede utilizar el código para infectar miles de dispositivos.

En septiembre, la firma de seguridad G Data lanzó un programa que niega el acceso a un teclado cuando se conecta, dando oportunidad al usuario de verificar si el dispositivo que conectó a través del puerto USB es genuinamente un teclado o si se trata de una USB infectada. Por otra parte, esta es una solución incompleta y que puede ser burlada.

A pesar de todo, BadUSB no es lo peor que le puede pasar a las USB. Caudill y Wilson están trabajando en otro hack invisible que inyectaría malware a los archivos de una USB al momento de ser copiados a una computadora. A partir de ese momento, cualquier USB que se conecte a la computadora infectada contraería el mismo código malicioso, convirtiendo al exploit en una posible epidemia.

informatica

Dado el peligroso impacto que podría tener este último descubrimiento, los investigadores aún debaten el publicar el código, pues ambos están conscientes de que se encuentran en un dilema ético. “Hay un equilibrio difícil entre probar que esto es posible y hacer que sea fácil que las personas lo hagan. Queremos asegurarnos de que estamos en el lado correcto.”

A pesar de estos descubrimientos, siempre se ha recomendado como una práctica segura el no utilizar dispositivos USB cuya procedencia sea desconocida o poco confiable, y esta precaución no perderá vigencia.

Nuestro servidor de tuneles siempre online (2ª parte) ssh-tunnel & wake on wan

Estándar

Siguiendo con esta serie de entradas hoy retomaremos nuestro recién creado server y lo dotaremos de un par de servicios de tunneling más de los cuales nos podremos servir en un futuro.

También veremos cómo hacer un wake on wan sin necesidad de un wol-relay, aunque si recordáis yo para el server utilice una raspberry (se puede utilizar cualquier máquina) y, aunque el chipset soporta la tecnología wol, no lo tuvieron en cuenta a la hora de diseñarla (RPI no soporta wol).. por lo menos en el modelo de mi placa…

A decir verdad el consumo de Rpi 2,5W no es nada frente a los 125W que puede llegar a consumir cualquier sobremesa.. Por eso seria bueno tener online este tipo de server solo cuando lo utilicemos, además de ahorrar es ecológico 🙂

WAKE ON LAN/WAN

Wake on Lan/Wan, es una tecnología mediante la cual podemos encender un ordenador de manera remota, simplemente mediante una llamada de software. Puede implementarse tanto en redes locales (LAN), como en redes de área extensa (WAN o Internet). Las utilidades son muy variadas, tanto encender un Servidor Web/FTP, acceder de manera remota a los archivos que guardas en tu equipo, teletrabajo y hasta por pura vagancia.

Requerimientos hardware
1 – Fuente de alimentación ATX 
2 – Tarjeta de red con cable de tres pines. 
3 – Placa base con soporte WOL
Lo primero que tenemos que hacer para llevar a cabo un wake on wan es abrir el puerto UDP  9. El Magic Packet es un paquete que funciona a nivel de enlace, en la capa 2del modelo OSI, ya que lo que se envía en el mismo es una dirección MAC. pero el router es un dispositivo de nivel de red (nivel 3), o sea, que se “entiende” con direcciones IP, no con las direcciones MAC. Eso quiere decir que deberemos ser capaces de enrutar este paquete desde Internet hacia el ordenador objetivo.
Podemos hacerlo accediendo al router bien por http o bien por telnet (en mi caso el soft del router no tiene la posibilidad de tocar las tablas nat por http/https, así que no me queda otra que acceder por telnet):
Lo que conseguimos es que  todas las tramas UDP que lleguen a la dirección IP pública del router por el puerto 9, serán reenviadas a ese mismo puerto de la dirección IP privada 192.168.1.128.

En el caso de tener varias máquinas que despertar podemos asignarle a cada una un puerto en la nat y según cual queramos despertar mandaremos el magic packet por un puerto u otro.

Pero un nuevo problema. Al estar el equipo apagado, cuando el router trata de reenviar el paquete mágico a la IP del equipo destino, no hay nadie que le conteste diciendo “yo tengo esa IP”, con lo cual, el router no sabe cuál es la dirección MAC. Esto se soluciona con latabla ARP del router debidamente configurada.
Para hacer el wake on wan lo podemos hacer desde el smartphone (aconsejo wake on lan de mafro pues nos deja configurar el puerto) u otro equipo.

Sea cual sea la aplicación que utilicemos, los datos son siempre los mismos: la MAC del equipo destino, la IP pública de router (o bien nuestro dominio registrado enfreedns.afraid.org), como máscara hay que poner 255.255.255.255 (broadcast) y finalmente el puerto por el que queramos establecer el envío.

Ya estaríamos listos para despertar nuestra máquina desde cualquier parte del mundo!
Un momento y la ip pública??

Si fuisteis buenos y seguisteis los pasos del post anterior tendréis asociada la IP-Publica de vuestro router a un subdominio y puedes saber tu ip por ejemplo haciendo ping. Tu subdominio en el caso del ejemplo era hackpy.chikenkiller.com o bien puedes utilizar el subdominio a pelo.

Debemos tener en cuenta los modos de apagado de nuestra máquina…. por ejemplo mi sobremesa despierta de un halt igual que de un suspend o hibernate… pues digamos que este el wol lo hace por hardware…

Sin embargo mi portátil solo despierta si lo suspendo y antes configuro la tarjeta eth0 para ello.

 ethtool -s eth0 wol g

Bueno despues de este apunte sigamos por donde nos quedamos la semana pasada en Cómo montar nuestro propio servidor de tuneles siempre online (1ª parte).

SSH-TUNNEL

¿Qué es un túnel SSH?
 
Las siglas corresponden a Secure Shell. Sirve para acceder a máquinas remotas, igual que hace telnet, pero de una forma segura ya que la conexión va cifrada. El transporte se hace mediante TCP, por tanto nos garantiza que las órdenes van a llegar a su destino (conectivo, fiable, orientado a conexión).

¿Para qué nos puede servir?

  1. El túnel SSH es una buena solución para navegar por Internet en el caso que nos hallemos en Red local No segura.
  2. La navegación a través de un túnel SSH garantiza nuestra confidencialidad ya que nadie podrá conocer las páginas web que estamos visitando ni que estamos haciendo.
  3. La navegación a través de un túnel SSH garantiza la integridad de los datos transmitidos y recibidos ya que la probabilidad que alguien pueda modificar las datos que enviamos o recibimos es muy baja.
  4. Los túneles SSH nos pueden servir también para vulnerar ciertas restricciones impuestas por nuestro ISP o por ejemplo también nos puede servir para vulnerar ciertas restricciones impuestas por proxies y firewall.
  5. Los túneles SSH son una buena solución para asegurar la comunicación entre 2 máquinas y para fortificar protocolos débiles como por ejemplo HTTP, SMTP. FTP, Telnet, etc.
  6. Montarse un servidor SSH propio es sumamente mucho más sencillo que montarse un servidor VPN o un servidor proxy.

Empecemos…

Desde nuestra raspberry pi nos bajamos open ssh:

apt-get install openssh-server openssh-client
lo siguiente será cambiar el puerto por el que ssh escuchará, para ello editaremos el fichero /etc/ssh/sshd_config y lo pondremos en el 22222:
Ahora en el router abriremos el puerto en la nat:
Ahora abrimos el firewall de nuestro server (en caso de tenerlo activado )

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

Ya estamos en disposición de recibir en nuestro server las conexiones ssh por el puerto 22222.

Tunelizado la conexion

ssh -p 22222 -N -D 1027 hackpy.chikenkiller.com


-p 22222: Con este parámetro indicamos el puerto de escucha de nuestros servidores SSH.

D 1027: Estamos especificando que se realice un reenvío dinámico de puertos o túnel dinámico. En este puerto habrá un servidor proxy socks que escuchará las conexiones del puerto 1027. Cuando el servidor proxy socks detecte una solicitud o conexión en el puerto 1027 enviará el tráfico cifrado a través del tunel SSH que creamos entre la red que estemos y nuestro server.

Configurando el proxy para poder navegar

Una vez establecido el túnel deberemos configurar las aplicaciones que van a funcionar por el, en este caso lo que pretendemos es securizar nuestra navegación.

Para ello y yo como estoy utilizando iceweasel para navegar me bajaré e instalaréfoxyproxy (lo tenemos para varios navegadores y si no cualquier proxy web vale) y lo configuraremos  para este menester.

en la siguiente captura podemos ver como navegamos por ssh:

Si comprobamos las ip veremos que no son las mismas…

Sin tunnel:




 

Con tunnel:

Ya hemos conseguido nuestro SSH-TUNNEL… mediante el cual podremos navegar.

UTILIZANDO UN CLIENTE ANDROID

Para utilizarlo con nuestro smartphone (sin rootear) podemos utilizar la aplicación connetBoot y Firefox. Si tenemos root en el terminal tenemos mejores opciones como la app ssh-tunnel, pero hagámoslo difícil.

abrimos coonectboot y conectamos con nuestro server:

root@NuestraIpPublica:22222

Luego tocamos la tecla menú y seleccionamos la opción traducciones de puerto:

Lo configuramos como en la foto de la izquierda, aseguraros de reescribir el puerto por el 8080 hasta que se queda en negro….

Ahora tan solo debemos configurar firefox en nuestro smartphone para que tire de nuestro SSH-TUNNEL.

Lo haremos abriendo nuestro navegador y poniendo “about: config” y cambiando los valores por defecto por los siguientes:

network.proxy.type 1

Y YA estamos en disposición de navegar seguros!

Hasta aquí tenemos nuestro server dispuesto para aplicar dos técnicas de tunneling (DNS Y SSH) desde cualquier parte del mundo y también somos capaces de apagarlo y encenderlo a placer para ser mas ecológicos.. os emplazo a una tercera entrega donde iremos completando nuestro server.

Por hoy tan solo recordaros que podemos “tunnelar” muchos servicios por ssh, desde el correo a servicios RPD.. y que este hilo es solo una de las mil formas de hacerlo.

un saludo!