Un par de TIPs rápidos sobre túneles SSH

Esto iban a ser un par de comandos para el apartado ful scripts, pero luego he pensado que quizá merecía la pena montar un mini-artículo que explicase de qué iba el tema.

Túnel a través de ssh

Muchas veces tenemos que acceder a servicios de una LAN que no están accesibles directamente desde internet; sin embargo, sí tenemos conexión de ssh.
La solución es muy sencilla, crear un tunel a través del ssh (esto se puede hacer también a través del putty si tienes la desgracia de que el S.O. del cliente es un windows...

Escenario:

• Servicio ssh escuchando en internet en la IP pública 64.233.183.99
• En otra máquina dentro de la misma LAN está escuchando una BBDD postgres en la IP 192.168.10.69 en el puerto 5432
• Conectamos nuestro portátil a una Wireless que algún alma caritativa tiene abierta (0 no) y creamos un túnel con el siguiente comando:

ssh -CvNL 5432:192.168.10.69:5432 bpk@64.233.183.99

Explicando rápidamente el tema:

• C -->Habilita la compresión, para minimizar el uso de ancho de banda
• v -->Verbose. Útil para ver cuando y cómo se establecen las conexiones dentro del tunel.
• N -->Para que no levante una shell ni permita ejecutar comandos en el servidor destino. Útil si tenemos un usuario para estos menesteres que no tiene shell
• L -->Con este parámetro estamos levantando el túnel que necesitamos. Concretamente le estamos diciendo que escuche en el puerto local del protátil 5432 y que lo que reciba por ahí lo reenvíe a la IP 192.168.10.69 al puerto 5432 a través de la conexión SSH.
• usuario@IP_pública -->Los datos con los que levantaríamos una conexión típica de SSH.

Una vez establecida la conexión SSH sólo tendremos que decirle a nuestro cliente preferido de postgres que se conecte a la IP local 127.0.0.1 en el puerto 5432 y listo.


Otro posible escenario sería:

• Servicio ssh escuchando en internet en la IP pública 89.185.234.89
  
• En otra máquina dentro de la misma LAN tiene montado un servidor FTP que sólo está accesible desde dentro de la red con la IP 172.26.0.69
  
• Tenemos que realizar un backup del pr0n en nuestro portátil. Para ello creamos el túnel con el siguiente comando:

ssh -CvNL 10000:172.26.0.69:21 bpk@89.185.234.89

Y desde otro terminal:
ftp 127.0.0.1 10000

La idea es la misma, aunque creo que es más intuitivo así.


Este tipo de túneles se pueden empalmar para ir saltando de máquina en máquina dentro de las distintas subredes de la empresa, pero no quiero complicar el ejemplo, así que eso queda como deberes para cuando lo necesitéis ^_~

Túnel Dinámico a través de ssh

Otro uso práctico de túneles. En este caso túneles dinámicos.
Si estáis en una red no confiable (sipe, lo sé, todas las redes son no confiables, pero unas lo son menos que otras). Pongamos por caso que el vecino con wireless que mencionaba más arriba es un pequeño cabroncete, y le encanta jugar con nuestro tráfico de formas que no nos resultan agradables (no como lo haría la madre de Juako). A través de ssh podemos levantar un túnel dinámico que se comportará como un proxy SOCKS y sólo tendremos que configurar nuestro navegador (o la aplicación que sea) para que utilice el proxy que hemos creado. Por supuesto, conseguiríamos el mismo resultado con una VPN, pero este método tiene la ventaja de que no tenemos que montar ningún servicio adicional y siempre es más común tener un ssh escuchando que una VPN montada.

Escenario:

• Servicio ssh escuchando en la IP pública 64.233.183.99 (máqina dentro de una red confiable)
• Ejecutamos el siguiente comando en el portátil que está conectado a internet desde la WIFI del vecino cabrón.

ssh -CvND 7777 bpk@64.233.183.99

En este caso, la 'D' es la encargada de levantar el túnel dinámico, y el puerto en el que el que está escuchando el proxy SOCKS es el 7777


Notas referentes al firefox:

Recomiendo usar Add-ons como FoxyProxy para poder alternar configuraciones de distintos proxys (dinámicos, TOR, SQUID...) de una forma rápida y cómoda.

Si vamos a tunelar el tráfico, conviene comprobar que el parámetro "network.proxy.socks_remote_dns" esté en "true" para que así vaya también por el túnel.
Para comprobar/cambiar el valor: En la barra de direcciones del firefox vamos a "about:config" y buscamos este parámetro (podemos filtrar por "dns" para encontrarlo antes)


UPDATE - Notas referentes al servidor SSH:

Si tienes problemas y no funciona el túnel, comprobar que está habilitado en el servidor. Para ello editar el archivo de configuración /etc/ssh/sshd_config y buscar el siguiente parámetro:
AllowTcpForwarding yes

Y ya que estáis editando el archivo, no está de más capar el acceso a root como medida de seguridad:
PermitRootLogin no

El NTP de los pobres

Bueno, de los pobres, o de los vagos, o de los kutres....el caso es que aquí va mi segundo kutre-script.

Hace unos meses, me encontré en una red en la que el UDP estaba capado... yo tampoco sé en qué estarían pensando cuando decidieron esa política de seguridad, pero los caminos de lo políticos haciendo de admin son inescrutables.

El caso es que estuve investigando alguna solución que permitiese hacer NTP por TCP y no encontré nada.
La siguiente opción consistía en encapsular UDP dentro de TCP, pero no era viable al tratarse de una red aislada, sin otras redes de apoyo externas o que dieran este tipo de servicos. Además están muy desaconsejados este tipo de workarounds.
Por último, yo que antes de nada soy práctico, pensé "¿porqué no hago la consulta a algún servidor web y le meto la hora a las bravas?". Y a mí todo lo que sea meter a las bravas siempre me ha parecido una buena idea, así que creé el siguiente kutre-script:

root@osaka:~# cat /usr/local/bin/time_sync.sh
#!/bin/bash
date -u -s "`wget -O- http://www.time.gov/timezone.cgi?UTC/s/0 2> /dev/null \
| sed -n -e 's/.*size="[75]".*>\(.*\)<br>$/\1/p'`" >& /dev/null

¿Se nota que estoy intentando aprender bash scripting? xD

Ahora sólo hay que añadirlo al cron del usuario root. Para editar el cron, desde una terminal de root, ejecutamos:
root@osaka ~-> crontab -e

Y añadimos la siguiente linea:
00 09 * * * root /usr/local/bin/time_sync.sh

Yo sólo sincronizo una vez al día, porque a la peña de las páginas web les sienta muy mal que utilicen sus páginas las máquinas en vez de las personas, y no es plan de que se cabreen y pongan CAPTCHAs ^_^. Si quieres ponerlo más a menudo, ya sabes:
man -S 5 crontab

Por si un copypaste es demasiado kurro time_sync.sh

PD: Por supuesto, gracias a la gente de http://www.time.gov/ , sin vosotros esto no habría sido posible xDD

NOTA: He actualizado el artículo y el script porque ha cambiado la URL desde la que extraer la hora.
Ya sabes: apt-get update && apt-get upgrade net_para_los_pobres (just kidding)

Avahi ... un misterio menos

Para aquellos que sepan qué es avahi, que no sigan leyendo... a no ser que quieran reirse de mi ignorancia ¬_¬

Hay una cosa de la que siempre que he podido me he quejado de Ubuntu:
A la hora de configurar la red, como siempre pasa en estos mundos del software libre, tienes un millón de formas de hacerlo; pero en Ubuntu es donde
me he encontrado por primera vez que cuando configuras la red a través del herramienta gráfica, luego mirabas en el archivo /etc/network/interfaces ...
¡Y ahí no había nada de lo que habías estado poniendo!

Por otro lado, cuando realizas los cambios en el /etc/network/interfaces alguna vez me he vuelto medio loco porque no conseguía que el servicio se
comportase como se le supone...
En fin, un montón de cosas raras más propias de otros sistemas que basan su configuración en un oscuro registro y de lo que yo pensaba que estaba a
salvo en el sistema del pingüino...

Pues bien, hoy estaba jugando con el lsof y aprendiendo algunas opciones interesantes (eso para otro día en el que me ponga a escribir un artículo
de verdad ~_^) y he visto el proceso ese raro:


root@acer-laptop:/home/bpk# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
avahi-dae 4666 avahi 13u IPv4 15856 UDP *:mdns
avahi-dae 4666 avahi 14u IPv4 15857 UDP *:32769
Y yo pensado, ¡coño, qué es esto!


root@acer-laptop:/home/bpk# dpkg -l "avahi*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-=================================-=================================
ii avahi-autoipd 0.6.17-0ubuntu3 Avahi IPv4LL network address configuration daemon
ii avahi-daemon 0.6.17-0ubuntu3 Avahi mDNS/DNS-SD daemon


Interesante...


root@acer-laptop:/home/bpk# apt-cache show avahi-autoipd
Package: avahi-autoipd
Priority: optional
Section: net
Installed-Size: 176
Maintainer: Ubuntu Core Developers
Original-Maintainer: Utopia Maintenance Team
Architecture: i386
Source: avahi
Version: 0.6.17-0ubuntu3
Depends: libc6 (>= 2.5-0ubuntu1), libdaemon0, adduser
Recommends: dhcp3-client, iproute
Conflicts: zeroconf
Filename: pool/main/a/avahi/avahi-autoipd_0.6.17-0ubuntu3_i386.deb
Size: 42356
MD5sum: 6bf4b572186ebae0f77ef22ac721cf3b
SHA1: 7a6ae3c80a7ca5b8d72117b56a93cbae9b67a981
SHA256: b43a7725850cbcdfa339be0c0cdea26ad4de402e80ee9aded41a0a4ad5a650d5
Description: Avahi IPv4LL network address configuration daemon
Avahi is a fully LGPL framework for Multicast DNS Service Discovery.
It allows programs to publish and discover services and hosts
running on a local network with no specific configuration. For
example you can plug into a network and instantly find printers to
print to, files to look at and people to talk to.
.
This tool implements IPv4LL, "Dynamic Configuration of IPv4 Link-Local
Addresses" (IETF RFC3927), a protocol for automatic IP address
configuration from the link-local 169.254.0.0/16 range without the
need for a central server. It is primarily intended to be used in
ad-hoc networks which lack a DHCP server.
Bugs: mailto:ubuntu-users@lists.ubuntu.com
Origin: Ubuntu
Task: ubuntu-desktop, kubuntu-desktop, xubuntu-desktop

y


root@acer-laptop:/home/bpk# apt-cache show avahi-daemon
Package: avahi-daemon
Priority: optional
Section: net
Installed-Size: 364
Maintainer: Ubuntu Core Developers
Original-Maintainer: Utopia Maintenance Team
Architecture: i386
Source: avahi
Version: 0.6.17-0ubuntu3
Depends: libavahi-common3, libavahi-core5, libc6 (>= 2.5-0ubuntu1), libcap1, libdaemon0, libdbus-1-3 (>= 0.94), libexpat1 (>= 1.95.8), adduser, dbus
(>= 0.60)
Recommends: libnss-mdns
Suggests: avahi-autoipd
Conflicts: mdnsresponder
Filename: pool/main/a/avahi/avahi-daemon_0.6.17-0ubuntu3_i386.deb
Size: 78398
MD5sum: 09ad1ba9c1979c05dc03e1c83935a3c7
SHA1: 42e8310fc438fd67ce39274031d2d72f0748ed8c
SHA256: 9d96182dc6c3e02f29593be65d8b0fc4b099ddf19e2244d7b0c927ff21b7853a
Description: Avahi mDNS/DNS-SD daemon
Avahi is a fully LGPL framework for Multicast DNS Service Discovery.
It allows programs to publish and discover services and hosts
running on a local network with no specific configuration. For
example you can plug into a network and instantly find printers to
print to, files to look at and people to talk to.
.
This package contains the Avahi Daemon which represents your machine
on the network and allows other applications to publish and resolve
mDNS/DNS-SD records.
Bugs: mailto:ubuntu-users@lists.ubuntu.com
Origin: Ubuntu
Task: ubuntu-desktop, kubuntu-desktop, edubuntu-desktop, xubuntu-desktop


Y por último, echando una visual en el predecible directorio /etc/avihi/ se ve claramente como funciona el programa de marras y qué cositas hace.

Los links de rigor, por si alguien quiere ver lo que se puede hacer con el programa de marras:

La peich de la wikipedia
La página oficial

Especialmente interesante el man del archivo de configuración


That´s all folks!

Primeros pasos con Netcat (como cp por TCP/IP)

Bueno, seguimos con el copy&paste - mira que hay que ser cutre para autoplagiar algo tan malo xDD

Este mini-articulo es en homenaje a un tio que conocí en la Campus-party que pilotaba de linux un rato largo y me enseñó lo que puede dar de sí Netcat... (hola Yshi/Plue ;-))

