El mito de la seguridad de los Unix/Linux

Es muy común entre los aficionados a las computadoras hablar de lo inseguro que es Windows y lo confiables que son los sistemas operativos Unix o sus derivados como por ejemplo el OS X, e incluso Linux que aunque no es un Unix de pura sangre, si cumple los estándares POSIX. Lo divertido de muchos de estos debates en foros, blogs y demás espacios de discusión públicios que muchas veces toman giros radicales, es que quienes más defienden los sitemas Unix/Linux, son aquellos que no los usan diariamente. Y es que aquellos que trabajamos con estos entornos de forma cotidiana tenemos que convivir con sus limitaciones y las imprudencias de los usuarios (es decir los aficionados).

Si hicieramos una comparación con el fútbol, el hincha que está en la tribuna gritando y peleandose con los del otro equipo son los usuarios. Los sufridos system administrator, somos los que estamos en la cancha de la web 2.0 sufriendo los golpes del adversario y la ira de los hinchas cada vez que algún error se comete, y es que como dice el refrán, los toros se ven mejor de lejos. Yo soy un profesional de la informática, es decir me pagan por hacer esto, y hay días en los que me arrepiento de ganarme la vida de esta forma, aunque esos son los menos. La mayor parte del tiempo soy un aficionado más de la informática también, es decir lo hago porque me gusta y tengo mi equipo (Linux), lo cuál no quita que pueda jugar (cobrando) por otro u otros equipos.

Los comentarios anteriores eran porque he leído una nota en CBC News, en donde se describe como un grupo de cybercriminales consiguió montar la primera red de mac-bots, es decir una red de computadoras zombies constituída por Macs. La forma como lo hicieron fue escondiendo un trojano dentro de programas comerciales que se distribuyen a través de torrents públicos, es decir se aprovecharon de la piratería para infectar las computadoras de las víctimas. Lo cuál es básicamente lo que pasa también con los usuarios de Windows, y creanlo o no con los usuarios Linux también.

Por ejemplo es muy común que los usuarios de mis servidores, por facilidad no configuren apropiadamente un directorio al que le otorgan privilegios 777, y si el CMS que están utilizando posee alguna vulnerabilidad, sencillamente están dejando la puerta abierta para que un atacante remoto pueda instalar código arbitrario en el servidor. El año pasado publique un post titulado "Colección de exploits" en el que discutía lo peligroso de los permisos 777, pero como suele pasar el mito de la seguridad de los Unix/Linux puede más que la realidad de que un sistema no puede ser más seguro que sus usuarios.

Pero para ello estan las herramientas que nos permiten detectar si hemos sido invadidos por estos molestos programas, que una vez instalados usan nuestras computadoras como plataformas para lanzar ataques contra otras redes. Es por ello que si Ud. tiene un Linux, se tome la molestia de al menos una vez a la semana utilizar cualquiera de estos detectores de rootkits chkrootkit y rkhunter. Además de verificar mensualmente con Nessus si alguno de sus servidores es vulnerable. Así que no crean que por qué están en Unix/Linux pueden tener el mismo comportamiento descuidado que tenían en Windows, porque podrían tener una desagradable sorpresa.

Adicionalmente a las medidas anteriores recomiendo instalar tambien denyhosts, un scripts en Python que bloquea cualquier intento de ataque basado en fuerza bruta, luego de leer el artículo publicado por Peter Hansteen en su blog That gumpy BSD guy, le eche una ojeada a mi /var/log/auth.log para ver si había intentos de hacking usando el puerto ssh como describía Hansteen en su artículo y quede sorprendido de lo frecuentes que eran y lo diverso del origen. Fue por ello que le aplique el denyhosts a todos mis servers. En caso de que seamos más paranoicos y no deseemos que nadie pueda siguiera tener el prompt podemos usar los TCP wrappers para bloquear todo intento de conexión al ssh desde fuera de nuestra red, pero eso tiene el terrible inconveniente de dejarnos fuera incluso a nosotros mismos cuando estamos en el camino y necesitamos urgentemente arreglar algo en el servidor, en ese sentido denyhosts ofrece la mejor combinación flexibilidad/seguridad.

