sábado, 31 de agosto de 2013

Descargar videos de youtube con un combo de teclas.

Siguiendo la línea del post anterior en que uso mplayer para reproducir videos de youtube, se me acaba de ocurrir otro tip estúpido, de esos que simplifican la vida:
Descargar videos de youtube simplemente presionando una combinación de teclas (evitando así eso de instalar extensiones para el navegador que cumplan la misma función y si te pasa como en mi caso, evitando llevar las manos hasta el mouse para hacer click, que soy de los que tienen mas tiempo las manos en el teclado que en el mouse).
La idea es:
  • Copiar la URL (la dirección del video de youtube) al clipboard o portapales – como prefieran
  • Llamar por medio de un atajo de teclado a un script de bash que descargue el video en donde le especifiquemos.
  • Opcional: reproducir el video descargado con mplayer o tu reproductor de cabecera.
Desde un terminal (o si prefieren, en modo gráfico) creen una carpeta en donde almacenar los videos que descargará el script. El siguiente comando crea una carpeta llamada videos dentro de /home/tu_usuario/ :
mkdir  ~/videos
Instalar el paquete youtube-dl y si no lo tienen instalado del post anterior instalen además el paquete xclip. No puedo dar instrucciones específicas para cada distribución. Usen su gestor de paquetes para instalarlos. En Gentoo:
emerge youtube-dl xclip
Crear un archivo en blanco:
touch ytdl.sh
hacerlo ejecutable:
chmod +x ytdl.sh
Editar con su editor de texto de cabecera el archivo ytdl.sh:
nano ytdl.sh
Copiar dentro del archivo el siguiente contenido:
#!/bin/bash
youtube_url=`xclip -o|sed “s/ .*//”|head -n1`
cd ~/videos
#Descomentar la opción que se vaya a usar:
#Opción 1 sin especificar nombre de usuario y contraseña:
#youtube-dl -b -t $youtube_url
#Opción 2, especificado usuario y contraseña:
#youtube-dl -u <usuario> -p <password> -b -t $youtube_url
Crear un atajo de teclado que llame a ytdl.sh:
De nuevo no puedo dar instrucciones específicas pero todos los gestores de ventanas (Gnome, KDE, XFCE, etc…) tienen algún modo de definir atajos de teclado.
He estado mirando un poco y para usar atajos de teclado en XCFE que es el entorno de escritorio que estoy usando hay que ir a Settings / Xfce 4 settings manager / Keyboard / Application shortcuts. (Sepan disculpar pero tengo XFCE instalado en inglés).
Por ejemplo, asociar el combo de teclas CTRL + Y para que al ser pulsado ejecute ytdl.sh o si quieren llamarlo por el path completo, que llame a /usr/bin/ytdl.sh
Es realmente un TIP estúpido ¿No?
Simplifica mucho la vida, eso si…

Eliminar todos los archivos corruptos después de una recuperación de datos

Típico caso: Recuperación de datos, el medio ha sido sobreescrito con información reciente, con lo que no todos los archivos recuperables a bajo nivel salen sanos.
Lo que haría todo el mundo es abrir archivo por archivo de a uno verificando cuales estan sanos y cuales rotos lo que por resumirlo de alguna manera que englobe totalmente el concepto que quiero transmitir: Es un reverendísimo dolor de bolas.

Acción y efecto de probar todos los archivos recuperados uno por uno para detectar de forma manual cuales están corruptos
Buscar de entre los miles de archivos que nos puedan interesar cuales salieron sanos y cuales se corrompieron de manera manual como hice toda la vida es la parte que mas tiempo y recursos (mentales) consume. Por suerte alguien en los foros de Gentoo -fuente de eterna sabiduría informática si las hay- tuvo la misma inquietud pero además fué un poco mas inteligente que yo, quería hacerlo automáticamente. Ya de entrada venía bien encaminado cuando dijo:
Hola,
Tengo un respaldo de archivos antiguos de mi trabajo (principalmente MSOffice), en algún momento varios archivos se corrompieron, por lo que hay archivos que se pueden abrir y otros que no hay caso.
Quiero eliminar los archivos corruptos.
Para diferenciarlos de los buenos se me ocurrió utilizar el comando “file”
Ahí fué que se me encendió la lamparita y vengo utilizando este método automático desde entonces exitosamente. Es que el comando “file“, puede diferenciar a la perfección un tipo de archivo de otro con lo que cualquier archivo que estuviera corrupto, ya sea una imagen, un video, música o un documento de office en lugar de ser identificado como corresponde, simplemente figurará como de tipo “data“.
Tan sencillo como eso, eliminar del directorio que contiene los archivos recuperados, todos aquellos que figuren como de tipo “data“, a lo que Stolz, moderador del foro y mago programador de Bash respondió con este sencillo script que navega subdirectorios recursivamente eliminando todos los archivos que sean de tipo “data”:
find . -type f | while read linea; do
  tipo=`file -b "$linea"`
  if [[ $tipo == "data" ]];then
    rm  "$linea"
  fi
done
Paso a paso:
Se crea un archivo dentro de /usr/bin para que contenga al script, lo llamaremos “borrador_de_archivos_corruptos“:
nano /usr/bin/borrador_de_archivos_corruptos
Se copia el contenido del script y se pega dentro del archivo que estamos editando con nano (o el que sea tu editor de texto de cabecera).
Se sale guardando los cambios.
Se convierte el archivo en ejecutable:
chmod +x /usr/bin/borrador_de_archivos_corruptos
Y ya estça listo para usar.
IMPORTANTE: Ejecutar borrador_de_archivos_corruptos únicamente dentro de la carpeta que contiene la información salvada del proceso de recuperación de datos. Ejecutar el script fuera de la misma te va a borrar archivos que son de tipo “data” por que tienen que serlo, te va a hacer mierda todo lo que encuentre a su paso, para que se entienda.
Ya tenés otro motivo mas para tener un Linux siempre a mano.

3 formas de conocer el espacio en disco desde la consola de Linux

1 – Como saber cuanto ocupa una carpeta en Linux.

¿Cuantas veces necesitaste conocer cuanto espacio ocupa un directorio en particular? Desde la consola al ejecutar “du” por “Disk Ussage“:
~ # du /home/dvr/video/movie/
Te devuelve el tamaño en bloques del directorio en cuestión:
48004   /home/dvr/video/movie/
Como al sistema de archivos lo formateé en su momento con un tamaño de bloque de 1024 bytes -Por defecto se usan 4096 bytes si no se especifica un valor diferente para el parámetro en el argumento de la utilidad que formatea-, la cuenta es facil: 48004 bloques de 1024 bytes cada uno suman 49156096 bytes.
Como no podía ser de otra forma, para no tener que andar haciendo cálculos estrambóticos, se le puede pasar a la utilidad como argumento “-h” por “Human Readable”  para que devuelva el resultado en formato entendible por humanos:
~ # du /home/dvr/video/movie/ -h
47M     /home/dvr/video/movie/
Como el comando es recursivo, puede que te interese además agregarle la opción “-s” por “silent” para que cuando tenga que navegar muchos subdirectorios para sacar la cuenta no te llene la pantalla de texto. La otra muy util que tiene de entre tantas opciones disponibles es la posibilidad de producir un “gran total” con la opción “-c“, por ejemplo:
~ # du /home/dvr/video/movie/ -csh
47M     /home/dvr/video/movie/
47M     total

2 – Conocer el espacio utilizado/disponible por partición

Con la salida en modo “bloques” para el comando “df” por “Disk Free“:
~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda3              9297812   1988296   6837208  23% /
/dev/sdb1               397475    295084     75886  80% /usr/portage
/dev/sdb2             78628740   6382688  72246052   9% /home
O en modo “Human Readable” pasándole el argumento “-h“:
~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             8.9G  1.9G  6.6G  23% /
/dev/sdb1             389M  289M   75M  80% /usr/portage
/dev/sdb2              75G  6.1G   69G   9% /home

3 – Gráficos en la consola

Por ultimo la frutillita del postre, el que uso todo el tiempo, powered by python, “pydf“:

pydf en funcionamiento, mas gráfico imposible (para ser en consola).
Cada quien sabrá como lo instala con el gestor de paquetes de su distribución de cabecera, en Gentoo es tan simple como ejecutar:
~ # emerge pydf

Como seguramente habrá mas aplicaciones que no conozco, ¿Conocen ustedes algo mejorcito que pydf?

Loguear texto arbitrario a Syslog en Linux

Loguear texto arbitrario a Syslog en Linux

Esto viene mas que bien si ya estás aplicando el método que explico en este artículo anterior para centralizar todos los Logs que generan Linux, Windows y otros dispositivos que pudieras tener pululando en tu red en un solo host, para poder después leerlos cómodamente desde una página web.

Para que veas todo el mundo que te rodea en modo texto, de preferencia verde sobre fondo negro
Se puede loguear texto arbitrario a syslog desde cualquier PC corriendo Linux en la red simplemente por medio del comando “logger” (sin las comillas).
La salida de logger va a parar derechito a syslog y es accesible desde /var/log/messages:
~ # logger puto el que lee
~ # tail /var/log/messages