Como en la descripción de su ayuda indica el netcat es la “navaja suiza de TCP/IP”, lo que hace “solamente” es escribir o leer a traves de la red. Precisamente en su simplicidad está su potencia (ya sabeis, la filosofía Unix de pequeñas herramientas para combinarlas bla, bla, bla ;-))

Una de su mayores ventajas es que se comporta exáctamente igual independientemente del puerto en el que trabaje, de ahí que muchos lammers malos malísimos utilicen esta herramienta para simular un servidor ftp o un telnet y conseguir contraseñas (¿De verdad hay gente tan g$l$p$ll$s? XDDDD).

Yo principalmente uso netcat (o nc) para intercambiar ficheros cuando no quiero perder el tiempo instalando samba, nfs, scp o lo que sea. Esto va directo a vena ;-). Este articulo intentará explicar como utilizar netcat como un cp a traves de la red.

Aquí es donde llega el como instalarlo y tal, vamos a intentarlo:

Para Debian: apt-get install netcat
Para gentoo: emerge -va netcat
Para mandrake/Red Hat: urpmi netcat


Habeis cojido la idea, ¿no?. Bueno, para los machotes de slack, BSD o LFS, no sé que cojones hacéis leyendo esto ~_^

Al tomate:

Primero elegimos un puerto por el que se comunicarán (p.e. el 6600)