Espero que esta información les haya sido de utilidad y sirva para clarificar algunas ideas. Pero lo más importante, que haya servido para asegurar nuestros servidores Linux.

La web del APRA hackeada desde el jueves pasado

En el blog de Necudeco, encontre una referencia a que la web del APRA (actual partido de gobierno en el Perú) había sido hackeada. La fecha del post de Necudeco era del jueves pasado (12 de marzo), razón por la cuál creí que el problema ya estaba solucionado. Cuál no sería mi sorpresa cuando al intentar seguir el URL dado por Necudeco http://www.apra.org.pe/index.asp encuentro el defacement fallido. Al parecer el hacker consiguió acceso al directorio raíz del web pero fallo en el nombre de la página de incio, pues la nombro index.asp, siendo la página de incio de dicho server default.asp.

Como dice Necudeco, el hacker fallo en el nombre, pero consiguió accesar a dicho server y poner una página en el directorio raíz. Lo peor de todo es que al parecer el encargado de la página web aún no se ha dado cuenta de que la seguridad del server ha sido vulnerada, pues la página subida por el hacker esta todavía alli. Aquí les dejo un screenshot que realice el día de hoy  la 12:15 PM hora de Perú.

Web APRA hackeada

Vulnerabilidad confirmada en DJBDNS y reflexiones sobre seguridad

El hasta ahora invulnerable servidor de nombres de dominio DJBDNS, escrito por Daniel J. Bernstein, cuya última actualización 1.05 data de febrero de 2001, fue exitosamente vulnerado por Matthew Dempsky, y el fallo confirmado por el mismo Bernstein. Bernstein estaba tan seguro de la seguridad de sus programas que ofreció un premio de $1000 a la primera persona que encontrara una falla de seguridad verificable en DJBDNS y $500 a quien lo hiciera en qmail, la famosa garantía Bernstein. La vulnerabilidad encontrada por Dempsky permite a un atacante bajo ciertas condiciones crear falsos registros en el servidor DNS, no es una condición general, ni común del programa, pero no debería permitirlo, es decir fue un error verificable del programa y por ello Bernstein pagó el premio. No ha pasado lo mismo con las vulnerabilidades encontradas con qmail, pues Bernstein alega que en condiciones normales nadie asigna más de 2GB de RAM a un proceso qmail-smtp, pues bajo esas condiciones se puede tener ataques exitosos por desbordamiento de memoria en qmail.

Lo que queda claro luego del incidente, es que no se puede crear el software perfecto, es decir aquel que no presente ningún error. Nadie puede predecir por adelantado todas las variables que intervienen en un sistema. Además a más "perfecto" aparente ser un software, habra mucho más interés en encontrarle una vulnerabilidad, es decir más alla del premio que haya esta el hecho de demostrar ser más inteligente que el tipo inteligente que creo el software, y esta demostrado que el principal motor de los hackers muchas veces no es el dinero sino la vanidad de ser el chico más listo. Lamentablemente un efecto colateral de un software perfecto es que si se vuelve de uso masivo un pequeño error puede compreter a un gran número de seres humanos que dependan de los servicios ofrecidos sobre él.

Al final la motivación de hacer el software perfecto es un deseo profundo de reconocimiento, coincidentemente el deseo de romper la seguridad del software perfecto es el mismo, por lo que ambos bandos entablaran una lucha sin fin, cuya moneda de cambio es la vanidad. En cierta forma es un deseo muy humano, y podría decir que hasta artístico. Pero contrapuesto a lo que es la ingeniería, que no es una ciencia sino una técnica, es más la suposición básica en ingeniería es que todo fallará en algún momento. Pero en cambio se usan otras métricas para determinar si algo cumple su misión o no. Factores ligados al costo/beneficio como pueden ser escalabilidad, flexibilidad, portabilidad son de lejos mucho más importantes que una seguridad al 100%, porque no importa que tan bello sea uno a los 20, siempre se llegará a los 70. No me mal interpreten no estoy diciendo que buscar la seguridad no sea bueno, por ejemplo buscar una flexibilidad ilimitada también es un despropósito, tal vez una frase que se la escuche por primera vez a mi abuela cuando tenía 6 años puede resumir la idea que trato de explicar: "Bueno es culantro (cilantro), pero no tanto". Es decir algo que puede parecer bueno si se busca en demasia puede terminar teniendo resultados contrarios a lo esperado, tal vez una frase perteneciente a la cultura americana puede ser aplicada en el mismo contexto "Ten cuidado con lo que deseas, porque se te puede cumplir".