Nov 10 23:30:01 dvr cron[12109]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:40:01 dvr cron[12161]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:46:25 dvr root: puto el que lee
Hasta ahí nada de otro mundo, un comando que por si solo no tiene mucha magia, manda texto al syslog, ¿Y?
Por si solo no resalta en absoluto pero: ¿Qué pasa cuando necesitás loguear a syslog la salida de un comando cualquiera que por defecto va a la pantalla y no a syslog?
¡Bingo! Usando un pipe es cuestión de redireccionar la salida a logger para tenerlo accesible desde /var/log/messages, desde la red en el syslog server y desde la página web para mayor comodidad. Supongamos que quiero loguear la salida de ping a uno de los DNS de google:
~ # ping 8.8.8.8 -c2 | logger
~ # tail /var/log/messages

Nov 10 23:40:01 dvr cron[12161]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:46:25 dvr root: puto el que lee
Nov 10 23:50:01 dvr cron[12220]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:56:17 dvr logger: PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
Nov 10 23:56:17 dvr logger: 64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=178 ms
Nov 10 23:56:18 dvr logger: 64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=178 ms
Nov 10 23:56:18 dvr logger:
Nov 10 23:56:18 dvr logger: --- 8.8.8.8 ping statistics ---

Nov 10 23:56:18 dvr logger: 2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Nov 10 23:56:18 dvr logger: rtt min/avg/max/mdev = 178.639/178.658/178.677/0.019 ms
Te cambia la vida, ¿No?
A ver cuantos miles de usos le encontrás a esto.

Recibir logs remotos usando Syslog

Recibir logs remotos usando Syslog

Al que como yo se encuentre en un punto en donde se le vuelve tedioso ir servidor por servidor, dispositivo por dispositivo revisando los archivos de bitácora (logs) de cada uno, esto le resultará de utilidad.
syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.
Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye la fecha y hora del envío.

Recibir los logs de otros servidores en un servidor Linux:

En mi caso, mi servidor central corre Syslog-NG, pretendo recibir en este servidor todos los logs que generan otros servidores corriendo Linux y Windows, cámaras de seguridad, routers y puntos de acceso inalámbricos que controlo.

Syslog puede enviar información sobre TCP o UDP indistintamente. Por convención se usa el puerto 514 UDP. La mayoría de los dispositivos del tipo access points wireless o cámaras de seguridad no permiten especificar puerto o protocolo así que lo mejor es crear una regla en el firewall que reenvíe todo el tráfico del puerto 514 UDP que es la configuración por defecto a nuestro Syslog server:
iptables -A PREROUTING -t nat -i eth0 -p udp –dport 514 -j DNAT –to 192.168.1.150
Una vez hecho esto, habilitar Syslog-NG para que reciba tráfico por UDP editando el archivo /etc/syslog-ng/syslog-ng.conf:
source src {
unix-stream(“/dev/log” max-connections(256));
internal();
file(“/proc/kmsg”);
udp();
};
Con eso ya tenemos suficiente como para recibir todos los logs de otros servidores y dispositivos en la red o desde internet en nuestro servidor central syslog.

Consultando los Logs:

Todos estos logs se pueden consultar en diferido usando:
less /var/log/messages
O verlos en tiempo real desde una consola:
tail -f /var/log/messages
O traerlos desde tty12 a la tty1 para una cómoda visualización nuevamente editando /etc/syslog-ng/syslog-ng.conf:
# By default messages are logged to tty12…
destination console_all { file(“/dev/tty1“); };

Trayendo logs remotos hasta nuestro servidor syslog:

El paso siguiente es traer todos los logs remotos a nuestro servidor central para poder administrarlos con mas comodidad. A continuación algunos ejemplos para diferentes escenarios.

Windows:

En el caso de servidores que corren windows, bastará con instalar NTsyslog (requiere .NET 2.0 y windows installer 3.0) y configurarlo para que envíe los logs hasta nuestro syslogserver usando el número de IP o el nombre de dominio del mismo.

Linux:

Cuando el servidor remoto corre syslog-ng, agregar en el archivo de configuración:
destination remote { udp(“mi.servidor.com” port(514)); };
Cuando el servidor remoto corre rsyslog o similares, agregar en /etc/rsyslog.conf:
*.*     @mi.servidor.com

Otros dispositivos:

Dependerá del caso pero la gran mayoría de equipamiento de red de calidad permite el reenvío de logs a otros dispositivos, solo es cuestión de acceder a la página web de administración de los mismos y configurarlos según corresponda.
Por último, la frutillita del postre, acceder a estos logs usando un cliente web usando phpsyslogng, (requiere Apache/PHP/MySQL), eso lo dejo para la próxima entrada, que por hoy se me acabó el tiempo:

Video vigilancia automatizada con detección de movimiento en Linux.

Video vigilancia automatizada con detección de movimiento en Linux.

Este (mini)artículo no es mas que una actualización del artículo anterior: [HowTo] Sistema de vigilancia casero basado en Linux usando una webcam
.
En las pruebas que he ido haciendo hasta el momento, después de 15 días de funcionamiento sostenido:
~ # uptime
  
22:59:32 up 15 days,  7:47,  1 user,  load average: 0.31, 0.39, 0.36
Se porta como si recién hubiera arrancado:
~ # free -m
             total       used       free     shared    buffers     cached
Mem:           228        206         21          0         73         90
-/+ buffers/cache:         42        185
Swap:          517          2        515
Hoy cumple exactamente 31 días de grabación de corrido, en estos 31 días, como únicamente graba –y toma instantáneas- a 640×480 si detecta movimiento, me ha generado un total de 154579 archivos entre fotografías y videos, 7Gb de información:
~ # du -sh /home/dvr/video/
7.3G    /home/dvr/video/
Así que con un disco de 80Gb que tiene supera ampliamente mis estimaciones iniciales, tengo para grabar sin tener que borrar nada apróximadamente 10 meses de corrido, mejor que cualquier DVR comprada con disco de 320Gb.
Para ser gratis y casero, nada mal ¿Eh?

Sistema de videovigilancia casero usando una webcam.

Sistema de videovigilancia casero usando una webcam.

