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.