Hago mencion a lo anterior pues se aplica al caso de los programas de Bernstein, ambos (qmail y djbdns) son de lo más seguros que existen en sus areas, pero no son los más populares porque carecen de la flexibilidad y escalabilidad de otros proyectos similares. Este también creo que es un argumento que apunta a que la diversidad existente en el mundo de las distribuciones Linux, suma en lugar de restar, pues está probado en la práctica como en el caso de Windows que una línea única, lleva a cometer errores difíciles de corregir, sino me creen basta con recordar los casos de Windows Me y Windows Vista.

Protegiendo con contraseñas un directorio en Linux

El día de ayer leí en el blog de Álvaro Felipe, un tutorial sobre como proteger con contraseña un directorio (carpeta) en Ubuntu, y bueno el método que propone no protege completamente el directorio, aún es posible para cualquiera con privilegios de root leer el contendio de dicha carpeta. Por qué esto es peligroso pues si alguien tiene acceso directo a nuestro PC y bootea el sistema usando un LiveCD o un LiveUSB, pues podrá montar nuestro disco y tener acceso a todo nuestros archivos. Una característica muy buena de Mac OS X es el FileVault, que permite incluso proteger a través de encriptación y password el contenido del directorio home del usuario.

Dado que Mac OS X es un Unix, pues en teoría debería ser posible hacer lo mismo en Linux, así que me puse a investigar y encontré que el método a utilizar sería usar un sistema de archivos loopback encriptado, la idea la he tomado de howto Loopback Encrypted Filesystem HOWTO. Sin embargo la he adaptado para su uso en Ubuntu, la razón de ello es que es bastante popular entre los usuarios que se han unido a la comunidad Linux en los últimos dos años.

Primero permitamente explicarles que ventajas se obtienen al hacer esto:

  1. Sin la contraseña utilizada al momento de la creación del filesystem, ni siquiere un usuario con privilegios root podría hacerlo.
  2. Cuando el archivo contenedor del sistema de archivos loopback se monta, todo el contenido que dejemos en él, es automáticamente encriptado usando el protocolo AES y esto es de forma transparente al usuario.
  3. Todo lo que es visible por el usuario root es sólo el archivo contenedor.

Lo que no hace este método es impedir que el usuario root borre el archivo contenedor, pero por otro lado si el usuario root lo desea puede hasta reparticionar toda la unidad haciendo inaccesible la información permanentemente, pero en teoría el usuario root es o debería ser el usuario más confiable.

Comencemos pues, primero debemos de cargar el módulo que permite el loopback encriptado, para ello usamos el comando:

user@host:~$ sudo modprobe cryptoloop

Para verificar si se ha cargado exitosamente ejecutamos el comando:

user@host:~$ lsmod | grep cryptoloop
cryptoloop              4352  1
loop                   18948  2 cryptoloop

Luego es conveniente verificar si el módulo AES esta cargado ya, para ello debemos de ejecutar este comando:

user@hots:~$ lsmod | grep aes
aes_i586               33536  1

Si no esta cargado, debemos proceder a cargarlo con el comando modprobe, pero en Ubuntu en su versión desktop ese módulo es cargado por defecto, sin embargo nunca esta demás asegurarnos.

Ahora debemos proceder a crear un archivo imagen vació, para luego agregarle la encriptación, para ello utilizamos los comandos:

user@host:~$ sudo dd if=/dev/urandom of=privado.img bs=1M count=100
user@host:~$ sudo losetup -e aes /dev/loop0 privado.img
Password:
[ponga aquí el password que más le guste]

