Ejecutar como servicio un programa que no es demonizable

Hoy estuve lidiando con una aplicación que se ejecuta desde consola y queda escuchando en un puerto, pero que no provee la posibilidad de correr como demonio (tipo Apache, sshd, etc). Para no tener que loguear un usuario y dejar la aplicación en ejecución en alguna consola colgada, mejor es convertirla en un servicio. Mi caso en particular se dió con la aplicación CherryMusic, que permite compartir musica a través de una interfaz web.

Como primer paso, vamos a crear un directorio donde alojar la aplicación, y para un caso como el que describo, creo que el mejor lugar es /opt:

# mkdir /opt/cherrymusic

Para cherrymusic, si hacen un clone del proyecto, el directorio se crea sólo, lo mismo si descomprimen un tar.gz.

A continuación creemos el usuario con el que se ejecutará la aplicación:

# useradd cherrymusic -d /opt/cherrymusic -s /bin/false

El comando anterior indica que el home del usuario será /opt/cherrymusic y que utilice /bin/false como shell... es decir, que no tenga shell.

Para ver qué sucede con nuestra aplicación, estaría bueno ver algún log, así que creemos uno, con los permisos necesarios para que la aplicación pueda escribir:

# touch /var/log/cherrymusic
# chown cherrymusic /var/log/cherrymusic

La ejecución del programa la haremos de la siguiente forma:

# sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic --port 8080 &>>/var/log/cherrymusic

Esto es, le decimos que ejecute la aplicación con el usuario cherrymusic (-u), usando el home de dicho usuario (-H), y redirigimos la salida a /var/log/cherrymusic

Como último paso, creamos un init script. Si usamos el viejo estándar, podemos meter un script como el siguiente en /etc/init.d/cherrymusic

#!/bin/bash
### BEGIN INIT INFO
# Provides:          cherrymusic
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO
case "$1" in
  start)
    iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
    sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic --port 8080 &>>/var/log/cherrymusic
    ;;
  stop)
    iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
    killall -u cherrymusic
    ;;
  *)
    echo "usage: $0 <start | stop>"
    ;;
esac

Ok, tal vez un killall no es lo mejor, pero sirve para mostrar un script muy simple.

Al script le agregué un "plus" que es levantar una regla iptables que redirija lo que llegue por el puerto 80, al 8080. Esto se debe a que, al ejecutar el script con un usuario no privilegiado, el mismo no se puede hookear al puerto 80.

Faltaría sólo agregarlo para que se ejecute al inicio:

  # update-rc.d cherrymusic defaults

Si quisieramos hacer lo mismo, pero utilizando upstart, podemos crear el siguiente archivo en /etc/init/cherrymusic.conf:

# Cherry Music
#
start on runlevel [2345]
stop on runlevel [!2345]
script
  iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
  sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic --port 8080 &>>/var/log/cherrymusic
end script
post-stop script
  iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
end script

Eso es todo, ya pueden utilizar "service cherrymusic start" y "service cherrymusic stop", y además la aplicación se ejecutará cada vez que se encienda el equipo. Los pasos serían los mismos si ejecutaran cualquier otra aplicación =)

ejabberd LDAP, certificados y clustering

Después de pelear durante un par de días con ejabberd, me pareció interesante compartir la experiencia ganada en el proceso, ya que no todo es tan directo como parece. La documentación oficial está buena, pero la encontré un poco escueta, por lo que si no usas una configuración similar a la de los ejemplos, no sabes bien qué poner en cada parámetro.
Ejabberd está escrito en lenguaje Erlang, y utiliza el formato de este lenguaje para su archivo de configuración. Si bien no es complicado, no es a lo que uno está acostumbrado.

Comenzaré con lo básico de todos los tutoriales, pero con la idea de que el servidor autenticará con LDAP en lugar de la autenticación interna. Luego pasaré a los topics más interesantes como autopopular rosters con grupos de usuarios LDAP y armar un servicio de alta disponibilidad con dos servidores ejabberd.


Instalación

En debian, Ubuntu y supongo que otros derivados también, ejabberd se encuentra en los repositorios oficiales, por lo que instalarlo es tan fácil como ejecutar lo siguiente:
  # apt-get install ejabberd


Configuración básica

Toda la configuración se realiza desde el archivo /etc/ejabberd/ejabberd.cfg. De base, tendremos que editar lo siguiente:

  {hosts, ["dvpem.org"]}.
  {acl, admin, {user, "vektor", "dvpem.org"}}.

donde:

• hosts especifica los dominios que ejabberd manejará.
• acl Indica cuál es el usuario admin. Si utilizan LDAP (ver a continuación) este usuario debe ser uno que exista en el servidor de LDAP.

Como ven, muy poco es necesario para tener ejabberd funcionando. Si no utiliza LDAP deberán cambiar el nombre de usuario por uno local, y luego agregarlo con el comando ejabberctl. Por ejemplo:

  # ejabberdctl register vektor dvpem.org superPASS

Es posible acceder a una interfaz web de administración apuntando a la siguiente URL:

http://<host-o-IP>:5280/admin

Habilitar LDAP

Para habilitar autenticación por LDAP veamos un ejemplo de configuración y qué significa cada valor:

%%{auth_method, internal}.
{auth_method, ldap}.
{ldap_servers, ["ldap.dvpem.org"]}.
{ldap_base, "ou=People,dc=dvpem,dc=org"}.
{ldap_rootdn, "cn=Usuario,dc=dvpem,dc=org"}.
{ldap_password, "PASSusuario"}.
{ldap_port, 636}.
{ldap_encrypt, tls}.
{ldap_uids, [{"uid", "%u"}]}.

Vamos por línea:

1. Deshabilita (comenta) autenticación interna.
2. Habilita autenticación por LDAP.
3. ldap_servers: indica cuáles son los servidores LDAP a los que se conectará ejabberd.
4. ldap_base: especifica el DN base a partir del cual buscar los usuarios. Esto dependerá si se utiliza AD, OpenLDAP, u schemas propios.
5. ldap_rootdn: especifica el usuario utilizado para conectar ejabberd con LDAP. El usuario utilizado debe poder listar usuarios y grupos, como mínimo.
6. ldap_password: password del usuario utilizado en la conexión con LDAP.
7. ldap_port: puerto del servidor LDAP.
8. ldap_encrypt: indica que utilice TLS en la conexión.
9. ldap_uids: indica qué atributo contiene el identificador del usuario. Esto también variará según el schema. En AD podría utilizarse samAccountName.

Reiniciar servidor ejabberd:

# server ejabberd restart

Nota 1: si iniciar ejabberd falla, probar de ejecutarlo en modo debug:

# ejabberd --debug

Nota 2: cuando la configuración está mal (o algo falla), puede que igualmente ejabberd deje un procesos corriendo y que ello les traiga problemas al intentar iniciar ejabberd nuevamente. Es un problema que queda medio oculto porque al iniciar ejabberd no arroja error, pero al mirar la lista de procesos escuchando, vemos que ninguno espera conexiones en el puerto default 5222 o 5280. En este caso, buscar y matar los procesos colgados antes de iniciar ejabberd nuevamente:

# killall -u ejabberd

Usar grupos de LDAP como grupos en los rosters

Es posible tomar los grupos de LDAP y utilizarlos en el roster, de forma que cada cliente que se conecte vea los grupos y los usuarios incluidos. Para ello, se puede utilizar el módulo mod_shared_roster_ldap, que por defecto no viene habilitado. Editar el archivo ejabberd.cfg, y en la sección de módulos agregar mod_shared_roster_ldap:

...
{modules,
 [
  ....
  {mod_shared_roster_ldap, [
        {ldap_base, "ou=Group,dc=dvpem,dc=org"},
        {ldap_rfilter, "(objectClass=posixGroup)"},
        {ldap_ufilter, "(&(objectClass=posixAccount)(uid=%u))},
        {ldap_gfilter, "(&(objectClass=posixGroup)(cn=%g))"},
        {ldap_groupattr, "cn"},
        {ldap_groupdesc, "cn"},
        {ldap_memberattr,"memberUid"},
        {ldap_memberattr_format, "cn=%u,ou=People,dc=dvpem,dc=org"},
        {ldap_useruid, "uid"},
        {ldap_userdesc, "cn"}
        ]},
 ]}.

El ejemplo está armado pensando en un servidor OpenLDAP, pero es fácilmente adaptable a AD, sólo hay que cambiar los nombres de los atributos.
Veamos cada uno de los atributos:

• ldap_base: indica a partir de donde buscar los grupos para popular el roster.
• ldap_rfilter: filtro que utilizará para popular el roster, y como los grupos del roster son los mismos de LDAP, pues ahí va. Dado que el base ya apunta a los grupos, no sería estrictamente necesario ya que no debería haber otra cosa que grupos en esa OU, pero por las dudas... En este caso se asume que los grupos son Posix, si usan AD tendrán que cambiar por el fitro que mejor les quede.
• ldap_ufilter: filtro para obtener el atributo que contiene el nombre "humano" del usuario. Préstese atención que con este filtro obtenemos el nombre del atributo, no el valor del atributo, para esto último está ldap_user_desc. 
• ldap_gfilter: filtro para obtener el nombre "humano" de los grupos. Misma idea que con ldap_ufilter.
• ldap_groupattr: nombre del atributo LDAP que tiene el nombre del grupo.
• ldap_groupdesc: nombre del atributo que tiene el nombre "humano" del grupo. Se usa en conjunto con ldap_gfilter, obteniendo del resultado de este filtro su valor.
• ldap_memberattr: nombre del atributo LDAP que apunta a los miembros del grupo (member también es común).
• ldap_memberattr_format: especifica el formato en que se guardan los miembros de un grupo. Por ejemplo, pueden tener cn=vektor,ou=People,dc=dvpem,dc=org. El %u le indica cuál es el nombre del usuario.
• ldap_useruid: nombre del atributo que contiene el ID de usuario (en AD samAccountName).
• ldap_user_desc: nombre del atributo que contiene el nombre "humano" del usuario. Se utiliza en conjunto con ldap_ufilter, obteniendo del resultado de este filtro su valor.

Instalar certificado propio

Para habilitar TLS/SSL ejabberd utiliza un sólo archivo que contiene clave privada, certificado y cadena de certificados. Por defecto, se genera uno al instalar ejabberd, denominado ejabberd.pem. Para no tener que editar el archivo de configuración, lo más simple es reemplazar este archivo con uno generado por nosotros a partir de nuestros certificados y clave. Este super archivo debe contener los datos en el siguiente orden:

1. Clave privada
2. Certificado
3. Cadena certificante

De modo que, si por ejemplo tenemos los archivos private.key, certificado.crt y CA.crt, podemos unirlos fácilmente utilizando cat de la siguiente manera:

# cat private.key certificado.key CA.crt > /etc/ejabberd/ejabberd.pem

Timeouts

Un problema que surgió en uno de los servers que instalé, es que después de un rato de inactividad, las conexiones TCP de ejabberd con LDAP mueren. Buscando encontré que si no hay actividad durante un dado período de tiempo, algunos equipos de red pueden "desconectar" las sesiones TCP sin notificar al software que las está usando. En este caso, desde ejabberd se sigue viendo como que la conexión está activa, y al ver la conexión activa la utiliza pero sin obtener resultados. Desde mi punto de vista, esto es un bug en ejabberd, ya que si al realizar consultas no se obtiene respuesta, debería cerrar esa conexión e intentar conectarse nuevamente al servidor LDAP. En lugar de hacer eso, sólo da un authentication failure, sin loguear siquiera un timeout en los logs :S

Lo importánte aquí es la solución a este problema. El kernel de Linux soporta el envío de paquetes keepalive, para mantener activas conexiones TCP o marcar una conexión como "muerta". Esto lo realiza enviando paquetes keepalive a intervalos definidos de tiempo, esperando respuesta del servidor para decidir si la conexión está muerta. Es decir, cumple dos funciones, por un lado envía paquetes generando tráfico de red para que la conexión no se muera, y en el caso de que la conexión ya esté muerta, lo detecta y le avisa a la aplicación que la está usando.
La configuración se realiza a través de tres variables que se encuentran en /proc/sys/net/ipv4/

• tcp_keepalive_time: default 7200 segundos, es decir, 2 horas. Especifica el intervalo en segundos entre el primer paquete de una secuencia de pruebas keepalive y el primer paquete de la próxima.
• tcp_keepalive_intvl: default 75 segundos. Indica cada cuántos segundos enviar paquetes keepalive en una secuencia.
• tcp_keepalive_probes: default 9. Valor numérico que especifica cuántos paquetes enviar en una secuencia.

El mecanismo es el siguiente: el kernel envía un paquete keepalive, espera el tiempo especificado en tcp_keepalive_intvl y envía otro, espera de nuevo y luego envía otro, así hasta alcanzar la cantidad de pruebas indicadas en tcp_keepalive_probes. Es decir, por defecto enviará 9 paquetes con una diferencia de 75 entre sí. Si no hay respuesta del otro lado, marca la conexión como muerta. Mientras tanto, una vez que se envió el primer paquete de esta secuencia, comienzan a contarse los segundos, y cuando se llega al valor de tcp_keepalive_time, comienza de nuevo con la secuencia mencionada.

Para no tener el problema de conexiones muertas podemo acomodar estos valores, ya que 2hs de espera puede ser demasiado. Según este post (http://start.nwt.fhstp.ac.at/blog/?p=307), los valores que mejores resultado les dieron son los siguientes:

tcp_keepalive_time = 600
tcp_keepalive_intvl = 30
tcp_keepalive_probes = 5

Lo cual se puede setear ejecutando:

# echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 30 > /proc/sys/net/ipv4/tcp_keepalive_intvl
# echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

Al reiniciar el servidor, estos valores se perderán, pero pueden generar un script en bash que se ejecute al inicio.

Así que ya saben, si ven que las conexiones con el servidor LDAP figuran activas (lsof -Pni), pero los clientes dan authentication failure sin razón, prueben esta solución.


Clustering 

La configuración de un cluster ejabberd, es decir, tener más de un servidor ejabberd sirviendo el mismo dominio, es medio críptica, pero no compleja. Digo críptica porque hay que ejecutar comandos Erlang para que funcione. Básicamente configurar un cluster ejabberd es igual a configurar un cluster mnesia. Erlang utiliza mnesia, un manejador de base de datos distribuido, y lo que hay que hacer es configurar mnesia para que funcione en modo replicación.

Si bien la configuración puede ser multimaster, llamaré Master al primer nodo que damos de alta y Slave al segundo.


Configuración Master

Copiar cookie mágica de Erlang que se encuentra en /var/lib/ejabberd/.erlang.cookie al nodo slave. Esta cookie debe ser igual en todos los nodos.

# scp /var/lib/ejabberd/.erlang.cookie vektor@chat2.dvpem.org:~

O bien hacer un cat de .erlang.cookie y pegar el contenido en el nodo destino.

Editar archivo /etc/default/ejabberd y agregar las líneas:

ERLANG_NODE=ejabberd@chat1
INET_DIST_INTERFACE={192,168,1,1}

donde:

1. ERLANG_NODE especifica el nombre completo del nodo.
2. INET_DIST_INTERFACE es la IP en la cual esperará conexiones. Utilizar comas para separar los octetos, es decir, en lugar de utilizar los convencionales puntos, separar con comas.

Reiniciar el master:

# service ejabberd restart

Configuración Slave

Detener el servicio de ejabberd:

# service ejabberd stop
# killall -u ejabberd

Editar archivo /etc/default/ejabberd y agregar las líneas:

ERLANG_NODE=ejabberd@chat2
INET_DIST_INTERFACE={192,168,1,2}

Mover la cookie al directorio de ejabberd y cambiar los permisos para que el usuario ejabberd la pueda acceder:

# mv .erlang.cookie /var/lib/ejabberd/
# chown ejabberd:ejabberd /var/lib/ejabberd/.erlang.cookie
# chmod 400 /var/lib/ejabberd/.erlang.cookie

Iniciar ejabberd:

# service ejabberd start

Asegurarse que ejabberd se está ejecutando:

  # ejabberctl status

Abrir una consola Erlang para conectar al nodo 1 y realizar una copia de la base de datos:

# ejabberctl debug

En la consola Erlang, ejecutar lo siguiente:

(ejabberd@chat2)1> mnesia:stop(),
(ejabberd@chat2)1> mnesia:delete_schema([node()]),
(ejabberd@chat2)1> mnesia:start(),
(ejabberd@chat2)1> mnesia:change_config(extra_db_nodes, ['ejabberd@chat1']),
(ejabberd@chat2)1> mnesia:change_table_copy_type(schema, node(), disc_copies).
(ejabberd@chat2)1> mnesia:info().

Cerrar la sesión precionando Ctrl+c Ctrl+c

donde:

• mnesia:stop() detiene la ejecución de la BD mnesia,
• mnesia:delete_schema([node()]) elimina el schema actual del nodo,
• mnesia:start() inicia nuevamente la BD,
• mnesia:change_config(extra_db_nodes, ['ejabberd@chat1']) apunta la base de datos al nodo 1
• mnesia:change_table_copy_type(schema, node(), disc_copies) crea una copia local del schema.
• mnesia:info() imprime información del nodo. Al ejecutar este comando deberían ver ambos nodos en ejecución:
    ...
    running db nodes   = ['ejabberd@chat1','ejabberd@chat2']
    ...

Esto sólo copia el esquema de la base de datos en el slave. Si bien todo funciona correctamente así, si el master cae, el sistema en teoría deja de funcionar, ya que el slave no tiene copia de las tablas.
Ahora, para tener un entorno multi-master hay que realizar una copia de todas las tablas en el nodo slave... que ya no sería más slave, sino otro master. En este caso los writes serán más lentos, pero tendremos un entorno de alta disponibilidad.
El comando para copiar tablas de otro nodo es mnesia:add_table_copy... pero hacerlo tabla por tabla es tedioso. Encontré en un comentario de StackOverflow como hacer una copia de todas las tablas en un comando:

(ejabberd@chat2)1> [{Tb, mnesia:add_table_copy(Tb, node(), Type)} || {Tb, [{'ejabberd@chat1', Type}]} <- [{T, mnesia:table_info(T, where_to_commit)} || T <- mnesia:system_info(tables)]].

Hay que ejecutarlo en una consola Erlang con "ejabberdctl debug".


Referencias

• ejabberd 14.12 - Installation and Operation Guide 
• Ejabberd Installation and Operation Guide 
• Ejabberd Active Directory LDAP Login 
• mod_shared_roster_ldap 0.5.3 - Shared Roster LDAP Documentation 
• Ejabberd SSL Certificate 
• Ejabberd cluster on Ubuntu Server  
• Set up a federated XMPP Chat Network with ejabberd, your own Google Talk/Hangouts alternative 
• Straight-forward Clustering of ejabberd 

Tips: Montar carpeta compartida VirtualBox en Guests debian y derivados

Hoy me topé con un problema extraño, pero que por lo que encontré googleando, es común. Hasta ahora no se me había dado por montar shares en una máquina virtual debian (virtualizada usando VirtualBox), así que no me había pasado. Usando guests Windows siempre me funcionó correctamente.
Dado que requiere algunos pasos, decidí armar un mini instructivo de cómo hacerlo, ya que seguramente alguien más se encuentre con el mismo problema. Veamos los pasos:

Como todo manual de VBox indica, primero hay que instalar las Guest Additions antes de poder compartir carpetas entre el host y el guest. Previo a esto, hay que contar con los headers del kernel (paquete linux-headers-), y make. Una vez que cuentan con estos paquetes (make instala los compiladores y demás), realizar lo siguiente:

1. Ir a la ventana de la máquina virtual, elegir la opción "Dispositivos" -> Insertar imagen de CD de las «Guest Additions»". Esto habilitará la imagen en la lectora virtual del guest.
2. Montar el cd virtual ejecutando: mount /dev/cdrom -o exec
3. Ejecutar el script correspondiente a Linux:  /media/cdrom/VBoxLinuxAdditions.run

Con lo anterior debería bastar para montar los shares según el manual oficial, ejecutando:

mount -t vboxsf share /lugar-a-montar

Sin embargo esto no es así en debian (y derivados también, no se en otras distros), al menos al utilizar VBox 4.3.10. Por alguna razón cambiaron de lugar el path donde se instalan las Guest Additions, o bien apuntaron mal el enlace de mount.vboxsf... sea cual sea la razón, al intentar montar una partición, mount dará error y syslog dirá:

sf_read_super_aux err=-22

Para evitar esto, tenemos dos alternativas:
1. Linkear el directorio desde donde debería estar a donde realmente está:

ln -s /opt/VBoxGuestAdditions-4.3.10/lib/VBoxGuestAdditions /usr/lib/

2. O linkear el ejecutable mount.vboxsf a donde está el ejecutable realmente:

rm /sbin/mount.vboxsf
ln -s /opt/VBoxGuestAdditions-4.3.10/lib/VBoxGuestAdditions/mount.vboxsf /sbin/mount.vboxsf

Bien, esto debería alcanzar... salvo en algunos casos. Increíblemente si dejamos el mismo nombre de share que el del directorio al que apunta el share (por ejemplo usar el share "datos" para apuntar al directorio /datos), mount fallará horriblemente diciendo:

/sbin/mount.vboxsf: mounting failed with the error: Protocol error

Mientras que syslog indicará lo siguiente:

sf_read_super_aux err=-71

WTF?! si, increíble. Así que recuerden llamar distinto al share que a la carpeta a la que apunta. Por ejemplo, ponerle vdatos al share que apunta a /datos en el host (siguiendo el ejemplo anterior).

Ahora si, a montar felizmente (?!).

Referencias

Shared folders will not mount after 3.10 update
Mounting share directory on Linux host result in Protocol error if default share name is used

Teclado loco en Ubuntu

Escribo este post porque perdí toda la mañana del domingo renegando con esto y tal vez a alguien le sirva la solución:

El día anterior necesitaba trabajar en mi notebook y tuve la idea de usar los periféricos de la PC (monitor, teclado y mouse) para estar más cómodo. Todo funcionó perfecto, salvo que tuve que ajustar un poco la frecuencia de refresco para que se adapte mejor al monitor de 17" de la PC.

El problema apareció hoy cuando quise volver a utilizar mi notebook sin los periféricos de la PC. Al iniciar gnome, luego de loguearme, el teclado funcionaba de manera extraña: la tecla 'u' escribía un '4'; la 'i' un '5'; la 'o' un '6'; etc. Pero la mitad izquierda del teclado funcionaba perfectamente.

Al darme cuenta que el teclado funcionaba perfectamente antes de iniciar gdm (ya que mi contraseña para ingresar funcionaba) comencé a investigar un poco la configuración de gnome. Encontré que en directorio:

~/.gconf/desktop/gnome/peripherals/keyboard/.../0/

Existía un archivo llamado:

%gconf.xml

El mismo (lamentablemente lo borré por lo que no tengo el contenido exacto) tenía una única línea significativa que indicaba que la tecla 'Block Num' estaba activada. He aquí el problema, mi notebook no posee teclado numérico, por lo tanto no tiene esa tecla. Lo que sucedía era que las teclas entre la 'n' y la 'p' funcionaban como teclado numérico.


La solución fácil

Borrar el archivo "%gconf.xml" y el reiniciar gdm. El teclado vuelve a la normalidad.

236 troyanos en el disco C:\

Recientemente tuve que reparar un Windows XP infectado con un bonito virus polimórfico (W32.Sality). Este virus infecta los archivos ejecutables en discos locales, removibles y shares de smb. Además crea una botnet P2P y, lo mejor de todo, deshabilita todo software de seguridad instalado (léase antivirus). Esto último que parece tan peligroso en realidad es una debilidad, ya que lo pone en evidencia y permite detectar fácilmente que el sistema está infectado (un virus indetectable es mucho más peligroso ya que puede controlar un sistema durante mucho tiempo).

En el sitio de Symantec se puede leer una descripción completa del mismo. Aparentemente es un virus antiguo ya que se originó en Rusia (que novedad jeje) por el 2003. Se infecta reemplazando el código en el punto de entrada de los ejecutables para redirigir al código polimórfico, que se encripta y se adiciona en la última sección de los archivos.

Como comenté anteriormente, la forma de detectarlo fue fácil: desapareció el ícono del antivirus (en este caso ClamWin) de la barra de tareas de Windows XP y era imposible tratar de iniciarlo. Luego de escanear los discos utilizando clamav (desde un Linux instalado en otra partición, aunque podría ser también desde un livecd) se detectaron una gran cantidad de infecciones en archivos .exe.

Para remover el virus sin acudir a simple pero tediosa "formateada/reinstalada" utilicé una herramienta de AVG hecha a medida para este caso. Aunque previamente tuve que reparar la registry ya que Windows era incapaz de arrancar en modo a prueba de fallos a causa del virus.

Luego de desinfectar completamente el sistema utilizando la herramienta de AVG (tardó unas tres horas aproximadamente) el mismo volvió a funcionar correctamente, sin rastros del virus.


Ahora, que tiene que ver todo esto con el título del artículo?

Luego de escanear el sistema con clamav pasé un tiempo investigando el virus y la forma de removerlo. En un foro, no recuerdo cual, encontré un link al sitio www.virustotal.com.



Este sitio me pareció de lo más útil y original. Te deja subir un archivo infectado, lo escanea con una variedad de antivirus y te muestra el resultado. En ese momento me sirvió para confirmar el tipo de virus que tenía infectado, pero luego sentí curiosidad por probar este sitio un poco más. Para esto me puse a buscar virus y ver resultados:



Luego me dí cuenta que también es posible enviar una URL, por lo que me puse a buscar sitios maliciosos (de scam o malware) y ver que resultados tenía. Fue cuando me encontré con este espectacular sitio de malware:



Este sitio primero muestra un alert diciendo algo como "Se ha detectado actividad sospechosa en su sistema y a continuación será escaneado en busca de virus" Jaaa! es muy bueno. Luego se abre una imitación, muy bien lograda, del explorador de archivos de Windows con una barra de progreso del escaneo, el cual detecta 236 troyanos en el disco C:

Menuda infección jeje. Luego de este simulacro se redirige a la descarga de un archivo ejecutable y el resto se imaginarán.

De esta forma se puede ver un sitio de malware en acción, realmente brillante, sobretodo teniendo en cuenta que me apareció en la segunda página de la búsqueda en Google de la palabra "keygen". Esta clase de sitios pueden engañar a una gran cantidad de usuario de Windows, por eso no sorprende la cantidad y el tamaño de las botnets.

Procedí a escanear este sitio con VIRUS TOTAL el cual me mostró el siguiente resultado:



Me pareció raro que no todas las herramientas lo detectaran como sitio de malware. También me pareció raro que Google Safebrowsing lo detecte como sitio de malware pero aparezca en la segunda página de la búsqueda de la palabra "keygen" en Google Search... Cuestiones de Google.

En definitiva, VIRUS TOTAL, una excelente herramienta para tener a mano para analizar archivos sospechosos y sitios de scam.

Para finalizar les dejo unas recomendaciones:

• Mantengan su software antivirus actualizado (todos los días)


• Eviten visitar sitios sospechosos/desconocidos


• Tengan cuidado dónde hacen clic, siempre revisen las direcciones de los links que aparecen en la barras de estado de los browsers


• Mucho más cuidado con las descargas y archivos adjuntos


• Escaneen absolutamente todo lo que descarguen antes de abrir/ejecutar, por más tedioso que sea es preferible esto antes que enfrentarse a la pérdida de datos

Saludos y feliz 2011!!!

P.D.: Espero que el título del artículo resulte tan "vendedor" como el sitio de malware desde donde lo obtuve!

Configurando una red inalámbrica hogareña

Luego de un período con grandes cambios a nivel personal, vuelvo a tener tiempo (y ganas) de escribir un artículo. En este caso para contar mis experiencias configurando mi red inalámbrica hogareña.

Para comenzar el desarrollo de la red hace falta conseguir lo más importante, que es el router inalámbrico. La marca/modelo a comprar depende del área a cubrir y el dinero que dispongamos. En mi caso opté por un router TP-LINK TL-WR340G ya que sólo me interesa cubrir mi departamento y es una opción super económica.

La configuración de este router es extremadamente sencilla: conectamos el cable de red de nuestro ISP al router; conectamos nuestra PC/Notebook (utilizando una IP fija 192.168.0.0/24) a una boca ethernet del router; y finalmente ingresamos por Web al router ingresando 192.168.1.1 en nuestro navegador.

La interfaz Web es muy intuitiva y haciendo unos pocos clics ya tenemos la red inalámbrica funcionando con DHCP. Lo más importante son dos cuestiones. La primera: dependiendo del servicio de Internet contratado, será necesario configurar PPPoE (Point-to-Point Protocol over Ethernet) para conectarse al ISP (con un nombre de usuario y contraseña otorgados por el proveedor). La segunda: habilitar la seguridad Wireless en el router (autenticación y encripción). A pesar de que WEP es mejor que nada, es un protocolo que posee varias debilidades, por lo tanto es altamente recomendable utilizar WPA/WPA2. Basta con seleccionar WPA-PSK (PSK: Pre-Shard Key, autenticación mediante clave compartida) en el router y utilizar una clave fuerte (formada por letras mayúsculas, minúsculas, números, símbolos y lo suficientemente larga).

Luego de configurar el router (la parte sencilla) la tarea de configurar los clientes no fue tan trivial.

El primer cliente fue una Notebook con Windows XP instalado de base con su placa de red inalámbrica funcionando correctamente. Para conectarlo a nuestra red simplemente hacemos clic derecho sobre el ícono del adaptador de red inalámbrico en la barra de tareas, luego clic en "Ver redes inalámbricas disponibles", luego seleccionamos nuestra red, clic en "Conectar" e introducimos la contraseña dos veces. Hasta acá muy fácil y bonito.

El siguiente cliente fue una Notebook con Ubuntu 9.04. Esta versión de Ubuntu ya incorpora los drivers para la placa de red Realtek RTL8187B y funciona correctamente. Pero los problemas comenzaron al tratar de conectarse a una red protegida con WPA. Ya sea utilizando el administrador de redes "network-manager" o "Wicd", la conexión se pierde luego de un corto lapso de tiempo. El error se repite una y otra vez. Luego de investigar un tiempo en Internet supe que se trata de un problema de autenticación (bastante común entre los usuarios de esta distro) entre gnome-keyring/Dbus/Network Manager. Para solucionarlo le otorgué permisos para utilizar adaptadores inalámbricos al usuario en cuestión desde el menú "System > Administration > Users and Groups". Luego de esto, utilizando Wicd, la red comenzó a funcionar "más o menos bien" aunque tarda mucho tiempo en detectar y conectarse a la red y sufre alguna desconexión esporádica.
La solución a implementar para que la red funcione perfectamente en este sistema operativo es la misma que describo más adelante para Slackware.

El próximo cliente fue una PC con Windows XP. Como no tenía un adaptador de red inalámbrico decidí comprar uno USB (la solución más económica y práctica para mis necesidades). Luego de conectar el dispositivo cometí el error de instalar los controladores directamente desde el disco compacto que incluía en la caja. Este instalador agregó un horrible manejador de redes inalámbricas en la barra de tareas que reemplazó al manejador de redes inalámbricas de Windows. Luego de la clásica reiniciada, el manejador no detectó ninguna red y no me permitió utilizar el de Windows. Por lo tanto tuve que desinstalar los controladores, reiniciar y comenzar de nuevo, esta vez utilizando el "Asistente para agregar hardware" en lugar del instalador del CD. Cuando se abre el asistente insertamos el CD y presionamos en "Siguiente". Luego de que Windows detecta los drivers que se encuentran en el CD, seleccionamos el driver de acuerdo a nuestra versión de Windows y continuamos con la instalación.
Una vez instalado el hardware utilizamos (previa reiniciada) el manejador de redes inalámbricas de Windows que se encuentra en la barra de tareas y nos conectamos perfectamente a nuestra red (esta vez sin utilizar el horrible manejador de redes incorporado en el CD del fabricante) como para el caso del primer cliente.

Luego de renegar con Windows y Ubuntu me puse el overol para aprender cómo funcionan las cosas de la mano de Slackware. La versión 13.1 instalada en la PC incorpora los drivers para el adaptador USB (utiliza el mismo chip Realtek RTL8187B de la notebook) por lo tanto la red inalámbrica funciona perfectamente.
Ya que vamos a conectarnos a una red inalámbrica con seguridad WPA, no basta con utilizar iwconfig para configurar el adaptador, es necesario utilizar wpa_supplicant. WPA Supplicant es el componente del protocolo IEEE 802.1X/WPA utilizado en las estaciones cliente. Implementa la negociación de claves con un autenticador WPA (en este caso nuestro router). Funciona como un demonio que se ejecuta en background y actúa como un componente back-end que controla la conexión wireless. En Slackware 13.1 viene incluido en la instalación base y en las distribuciones basadas en Debian lo provee el paquete wpasupplicant.
wpa_supplicant toma la configuración de las redes inalámbricas con seguridad WPA desde el archivo /etc/wpa_supplicant.conf. Para agregar una red en este archivo se utiliza el comando wpa_passphrase con el SSID de la red como parámetro:

$ wpa_passphrase myssid

Este comando lee la clave compartida de la red WPA (la misma que ingresamos en el router) por la entrada estándar y genera la clave encriptada para almacenar en el archivo /etc/wpa_supplicant.conf (para no tener que escribir la contraseña cada vez que nos conectamos a la red). Copiamos la salida de wpa_passphrase y la pegamos al final del archivo /etc/wpa_supplicant.conf.
Luego de estos pasos podemos conectarnos a la red inalámbrica:

# iwconfig wlan0 essid "myssid"
# ifup wlan0
# wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf
# dhcpcd wlan0

El cliente WPA Supplicant es bastante vervoso e imprime por salida estándar todos los pasos durante la autenticación con el AP. Luego podemos verificar que la red haya tomado una dirección IP desde el AP utilizando el comando ifconfig.

Parece una tarea tediosa, pero el aprendizaje es invaluable y la red funciona excelentemente.

Aunque si no desean escribir estos 4 comandos cada vez que se conecten a la red, en Slackware pueden agregar un script en /etc/rc.d que lo haga automáticamente o en las distribuciones basadas en Debian pueden editar el archivo /etc/network/interfaces:

auto wlan0
iface wlan0 inet dhcp
up wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -Bw
down killall wpa_supplicant

La opción -B pone el demonio wpa_upplicant en background y la opción -w le indica que no haga anda hasta que la interfase esté levantada.

Luego de esta tarea tengo mi red inalámbrica funcionando en perfectas condiciones. A aquellos usuarios de Linux espero que les sirva la info y a los de Windows, bueno... nadie es ferpecto.

Saludos!


P.S.: Perdón por las screenshots!


Referencias:

• http://hostap.epitest.fi/wpa_supplicant/
• http://www.enterprisenetworkingplanet.com/netsecur/article.php/3594946/Linux-on-Your-WLAN-Configure-WPA.htm

Tips Slackware 13.1

Por qué elegí Slackware?

Luego de haber utilizado Ubuntu por 4 años finalmente me decidí por instalar una distribución GNU/Linux más estable y "espartana" (como diría un profe de la Universidad Nacional del Sur), aunque tuviera que resignar facilidad de uso y mantenimiento. No tengo nada en contra de Ubuntu, creo que es una distribución formidable, muy pero muy fácil de utilizar. Es más, creo firmemente que es mucho más fácil de utilizar que cualquier Windows. A cualquier persona que utiliza una computadora por primera vez le daría una distro basada en Ubuntu por su simplicidad. Pero esta facilidad de uso es lo que me "aburrió", todo es muy fácil y se pierde mucho control sobre lo que el sistema operativo hace (y se pierden muchas oportunidades para comprender y aprender como funciona el sistema operativo). Siempre me divertí más poniéndome el overol que haciendo un "apt-get install ...".
Respecto a la estabilidad, investigando durante mucho tiempo en foros y páginas de Internet descubrí que Slackware es considerada "la distribución de GNU/Linux más estable" y supuse que el mundo no debe estar equivocado por ser la distribución de GNU/Linux más antigua aún con vida.

Un poco de historia...

Mis primeras armas con GNU/Linux las hice utilizando una distro más que "espartana": DSL (abreviatura de Damn Small Linux). Por esa época utilizaba DSL versión 3.4 con un kernel Linux 2.4.26 y corría en un procesador AMD K6 II de 450 MHz (un sólo núcleo obviamente jeje) con unos increíbles 64 MB de memoria RAM. Esta distro ultra liviana, basada en Knoppix, no tenía manejador de paquetes, utilizaba el manejador de ventanas fluxbox, y tanto su "instalación" (estaba pensada para funcionar como live CD, no se recomendaba la instalación) como uso era para usuarios intrépidos. Aunque... si tienen un cacharro viejo tirado en la pieza pónganle un DSL y devuélvanlo a sus años dorados.
Abandoné DSL el día que compré mi máquina de escritorio actual y decidí pasarme a una distribución más moderna, en ese momento Ubuntu 6.04.

Instalando Slackware 13.1

Recuerdo cuando le comenté a demasiadovivo:

- Voy a instalar Slackware en mi PC.

A lo que él respondió:

- ¿Tenés ganas de meterte en problemas?

Durante un momento me acobardé un poco pero me mantuve firme en mi decisión y un sábado a las 2 de la mañana, luego de cumplir con mis obligaciones, instalé Slackware 13.1. Esta versión viene con el kernel de Linux 2.6.33.4, Xfce 4.6.1, KDE 4.4.3, muchas herramientas de desarrollo (Perl, Python, Ruby, Subversion, KDeveloper, etc.), una variedad de Web browsers (Konqueror, SeaMonkey, Firefox) y una colección de aplicaciones basadas en GTK+ (Pidgin, GIMP, GXine, XChat, etc.) entre lo más destacado. Información más detallada en http://www.slackware.org/announce/13.1.php.
La instalación es muy sencilla, la parte más complicada para un usuario inexperto es el particionamiento de los discos utilizando 'cfdisk', pero para aquellos dinosaurios como yo que instalaron Windows 98 una gran cantidad de veces y particionaban sus discos con 'fdisk'... es pan comido. Si tuvieron la oportunidad de instalar FreeBSD se darán cuenta que el instalador es muy similar, también el manejador de paquetes 'pkgtool' el cual utiliza archivos comprimidos tar. Una limitación que tiene el manejador de paquetes es que no resuelve dependencias, como lo hacen otros manejadores de paquetes (por ejemplo aptitude). Pueden encontrar ayuda oficial para instalar Slackware 13.1 en http://www.slackware.org/install/.

Veamos la instalación paso por paso:

1. Primero tenemos que conseguir un DVD de Slackware, bueno esto es fácil, ingresamos en http://www.slackware.org/getslack/torrents.php y descargamos el torrent de la imagen del DVD (es más practico que 6 CDs) y lo descargamos con nuestro cliente bit-torrent favorito (en mi caso fue transmission). Luego de quemar el DVD booteamos desde la unidad lectora de discos. Ingresamos al sistema como usuario 'root' (sin contraseña).

2. Esta es la parte más compleja de la instalación: crear las particiones. Para hacerlo de la forma más sencilla posible vamos a crear dos particiones: una partición para memoria swap (aproximadamente el doble del tamaño de la memoria RAM para la mayoría de los sistemas) y otra partición para el resto del sistema. Lo ideal es crear particiones separadas para los directorios /boot y /var (y posiblemente también una para /etc). No voy a explicar cómo utilizar 'cfdisk' porque sería muy extenso, pero pueden encontrar una guía en español en http://manual.sidux.com/es/part-cfdisk-es.htm.

3. Teniendo nuestras particiones, ejecutamos el comando 'setup'. Esto inicia el proceso de instalación interactivo que contiene las siguientes etapas: HELP, KEYMAP, ADDSWAP, TARGET, SOURCE, SELECT, INSTALL, CONFIGURE, PKGTOOL, EXIT.

• KEYMAP: Nos permite elegir el mapa de teclado adecuado (en mi caso qwerty/es).


• ADDSWAP: Indicamos que partición se utiliza como memoria de intercambio (el proceso es automático).


• TARGET: Seleccionamos la partición donde instalar el sistema y formateamos con ext4.


• SOURCE: Detecta el origen de la instalación (en este caso el DVD).


• SELECT: Seleccionamos el software para instalar, debemos seleccionar todos (KDEI para instalar otros idiomas en KDE, lo que incluye el idioma español).


• INSTALL: Instalamos seleccionando 'full'. Seleccionamos la instalación de lilo automática, el framebuffer de lilo 'auto' y el destino 'MBR'.

Se puede encontrar una guía detallada de la instalación en http://troesma.wordpress.com/2010/05/28/como-se-debe-instalar-slackware/.

Una vez finalizada la instalación reiniciamos la PC y nos topamos con lilo, el cual detectó automáticamente durante la instalación otros sistemas operativos instalados, e iniciamos Slackware. Nos logueamos como 'root' e iniciamos KDE mediante el comando 'startx'. Ya tenemos el sistema funcionando!
Lo que sigue a continuación es una lista de tips post-instalación que fui realizando para "tunear" el sistema de acuerdo a mis necesidades. Son configuraciones simples pero que, una vez hechas, me es imposible recordar cómo las hice, por eso decidí anotarlas y eso me motivó a escribir este artículo.

Agregar un nuevo usuario

Por razones de seguridad, no es conveniente correr el sistema como usuario 'root', por lo tanto lo primero que deberíamos hacer es crear un nuevo usuario. La forma más sencilla es utilizar el manejador de usuarios de KDE (también se puede utilizar el comando 'useradd', ver manual). Iniciamos KUser desde "K > Applications > System > User Manager". Luego utilizamos el botón 'Add', el resto es fácil. Una vez creado el nuevo usuario debemos agregarlo al archivo 'sudoers' para que pueda utilizar el comando 'sudo' y realice tareas de administración. Si no se desea que el usuario pueda utilizar 'sudo' se debe omitir este paso.
Otorgar 'sudo' al nuevo usuario 'emi':

# visudo

[Insert]
emi ALL=(ALL) ALL

[Esc]
:wq

Si otorgamos 'sudo' es conveniente agregar las rutas '/usr/local/sbin', '/usr/sbin' y '/sbin' a la variable de entorno $PATH, para que bash encuentre los ejecutables de administración del sistema (por ejemplo 'cfdisk', 'dhclient', 'fsck', 'halt', 'ifconfig', 'ip', 'lilo', 'mkfs', 'mount', 'poweroff', 'reboot', 'umount', etc.):

1- Crear el archivo '.profile' en el directorio $HOME
2- Agregar los directorios a la variable $PATH:

PATH=/usr/local/sbin:/usr/sbin:/sbin:$PATH

Cambiar locale

Para que se visualicen correctamente los acentos y 'ñ' en los nombres de archivo debemos cambiar el 'locale' que es el conjunto de reglas de lenguaje y culturales que se aplica en el sistema. Esto incluye el conjunto de caracteres. Para esto editamos el archivo '/etc/profile.d/lang.sh' de la siguiente forma:

Comentar la línea:

#export LANG=en_US

Descomentar la línea:

export LANG=en_US.UTF-8

Deshabilitar servidor Akonadi:

Akonadi es un servicio de manejo de información personal (PIM) incluido en KDE 4. Administra información como contactos de correo electrónico, notas, alarmas, etc. de forma centralizada en una base de datos MySQL. Este servicio puede consumir recursos como memoria, espacio en disco y CPU. Para mejorar el desempeño de KDE en general decidí deshabilitarlo. Si desinstalamos este paquete, aplicaciones como Kontact, KOrganizer, KMail, etc. dejan de funcionar. Por lo tanto no se debe desinstalar, para resolver esto debemos seleccionar nuevos recursos de almacenamiento de datos de KDE desde "K > System Settings > Advanced > KDE Resources". Por ejemplo se pueden utilizar archivos locales para almacenar datos de contactos. Para más información sobre Akonadi leer http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_FAQ.

Instalar paquetes

Slackbuilds.org es un repositorio de paquetes que no vienen incluidos en la versión oficial de Slackware. A pesar de no ser oficiales, son referenciados en el sitio oficial de Slackware ya que varios desarrolladores de Slackware también desarrollan scripts para slackbuilds.org. Cabe recordar que Slackware trabaja con paquetes tar comprimidos, por lo tanto en el sitio slackbuilds.org proveen scripts que crean los paquetes tar comprimidos a partir del código fuente del paquete que se desea instalar. Por lo tanto, si deseamos instalar un paquete que no está incluido en la versión oficial de Slackware debemos seguir los siguientes pasos (voy a utilizar OpenOffice.org como ejemplo):

1. Buscar el script en slackbuilds.org, en este caso "openoffice".
2. Descargar código fuente del paquete desde el sitio oficial del mismo (en la misma página de slackbuilds.org donde descargamos el script hay un link al fuente del paquete).
3. Extraer el tarball descargado desde slackbuilds.org y editar el archivo .info si no coincide la versión del fuente descargado.
4. Colocar el fuente (generalmente un .tar.gz) en la carpeta donde se encuentra el script .Slackbuild. Luego ejecutar el script, el mismo crea el paquete a partir del código fuente.
5. Instalar el paquete creado en el directorio /tmp utilizando el comando 'installpkg'.
6. Disfrutar! No es tan complicado como parece.

Personalizar lilo (bootloader)

Si deseamos personalizar lilo, por ejemplo cambiar el timeout, el orden de aparición de los OS o el bitmap, debemos:

1- Editar el archivo /etc/lilo.conf
2- Luego ejecutar lilo para que tome la nueva configuración:

lilo -C /etc/lilo.conf

Instalar NVIDIA video driver

Para aquellos dueños de placas de video NVIDIA, los pasos son idénticos que para otra distro:

1- Descargar driver desde www.nvidia.com
2- Cerrar X (Logout desde KDE)
3- chmod u+x NVIDIA.run
4- sh NVIDIA.run
5- startx
6- K > Applications > Settings > NVIDIA X Server Settings
7- Disfrutar!

Instalar mod_perl

Esto tuve que hacerlo para ejecutar Perl en modo cgi (o sea, servir páginas Web escritas en Perl):

1- Instalar mod_perl utilizando el script de slackbuilds.org.
2- Editar /etc/httpd/mod_perl.conf si es necesario.
3- Agregar la siguiente línea en el archivo /etc/httpd/httpd.conf:

Include /etc/httpd/mod_perl.conf

Iniciar firewall automáticamente

Slackware no utiliza "/etc/init.d/" sino que utiliza "/etc/rc.d/" para cargar demonios automáticamente. En mi caso necesito levantar mi firewall escrito con 'iptables' automáticamente cada vez que inicia el sistema. Para esto:

1- Crear bash script con las reglas de iptables
2- Crear un link simbólico al script en la carpeta /etc/rc.d/:

ln -s /home/emi/firewall.sh /etc/rc.d/rc.firewall

Ojo con los permisos del archivo firewall.sh! El dueño debe ser 'root' y ni el grupo ni los otros deben tener permisos de lectura/escritura

Agregar etiqueta a una partición (sin formatear)

Acá fue cuando hice macanas, quería asignarle una etiqueta a una partición ext4 y (por no leer el manual completo) utilicé el comando 'mke2fs' con la opción -L lo cual borró la tabla de inodos perdiendo el contenido completo de la partición (como si hubiera formateado una partición NTFS). Afortunadamente, pude recuperar la información utilizando 'e2fsck' y aprendí a asignar una etiqueta sin formatear la partición utilizando el comando:

e2label /dev/sdb4 etiqueta

Personalizar atajos de teclado (multimedia)

Si tenemos un teclado con botones adicionales y queremos cambiar su comportamiento, podemos hacerlo desde:

K > Computer > System Settings > Keyboard & Mouse > Standard Keyboard Shortcuts

Instalar corrección ortográfica (aspell-es)

Para poder corregir la ortografía en idioma español es necesario instalar el diccionario español de GNU Aspell:

1- Descargamos el diccionario español desde: ftp://ftp.gnu.org/gnu/aspell/dict/0index.html.
2- Extraemos el contenido del tarball.
3- Instalamos el diccionario:

./configure
make
make install

Links

www.damnsmalllinux.org
www.slackbuilds.org
www.slackware.org
www.ubuntu.com

cómo obtener una dirección IP a partir de una dirección MAC?

A veces es necesario obtener una dirección IP a partir de una dirección MAC. Por ejemplo, si estamos monitoreando nuestra red local y nos encontramos con tráfico de protocolos por debajo de la capa de red o tráfico IPv6.


Utilizando Wireshark es posible obtener todos los paquetes que tienen la dirección MAC determinada mediante el filtro eth.src==MACADDR. Si el host que posee la MAC envió tráfico IP podremos determinar la dirección IP inspeccionando los paquetes filtrados.
También es posible consultar la caché ARP para ver si existe una entrada con la dirección MAC.
Si se utiliza DHCP dentro del segmento y tenemos acceso al servidor DHCP, es posible determinar la dirección IP consultando la asignación de leases.
Pero si no hay una entrada con la dirección MAC correspondiente dentro de la caché ARP y no tenemos acceso al servidor DHCP, podemos realizar fuerza bruta sobre todas las direcciones IP dentro del segmento de red para encontrar la IP buscada.

El siguiente script bash busca la dirección IP correpondiente con una dirección MAC utilizando fuerza bruta sobre el rango de direcciones IP especificado. Básicamente lo que hace es un pedido ARP para cada IP del rango, si la MAC obtenida coincide con la MAC suministrada hemos encontrado la dirección IP correspondiente. El pedido de ARP se puede hacer de varias formas. Por ejemplo, es posible forzarlo enviando un paquete de una capa superior, como un ICMP echo request, y luego consultar la caché ARP y buscar la MAC deseada para obtener la IP correspondiente. También es posible utilizar directamente la herramienta arping utilizando cada dirección IP como parámetro.

#!/bin/bash

START_IP=192.168.0.1
END_IP=192.168.0.254

if [ $# -lt 2 ]
then
echo "usage: $0 <mac-addr> <start-ip> <end-ip>"
exit -1
fi

MAC_ADDR=$1
START_IP=$2
END_IP=$3

IP=(${START_IP//./ })
IP_FIN=(${END_IP//./ })

timestamp=$( date +"%s" )

echo -n "Scan progress"

for (( A=${IP[0]}; A<=${IP_FIN[0]}; A++ ))
do
for (( B=${IP[1]}; B<=${IP_FIN[1]}; B++ ))
do
for (( C=${IP[2]}; C<=${IP_FIN[2]}; C++ ))
do
  for (( D=( ${IP[3]} ); D<=${IP_FIN[3]}; D++ ))
  do
    IP_ADDR="$A.$B.$C.$D"
    echo -n "."
    #ARPING_OUT=$( arping -c 1 $IP_ADDR 2> /dev/null )
    ping -c 1 $IP_ADDR &> /dev/null
    ARP_OUT=$( arp -n | grep -i $MAC_ADDR )
    #if [[ "$ARPING_OUT" =~ $MAC_ADDR ]]
    if [[ "$ARP_OUT" =~ $MAC_ADDR  ]]
    then
        echo ""
        echo $ARP_OUT
        IP_FIN[0]=$A
        IP_FIN[1]=$B
        IP_FIN[2]=$C
        IP_FIN[3]=$D
    fi
  done
done
done
done

endtimestamp=$( date +"%s" )
scantime=$(( endtimestamp - timestamp ))
echo ""
echo "Done ($scantime seconds)"

Ahora veamos el script en acción:

Survey servers más confiables

Ayer leí sobre un survey analizado en infoworld.com donde se comparan los tiempos "fuera de servicio" (downtime) de las distintas combinaciones de servidores.
Para el análisis se eligieron 15 de las combinaciones más populares de hardware y sistema operativo y se consultó a ejecutivos con conocimientos y administradores IT de 400 organizaciones apostadas en 20 países sobre tiempo fuera de servicio no planeado, parcheo (patching), y otros indicadores de confiabilidad.
Si bien no se que tan influenciado puede estar el survey (léase $$$), los resultados obtenidos dan como vencedor a IBM y su SO AIX Unix que en promedio sufre de tan solo 15 minutos de downtime por año. El segundo puesto como servidor más confiable se lo lleva la versión de Novell Suse Linux customizada corriendo en hardware x86 estándar, con un promedio de 17.4 minutos de downtime por año. Sin embargo la version de Suse no customizada promedia los 54mins.
Otras distribuciones de Linux como TurboLinux y Mandriva sobre hard x86 estándar promediaron 31.8 minutos de downtime/año, mientras que Sun Solaris sobre servidores Sparc sufrieron de 35.4 mins.
Por otro lado, servidores HP 9000 corriendo el SO HP Unix aparece en 5to lugar con 36mins/año. En sexto aparecen los servidores Apple G4 Mac corriendo Mac OS X con 37.8 mins/año.
Por supuesto los servidores Windows corriendo sobre hard intel están bien abajo, donde Windows 2003 server tuvo 3 horas y media por año y Windows 2008 server cerca de 2 horas y media por año.
Muy a mi pesar, distribuciones libres como debian aparecen etre los peores casos con más de 4horas de downtime por año.
Por su parte, servidores basados en Ubuntu la safaron bastante bien con 1 hora 40 mins de downtime por año, aunque empeoró bastante su rendimiento en comparación del año pasado donde sólo promedió 1 hora de downtime.

Para resumir, y porque me encantan los rankings, les dejo la lista armada amablemente por su servidor según los datos leídos.
1. IBM AIX Unix - 15 mins/año
2. Novell Suse Linux sobre x86 - 17.4 mins/año
3. TurboLinux, Madriva (posiblemente otras) sobre x86 - 31.8 mins/año
4. Sun Solaris sobre Sparc - 35.4 mins/año
5. HP's Unix sobre HP 9000 - 36 mins/año
6. MacOS X sobre Apple G4 Mac - 37.8 mins/año
más abajo. Ubuntu - 1.30 hs/año
lejos 1. Windows 2008 server sobre Intel - 2.3 hs/año
lejos 2. Windows 2003 server sobre Intel - 3 hs/año
lejos 3. distros libres (como debian) - más de 4 hs/año

Como nota final, cabe aclarar que en el survey sólo se incluyeron enterprise servers y no mainframes, los cuales seguramente estarían primeros. El motivo (según el analista) es que los mainframes son una clase propia, ellos no suelen tener downtime.

Ranking popularidad distribuciones GNU/Linux

Para continuar con los ya clásicos (!?) post de rankings, qué mejor que hacerlo con la lista de distros de linux más populares?
En distrowatch se mantiene un ranking armado a partir del H.P.D (visitas diarias actualizado diariamente) de cada distribución. Es decir, la cantidad de visitas que tiene el link dedicado a cada distribución. Si bien el ranking no es la absoluta verdad (no todo el mundo visita distrowatch), es una buena referencia sobre lo que la gente busca.
El ranking con las 15 primeras posiciones para los últimos 12 meses es el siguiente:
Hace ya varios años que Ubuntu viene reinando en popularidad, teniendo una gran ventaja sobre las demás, es extraño seguir viendo openSUSE tan arriba, siendo que ya no la escucho nombrar tanto. Por su parte Mint viene ganando posiciones, y lo tiene merecido por ser muy sencilla y traer menos problemas que Ubuntu. Luego figuran las clásicas Fedora, Debian y Mandriva que no decaen gracias a la buena calidad que han brindado a lo largo de los años.

Por si todavía no la conoces, distrowatch es una página dónde se mantiene información sobre las distribuciones más importantes (y las no tanto), conteniendo una descripción de cada una, junto con actualizaciones del estado de éstas. Si usas linux o deseas usarlo y todavía no la visitaste, no esperes más!
Para ver el ranking completo, visiten la sección Linux Distributions - Facts an Figures.