IP de la máquina origen: 172.26.0.10

IP de la máquina destino: 172.26.0.20

Para pasar un archivo:

Ponemos la máquina destino en escucha:

netcat -l -p 6600 172.260.10 < archivo


Y en la máquina origen escribimos:

netcat 172.26.0.20 -p 6600 > archivo


Paso a explicarlo:

-l Indica que lanzamos netcat en modo escucha (listen)

-p 6600 Puerto en el que espera la conexión

172.26.0.x Cuando en la máquina que escucha especificamos una IP, restringimos quien le manda la información, de forma que si recibiese información de otra IP, simplemente terminaría. En la máquina que escucha podemos omitir la IP sin problemas, todo depende de como de hostil sea tu red :-p

Pero es un coñazo hacer un nc con cada archivo que queramos pasar, ¿no?, ¿recordáis aquello de la filosofía Unix y combinar las pequeñas herramientas?, pues ahora vamos a tirar de tar que para eso está.

Como copiar un directorio por red:

Ponemos la máquina destino en escucha:

netcat -l -p 6600 172.26.0.10 |tar xvjf -


|tar xvjf - No voy a enumerar cada opción del tar porque no es el objetivo de este articulo, ya sabéis RTFM ^_^. Simplemente saber que el tar desempaquetará y descomprimirá todo lo que reciba. (si andais jodidos de espacio y sobrados de ancho de banda, podéis omitir la “j”)

Y en la máquina origen que envía los archivos:

tar cvjf – directorio_que_queremos_enviar/ | nc 172.26.0.20 6600


Como supondréis, lo que hace es compactar y comprimir un directorio para mandarlo por netcat en un solo archivo.

Como rollo anecdótico podemos usar el nc como servidor web con algo tan tonto como:

nc -l -p 80 index.html


Por supuesto, tiene otros muchos usos: Como chat, para conseguir información de servidores, etc.

Links de interes:

Tutorial de LINUCA bastante más completo que este :-)

Tutorial de lammers que encontré buscando info de netcat para no meter demasiado la pata (¡por favor, no me jakeeis la aspiradora!)XDDDD

Si alguien tiene dudas de como funciona esto de las tuberías ( “<”,“>”,”|”,”-”, etc), nada mejor que TLDP-ES/LuCAS

Y eso es todo, ¡espero que os haya sido de utilidad!