El tamaño que le hemos asignado al contenedor es 100 MB, pero pueden variar el tamaño de acuerdo a sus necesidades con solo cambiar el parámetro count. Ahora debemos formatear la unidad lógica que ya tenemos creada, en lo personal he seleccionado el formato vfat para hacer fácil la asignación posterior de usuario y grupo al momento de montar la unidad, pero pueden seleccionar cualquier tipo de formato soportado por Linux es decir ext2, ext3, hfs, hpfs, ntfs, udf, etc.

user@host:~$ sudo mkfs -t vfat /dev/loop0

Ahora ya podemos montar/desmontar nuestro filesystem loopbak encriptado, para ello podemos usar los siguiente comandos para montar la unidad en un directorio de nuestro home:

user@host:~$ mkdir privado
user@host:~$  sudo mount -o loop,uid=1000,gid=1000,encryption=aes privado.img ~/privado
[sudo] password for user: 
[el password de super user de Ubuntu]
Password: [el password que seleccionó al momento de crear la unidad lookback]

  • nota:  uid=1000 y gid=1000 son por lo general el usuario y el grupo de usuario perteneciente a la cuenta creada al momento de instalar Ubuntu, si Ud. comparte el sistema y no fue el usuario que instaló Ubuntu puede averiguar su UID y GID revisando el archivo /etc/passwd

Ahora podrá ver y escribir sobre el directorio ~/privado como si se tratara de un directorio común y silvestre:

user@host:~$ cd privado
user@host:~/privado$ ls -la
total 20
drwxr-xr-x   2 user   user   16384 1969-12-31 19:00 .
drwxr-xr-x 139 user   user    4096 2009-02-25 09:09 ..
user@host:~/privado$ touch prueba.txt
user@host:~/privado$ ls -l
total 0
-rwxr-xr-x 1 user   user   0 2009-02-25 11:05 prueba.txt

Para desmontar la unidad, sencillamente debemos ejecutar estos comando:

user@host:~/privado$ cd
user@host:~$ sudo umount privado
user@host:~$ rm -rf privado

Borramos el directorio que usamos para montar la unidad sencillamente para mantener el orden en nuestro directorio home. Es posible que estos comandos sean puestos en un script y de esa forma automatizar el proceso de montaje/desmontaje del sistema loopback.

Cuando tengan desmontado su sistema loopback lo único que podría ver el usuario sería el archivo contenedor:

user@host:~$ ls -la privado*
-rw-r–r– 1 user   user   104857600 2009-02-25 09:05 privado.img

Espero que esta información les haya sido de utilidad sobre todo a aquellos usuarios que manejan información muy sencible y desean tenerla lo más protegida posible.

Un error de $ 6,600 millones

British IDLeí la noticia en Crunchgear y quede sorprendido, los ingleses han preparado la tarjeta de identificación inteligente más avanzada del mundo, incluyendo en ella información biométrica como por ejemplo un escaneo del rostro y las huellas digitales que hacen a esta tarjeta de identificación practicamente imposible de falsificar, y un instrumento muy confiable para identificar positivamente a una persona, han invertido en la implementación de la misma el equivalente a $6,600 millones, para entregarle una a cada ciudadano, el único problema han olvidado comprar los lectores de las tarjetas. Es decir no hay puesto fronterizo, ni estación de policía con lectores capaces de leer estas nuevas tarjetas, es decir como si un comprador novato haya comprado una película en BlueRay pero no el reproductor.

Lo más increíblemente estúpido es la versión oficial, no se han comprado los lectores de las tarjetas porque serían un gasto adicional para los contribuyentes. ¿Qué lógica tiene esa explicación?. Es como decir que se compran las balas, pero no las pistolas porque costaría un dinero extra, entonces ¿cuál fue el propósito de comprar las balas en primer lugar?

Al parecer no hay limitación geográfica para la ineptitud y esta es una clara prueba de ella, la otra explicación sería pensar que en este negocio alguien hizo mucho dinero, y planea seguir haciendolo en el futuro cuando se decidan a comprar los lectores de las tarjetas de identificación. Sólo espero que este tipo de cosas no inspire a los políticos de países subdesarrollados a imitar el ejemplo europeo.