Otro título sugerido:
Lo que en Gentoo es facil, en Ubuntu se me complica.
Me he visto en la necesidad de implementar un sistema de videovigilancia para poder monitorear ciertos sectores de mi casa. Como me he cruzado en varias oportunidades con esas DVR de tipo standalone y me ha tocado configurarlas para que salgan a internet he visto que en muchos -si no en todos los- casos estos aparatitos por dentro corren Linux, el típico micro-kernel, busybox, un init a medida, un webserver básico y poca cosa mas.
Ante la disyuntiva “comprar uno de estos DVR vs hacerme uno propio“, de puro chatarrero me decidí por la segunda opción pensando que si un DVR con tan poco hardware puede hacer todo el trabajo, cualquier PC viejita debería darme el mismo resultado.
No es tan así. Un VIA Samuel 2 de 800Mhz (El que se vendía como VIA C3 1500+, básicamente un K6 III de 800Mhz o un Pentium II con esteroides, que ni siquiera es compatible con i686) a duras penas si alcanza para las dos cámaras que le he instalado.
La cuestión es que necesitaba el sistema funcionando, y lo necesitaba inmediatamente -eso fué hace una semana-, así que googleando un poco dí con Zoneminder, un centro de video vigilancia de código abierto con todas las de la ley que no tiene nada que envidiarle a los mejores productos pagos para otras plataformas.
¿Que hace uno cuando necesita un Linux funcionando rápido?
Va por la que debería ser la mas rápida de todas las opciones: Ubuntu
Craso error.
Nuevamente, no es tan así. Necesitaba el sistema implementado de inmediato y ya habían pasado tres días de prueba, google y error. No había conseguido hacer funcionar Zoneminder como debería, me dí cuenta de que por falta de recursos de hardware, puntualmente falta de microprocesador en Ubuntu… Después de limar Ubuntu hasta donde pude, desactivar todo lo que sé que no voy a usar, incluído el entorno gráfico, llegué a un punto en donde perdí conectividad, se rompió la consola de comandos, se rompió la instalación de Xorg, y se rompió al punto donde lo mas rápido era reinstalar que ponerse a reparar…
Como la necesidad tiene cara de hereje, Taringa de por medio, encontré que para windows hay infinidad de programas mucho menos profesionales que Zoneminder pero que en definitiva cumplen la misma función, lo único que necesito: Streaming HTTP de video desde dos Webcams en tiempo real y grabación con detección de movimiento.
Así fué como al cuarto día estaba cometiendo sacrilegio, instalando un Windows XP en la PC para poder grabar video con detección de movimiento.
Dos días mas tarde, todavía estaba peleando contra el crack, el virus que venía en el crack, el overlay que no funcionaba con la placa de video onboard de tan viejo motherboard, el driver de la placa de video a ver si esto mejoraba, al ver que no mejoraba. a cambiar de programa por algún otro que tampoco me convencia y así sucesivamente en un bucle infinito y la cosa se empezaba a poner desesperante.
En medio de todo eso andaba cuando de nuevo gracias a Google dí con un tal Motion.
Llenas las bolas como las tenía me decidí por la que debería haber sido mi primera opción, mi distribución de Linux de preferencia: Gentoo
Obviamente, instalar Gentoo en una PC de estas características lleva su tiempo, casi dos horas hasta tener un sistema autónomo booteable con lo básico para funcionar: El kernel, la red inalámbrica y motion. (De hecho, dos días después, mientras escribo esto, la pobrecita pc todavía está compilando software extra que quiero agregarle).
Una vez compilado el kernel para que tenga soporte para las dos webcams e instalado Motion, en Gentoo al menos, es coser y cantar.
Motion hace exactamente lo que necesito y mas inclusive. Corriendo sobre Gentoo, donde Ubuntu me dejaba sin microprocesador -por tantas pelotudeces que carga en el entorno gráfico y por fuera del mismo-, Gentoo va extra liviano. Con 7 Horas de uptime y mientras corre Motion y compila Samba:
dvr ~ # uptime
00:19:47 up  7:03,  1 user,  load average: 1.61, 1.66, 1.80
dvr ~ # free -m
total       used       free     shared    buffers     cached
Mem:        477480     424776      52704          0      38620     307212
-/+ buffers/cache:      78944     398536
Swap:      1060248        380    1059868
dvr ~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 799.047
cache size      : 64 KB
Por si no se entendió, 134Mb de ram utilizados, nada de Swap todavía, vamos a ver que pasa después de unos cuantos dias.
Tomando un screenshot cada vez que detecta movimiento y filmando además un video en formato mpeg4, después de 24 Hs de funcionamiento continuado me ha generado un total de 164Mb de información:
dvr ~ # du -sh /home/dvr/video/
164M    /home/dvr/video/
Regla de tres simple, tiene un viejo disco de 80Gb nada mas que para almacenar video, a 170Mb de video/fotografías por día promedio, tengo espacio suficiente como para grabar unos 45 días de corrido, un mes y medio. Nada mal para ser que no gasté ni un centavo.
Un poco de información técnica:
Instalar motion en Gentoo es tan simple como ejecutar:
emerge motion
Y esperar a que termine de compilar. La configuración se controla desde el archivo /etc/motion.conf y es autoexplicativa. Usando el viejo truco, he limpiado de comentarios mi archivo de configuración para que vean como me quedó:
dvr ~ # nocomentarios /etc/motion.conf
daemon on
process_id_file /var/run/motion/motion.pid
setup_mode off
videodevice /dev/video0
v4l2_palette 8
input 8
norm 0
frequency 0
rotate 0
width 640
height 480
framerate 24
minimum_frame_time 0
netcam_tolerant_check off
auto_brightness on
brightness 128
contrast 0
saturation 0
hue 0
roundrobin_frames 1
roundrobin_skip 1
switchfilter off
threshold 1500
threshold_tune off
noise_level 32
noise_tune on
despeckle EedDl
smart_mask_speed 0
lightswitch 0
minimum_motion_frames 1
pre_capture 5
post_capture 0
gap 60
max_mpeg_time 0
output_all off
output_normal on
output_motion off
quality 75
ppm off
ffmpeg_cap_new on
ffmpeg_cap_motion off
ffmpeg_timelapse 0
ffmpeg_timelapse_mode daily
ffmpeg_bps 500000
ffmpeg_variable_bitrate 0
ffmpeg_video_codec mpeg4
ffmpeg_deinterlace off
snapshot_interval 0
locate off
text_right %d-%m-%Y\n%T-%q
text_changes off
text_event %Y%m%d%H%M%S
text_double off
target_dir /home/dvr/video
snapshot_filename %v-%Y%m%d%H%M%S-snapshot
jpeg_filename %v-%Y%m%d%H%M%S-%q
movie_filename %v-%Y%m%d%H%M%S
timelapse_filename %Y%m%d-timelapse
webcam_port 8080
webcam_quality 100
webcam_motion off
webcam_maxrate 24
webcam_localhost off
webcam_limit 0
control_port 8081
control_localhost off
control_html_output on
control_authentication usuario:contraseña
track_type 0
track_auto off
track_motorx 0
track_motory 0
track_maxx 0
track_maxy 0
track_iomojo_id 0
track_step_angle_x 10
track_step_angle_y 10
track_move_wait 10
track_speed 255
track_stepsize 40
quiet on
thread /etc/motion1.conf
El archivo /etc/motion1.conf es una copia idéntica del anterior pero tomando video desde /dev/video1 (la segunda webcam).
Las webcams no tienen ninguna ciencia, son las típicas de 640×480 a 30FPS que en windows no necesitan driver ni nada para funcionar. La PC es un CPU sin monitor, ni teclado ni mouse, escondido para que no se vea, conectado a mi red inalámbrica. Tiene dos discos, uno de 10Gb desde donde Bootea y uno de 80Gb para almacenamiento. Tiene también 512Mb de RAM que nunca llegará a utilizar para nada con Gentoo al parecer. Con 128Mb andaría sobrado seguramente.
En definitiva: Si tenés por ahí una webcam y un CPU viejo tirado y necesitás videovigilancia superprofesional: Zoneminder es para sacarse el sombrero. Para uso doméstico, Motion va mas que bien y hasta donde lo he podido probar funciona todo tal y como debería, mejor inclusive que los 6 o 7 programitas diferentes para windows que probé y que supuestamente cumplían la misma función.
¿Lo mejor de todo?
GRATIS
Mi único gasto fueron los cables extensores USB para poder llevar las webcams lejos del CPU en cuestión.
Moraleja: El que no coje, se deja En informática, lo que parece el atajo es en realidad el camino mas largo entre dos puntos.

Controlar los logs generados por syslog desde una página web

Controlar los logs generados por syslog desde una página web


Usando phpsyslogng se pueden controlar los logs de cualquier PC que corra Linux y Syslog-NG de forma mucho mas visual e intuitiva.
Phpsyslogng provee  además de interesantes gráficos estadísticos y un potente sistema de filtrado por host, aplicación, prioridad y facility.

Para que todo esto funcione es necesario contar con una instalación preexistente de Apache con PHP y MySQL. No voy a entrar en detalles acerca de la instalación y configuración de cada uno de estos servicios por que está fuera del alcance de esta guía.

Instalación:

Usando el gestor de paquetes de su distribución preferida, instalar phpsyslogng. En Gentoo:
echo “app-admin/phpsyslogng mysql” >> /etc/portage/package.use
emerge  phpsyslogng
Opcional, si el servidor Apache está configurado para usar hosts virtuales, se puede instalar solo en uno de estos vhost habilitando la use flag correspondiente.
Una vez instalado, crear la base de datos correspondiente:
mysql> create database syslog;
Query OK, 1 row affected (0.18 sec)
El nombre de la base de datos (syslog) es arbitrario, pero es el que se sugiere por defecto durante la instalación.

Configuración de phpsyslogng:

Para que se rellene la base de datos con las tablas correspondientes basta con apuntar el browser a http://host.dominio.com/phpsyslogng, esto iniciará el asistente para finalizar la configuración en donde se solicitarán el nombre de usuario y contraseña de acceso, parámetros de la base de datos, etc.

Configurando Syslog-NG:

El paso siguiente es configurar Syslog-NG para que pueda convertir los logs a un formato que permita su inserción en la base de datos MySQL, para lo cual basta con editar /etc/syslog-ng/syslog-ng.conf y agregar lo siguiente:
destination d_mysql {
pipe(“/var/log/mysql.pipe”
template(“INSERT INTO logs
(host, facility, priority, level, tag, datetime, program, msg)
VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MON$
‘$PROGRAM’, ‘$MSG’ );\n”) template-escape(yes));
};
log {
source(src);
destination(d_mysql);
};
Como ven, todos los logs se envían al archivo /var/log/mysql.pipe que será el encargado de parsearlos y insertarlos en la base de datos, por lo cual, el próximo paso es generar este archivo.

Creando el pipe /var/log/mysql.pipe

Crear un archivo nuevo de nombre arbitrario y con permisos de ejecución:
touch /usr/bin/syslogasql.sh
chmod +x  /usr/bin/syslogasql.sh
Dentro de ese archivo copiar las siguientes líneas:
if [ ! -e /var/log/mysql.pipe ]
then
mkfifo /var/log/mysql.pipe
fi
while [ -e /var/log/mysql.pipe ]
do
mysql -u aqui_tu_usuario –password=aqui_tu_password syslog < /var/log/mysql.pipe >/dev/null
done
Este archivo ejecutable será el encargado de crear el archivo de tubería que rellene la base de datos con la información obtenida desde los logs del sistema. Tiene que estar en constante ejecución por lo que es conveniente que se ejecute al inicio del sistema. En Gentoo esto se logra agregando el nombre del archivo a /etc/conf.d/local.start:
echo “/usr/bin/syslogasql.sh” >> /etc/conf.d/local.start
Es importante que este archivo no se ejecute antes de que se haya iniciado el servidor MySQL.

¡Y eso es todo!

Mientras syslogasql.sh se mantenga en ejecución, toda la salida de syslog será cargada en la base de datos y podrá ser consultada desde phpsyslogng.

Una vez terminada la instalación, un poco de seguridad:

Borrar el directorio de instalación:
rm -fr /var/www/localhost/htdocs/phpsyslogng/install
Evitar accesos ilegítimos a directorios comprometedores agregando las siguientes directivas al archivo de configuración de Apache:
<Directory “/var/www/phpsyslogng/scripts”>
Deny from all
</Directory>
<Directory “/var/www/phpsyslogng/includes”>
Deny from all
</Directory>
<Directory “/var/www/phpsyslogng/config”>
Deny from all
</Directory>

Reiniciar Linux automáticamente si pierde conexión

Reiniciar Linux automáticamente si pierde conexión


Necesitaba reiniciar una PC en caso de que esta perdiera conectividad, lo que se conoce como “watchdog” – (perro guardián), así que a falta de conocimientos de programación, google de por medio, encontré este escript que transcribo mas abajo, ligeramente adaptado para que cumpla con esta función, ya que el original en realidad envíaba un email avisando del incidente:
#!/bin/sh
### Comprobar conectividad cada 60 segundos
while sleep 60
do
for ip in 192.168.1.100 192.168.1.102 192.168.0.7
do
if ping -c 1 -t 2 $ip >/dev/null
then
echo “$ip da OK”
else
echo “$ip perdió un paquete”
## Esperar 10 segundos y probar de nuevo
sleep 10
if ! ping -c 1 -t 2 $ip >/dev/null
then
echo “$ip perdió dos paquetes, reiniciando…”
reboot
fi
fi
done
done 2>&1
Lo he  guardado como /usr/bin/watchdog y lo he convertido en ejecutable con el comando:
chmod +x /usr/bin/watchdog
Funciona a la perfección. Se podría adaptar para cualquier otro uso, por ejemplo, que en lugar de reiniciar la PC reinicie la conexión de red únicamente, o que registre las desconexiones, etc, etc.
Me lo dejo de ayuda memoria y se los dejo por si le viene bien a alguien.

Cazando phishing, scammers, spammers y demases.

¿Cada quien se divierte como quiere no? Me llegó un mail de esos con publicidad barata, el tipico SPAM prometiendo la vida facil, inversiones rentables, la chancha, los 20 y la máquina de hacer chorizos…

Y me llegó en mal momento… (Me llegó sin tener yo nada mejor que hacer que enojarme con este tipo de gente).
Una cosa es que te manden propaganda no solicitada intentando vender algo. Si me interesa lo miro, si no, lo dejo pasar.
Otra cosa muy distinta es que por medio de engaños intenten sacarte guita. Meter la mano en el bolsillo de los ingenuos. DELITO, penado por la ley y todo.
Este SPAM (o SCAM, o PHISHING) que me llegó, si no fuera por un poco de investigación que hice tendría toooooda la pinta de ser uno de esos casos en donde el pobre estúpido engañado pierde unos cuantos pesos, y yo no tengo nada mejor que hacer ya mismo, así que -como dijo jack el destripador- vamos por partes:

Que se puede deducir de los hipervínculos (enlaces, links) nada mas pasando el mouse por encima:

Este email que recibí tiene varios enlaces como este:
http://uv0171.us13.toservers.com/emkt/out2.php?ie=37654&ic=2953&URL=http://www.elinmobiliario.com/info.php?cont=poolinmobiliario.pta&emp=Pool%20Inmobiliario
No hace falta ser un iluminado para darse cuenta de que están interactuando dos dominios: Tenemos por un lado el que llamaré dominio1: “uv0171.us13.toservers.com”  y por el otro el que llamaré dominio2: “www.elinmobiliario.com”.
Dominio1 con seguridad debe pertenecer al encargado del SPAM. Que puede que sea la misma persona dueña de dominio2, pero eso veremos mas adelante.
Dominio2 muy probablemente pertenezca a la persona que le está pagando al dueño de dominio1 a cambio de una campaña de SPAM.
La parte críptica que hay entre ambos dominios y que dice:
emkt/out2.php?ie=37654&ic=2953
Evidentemente se refiere a email o electronic marketing a lo que le sigue un tal out2.php. Este out2.php es el encargado de redireccionar la petición http que yo originaría si hiciera click en el enlace incrustado en el email desde dominio1 hasta dominio2, pero hay un detalle a tener en cuenta: ¿Cómo llevar un registro de la efectividad de la campaña de SPAM?
Ahi es donde entra en juego  ie=37654&ic=2953. Esos dos valores representan mi dirección de correo electrónico en su puta base de datos. Si yo le hubiera hecho click al enlace que inctrustaron en el correo electrónico que me enviaron, tan solo hubiera visto la página web que el señor SPAMMER pretendía vender, en este caso dominio2, pero en el trasfondo, quedaría registro:
  1. Yo hice click. La campaña de SPAM sirve.
  2. Peor aún: MI DIRECCION DE E-MAIL EXISTE! (si bien esto queda confirmado cuando un email no “rebota”).
  3. Habiendo clickeado el enlace he confirmado que la dirección de correo electrónico no solo que existe, si no que además está activa!!
…Imagino que el próximo paso hubiera sido mover o diferenciar de alguna manera con una marca en la base de datos las direcciones existentes de las que no, para de esta forma poder enviar mas correo basura no deseado y vender o canjear esta base de datos a otros SPAMMERS, con lo que la curva de correo basura que uno va recibiendo a lo largo de su vida, se vuelve exponencial, cosa que no me molesta en absoluto siempre y cuando quieran venderme algo y no tomarme por pelotudo.

Y se pone peor: ¿Qué se puede averiguar nada mas mirando el código fuente del susodicho  mensaje?

Received: from pajarito1.no-ip.info ([190.231.18.112])
Cosas como esta: El mail se envió desde una pc que es capaz de resolverse a si misma con el nombre de dominio pajarito1.no-ip.info que es parte de los nombres de dominio que se pueden obtener de dyndns.org gratuitamente para usuarios con número de IP dinámico. Al momento de enviar el mensaje, el número de IP público de este dominio de dyndns era 190.231.18.112 y que actualmente mientras escribo ha cambiado a este otro: 69.65.19.125.
Received: from unknown (HELO misreportes.com) (mrepo@192.168.1.6)
Que además de resolverse a si misma por la interface wan con un dominio de dyndns, el nombre de host de la pc desde la que se envió el correo basura es mrepo y en la red tiene el número de IP 192.168.1.6. (Con lo que se podría deducir que hay además de esta pc enviando SPAM, no menos de otras 4 pc en la misma red local).
Return-Path: newsr@misreportes.com
Que el objetivo de la campaña es llevar visitas a la página web de dominio2, que no prentenden recibir feedback (respuestas) por el mismo medio ya que la dirección de retorno pertenece a un dominio distinto a dominio2.
Si alguien sintiéndose interesado respondiera al correo electrónico que recibió lo único que lograría sería mas correo basura en su casilla de email, al confirmar que esta existe y está activa. (ver punto anterior).

Armado con todos estos datos, ¿Ahora que?

Veamos que hay detrás de uv0171.us13.toservers.com:
Interesting ports on us13.toservers.com (200.62.54.213):
Not shown: 984 filtered ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
26/tcp open rsftp
80/tcp open http
81/tcp open hosts2-ns
82/tcp closed xfer
110/tcp open pop3
143/tcp open imap
443/tcp open https
465/tcp open smtps
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql
5432/tcp closed postgresql
40911/tcp closed unknown
Se trata de un servidor linux, evidentemente. Está corriendo SSHd en el puerto 22 tcp.
La RSA Key fingerprint del servidor SSH es  7d:6f:0a:de:bc:9f:9c:19:be:1c:71:f6:a2:84:bc:4d (Se podría buscar en la lista de claves pseudo aleatorias generadas por la famosa vulnerabilidad de openssh en Debian y derivados para saber si estamos lidiando con este sistema operativo en -relativamente- poco tiempo.
~ $ ncat us13.toservers.com 21
220-FTP server ready.
220 This is a private system – No anonymous login
Nada por aquí, nada por allá, pero eso tiene toda la apariencia de ser el típico flag de bienvenida de proftpd.
~ $ ncat us13.toservers.com 25
220 us13.toservers.com ESMTP Postfix 2.7.40
Postfix corriendo en el 25 y 465… Ninguna pista acerca de la versión de linux.
~ $ curl http://us13.toservers.com
<b>us13.toservers.com</b>
Es un servidor dedicado parte del pool de toservers.com, nuestro scammer está haciendo uso del subdominio uv0171 dentro del mismo:
curl uv0171.us13.toservers.com
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
<html>
<head>
<title></title>
</head>
<body>
</body>
</html>
Ninguna pista interesante, no han alojado una página web en el subdominio para no levantar sospechas…
~ $ ncat uv0171.us13.toservers.com 80
GET HTTP/1.1
Apache tampoco revela nada, acerca de  la versión o sistema operativo sobre el que corre, el que mantiene estos servidores dedicados sabe lo que hace.
Veamos que pasa si hacemos fallar apache:
~ $ curl uv0171.us13.toservers.com/pepito.html
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /pepito.html was not found on this server.<P>
<P>Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.
<HR>
<ADDRESS>Apache/1.3.29 Server at onlineproject.com.ar Port 80</ADDRESS>
</BODY></HTML>
Bingo! Apache/1.3.29 Server at onlineproject.com.ar

Haciendo un poco de orden, que averigüé en 5 minutos acerca de la gente que está detrás de este mensaje de correo no deseado:

  • Dos números de IP: 190.231.18.112 y 69.65.19.125 (por pajarito1.no-ip.info) desde los cuales alguien sentado frente a la pc que en su red interna se llama mrepo cuyo número de IP es 192.168.1.6 envió SPAM por medio de un PHP mailer instalado en un servidor dedicado.
  • 5 nombres de dominio implicados: pajarito1.no-ip.info / misreportes.com / elinmobiliario.com / toservers.com (que probablemente no tenga nada que ver en el asunto) / onlineproject.com.ar
Que mas se puede sacar en claro disponiendo de esta información:
Podemos empezar por ver quienes son esos números de IP en ws.arin.net:
El primer número de IP desde el cual se originó el mensaje de correo, siguiendo el enlace desde arin.net hasta lacnic.net pertenece a Telecom:
inetnum: 190.231.18/23
status: reallocated
owner: Apolo -Gold-Telecom-Per
Nada nuevo, el tipo tiene Arnet de Telecom en su oficina, ¿Y con esto que?
Que un usuario mal intencionado bien intencionado podría hacer uso de:
person: Administrador Abuse
e-mail: abuse@TA.TELECOM.COM.AR
address: Dorrego, 2520, Piso 7
address: 1425 – Buenos Aires -
country: AR
phone: +54 11 4968 [4900]
Para poner una denuncia, si no fuera que estamos en un país bananero en donde nadie nos va a dar ni tronco de bola.
El segundo número de IP está asentado en Illinois, EE.UU. Lo único que se saca en concreto de esto es que se está haciendo uso de un proxy en alguno de los dos casos usandolo como cloak para la IP real. Esto es facilmente comprobable tirando de nmap:
Interesting ports on 69.65.19.125:
Not shown: 997 filtered ports
PORT STATE SERVICE
80/tcp open http
8080/tcp open http-proxy
8888/tcp open sun-answerbook
Hagan sus apuestas: ¿Cual era el número de IP real del SPAMMER hoy 20 de Julio de 2009 a la hora 13:39:46 GMT -3 y cual es el que está detrás de un proxy?
Adivinaron!

¿Que mas se puede obtener de los 5 nombres de dominio ?

El dominio elinmobiliario.com, según el Network Information Center:
Administrative Contact:
Rossetti, Esteban erossetti@<borrado para evitar que le llegue SPAM>
Desarrollo Creativo
Calle Rivadavia <borrada la altura>
Cordoba, Cordoba 5000
Argentina
<borrado telefono> <borrado fax>
Parece ser simplemente el webmaster del sitio en cuestión si no fuera que además tiene a su nombre el dominio onlineproject…
Igualmente interesante, el dominio misreportes.com según nic.com:
Administrative Contact:
Pallaro, Andres soyrapallaro@<borrado, para que no le manden SPAM>
Calle Tucuman <borrada la altura>
Cordoba, Argentina 5000
Argentina
<borrado el teléfono celular>
Por último: El dominio onlineproject.com.ar según el Network Information Center de Argentina que es el que aloja el phpmailer en donde una base de datos corroborará si hice click o no en el vínculo:
Entidad Registrante: Esteban Rossetti
País: Argentina
Actividad: desarrollos de sitios web
Datos en Argentina

Domicilio: Rivadavia <borrado> piso <borrado> dpto <borrado>
Ciudad/Localidad: Cordoba
Provincia:
Código Postal: 5000
Teléfono: <borrado>
Fax: <borrado>
Conclusión:
  • No toma mas de diez minutos obtener, dirección de email, dirección real, nombre real, teléfonos, etc.
  • Aparentemente se trata solo de una campaña de email intentando vender y no de PHISHING, (gente intentando engañar), lo cual me molesta un 99.9% menos que las revistas de supermercados que me pasan por debajo de la puerta con ofertas, que esas si me ocupan espacio en la vida real, me llenan el cesto de basura, me ensucian las manos, me joden las pelotas! Alguien que legisle ese tipo de SPAM, que estoy seguro que contamina mas y jode mas.
  • No soy quien para hacer lío por esto, menos en un país en donde las leyes no funcionan.
  • Nada de esto pasará nunca de una mera explicación, pero que espero sirva para entender con que facilidad se puede rastrear a la persona detrás del correo electrónico.

CADENAS DE EMAIL, El famoso FWD:

Por cada vez que reenvias una de esas cadenas de email a todos tus contactos sin usar CCO (Con Copia Oculta) estás metiendo a todos tus contactos en una lista de gente que mas tarde o mas temprano acabará en las manos de un spammer que la usará para engrosar su base de datos, y que a su vez la venderá o canjeará engrosando las bases de otros spammers y así secuencialmente sucesivamente…
Usen el CCO, corten las cadenas de email reduciéndolas a lo que deberían ser, simples mensajes de correo electrónico que mueren en el destinatario. (Y mientras termino de escribir esto, siendo las 00:01 GMT -3 acabo de recibir otro SPAM de news@misreportes.com queriendo venderme dos edificios inmejorables en zona nueva

Backup automático de tu sitio web o blog por FTP usando rsync.

Backup automático de tu sitio web o blog por FTP usando rsync.

Lo que sigue debe de ser una de las formas mas ineficientes de hacer un backup de un sitio existiendo tantas otras alternativas. No es por nada que cpanel, plesk, ispadmin y demáses te ofrecen la posibilidad de descargar un único .tar.gz conteniendo toda la información de tu sitio de un solo plumazo, pero ¿y cuando no tenés acceso al panel de control o login de shell?
Este caso es un clásico:
  • Tenés únicamente acceso FTP al espacio en donde alojás tu sitio, CMS, Blog o lo que fuere.
  • Querés hacer backups de vez en cuando de todo el contenido así cuando todo se vaya al bombo tenés desde donde recuperarlo.
Te explico como lo hago en mi caso, que es una de las tantas alternativas existentes. Con suerte, podrías trasladarlo al tuyo o inclusive, usar pedazos de mi idea en algún otro de tus proyectos.
La cuestión no es si vas a perder tus datos o no. La cuestión es cuando y por que.
Herramientas necesarias:
  • Una PC corriendo Linux
  • curlftp instalado o la posibilidad de escalar privilegios a super-usuario para poder instalar la herramienta.
  • rsync
Curlftpfs es una implementación basada en FUSE que usa libcURL como backend para todo lo que hace a la transferencia de archivos. Te permite montar -de manera transparente para el sistema operativo y por intermedio del protocolo FTP- un directorio remoto cualquiera y trabajarlo como si fuera un directorio local mas del montón.
Si no lo instalaste ya, tirá de tu gestor de paquetes de cabecera e instalálo. Lo he probado en Gentoo y Debian, de los dos lados el paquete se llama igual: curlftpfs.
Rsync por otro lado, ni necesita presentación y suele venir pre-instalado en cualquier distribución de medio pelo para arriba.

Como funciona:
Con curlftpfs instalado y siempre como root o precediendo el comando con un buen “sudo”, esta es la sintaxis para montar un directorio remoto en el equipo local:
curlftpfs usuario:contraseña@servidor /ruta/al/directorio_local
Que siendo un poco mas realistas, debería verse mas o menos como sigue:
curlftpfs bill:mg1955@blog.microsoft.com /mnt/blog_remoto
Y que para simplificar todo el asunto, podés agregar a tu /etc/fstab como sigue:
curlftpfs#bill:mg1955@blog.microsoft.com /mnt/blog_remoto fuse defaults 0 0
Y de esta forma, obviar todo el comando larguísimo y en su lugar usar este comando cortito cada vez que quieras montar o desmontar el directorio FTP:
mount /mnt/blog_remoto
¿Vieron en donde en el fstab dice “defaults”? Eso es por que podés montar el sistema de archivos especificando diferentes atributos como por ejemplo: caché, uid, umask y un pequeño etcétera que podés encontrar ejecutando: man curlftpfs.
Teniendo montado el sistema de archivos remoto, solo tenés que tirar de rsync para sincronizar dos directorios arbitrarios:
rsync –av /mnt/blog_remoto /mnt/blog_local
Lo que hará que todo el contenido del directorio blog_remoto se replique dentro del directorio blog_local.
La primera ejecución traerá todos los archivos que hubiera en el sitio web por lo que podés esperar que se tome su tiempo pero de ahí en mas, cada ejecución consecutiva del comando sólo te va a descargar archivos nuevos o modificados. Ahorrás tiempo y ancho de banda.
Automatización:
Para que todo lo anterior ocurra sin tu intervención, podés hacer un script “backup.sh” que contenga algo parecido a esto:
#!/bin/bash
mount /mnt/blog_remoto
rsync –av /mnt/blog_remoto /mnt/blog_local
sync
umount /mnt/blog_remoto
Depués de que hubieras hecho a tu backup.sh ejecutable, podés llamarlo todos los días a las 13:00 por ejemplo, si en tu crontab dice:
00 13 * * * /ruta/al_archivo/backup.sh >/dev/null 2>&1

Mas tunning:
¿Y la base de datos?
Si tuvieras una o mas bases de datos MySQL, podés hacer un volcado de la misma a un .sql antes de correr tu backup.sh simplemente poniendo un script.php que se encargue de eso, por ejemplo:
Montás tu FTP en local:
mount /mnt/blog_remoto
Creás un directorio para alojar tus backups:
mkdir /mnt/blog_remoto/public_html/sqlbackup
Le das privilegios de escritura y ejecución:
chmod 777 /mnt/blog_remoto/public_html/sqlbackup
Ponés dentro de la carpeta recientemente creada un archivo “backup.php” como el que saqué de acá que dentro diga:
<?php
$dbhost   = “mysql.tusitio.com”;
$dbuser   = “tu_nombre_de_usuario”;
$dbpwd    = “tu_contraseña”;
$dbname   = “tu_base_de_datos”;
$dumpfile = $dbname . “_” . date(“Y-m-d_H-i-s”) . “.sql”;
passthru(“/usr/bin/mysqldump –opt –host=$dbhost –user=$dbuser –password=$dbpwd $dbname > $dumpfile”);
// report – disable with // if not needed
// must look like “– Dump completed on …”
echo “$dumpfile “; passthru(“tail -1 $dumpfile”);
?>
Y agregás una línea a tu backup.sh para que ejecute backup.php antes de iniciar el rsync, de modo que todo el script te quedaría mas o menos así:
#!/bin/bash
curl http://www.tusitio.com/sqlbackup/backup.php &&
mount /mnt/blog_remoto &&
rsync –av /mnt/blog_remoto /mnt/blog_local &&
sync &&
umount /mnt/blog_remoto
Para no llenar tu directorio sqlbackup con mierda dumps mysql, te recomiendo agregar en donde mas te guste una línea “rm *.sql” que se lleve puesto cualquier backup anterior que hubieras alojado ahí.

Reportes vía email:
Y por último, si te interesa recibir por mail un reporte del backup, podrías modificar tu crontab para que diga:
00 13 * * * /ruta/al_archivo/backup.sh | mail –s “Backup Diario – `date`” tu_direción@de_email.com
Ah, y si tu linux todavía no se comunica con vos por mail, podés seguir esta guía que escribí en su momento para usar una cuenta de Gmail a tal efecto.

Verificar el estado de salud de tu conexión a internet o Wi-Fi.

Verificar el estado de salud de tu conexión a internet o Wi-Fi.

“Dime cuantos paquetes de datos pierdes y te diré cuán como la mierda navegas.”
… O de como hacer uso y abuso del comando ping para verificar un enlace de datos.
Mas que nada en conexiones inalámbricas pero puede darse en cualquier otra circunstancia también y por motivos de lo mas diversos, además de una buena latencia es muy importante evitar la pérdida de paquetes de datos entre tu PC y su interlocutor a toda costa.
Hay miles de herramientas, algunas que funcionan en modo texto, otras tantas en modo gráfico que te permiten darte una idea muy aproximada de la calidad real de un enlace de datos pero si tengo que poner primera en la lista de las mas usadas al menos por mí -y creo que por el colectivo de informáticos también- definitivamente el comando ping para consola se lleva todos los laureles, además viene preinstalado de serie en cualquier sistema operativo, sea el que sea.
De todo corazón espero que no seas usuario de Windows. Si lo sos, entonces ni te gastes en seguir leyendo, por que si bien el comando ping para windows dispone de alrededor del 2% de las funcionalidades que nos provee el mismo para Linux, todo lo que voy a explicar a continucación queda sin efecto. Si sos usuario de Windows por otro lado, he aquí otra buena razón para tener siempre un Linux cualquiera a mano, en un CD, en un pendrive o en alguna partición pequeñita, por que nunca sabés cuando lo vas a necesitar.
Volviendo al asunto, no voy a entrar en detalles sobre el principio de funcionamiento del comando ping para Linux ni a explicar como entender la salida en pantalla del mismo (para los que se estén desayunando con esto por primera vez y les interese, los remito al manual del comando) si no a centrarme en una característica puntual que lo vuelve una de las mejores herramientas a la hora de hacer verficaciones de calidad de servicio mientras se hacen modificaciones sobre el enlace de datos: La capacidad de inundación, lo que en inglés se conoce como “Flood”.
Ping para Linux es la navaja suiza de las herramientas de testeo de calidad del enlace y la capacidad de floodear que posee debe ser una de las mejores herramientas “graficas” para consola que podés encontrar por ahí. Unicamente disponible para superusuarios -necesitás privilegios de root para poder usar esta caraterística- te permite conocer con presición como anda la cosa mientras toqueteás algún que otro parámetro en tu router.
La genialidad de la opción flood radica en su principio de funcionamiento: Por cada paquete de datos que se envía se imprime un punto -un ” . “- en la pantalla. Por cada paquete de datos que se recibe, se borra un punto. Eso es todo.
El nombre de “flood” o inundación que sería la traducción literal proviene del hecho de que el kernel no esperará absolutamente nada entre un paquete enviado y otro, inundará la red con peticiones usando el protocolo ICMP tan rápido con el enlace en si mismo lo permita y a menos que específicamente le habilites el modo “adaptativo” pasandole al comando la opción ” -A ” forzará al enlace a todo lo que dé produciendo inevitablemente fallos que serás capaz de visualizar a golpe de ojo nada mas viendo como se van imprimiendo (o no) puntitos en la pantalla en tiempo real.
Dependiendo del escenario puede que te interese verificar cuanto es el máximo ancho de banda disponible en un enlace inalámbrico o cuantos paquetes pierde tu conexiòn a internet por culpa de lo anterior. Suponiendo que quisieramos hacer esta última prueba, haciendo ping contra el servidor de DNS de Google por ejemplo, el comando en cuestión es tan simple como lo que sigue:
ping -f 8.8.8.8
Que en una red sana debería devolverte algo como esto:

Usando ping con flood habilitado para verificar el estado de la conexión.
Y que por otro lado, en una red con problemas, debería devolverte esto otro:



Verificando una red con problemas de pérdida de paquetes con ping.
Todos los puntitos que se ven en la última captura representaron en tiempo real la pérdida de paquetes que hubo durante todo el proceso. Usé además la opción “count” representada por ” -c ” para pedirle a ping que solo envíe 1000 paquetes y se detenga a continuación.
Es muy util también la opción “size” para especificar el tamaño de paquete, esto sirve para diagnosticar otro tipo de problemas por ejemplo cuando estás jugando con el MTU de tus routers o interfaces de red o el RTS o el Fragemnation Threshold de tu router inalámbrico.
Como la cabecera del protocolo ICMP utiliza siempre 8 bytes, para forjar un paquete por ejemplo de 512 bytes de tamaño necesitas tener estos 8 bytes en cuenta, restándoselos al momento de ejecutar el comando:
ping -f -c 1000 -s 504
Es muy común ver como una red inalámbrica se desempeña a la perfección con paquetes de datos pequeñitos, los de 64 bytes que envía ping por defecto (la cabecera ICMP + 56 bytes adicionales) cuando no se le especifica el tamaño pero se viene todo a pique cuando el tamaño de paquete excede los 512 o 768 bytes, por ejemplo. Y ni hablar de cuando excede al MTU que por defecto en este tipo de redes es de 1500 bytes.
También es muy útil a la hora de testear redes que tienen implementado QoS por que permite especificar los bits ToS en la cabecera del paquete, con lo que podés ver en tiempo real que tal se desempeña tu router en este sentido. Por ejemplo para el ToS “Maximice Data Throughput” basta con ejecutar:
ping -f -c 1000 -s 504 -Q 0x08
Ping: La herramienta que no te puede faltar a la hora de aislar fallos puntuales en una red. Preinstalada por defecto y gratis. ¿Que mas se puede pedir?

Los 10 comandos que mas utilizas

Linux: Los 10 comandos que mas utilizas.



Interesante combinación de herramientas esta, para que en una sola línea y aprovechandonos vilmente de los pipes podamos conocer cuales son los 10 comandos que mas tipeás en la consola de tu Linux:
history | awk ‘{print $2}’ | sort | uniq -c | sort -rn | head -10
Que en mi caso devuelve:
roadrunner ~ # history | awk '{print $2}' | sort | uniq -c | sort -rn | head -10
    180 ping
     76 ifconfig
     71 iwconfig
     50 iptables
     47 hamachi
     42 nmap
     36 emerge
     27 ssh
     27 cat
     25 eix
Esa fué mi laptop, como root. Saquen sus propias conclusiones: ¿Para que la uso mayoritariamente?
Y ya que estamos ¿Que resultados obtienen ustedes?

Como grabar una sesión en la consola de comandos de Linux

Como grabar una sesión en la consola de comandos de Linux.

En determinadas circunstancias (léase: mañana mismo ya no te vas a acordar de como fué que hiciste la tal o cual cosa), puede que te interese grabar un registro, un log, de todo lo que tu consola de comandos fué escupiendo y lo que le fuiste respondiendo en consecuencia.
Mas command Line Ninjitsu en Maldito Nerd y ya empieza a darme vergüenza usar siempre la misma fotito esta…

Si alguna vez te pasó cualquiera de estas, deberías seguir leyendo:

  • Necesitás reproducir todo el setup de la tal o cual aplicación que instalaste en una PC hace tres años, en otra PC que acabás de adquirir. Ni te acordás por donde empezar y el tutorial que seguiste aquella vez no lo encontrás por ningún lado, o nunca hubo e improvisaste sobre la marcha.
  • Como nunca lo encontraste, seguís un tutorial nuevo, hacés mierda todo y tenés que volver a empezar de cero por que llegaste al punto donde es mas rápido reinstalar que debuggear.
  • Necesitabas leer la salida del último comando que tipeaste, pero te escupió tanto texto junto que lo importante te quedó fuera del buffer así que por mucho scroll hacia arriba que hagas, estás cagado.
  • Estás corriendo algo dentro de una sesión de screen, te quedaste sin tabaco así que tuviste que salir de urgencia al kiosko de la esquina. Cuando volvés, te quedaste sin internet , se te cerró la conexión SSH, se te cerró screen y te perdiste de algo importante por que otra vez, te falta buffer.
  • Tenés que darle shell a tu (amigo/empleado/cliente/subordinado/programador nigeriano freelance) y querés registrar en un log todo lo que pase mientras el susodicho esté logueado solamente por que paranoia mejor que sobre y no que falte.
  • Por último, la mas boluda de todas pero es la que el manual propone como la única cosa para la que sirve: Necesitás tomarle examen a tus alumnos… ¿?
Y así sucesivamente, un largo etcétera…
Tanto todas las veces que te olvidaste de aumentarle el buffer a tu cliente de terminal, screen y/o PuTTY y te perdiste de algo, como las veces en que ni pensaste que fuera a hacer falta, mas tarde o mas temprano te vas encontrar con que tener un registro de todo lo que pasó, te hubiera venido de lujo y que no, no lo tenés.
También te puede servir, como decía al principio, de ayuda memoria, así que de las cientos de formas que debe haber de lograr el mismo resultado, aquí la que debe ser la mas fácil de todas:

Como registrar todo -pero todo todo-, lo que pasa en la consola de comandos:

El artilugio que hace toda la magia acá es el comando “script” que no tiene demasiada ciencia.
  • Si no se le especifica ningún parámetro, script registra toda la sesión en curso en el archivo ./typescript
  • Si querés agregar contenido al archivo de registro sin perder el contenido anterior, podés ejecutarlo en modo append: script -a
  • Si querés loguear en un archivo distinto al por defecto: script /path/al/archivo.txt (Se puede usar -a para append).
Si querés escribir desde el buffer al archivo línea a línea en lugar de al salir, tenés que ejecutarlo con flush activado: script -f
Si no usaste flush por líneas, para que el contenido de la sesión se grabe en el archivo hay que salir de script y volver al shell con “exit”.
Se supone además que esto puede funcionar como una forma rudimentaria de compartir una sesión con otros usuarios por shell por que hacés un fifo y escribís línea a línea: mkfifo session.txt && script -f session.txt y después uno o mas usuarios pueden ver que carajos estás haciendo, tirando de tail -f session.txt.
Eso si, todo muy bonito hasta que ejecutaste cualquier editor interactivo de texto, que es cuando se te llena el log de basura.
Por último, como es muy fácil tipear comandos sin que queden registrados en el ~/.bash_history, podría ser que quieras asegurarte de que tu programador nigeriano freelance no te vaya a instalar un ssmtp y se ponga a mandar scams desde tu número de IP.

Como espiar sigilosamente, como si fuera un keylogger barato, toda sesión de bash que pase por tu PC, para la posteridad o por las dudas:

Como cada vez que iniciás sesión en tu cuenta se ejecuta el interprete de comandos que hubiera especificado en /etc/passwd, poné un script con permisos de ejecución -léase chmod +x- en tu /home y cambiá tu /etc/passwd para que lo llame:
pink:x:1007:1007:pink,,,:/home/pink:/home/pink/log.sh
En donde en log.sh se lee:
#!/bin/bash
SHELL=/bin/bash /usr/bin/script -a -f /$PWD/bash_log-$USER-`date`.log 2>&1
Una porquería, lo sé, pero es lo que me salió hasta ahora…
Próxima entrega si la hubiera: Llamar a script desde /etc/profile o /etc/bash_profile como root así el usuario no puede ver y borrar/editar su propio log. (Todavía en fase alpha).

Como verificar un vhost desde la shell con cURL.

Como verificar un vhost desde la shell con cURL.

Shared Hosting, Hosting compartido, ¿te suena el concepto?
Si no te suena pero tenés un blog o página web, entonces debería, por que lo más probable es que estés en un hosting compartido, donde una única instancia de webserver por número de IP aloja mas de un dominio.
Mas command Line Ninjitsu en Maldito Nerd y ya empieza a darme vergüenza usar siempre la misma imágen esta…
Este blog, sin ir mas lejos, está en un hosting compartido. Este es el número de IP detrás del cual un Apache sirve los contenidos que estás leyendo ya mismo:
# host malditonerd.com
malditonerd.com has address 67.205.62.197
En este mismo servidor, además del hilachento, se alojan otros sitios, por ejemplo:
# host alsweddings.com
alsweddings.com has address 67.205.62.197
Internamente, el webserver -Apache en mi caso-, denomina a  cada uno de estos sitios “vhosts”.

¿Como sabe Apache que tu navegador está intentando entrar a malditonerd.com y no a alswedding.com cuando recibe la petición de servir una página?


Cuando tu browser quiere mostrarte el contenido de malditonerd.com, el sistema operativo le pregunta al servidor  de DNS:
- ¿Cual es el número de IP de malditonerd.com?
- Este: 67.205.62.197
El sistema operativo le avisa entonces al browser que se tiene que conectar al número de IP en cuestión y el browser establece la conexión agregando un HTTP Header especial: “host”.
El HTTP header “host” que recibe el Apache detrás del IP 67.205.62.197 se usa entonces para que el servidor web sepa distinguir si tiene que mostrar este blog de mierda o la paginita de una wedding planner. ¿No es maravilloso?.

Si acabás de montar una página nueva o blog que todavía no tiene un nombre de dominio o anduviste haciendo cambios en tus vhosts por la causa que fuera, te vas a encontrar con la necesidad de verificar si funciona pero no vas a poder por que cuando tu sistema operativo le pregunte a tu servidor de DNS cual es el IP del dominio especificado, tu DNS te va a responder con un número de IP incorrecto si existiera de antemano o directamente te va a decir que no existe, que no rompas mas los huevos.
Llegado a este punto, tus opciones son dos:
  • Agregar el par nombre de dominio / número de IP a tu archivo hosts.
  • Probar con un browser que te permita modificar los HTTP headers.

cURL al rescate.

Si leiste hasta acá probablemente seas del tipo de persona de los que siempre tienen una shell corriendo, entonces, ¿qué más fácil que usar el comando curl para testear un vhost?
Con la opción “-H” podés indicarle a curl que agregue al request HTTP headers adicionales, así que para probar el vhost malditonerd.com en el IP 67.205.62.197 no tenés mas que hacer:
# curl -H "host: malditonerd.com" 67.205.62.197
Si tu vhost no anda, debería devolverte un 404, not found, con lo que podés agregarle una vueltita de tuerca al asunto, como acá, que lo hago fallar adrede pidiéndole al Apache detrás de otro número de IP de vaya uno a saber quién, que me muestre a malditonerd.com:
curl -H "host: malditonerd.com" 75.101.143.93 | grep 404

Obvio, tenés que tener cURL instalado de antemano, pero es coser y cantar y es un viaje de ida.

Calidad de servicio fácil en Linux.

HowTo: QoS, Calidad de servicio fácil en Linux.

Ayer leyendo Un Sanjuanino en Rio Cuarto me dí con una entrada mencionando un vínculo a HowtoForge donde se plantea la alternativa mas facil que he visto hasta ahora para tener una implementación de QoS (por Quality of service en inglés: calidad de servicio) que aunque rudimentaria es totalmente funcional.
Se puede extender a cualquier otra disciplina de encolado y mejorar en función de las necesidades de cada uno, así que vamos a los bifes.

Requisitos necesarios:

  • Kernel con soporte para iptables.
  • Iptables instalado.
  • El comando tc instalado, que es parte del paquete iproute2
  • Opcional, l7filter para iptables.
Cualquier distribución orientada a servidor/router o redes en general ya trae estos tres requisitos preinstalados y configurados. En caso de no ser así basta con usar el gestor de paquetes de cabecera para instalar iproute2 e iptables, y seguir cualquier guía de configuración del kernel para darle soporte a iptables.

Esquematizando un poco:

El esquema de mi red es exactamente el mismo del ejemplo de howtoforge:
[internet]<–>[cablemodem]<–>[eth1  linux  eth0]<–>[red local]
Queda en cada uno adaptar las siguientes instrucciones para la topología de su red.

Implementación:

Todos los paquetes en su cabecera pueden contener o no el bit indicador de tipo de servicio (de ahora en mas ToS por Type of Service en inglés). Hay en total cuatro tipos de servicio que se pueden combinar entre sí en la práctica (aun que no debería hacerse en la teoría):
  • 0×02: Minimize Monetary Cost | Minimizar costo monetario
  • 0×04: Maximize Reliability | Maximizar fiabilidad
  • 0×08: Maximize Throughput | Maximizar tasa de transferencia
  • 0×10: Minimize Delay | Minimizar latencia
De la combinación de estos cuatro ítems surge un total de 16 combinaciones de ToS posibles, en hexadecimal:
  1. 0×00: No se especifica el bit ToS
  2. 0×02: Mimimize Monetary Cost (MMC)
  3. 0×04: Maximize Reliability (MR)
  4. 0×06: MMC + MR
  5. 0×08: Maximize Throughput (MT)
  6. 0x0a: MT + MMC
  7. 0x0c: MT + MR
  8. 0x0e: MT + MR + MMC
  9. 0×10: Minimize Delay (MD)
  10. 0×12: MD + MMC
  11. 0×14: MD + MR
  12. 0×16: MD + MMC + MR
  13. 0×18: MD + MT
  14. 0x1a: MD + MT + MMC
  15. 0x1c: MD + MT + MR
  16. 0x1e: MD + MT + MR + MMC
Que obviamente no es necesario recordar, pero que viene bien para entender mejor la sintaxis del comando tc mas adelante.

Creación de la disciplina de encolado raíz (qdisc root):

tc qdisc add dev eth1 root handle 1: prio priomap 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 0
La disciplina de encolado prio crea por defecto 3 colas, numeradas del cero al dos.
Priomap está enviando todo el tráfico que tenga activado los bits ToS de las primeras ocho combinaciones posibles -desde 0×00 hasta 0x0e- a la tercera cola (cola número 2) y  las siguientes siete combinaciones -desde 0×010 hasta 0x1c- en la segunda cola (cola número 1).
Todo el tráfico que tenga el bit ToS marcado como 0x1e irá a parar a la primera cola, la cero.
Hasta que no se vacía la primera cola, no se le da paso a la segunda cola, y hasta que no se vacía esta última no se le da paso a la tercera cola.
El howto a continuación agrega stochastic fairness queueing -que encabeza el top-ten de las cosas complicadas que he memorizado en mi vida- a cada una de las colas prio para que estas tengan además una disciplina de encolado por si misma:
tc qdisc add dev eth1 parent 1:1 handle 10: sfq
tc qdisc add dev eth1 parent 1:2 handle 20: sfq
tc qdisc add dev eth1 parent 1:3 handle 30: sfq perturb 10
Como la tercera cola es la que alojará todo el tráfico sin clasificar, se reconfigura el hash cada 10 segundos usando perturb 10. Con suerte, todo el tráfico p2p saltador de puertos -que hace las delicias del administrador de red promedio- irá a parar a esta cola.
Solo resta comenzar a clasificar el tráfico de alguna forma para que los servicios mas interactivos (SSH, World of Warcraft, Counter Strike, VoIP, etc…) vayan por la primera cola, el resto del tráfico “no-tan-importante” por la segunda cola, y todo el tráfico “bulk”, p2p y demás porquerías por la tercera cola.
Esto se puede conseguir de dos formas, con tc o con iptables.

Usando tc para clasificar el tráfico:

Ejemplo 1: Todo el tráfico que tenga como origen o destino el puerto 22 (SSH), por la primera cola:
tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:1
Y todo lo que tenga como origen el puerto 80 (HTTP), por la segunda cola:
tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 80 0xffff flowid 1:2
Ejemplo 2: Todo el tráfico que genera el host 192.168.0.150 por la primera cola:
tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip src 192.168.0.150 flowid 1:1
tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dst 192.168.0.150 flowid 1:1
Y así sucesivamente, por número de IP o por número de puerto, adaptándolo a sus necesidades.

Marcando el bit ToS con iptables:

La otra posibilidad es usar iptables dentro de la tabla mangle para modificar los paquetes al vuelo, habilitándole a cada uno el bit ToS correspondiente según sus necesidades.
Ejemplo 1: Tráfico SSH, por la primera cola se ha dicho! (marcado como 0x1e)
iptables -t mangle -A PREROUTING -p tcp –dport ssh -j TOS –set-tos 0x1e
iptables -t mangle -A PREROUTING -p tcp –sport ssh -j TOS –set-tos 0x1e
¿Descargas de rapidshare? A la segunda cola!:
iptables -t mangle -A PREROUTING -p tcp -sport 80 -j TOS –set-tos 0×10
Por supuesto que estos son solo ejemplos, habrá quien prefiera dejar HTTP para el final y priorizar otros servicios…
Ejemplo 2: El tráfico que genera 192.168.0.150 a la primera cola:
iptables -t mangle -A PREROUTING -s 192.168.0.150 -j TOS –set-tos 0×010
Frutillita del postre o ejemplo 3: Teniendo instalado l7filter se pueden hacer cosas como esta, indistintamente del número de puerto o número de IP:
iptables -t mangle -A PREROUTING -m layer7 –l7proto edonkey -j TOS –set-tos 0×02
Y asegurarnos de esta forma de que emule, edonkey, mldonkey y cuanto otro clon exista en nuestra red, vayan siempre por la tercera cola, por tener seteado el bit 0×02.
O este otro:
iptables -t mangle -A PREROUTING -m layer7 –l7proto worldofwarcraft -j TOS –set-tos 0x1e
Para asegurarnos la mas baja latencia -el menor ping, como dicen los gamers- posible en el juego en cuestión.
Para ver la lista de protocolos soportados por l7filter, visitar la página web del proyecto.
Cualquier duda, sugerencia, correción, critica destructiva, etc, no duden en comentar.

Como rutear todo el tráfico de tu PC o tu router por un tunel SSH

Como rutear todo el tráfico de tu PC o tu router por un tunel SSH

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.

¿Y por que no simplemente una VPN o un tunel SSH pensarán ustedes? Por todo lo siguiente:

  • No necesitas instalar una VPN en ambas puntas.
  • No necesitas privilegios administrativos en el servidor.
  • El servidor no necesariamente tiene que correr Linux.
  • Ni siquiera Hamachi es lo suficientemente simple en comparación.
  • Nunca vas a perder paquetes, la sesión SSH puede que pierda paquetes, inconveniente que TCP se encargará de solventar por vos con lo que tu conexión se vuelve mucho mas confiable.
  • No necesitás instalar nada en ninguno de los dos extremos, solo el interprete de comandos Python (Si llegaste hasta acá, sabés de que estoy hablando y obviamente tenés Python instalado).
  • Si quisieras routear mas de un servicio por medio de un tunel SSH deberías establecer una sesión SSH por cada uno de ellos y hacer uso de la tabla nat de iptables para redirigir paquetes, muy complicado de implementar cuando lo único que necesitás es una conexión fiable y encriptada y la necesitás ya mismo.

Ahora si, a los bifes:

Toda la magia radica en una maravillosa pieza de software escrita en Python por un tal Avery Pennarun que ha sido dada en llamar sshuttle (que conveniente) que se encarga de crear un tunel SSH a modo de proxy transparente y reenviar todo el tráfico que generan todas tus aplicaciones -salvo por las peticiones a los servidores de DNS, seguramente pensando en un relay local con caché, pero inclusive esto último también se puede enviar por el tunel llegado el caso- hasta un script también basado en Python que sshutlle se encargó previamente de subir y poner a correr en el servidor remoto. Este script es el que recibe el tráfico y lo reenvía de ida y vuelta. Todo lo anterior a su vez gracias a un par de reglas de redirección basadas en iptables con lo cual ni haría falta que te lo especifique pero va por las dudas, los requisitos:
  • Git
  • Python
  • Iptables
Complicadísimo, ¿No?
Salvo contadas excepciones, lo mas probable es que el Linux desde el que me estás leyendo ya venga con todo lo anterior preinstalado de serie así que ni te molestes. Si por otro lado, usás Windows, he aquí otra excusa mas de entre las tantas para tener siempre un Linux a mano.

¿Como se usa?

Mas facil, imposible: Primero, descargar sshuttle en cualquier lugar en donde te quede cómodo, se creará el directorio sshuttle automáticamente, como siempre:
git clone git://github.com/apenwarr/sshuttle
Habéndote posicionado en el directorio sshuttle -como root- lo ejecutás:
./sshuttle -r <usuario>@<servidor>:<puerto> 0/0
Y eso es todo. Para configuraciones mas complejas basta con ejecutar ./sshuttle para hacerse de la ayuda en pantalla.
El 0/0 del final no es mas que la abreviatura de 0.0.0.0/0 y hace referencia a subred desde la cual se considerará tráfico como permitido para transitar el túnel, esto es útil cuando por ejemplo la PC que establece el túnel es además el router de toda una subred con lo que podés cambiar el número de IP WAN de toda tu red en un santiamén para saltear las restricciones de algún servidor de descargas mal habido. Restringir el tráfico solo a una porción de tu subred puede servirte también para esos casos en que no confiás en todos tus usuarios.
Que les sea leve.