Seguridad on Marco Antonio Blanco

Truco Linux: Cómo instalar un detector de malware en Linux

Thu, 23 Oct 2014 16:46:47 +0000

A pesar de ser un sistema operativo muy robusto frente a los virus, hasta el punto de haberse acuñado la frase “Linux no tiene virus”, es indudable que puede ser vulnerable a código malicioso desarrollado para atacar activamente sistemas basados en Linux y ante el que necesitamos protección. Por ello quiero dedicar el truco de esta semana a la instalación de un detector de malware. El software elegido no tiene un nombre muy original que digamos. Se trata de Linux Malware Detect (LMD), un analizador de malware para Linux de licencia libre diseñado para detectar amenazas en entornos de red.

Las instrucciones que voy a dar a continuación para instalar son en esta ocasión independientes de la distribución de destino. Como siempre que instalamos un software, hay que ejecutarlas como superusuario.

Empezamos descargándonos el paquete con la versión más actual. Afortunadamente, sus autores lo han nombrado genéricamente maldetect-current.tar.gz, por lo que siempre estaremos seguros de bajarnos la última versión disponible. Por supuesto, la descarga la haremos en /usr/local/src, el directorio estipulado en el estándar para estos menesteres.

# cd /usr/local/src
# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
Resolviendo www.rfxn.com (www.rfxn.com)... 129.121.132.46
Conectando con www.rfxn.com (www.rfxn.com)[129.121.132.46]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
...
# tar xzvf maldetect-current.tar.gz
maldetect-1.4.2/
maldetect-1.4.2/CHANGELOG
maldetect-1.4.2/cron.daily
maldetect-1.4.2/README
maldetect-1.4.2/files/
...

Una vez descargado y descomprimido el paquete, nos cambiamos al directorio que contiene el software y procedemos a instalar.

# cd maldetect-1.4.2
# ./install.sh
Linux Malware Detect v1.4.2
(C) 2002-2013, R-fx Networks
(C) 2013, Ryan MacDonald
inotifywait (C) 2007, Rohan McGovern
This program may be freely redistributed under the terms of the GNU GPL

installation completed to /usr/local/maldetect
…
maldet(6698): {sigup} signature set update completed
maldet(6698): {sigup} 11791 signatures (9899 MD5 / 1892 HEX)

Como podremos comprobar, no sólo se ha instalado el analizador sino que además se han actualizado sus bases de datos de firmas de malware. Con esto ya está listo para su uso, que podemos hacer de dos formas, o bien puntualmente o bien como servicio del sistema. En cualquier caso, tendremos que hacerlo como superusuario.

Supongamos que queremos analizar /tmp de forma puntual e interactiva. Invocaremos LMD de la siguiente forma:

# maldet -a /tmp

Si preferimos que sea en segundo plano en vez de interactivamente, lo hacemos así:

# maldet -b /tmp

Y si queremos que LMD se ejecute como servicio del sistema:

# maldet -m /tmp

También podemos indicarle que monitorice los directorios domésticos de los usuarios:

# maldet -m users

Evidentemente, si se reinicia el sistema, tendremos que arrancar LMD de nuevo a mano. Para ello, lo mejor es incluir su invocación en el script local de inicio del sistema, que en Debian es /etc/rc.local.

Si queremos detener el servicio LMD, basta con el siguiente comando:

# maldet -k

Finalmente, podemos consultar los resultados de la monitorización en el fichero /usr/local/maldetect/event_log.

Ah, y no olvidemos actualizar las bases de datos de firmas periódicamente con:

# maldet -u

Como es habitual, este comando lo podemos planificar a nuestra conveniencia mediante cron. Hasta el truco de la semana que viene.

Truco Linux: Cómo comprobar si somos vulnerables al bug de BASH

Thu, 16 Oct 2014 12:52:22 +0000

Siendo sin duda el asunto más importante del año en cuestión de seguridad y sistemas informáticos, he pensado en seguir aportando mi granito de arena a luchar contra el bug de BASH y por ello quiero dedicar el truco Linux de esta semana a explicar cómo podemos comprobar de forma periódica si somos vulnerables a Shellshock o a alguna otra vulnerabilidad relacionada que pueda surgir en el futuro. Para ello vamos a utilizar un fantástico script escrito por Hanno Böck y que publica en su repositorio público de GitHub.

bashcheck, que así se llama el script, realiza un serie de comprobaciones en el sistema en el que se ejecuta para analizar si sufre de alguna de las 6 vulnerabilidades publicadas a fecha de este artículo. Veamos cómo instalar el script en nuestros sistemas, mantenerlo actualizado y ejecutarlo periódicamente para que nos informe por email de si alguno es vulnerable o no.

Empezamos con la instalación de bashcheck. Como ya he dicho, el proyecto se encuentra alojado en un repositorio de GitHub, lo que nos podría hacer pensar que la opción más directa para descargar el script sea hacer uso de Git. Pero teniendo en cuenta que sólo vamos a descargar un fichero, que Git no suele venir instalado de serie en las distribuciones Linux más populares y que no es precisamente un software fácil de utilizar sin experiencia previa, creo que es mejor utilizar alguna herramienta más sencilla pero potente que sí esté ya instalada en nuestro Linux y que nos evite el tener que “contaminar” nuestro sistema con la instalación de un software que va a tener un uso tan marginal.

Para estos casos yo prefiero utilizar Wget, el cual permite descargarse un fichero sólo si ha sido actualizado. Sin embargo, GitHub no nos lo va a poner fácil en este sentido, ya que ni nos deja descargarnos un único fichero a nuestra elección sino todo el repositorio completo, ni sirve la información temporal necesaria como para que Wget o cualquier otra herramienta pueda comprobar si efectivamente el fichero disponible es más moderno que el que ya tenemos descargado. Por ello vamos a tener que sortear estos obstáculos a través del siguiente script que he preparado para la ocasión:
{code type=php}
#!/bin/bash
#
# descargar_bashcheck.sh
# Descarga bashcheck desde GitHub e instala si es una nueva version
# 2014 (C) Activa Sistemas
# Este script se distribuye bajo licencia GPL
#
STAMP=$(date +%Y-%m-%d)
echo “Descargando bashcheck…”
wget –quiet https://github.com/hannob/bashcheck/archive/master.zip -O /tmp/bashcheck_$STAMP.zip
unzip -o -q -j /tmp/bashcheck_$STAMP.zip bashcheck-master/bashcheck -d /usr/local/tmp
rm /tmp/bashcheck_$STAMP.zip
diff -q /usr/local/tmp/bashcheck /usr/local/bin/bashcheck 2> /dev/null
if [ $? != 0 ]
then
echo “Actualizando bashcheck…”
mv /usr/local/tmp/bashcheck /usr/local/bin/bashcheck
chmod 755 /usr/local/bin/bashcheck
chown root.root /usr/local/bin/bashcheck
echo “Nuevo bashcheck listo para su uso”
else
echo “No es necesario actualizar bashcheck”
fi
{/code}

Guardamos el código en un fichero que llamaremos descargar_bashcheck.sh, lo almacenamos en /usr/local/bin (donde deben ir las herramientas propias que desarrollemos) y le otorgamos permisos de ejecución:

# chmod 755 /usr/local/bin/descargar_bashcheck.sh

Lo ejecutamos por primera vez para comprobar que todo es correcto y que se descarga la última versión disponible de bashcheck:

# /usr/local/bin/descargar_bashcheck.sh
Descargando bashcheck...
Actualizando bashcheck...
Nuevo bashcheck listo para su uso
# ls -l /usr/local/bin/bashcheck
-rwxr-xr-x 1 root root 2889 oct 13 10:48 /usr/local/bin/bashcheck

El último paso es asegurarnos de que se mantiene actualizado y que se ejecuta diariamente para avisarnos de eventuales vulnerabilidades. Para ello, programamos un par de tareas con cron. Aunque el usuario root cuenta con su propia lista de tareas programadas, personalmente prefiero dar de alta las tareas generales del sistema en el fichero /etc/crontab, en el que insertaremos las siguientes líneas:

# bashcheck
00 07 * * * root /usr/local/bin/descargar_bashcheck.sh
30 07 * * * root /usr/local/bin/bashcheck | mail -s "Resultado analisis bashcheck" alguien@ejemplo.com

Con esto habremos programado la ejecución diaria de ambas tareas a las 7:00 y las 7:30, respectivamente, y enviaremos por email el resultado de bashcheck a la dirección que queremos. Os dejo como ejercicio hacer que bashcheck sólo mande el email si el resultado del test es positivo, es decir, se ha encontrado una vulnerabilidad en el sistema.

Para el que tenga a su cargo un buen número de sistemas y se pregunte cómo copiar descargar_bashcheck.sh y modificar el crontab en cada uno de manera automática y con el menor esfuerzo posible, le diré que la mejor manera es a través de un buen software de gestión automatizada de sistemas, como Chef, Ansible, Salt o, mi favorito, Puppet. Evidentemente, una herramienta así también nos sirve para aplicar parches si bashcheck nos avisa de una nueva vulnerabilidad.

Para terminar, una anécdota: tanto bashcheck como descargar_bashcheck.sh están escritos en BASH ;) ¡Hasta el truco de la semana que viene!

Cómo resolver el bug de BASH en Debian

Wed, 01 Oct 2014 16:23:56 +0000

La noticia más destacada de la semana pasada (yo diría que de los últimos meses) es sin duda la del infame bug de BASH (también conocido como Shell Shock), que permite comprometer remotamente sistemas que tengan instalado este popular intérprete de comandos, como Linux, Unix o Mac OS. Se trata sin duda de una de las vulnerabilidades de mayor impacto en Internet de los últimos años (con el permiso de Heartbleed), tanto por su facilidad de explotación como por su propagación por la Red. Por ello, los administradores de sistemas hemos tenido que ponernos las pilas y parchear rápidamente los sistemas a nuestro cargo para mitigar las posibles consecuencias del bug. Como en Activa Sistemas tenemos a Debian como plataforma favorita, nuestros esfuerzos se han dirigido a resolver Shell Shock en dicha distribución Linux, esfuerzos que queremos compartir con nuestros lectores.

La metodología a seguir para parchear el bug es la misma independientemente de la versión de Debian de cada servidor, que consiste en instalar una versión actualizada de BASH que no contenga el bug, pero el camino para llegar a dichos paquetes actualizados sí que depende de la versión de Debian. Veamos qué hacer en cada caso:

Wheezy y posteriores: En el caso de la versión estable y las versiones en desarrollo e inestable basta con actualizar la base de datos de paquetes desde los repositorios oficiales:

# apt-get update

y, o bien actualizar todo el sistema:

# apt-get upgrade

o bien instalar sólo BASH:

# apt-get install bash

Squeeze: A la anterior versión estable se le otorgó el soporte extendido (LTS: Long Term Support) en Abril de 2014, lo que supone que recibirá actualizaciones de paquetes hasta Febrero de 2016. Esto implica que BASH tiene una actualización para Squeeze en los repositorios LTS. Por lo tanto, lo primero es añadirlos a nuestro sistema, para lo cual tenemos que incluir la siguiente línea en el fichero /etc/apt/sources.list:

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free

A continuación seguimos los pasos para Wheezy y tendremos BASH actualizado en Squeeze.

Lenny y anteriores: En el caso de que tengamos instalada en algún servidor una versión de Debian más antigua que Squeeze (por ejemplo, el típico caso de una máquina virtual instalada expresamente para dar soporte a una aplicación anticuada pero en uso), la única opción que tenemos es la de construir un backport del paquete de BASH para Wheezy. Esto consiste en descargar el paquete fuente y recompilarlo en una versión de Debian idéntica a la que tenemos en el servidor de destino.

Como se puede imaginar, esta operación no está al alcance de cualquiera, ya que implica tener experiencia en la compilación de código fuente y la construcción de paquetes de software. Por eso, hemos construido nuestros propios backports de BASH para Lenny y los hemos puesto a disposición de todo aquél interesado para que los utilicen para actualizar sus sistemas antiguos. Eso sí, los paquetes se ofrecen sin ningún tipo de garantía, por lo que recomendamos su instalación previa en un sistema de prueba antes de proceder al servidor en producción.

Al igual que en el caso de Squeeze, sólo hay que añadir el repositorio al sistema y proceder a la instalación del paquete actualizado.

Sólo queda comprobar si realmente la actualización ha surtido efecto. Para ello, ejecutamos el siguiente comando en una consola:

# env x='() { :;}; echo vulnerable' bash -c 'echo this is a test'

Si no se imprime en pantalla la palabra vulnerable, entonces hemos conseguido parchear el bug de BASH y estaremos a salvo, al menos hasta que se descubra otro ;)

Fail2ban, protección frente a ataques de fuerza bruta a servidores

Mon, 05 May 2014 14:08:04 +0000

Dentro de las preocupaciones que tenemos los que gestionamos servidores que ofrecen servicios a través de Internet destaca sin duda su seguridad a la vez que aseguramos su funcionamiento continuo. Uno de los ataques más recurrentes y habituales que sufren estos servidores es el de fuerza bruta, que consiste en la prueba sistemática y continua de un servicio hasta que se descubre una vulnerabilidad o hasta que se consigue que el servicio (en algunos casos incluso el propio servidor) deje de funcionar. Ante este tipo de ataques se utiliza una medida sencilla y efectiva, como es la utilización de algún sistema de control o filtrado de paquetes (por ejemplo, el conocido TCP Wrapper o el no menos popular iptables, el cortafuegos del núcleo de Linux). A través de alguna de estas herramientas podemos bloquear las direcciones IP de las que proceden los ataques. Sin embargo, son muchos los servicios a controlar y las IPs a bloquear al cabo de un tiempo. Afortunadamente, contamos con una gran herramienta que permite la automatización de esta línea de defensa: Fail2ban.

Se trata de un sistema de prevención de intrusiones que funciona no sólo en Linux sino en cualquier sistema POSIX que incluya un interfaz a un sistema de control de paquetes como los que he comentado antes, lo que quiere decir que funciona en otros sistemas como FreeBSD y Mac OS X. Además, como está escrito en Python, bastaría desplegar el código fuente y ejecutarlo para “echarlo a andar”. Sin embargo, es mucho mejor y más sencillo instalarlo a través de los repositorios oficiales de nuestra distribución Linux de elección.

En el caso de Debian, basta con:

# apt-get install fail2ban

Mientras que en el caso de Red Hat y sus derivativas se instala con:

# yum install fail2ban

Fail2ban funciona monitorizando los ficheros de registro del sistema en busca de entradas concretas y actuando en consecuencia a través de la ejecución de scripts que llevan a cabo las acciones deseadas por el administrador. Por ejemplo, si se detectan demasiados intentos erróneos de acceso al servidor FTP, se puede bloquear la IP desde la que se han realizado y enviar un email al administrador notificando el evento. Este bloqueo se realiza habitualmente mediante la adición de reglas en el cortafuegos y/o al fichero hosts.deny de TCP Wrapper. Además, se le puede indicar a Fail2ban que desbloquee la IP tras cierto periodo de tiempo, lo que nos sirve para evitar que conexiones legítimas (imaginemos un cliente de correo reinstalado al que se le introduce mal la contraseña del usuario) queden bloqueadas definitivamente. Generalmente, basta un bloqueo temporal para detener un ataque de fuerza bruta. Por defecto, 3 intentos fallidos (parámetro maxretry) en los últimos 10 minutos (parámetro findtime) provocan que una IP sea bloqueada otros 10 minutos (parámetro bantime).

Una vez instalado, Fail2ban nos ofrece una serie de configuraciones estándares para los servicios más habituales (apache, postfix, ssh, etc.), por lo que sólo tenemos que editar el fichero /etc/fail2ban/jail.conf y activar los filtros que nos convengan (basta con cambiar enabled = false por enabled = true en el filtro correspondiente). Estos filtros se definen a mediante expresiones regulares Python y se almacenan en ficheros dentro del directorio /etc/fail2ban/filter.d, por lo que es relativamente sencillo crear nuevos y adaptar los existentes. De igual modo, las acciones se guardan en el directorio /etc/fail2ban/action.d, en un formato propio de Fail2ban (muy sencillo) a través del cual se especifican los comandos a ejecutar y otros parámetros necesarios para un correcto funcionamiento de cada acción. Por cierto, a la combinación de un filtro y una acción se le conoce con el nombre de “jail” (cárcel). De ahí el nombre del fichero de activación de filtros.

Cada vez que realicemos un cambio en los ficheros de configuración de Fail2ban es necesario reiniciarlo, como es habitual en cualquier servicio:

# service fail2ban restart

Desgraciadamente, no hay sistema perfecto y Fail2ban presenta dos importantes carencias: no protege ante ataques distribuidos y no incluye soporte IPv6. Aún así, Fail2ban supone una gran ayuda y una línea más en la defensa de nuestros servidores expuestos en Internet.

El software libre es más seguro que el privativo, pero no como creéis

Wed, 23 Apr 2014 14:02:35 +0000

A estas alturas es bien conocida la gran conmoción causada por el bug Heartbleed en Internet, provocado por un error introducido en la rama 1.0 de OpenSSL. Esta librería, responsable de las transacciones seguras en diversos protocolos populares como HTTP o POP/IMAP, se encuentra presente no solo en todas y cada una de las distribuciones Linux, sino también en otros sistemas operativos, plataformas y productos (incluso privativos). Esta amplia presencia en el mercado viene dada por dos motivos: por el conjunto de funcionalidades que ofrece y por ser de licencia libre. Precisamente este segundo argumento es el que esgrimen los fans del software privativo como causa principal de la gravedad de la vulnerabilidad y sus consecuencias. Sin embargo, no pueden estar más equivocados.

En el mundo de la seguridad informática existen dos corrientes de pensamiento principales: la seguridad por la oscuridad y la seguridad por la transparencia. La primera argumenta que se obtiene un sistema más seguro si nadie tiene acceso a las “interioridades” del mismo: código fuente, diseño, información, etc. En cambio, la segunda sostiene que un sistema es más seguro cuanta más gente puede escudriñar su interior.

Precisamente este argumento concreto es el que se utiliza para atacar al software libre, indicando que el hecho de que el código fuente esté disponible no implica que haya nadie auditándolo. Y estoy totalmente de acuerdo. Sin embargo, ocurre exactamente lo mismo con el software privativo. Es decir, si nadie se pone, el código cerrado tampoco se audita, con la diferencia de que en el caso del software libre cualquiera con ganas puede hacerlo mientras que en el caso privativo sólo el fabricante tiene esa capacidad.

Aquí reside la ventaja del software libre desde el punto de vista de la seguridad, en la probabilidad de que un error sea encontrado en base a la cantidad de personas que tiene acceso al código fuente. Si Heartbleed hubiese estado dentro de un código cerrado, podría haber seguido allí durante décadas, ya que sólo el fabricante podría haberlo descubierto. En cambio, en el caso de OpenSSL, aunque se han tardado dos años, la vulnerabilidad se ha descubierto a raíz de una auditoría de un tercero.

Evidentemente, la disponibilidad del código fuente sirve tanto a buenos como a malos propósitos, pero estoy convencido que los beneficios superan con creces a las desventajas, como buen seguidor de la seguridad a través de la transparencia que soy. Sólo hay que revisar las hemerotecas para encontrar numerosos casos graves de seguridad en productos privativos resueltos tarde y mal.

Además, el software libre aporta otra ventaja frente al privativo: el tiempo de respuesta frente a vulnerabilidades. En el caso de Heartbleed, Debian publicó el parche que los resolvía en cuestión de una hora, y así el resto de distribuciones Linux. Sin embargo, famosos son los plazos que se toma Microsoft en la publicación de parches para Windows.

Quiero terminar el artículo con un apunte para los fans del software privativo. El impacto del bug Heartbleed demuestra la amplia aceptación del software libre, incluso con fabricantes privativos incorporándolo en sus productos. No será tan malo como nos queréis hacer creer…

Reestructuración de un sistema informático

Fri, 11 Jan 2013 13:12:59 +0000

Tal y como hemos anunciado hoy en nuestra web corporativa, la Federación Andaluza de Empresas Cooperativas de Trabajo Asociado (FAECTA) nos ha adjudicado la gestión de su sistema informático en los próximos dos años. Aparte de la alegría que supone, esta concesión implica además una gran cantidad de trabajo al inicio del proyecto, ya que el primer paso que damos en un servicio de asistencia informática es el de la reestructuración de los activos TIC del cliente en busca de una estabilidad, robustez, seguridad y eficiencia que permita traducir el uso de las herramientas informáticas en un aumento de la productividad de la entidad y en un notable descenso de las incidencias técnicas. Veamos en las siguientes líneas cómo lo llevamos a cabo en Activa Sistemas.

Existe un procedimiento previo indispensable e ineludible para llevar a buen puerto la reestructuración: la realización de una profunda auditoría del sistema informático que incluya un detallado inventario hardware y software y que permita descubrir las fortalezas y carencias del mismo a nivel de funcionalidad, rendimiento y seguridad. Con esta información en nuestro poder se procede a redactar una serie de medidas y propuestas a desarrollar para potenciar y proteger las fortalezas y resolver las carencias.

Aunque a priori es imposible saber con lo que uno se va a encontrar en un sistema informático con el que se tiene contacto por primera vez, es igualmente cierto que suele haber una serie de puntos a resolver y de medidas a tomar comunes a todos los proyectos (al menos esa es nuestra experiencia hasta la fecha).

Elaboración de políticas de uso y seguridad de los activos TIC. Su importancia radica en que sin estos documentos es prácticamente imposible conseguir la deseada estabilidad del sistema informático que permita aumentar la productividad y disminuir los costes de mantenimiento. Es fundamental que las políticas estén avaladas por la gerencia de la entidad para que tengan validez operativa y que no entren en conflicto con la normativa vigente para que tengan validez legal (por ejemplo, un error muy común es incluir penalizaciones a los usuarios por el mal uso del sistema, algo que corresponde realmente al reglamento interno, los estatutos de la entidad y la legislación vigente).
Saneamiento de la red local a nivel físico, tanto cableado como inalámbrico. La base de un sistema informático es su red local física y, si esta se encuentra en mal estado o no da el rendimiento adecuado, todo el sistema se resiente drásticamente. Por ello hay que asegurarse de que todos los nodos de la red cuentan con el acceso de calidad y ancho de banda que requieren para llevar a cabo sus funciones, preferiblemente cableado, relegando el acceso inalámbrico a los casos justificados.
Renovación del parque de puestos de trabajo. Para que un ordenador de escritorio sea realmente productivo como herramienta de trabajo, es imprescindible que su ciclo de vida no supere los cinco años (al meno, a día de hoy). Por algo será que en España las normas contables consideran que su amortización está completa a los tres años…
Implantación de un sistema de seguridad perimetral y de gestión de las comunicaciones. Con el aumento año tras año de las ciberamenazas, cada vez es más imprescindible con un sistema que no sólo gestione el acceso a Internet (y que incluso lo acelere en la medida de lo posible) sino que además permita conectar de forma segura y privada a usuarios remotos y que nos defienda de problemas externos, desde el spam hasta intrusiones, pasando por malware y contenido no deseado.
Implantación de un servidor centralizado de usuarios, datos y aplicaciones. He visto problemas y carencias de todo tipo, pero el que más me horroriza y que hace que me eche las manos a la cabeza es cuando me encuentro que la empresa no tiene servidor de ningún tipo y que toda la información se encuentra repartida en los distintos puestos de trabajo. Con un servidor central es posible controlar el acceso de usuarios a ficheros, la gestión de recursos compartidos e incluso permitirnos una intranet para el acceso desde cualquier sitio al correo, la agenda, las tareas, etc.
Implantación de un sistema de copias de seguridad.La gente no se lo cree, pero las desgracias ocurren y, una vez que se producen, es demasiado tarde y sólo queda lamentarse y asumir las consecuencias si no se han tomado las medidas oportunas. Por ello, al igual que se contratan diversos seguros para proteger los activos de una empresa, también hay que implantar un completo sistema de salvaguarda de la información de la entidad, contemplando desde los dispositivos de copia en sí (por ejemplo, un NAS o un espacio virtual en la nube) hasta la política adecuada a las necesidades locales.
Homogeneización de sistemas operativos, aplicaciones y herramientas. Un parque muy heterogéneo de programas, tanto a nivel de sistema operativo como de aplicaciones, conlleva ciertos problemas como una gestión compleja del sistema y una mayor probabilidad de fallos y averías. Sólo hay que pensar en mantenimiento, actualizaciones, incompatibilidades, etc., para darnos cuenta de lo crítico de este punto. Una sugerencia que podemos hacer en este punto es la de migrar a software libre y, si es posible, incluso a Linux.
Unificación de los servicios de Internet. Es demasiado común encontrarse con que la web corporativa está alojada en un proveedor y el correo electrónico en otro (usualmente, la misma empresa de telecomunicaciones que provee del acceso a Internet). Aparte de la complicación en la gestión que ello supone, implica un mayor gasto que si se unificara todo bajo un mismo proveedor y servicio de alojamiento.
Actualización del sitio web corporativo. Si poco caso se le echa al alojamiento, lo mismo podemos decir del contenido, es decir, el sitio web en sí. Una vez instalado por primera vez, las empresas suelen olvidarse del él, lo que agrava el gasto que supone el alojamiento. Para que un sitio web sea efectivo, es vital mantenerlo vivo, ya sea a nivel de contenidos para mejorar el posicionamiento en buscadores, a nivel de funcionalidades para ofrecer un mejor servicio a los visitantes como a nivel de motor para facilitar su gestión y resolver problemas de funcionamiento y seguridad.
Elaboración de un plan formativo de los usuarios para renovar y poner al día sus conocimientos TIC. Si se desea disminuir el número de incidencias técnicas y aprovechar los recursos TIC al máximo, es evidente que los usuarios deben estar capacitados para ello. Un plan formativo adecuado a las necesidades de la entidad y diseñado de forma dinámica y efectiva es una garantía de éxito.
Implantación de nuevos servicios y funcionalidades. Una vez resuelto todo lo básico, es el momento de mirar al futuro y de proponer novedades y mejoras TIC que supongan un salto cualitativo en la productividad de la entidad: software libre, cloud computing, teletrabajo, movilidad, etc.

No nos hemos encontrado aún una empresa u organización que necesite de todas estas medidas porque efectivamente sufra de todas las carencias correspondientes (sencillamente dudo que pudiesen funcionar), pero la mayoría sí que han necesitado de buena parte de estas soluciones. Es entonces de suma importancia que los responsables de la entidad sean capaces de ver que se trata de medidas necesarias (al fin y al cabo, un aprovechamiento óptimo de las TIC supone una enorme ventaja competitiva) y que la inversión sensata en TICs es eso, una inversión y no un gasto.

Back In Time, copias de seguridad personales para escritorios Linux

Mon, 26 Nov 2012 09:41:56 +0000

Hace algún tiempo un conocido mío usuario de Mac me “vaciló” con Time Machine (creo que se llama así), un software que automáticamente guarda copias de seguridad con los cambios realizados desde la salvaguarda anterior (lo que se conoce como copia incremental). Al realizarse de forma transparente para el usuario y ser la recuperación de ficheros muy sencilla, se trata de una herramienta muy útil e indispensable en cualquier escritorio moderno. Siendo los linuxeros como somos, hubiera sido muy raro que no contáramos con nuestra propia alternativa, así que busqué y no tardé en encontrar nuestra propia “cápsula del tiempo”: Back In Time.

Back In Time es, como ya he dicho, una herramienta de copia de seguridad dirigida a los escritorios Linux (aunque se puede utilizar en servidores, existen herramientas más especializadas para dichos entornos como Bacula) que permite realizar copias incrementales de forma sencilla y transparente para el usuario. Como es habitual en Linux, cuenta con una utilidad de línea de comandos que es la que realiza todo el trabajo de gestión de las copias y un cliente gráfico (realmente dos, uno para KDE y otro para GNOME) que hace las veces de interfaz para el usuario.

Su instalación en Debian no puede ser más sencilla, basta con elegir el cliente y ejecutar el comando correspondiente. En el caso del cliente KDE:

# apt-get install backintime-kde

Si preferimos el cliente GNOME:

# apt-get install backintime-gnome

En ambos casos, se instalará automáticamente la herramienta de línea de comandos.

Lo siguiente es configurar adecuadamente Back In Time. Para ello, arrancamos el cliente gráfico y pulsamos sobre el icono de la llave inglesa para modificar nuestras preferencias. Realmente sólo es necesario especificar tres cosas: dónde guardar las copias, qué queremos salvaguardar y cual será nuestra frecuencia de copia (puede ser manual, en el arranque del equipo o cada cierto periodo de tiempo). Tan sencillo como esto. Existen además numerosas opciones que nos permitirán personalizar aún más nuestras copias de seguridad, como el purgado automático de copias antiguas o si se desea continuar con la copia aunque se hayan producido errores, pero para salir andando y contar con un sistema robusto y estable de copias de seguridad sólo hacen falta los tres parámetros mencionados.

No debemos olvidar que, en caso de problemas o de mal funcionamiento del cliente gráfico, contamos con la herramienta de línea de comandos (que es quien realmente hace el trabajo). Una vez me dejó de funcionar el cliente KDE tras una actualización y pude seguir con mis copias sin problemas hasta que se arregló el cliente gráfico gracias a la línea de comandos. Es cierto que es algo más difícil de utilizar, pero al ser capaz de actuar en base a nuestra configuración de Back In Time, basta con lanzar la herramienta y ella solita se encarga de todo.

Un truco final. Podemos mejorar nuestro sistema de copias de seguridad basado en Back In time si lo integramos con algún servicio basado en la nube, como Dropbox, Google Drive, Wuala o el basado en software libre ownCloud. Para ello, sólo tenemos que indicarle a Back In Time que el directorio en el que queremos almacenar las copias de seguridad esté dentro de los directorios a sincronizar del servicio en la nube de nuestra elección. Con esto tendremos un sistema de backups personales a prueba de bombas (o casi).

Instalar el DNI electrónico español en Debian Wheezy

Fri, 02 Nov 2012 21:10:41 +0000

Recientemente he adquirido un nuevo PC de sobremesa para mi uso doméstico al que he instalado rápidamente mi sistema operativo favorito, Debian Linux. En esta ocasión, en vez de utilizar la versión estable actual (Squeeze), lo he hecho con la versión en desarrollo (Wheezy), ya que prefiero tener el software que uso lo más actualizado posible y de paso ayudo al proyecto Debian si encuentro algún fallo o defecto del que pueda informar.

Dado que se trata del PC de mi casa, es imprescindible para mí contar con soporte del DNI electrónico, de forma que pueda llevar a cabo desde el ordenador personal las aún escasas gestiones telemáticas disponibles en España. Estos son los pasos que he dado para conseguir dicho soporte, que por cierto son indiferentes de la arquitectura de Debian instalada (excepto a la hora de escoger los paquetes de software adecuados). En mi caso, elegí utilizar la arquitectura amd64 (64 bits) ya que mi nueva CPU lo permite.

En primer lugar debemos dirigirnos a la página web del Ministerio del Interior y descargarnos el paquete de soporte del DNI electrónico. Como no hay versión para Wheezy, tendremos que conformarnos con la de Squeeze, lo que nos provocará una serie de inconvenientes que comentaré a continuación junto con su solución. La dirección web para descargar el paquete correspondiente es la siguiente:

http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/distribuciones_linux.html

A continuación debemos descargarnos de Debian los paquetes de los cuales depende el anterior. Aquí surge el primer inconveniente, ya que algunos de dichos paquetes o bien no existen en Wheezy o los que sí existen no son compatibles. Así que debemos descargarnos los de Squeeze en su lugar. Pero antes procederemos a instalar como administrador del sistema los que sí son compatibles:

# apt-get install libpcsclite1 libopenct1 pinentry-qt

Si utilizamos Gnome en vez de KDE como escritorio, cambiamos el paquete pinentry-qt por pinentry-gtk2 (pinentry es el encargado de solicitarnos el PIN de nuestro DNIe cuando lo utilizamos).

Ahora pasamos a descargarnos los paquetes necesarios de Squeeze desde estas direcciones:

y a instalarlos junto con el paquete de DNI electrónico:

# dpkg -i Debian_Squeeze_opensc-dnie_1.4.8-2_amd64.deb opensc_0.11.13-1.1_amd64.deb libopensc2_0.11.13-1.1_amd64.deb mozilla-opensc_0.11.13-1.1_amd64.deb libssl0.9.8_0.9.8o-4squeeze13_amd64.deb

A continuación tenemos que configurar adecuadamente opensc para que utilice la librería libpcsclite1 correcta. Editamos el fichero /etc/opensc/opensc.conf, quitamos el comentario del parámetro provider_library y, según la arquitectura de nuestra Debian, le asignamos el siguiente valor:

32 bits: /usr/lib/i386-linux-gnu/libpcsclite.so.1
64 bits: /usr/lib/x86_64-linux-gnu/libpcsclite.so.1

Durante la instalación de los paquetes se nos informa de que para poder utilizar el DNI electrónico en Firefox, es necesario utilizar la opción “Registrar módulo DNIe PKCS#11” del menú “Aplicaciones -> Oficina”, algo que debemos hacer a continuación y sin el navegador abierto. Para aquellos que se lo estén preguntando, efectivamente bajo Linux sólo hay soporte de DNIe para el navegador Firefox. Una vez arrancado el navegador, procedemos a cerrarlo para que se instale el certificado raíz de la Dirección General de la Policía. Es posible que en este paso se nos solicite guardar el certificado en vez de instalarlo, por lo que a continuación lo importaremos en Firefox a través de “Preferencias -> Avanzado -> Cifrado -> Ver certificados -> Importar”.

Con esto debería ser suficiente para que funcione correctamente el DNI electrónico en Debian Wheezy, pero para estar completamente seguros en primer lugar miramos en “Preferencias -> Avanzado -> Cifrado -> Dispositivos de seguridad” si aparece en la lista “DNIe Modulo PKCS #11”. A continuación, comprobamos que el sistema reconoce sin problemas nuestro lector de tarjetas inteligentes. Para ello, instalamos los paquetes necesarios:

# apt-get install pcscd pcsc-tools

y ejecutamos el siguiente comando:

# pcsc_scan

el cual nos indicará si el lector ha sido reconocido y si hay introducida alguna tarjeta inteligente (como nuestro DNI electrónico). Incluso podemos probar en tiempo real a introducir y extraer el DNI para comprobar que dichas operaciones se detectan adecuadamente.

Ya sólo queda reiniciar la sesión de usuario y, tras acceder de nuevo al sistema, dirigirnos a algún sitio web que requiera del DNI electrónico y utilizarlo. Recomiendo utilizar la página que la propia Dirección General de la Policía facilita para esta comprobación:

http://www.dnielectronico.es/como_utilizar_el_dnie/verificar.html

Si la verificación es positiva, ya podemos utilizar nuestro DNIe con total garantía para realizar nuestras gestiones telemáticas, firmar documentos, etc.

PrivacyFix, una extensión de navegador que protege nuestra privacidad

Fri, 19 Oct 2012 10:06:59 +0000

Siguiendo la línea del artículo anterior sobre la privacidad de nuestros hábitos en Internet, en éste quiero hablar de una extensión para Firefox y Chrome de la que he tenido noticia de su existencia a través de un reciente artículo en Genbeta. Se trata de PrivacyFix, cuyo objetivo es el de mejorar nuestro nivel de privacidad al navegar por la Web.

Para conseguir su objetivo PrivacyFix actúa a través de dos herramientas: un analizador de vulnerabilidades en cuentas sociales y un rastreador en tiempo real de los sitios web que nos rastrean mientras navegamos, pudiendo incluso bloquear este rastreo (muy al estilo de como lo hace Ghostery).

En el artículo de Genbeta se preguntan si realmente es peor el remedio que la enfermedad ya que al instalar PrivacyFix le estamos dando acceso automático a todo nuestro historial de navegación, precisamente la información que estamos intentando proteger. Aunque la empresa que está detrás (PrivacyChoice) deja claro en su política de privacidad que la extensión no hace acopio de nuestros datos, al final es elección nuestra si confiar o no en un tercero nuestra seguridad.

Personalmente considero que PrivacyFix puede ser una buena opción para comprobar el nivel de privacidad de nuestras cuentas sociales, pero para el resto de opciones prefiero Ghostery. Si además le añadimos la extensión WOT y el uso de Tor con Privoxy, junto con unas buenas prácticas a la hora de navegar, habremos aumentado drásticamente la protección de nuestra privacidad en Internet.

Navegación anónima en Internet con Linux

Thu, 11 Oct 2012 11:23:45 +0000

Con el uso tan intensivo que le damos a Internet en la actualidad, hasta el punto de que nuestra vida diaria está muy integrada en la Red, es fundamental que nos preocupemos de salvaguardar nuestra intimidad de ojos ajenos. Una forma sencilla y completa de conseguirlo es combinando dos programas, Privoxy y Tor, de forma que el uso que le demos a Internet desde nuestro ordenador personal sea anónimo. Como creo que es importante conocer cómo funcionan las cosas para poder decidir si sirven o no, voy a profundizar en el trasfondo de estas tecnologías. Ni que decir tiene que ambas herramientas son de licencia libre.

En primer lugar presentemos a los actores. Privoxy es un proxy, es decir, un software intermediario entre el usuario y un servicio de red. De este modo, el usuario contacta con el proxy y es éste el que conecta con el servicio en nombre del usuario. Esto tiene numerosas aplicaciones, como acelerar la navegación web, filtrar el tráfico inadecuado, centralizar la gestión y el mantenimiento de un servicio o posibilitar la conexión a un servicio que de otra forma sería imposible.

Por otro lado tenemos a Tor, que es tanto una herramienta como una red abierta, diseñadas para ayudar al usuario a defender su privacidad y libertad personales. De este modo Tor permite proteger las comunicaciones de forma que nadie conozca nuestros hábitos de uso de Internet a través de cualquier servicio que dirijamos a través de Tor: navegación web, mensajería instantánea, redes sociales, etc.

Vemos como instalar y configurar ambas herramientas en un ordenador personal que corre Debian o alguna de sus derivaciones. Lo primero es proceder, como administrador del sistema, a instalar los paquetes necesarios:

# apt-get install privoxy tor

Este comando instalará Privoxy y Tor. Aunque existen clientes gráficos como TorK o Vidalia, lo cierto es que desaconsejo su uso por varios motivos: o bien están mal traducidos al español, o bien son complejos de configurar, o lo que es peor interfieren en el funcionamiento de Tor.

Una vez instalados los paquetes, Tor debería estar funcionando directamente. Al tratarse de un proxy SOCKS, para utilizarlo bastaría con configurar los programas que utilicemos en Internet y que entienda dicho protocolo con los siguientes datos:

Proxy SOCKS: 127.0.0.1 (para quien no lo sepa, esta IP siempre representa a nuestro propio equipo)
Puerto: 9050

¿Pero entonces para qué hemos instalado Privoxy? Para que traduzca automáticamente el protocolo HTTP al protocolo SOCKS, es decir, dirigiendo todo nuestra navegación web a través de Tor y consiguiendo así el ansiado anonimato web. Para ello tenemos que indicarle a Privoxy donde está Tor editando como administrador el fichero /etc/privoxy/config y añadiendo la siguiente línea:

forward-socks4a / localhost:9050 . (el punto no es una errata, hay que incluirlo también)

debajo de ésta otra:

listen-address localhost:8118

Sólo queda reiniciar Privoxy para que active la nueva configuración:

# /etc/init.d/privoxy restart

Para probar que ya podemos navegar de forma anónima, cogemos nuestro navegador favorito y lo configuramos para que utilice Privoxy como proxy de acceso a Internet. Por ejemplo, en el caso de Firefox, abrimos las Preferencias y nos dirigimos al apartado Avanzado, donde seleccionamos la pestaña Red. Allí tenemos un botón que nos sirve para configurar cómo Firefox se conecta a Internet. Una vez pulsado, en la ventana que aparece a continuación tenemos que seleccionar la opción “Configuración manual del proxy” y rellenar los campos de la siguiente manera:

Proxy HTTP: 127.0.0.1
Puerto: 8118
Usar el mismo proxy para todo: Sí

Una vez configurada, la pantalla debería quedar así:

Aceptamos y procedemos a comprobar que nuestra navegación ya es anónima conectándonos a https://check.torproject.org/ Si nos sale en pantalla un mensaje en verde diciendo “Congratulations. Your browser is configured to use Tor.”, eso quiere decir que lo hemos conseguido y que estamos usando la red Tor (en nuestro caso a través de Privoxy) para navegar de forma anónima por la Web.

La configuración de otros navegadores y otras herramientas es similar. Basta con probar con los datos ya mencionados, bien mediante Privoxy o directamente con Tor, para que todas nuestras comunicaciones sean realmente privadas.

Sólo una nota final. Tal y como avisan en el proyecto Tor, se trata de software experimental por lo que no debemos confiar en él si lo que buscamos es una anonimato a prueba de bombas.

Espero que esta receta os sea realmente útil, sobre todo para aquellos que tenéis menores en casa en edad de utilizar asiduamente Internet. Me gustaría conocer vuestras experiencias si decidís hacer la prueba con Tor y Privoxy.

Ghostery, la extensión que permite controlar el seguimiento web

Tue, 08 Mar 2011 00:49:32 +0000

Últimamente estoy especialmente concienciado con la privacidad en Internet, sobre todo desde que hay menores en casa que empiezan a navegar por la Web. Lo cierto es que siempre he tenido sospechas sobre el mal uso que terceros puedan realizar con los datos recopilados sobre nuestro comportamiento en la Red. Además de utilizar las herramientas de las que ya hablé en su momento, estoy en permanente búsqueda de nuevas utilidades que me permitan mejorar en la medida de lo posible el uso de la Red en mi hogar. Pues bien, mi último descubrimiento ha sido Ghostery, una extensión para Firefox, Chrome, Safari y (¡sorpresa!) Internet Explorer.

El objetivo de Ghostery es avisar al usuario cuando una página web que está visitando le está haciendo algún tipo de seguimiento, desde un recuento estadístico (como el popular Google Analytics o el paquete de software libre Piwik) hasta la creación de un perfil de consumidor (como DoubleClick), pasando por cualquier otra entidad interesada en conocer nuestra actividad en la Web. Este seguimiento se realiza a través de una serie de elementos, como scripts, iframes y gráficos, que no siempre son visibles en el código fuente de la página, por lo que la funcionalidad que ofrece Ghostery se vuelve aún más importante al desvelar estas prácticas.

Una vez identificado quién nos está siguiendo al visitar un sitio web concreto, Ghostery nos ofrece la posibilidad de saber más sobre cada entidad identificada, incluyendo cómo se describen a sí mismos y un enlace a su política de privacidad. Como paso final del proceso, Ghostery permite bloquear a aquellas entidades en las que el usuario no confíe, de forma que impida el mencionado seguimiento. Además, la extensión tiene una característica opcional llamada GhostRank, que envía anonimamente a los servidores de Ghostery información sobre los rastreadores encontrados y dónde se han encontrado, lo que permite crear una lista cada vez más completa. Como dicen sus creadores, “Ghostery pone tu privacidad web de vuelta a tus manos”.

Por todo ello, el papel de Ghostery en la defensa de la privacidad del usuario de la Web, sobre todo si como decía al principio hay menores de por medio, se me antoja de una importancia vital. Si además tenemos en cuenta que Ghostery es gratuita y que sus responsables han prometido no utilizarla nunca para publicidad, creo que nos encontramos ante un componente imprescindible para nuestros navegadores web.

¿Has probado ya Ghostery? ¿Cuáles son tus impresiones? Espero vuestros comentarios.

Seguridad en el teletrabajo

Fri, 11 Sep 2009 19:42:02 +0000

En el artículo anterior dejé pendiente profundizar en los aspectos de la seguridad a la hora de establecer la infraestructura necesaria para permitir el teletrabajo en una empresa u organización. Como decía en dicho artículo, no hay que olvidar que al instalar un sistema de teletrabajo se está habilitando una “puerta” de la empresa al exterior, lo que puede facilitar el acceso no autorizado a los datos y recursos telemáticos de la misma si no se planifica bien la seguridad de todo el sistema. En este sentido, los puntos de vista relacionados con la seguridad a tener en cuenta son tres: la seguridad de la comunicación, la seguridad en el acceso al dispositivo de conexión y la seguridad en el acceso a los datos y recursos de la empresa. Veamos en detalle cada uno de ellos.

Por seguridad de la comunicación me refiero principalmente al protocolo y nivel de encriptación de red privada virtual (VPN) utilizado para conectarse a la empresa. La mayor dificultad en este sentido radica en saber elegir un protocolo con una encriptación robusta, que sea relativamente fácil de configurar, que esté disponible en los sistemas operativos y dispositivos más populares, que no entre en conflicto con los sistemas de comunicación utilizados habitualmente (por ejemplo, que no obligue a reconfigurar un router ADSL simplemente para que la VPN pueda atravesarlo), que sea flexible y versátil y que resuelva las necesidades de la empresa. Además, si el protocolo es robusto, se relativiza la importancia de la seguridad del medio físico sobre el que corre el túnel virtual, ya que aunque utilizáramos una red inalámbrica con un sistema de protección pobre, el tráfico del túnel seguiría protegido por la propia tecnología de la VPN. Un mal ejemplo de tecnología VPN es el protocolo PPTP, muy fácil de configurar y echar a andar, pero cuya seguridad hace tiempo que fue comprometida, por lo que hay que huir de él en la medida de lo posible y sustituirlo con otros protocolos como L2TP o IPsec.

Igualmente importante es tratar de salvaguardar la seguridad del dispositivo de conexión (ordenador, portátil, móvil, agenda, etc.), ya que en el mismo momento en el que se conecta a la empresa por VPN, se comporta como si físicamente estuviera dentro de la misma, En este sentido, es necesario establecer una sencilla pero estricta política de uso de estos dispositivos que contemple cuestiones como la imposibilidad de guardar contraseña para su reutilización en sesiones posteriores o la implantación de mecanismos de autentificación de usuarios que pueden llegar a ser tan sencillos como la mencionada contraseña o tan complejos como las soluciones biométricas (como el control mediante huella digital), pasando por soluciones intermedias como el uso de certificados y tarjetas inteligentes. Por supuesto, si la seguridad del dispositivo se ve comprometida (por ejemplo, por culpa de un virus o porque el dispositivo ha sido robado), hay que proceder inmediatamente a revocar los permisos de acceso que dicho dispositivo concediese a sus usuarios.

Por último, vez que el usuario remoto se ha conectado por VPN a la red de la empresa, hay que gestionar la seguridad en el acceso a los datos y recursos de la misma, siendo lo ideal que dicho usuario reciba como máximo los mismos permisos y privilegios con los que cuenta cuando se encuentra físicamente en la empresa. En este sentido, una solución sencilla, elegante y versátil es implantar una intranet que sirva para acceder a los recursos de la empresa tanto desde dentro como desde fuera, evitando así el tener que mantener dos sistemas de seguridad distintos, algo que tarde o temprano va a producir incoherencias y a que la seguridad se vea comprometida por asignar más permisos de los que se debe a un usuario remoto o menos de los que necesita a un usuario local.

En definitiva, la seguridad es un aspecto primordial a tener en cuenta si queremos que la inversión en un nuevo sistema de teletrabajo en la empresa sea realmente útil y eficiente.

Protección de menores frente a contenido inapropiado en Internet

Wed, 22 Jul 2009 09:53:08 +0000

Hace poco leí un interesante artículo en Digital Inspiration acerca de cómo proteger a nuestros hijos frente a contenido inapropiado para ellos cuando acceden a la Web y otros servicios de Internet. Las herramientas de las que habla el artículo son muy efectivas, aparte de ser en su mayoría soluciones multiplataforma, pero pecan de ser muy específicas en el trabajo que realizan. Por eso me decidí a buscar una herramienta más completa y que, a ser posible, funcionase sobre Linux. He tenido éxito en mi búsqueda, pero antes de pasar a hablar de ella, voy a comentar las dos herramientas mencionadas en el artículo que me han llamado más la atención.

La primera es OpenDNS, un servicio gratuito de DNS que, configurado adecuadamente, nos puede servir para impedir el acceso a tanto a servidores de contenido inapropiado como a páginas de estafas por Internet (el tristemente famoso phishing). Para utilizarlo, basta con seguir las instrucciones disponibles según el sistema operativo del ordenador que utilicen los menores para acceder a Internet, que básicamente se reducen a cambiar los servidores DNS del ordenador, crear una cuenta en OpenDNS y configurar el nivel de filtrado adecuadamente. Aunque es un servicio válido para cualquier plataforma y sencillo de echar a andar, presenta una pega importante: al tratarse de un servicio de terceros nuestro control sobre su funcionamiento es prácticamente nulo, siendo posible que se produzcan tanto falsos positivos (que se bloqueen paginas válidas) como falsos negativos (que se muestren paginas inadecuadas). No por esto debemos desechar el uso de OpenDNS, simplemente no debemos relajarnos y confiarle al 100% la protección de nuestros hijos.

La segunda herramienta interesante del artículo es Web Of Trust (WOT), una extensión para Firefox e Internet Explorer de la que ya he hablado anterioremente. Su función es la de advertir de la confianza de un sitio web antes de acceder a él mediante el uso de un código de colores asociado a los enlaces que llevan a dicho sitio web. WOT se alimenta de la información proporcionada por los propios usuarios en base a varias categorías de puntuación. En caso de acceder a una página catalogada como peligrosa, WOT bloquea el acceso son un aparatoso mensaje en pantalla y nos da la opción de seguir adelante o dirigirnos a otro sitio web. Es justo aquí donde se encuentra su mayor pega: deja la elección de visitar un sitio web en manos del internauta, por lo que WOT sólo es útil si supervisamos la sesión de navegación del menor.

Es el momento de descubrir la herramienta de control parental para Linux. Se trata de WebContentControl, un completo interfaz de usuario que facilita el uso combinado de diversas herramientas del sistema y algunas de las aplicaciones más potentes para el control de acceso a Internet, como DansGuardian (filtro de contenidos), Tinyproxy (pasarela de acceso a la web) y FireHOL (aplicación de cortafuegos). De este modo, WebContentControl pone en manos del usuario doméstico toda la potencia de herramientas de seguridad muy populares en entornos empresariales. Su complejidad puede resultar algo farragosa cuando nos enfrentamos a él por primera vez, pero los resultados llegan pronto y son muy satisfactorios. Aunque sólo hay descarga para Ubuntu, yo lo he probado en una Debian sin problemas. Por ponerle alguna pega, tiene una elevada dependencia de GNOME, pero con algunos simples retoques se puede utilizar sin problemas bajo otros entornos (yo lo hice bajo KDE4). Además, parece ser un proyecto temporal, ya que se está desarrollando otro software (GChildCare) como sustituto. La distribución Molinux tiene un interesante tutorial sobre su uso y puesta en marcha.

La combinación de estas tres herramientas debe resultar en un sistema más seguro para que nuestros hijos puedan navegar por Internet sin experiencias desagradables. ¿Qué herramientas utilizáis vosotros?

Distribución de parches: la carrera entre piratas y administradores

Wed, 21 Jan 2009 12:59:46 +0000

Cuando se descubre una vulnerabilidad de seguridad, las acciones correctas a llevar a cabo son preparar un parche y conseguir que se distribuya lo más rápida y extensamente posible. Sin embargo, hay aún hoy en día quien piensa todo lo contrario, que la distribución de parches se debe retrasar en la medida de lo posible. Obviamente, se refieren a parches que resuelven problemas descubiertos por hackers “de sombrero blanco”, en oposición a las vulnerabilidades que ya estén siendo activamente explotadas por hackers maliciosos.

No hay duda de que un parche de seguridad ofrece un camino pavimentado para cualquiera que esté buscando vulnerabilidades, de forma que un pirata sólo tiene que mirar al trozo de código que está siendo arreglado. La publicación de un parche de seguridad permite a los administradores de sistemas cerrar un agujero, pero a la vez anuncia a todo el mundo la existencia y localización de dicho agujero. En este punto comienza una carrera en la que los administradores intentan aplicar el parche antes de que los piratas consigan explotar la vulnerabilidad.

Lo que se necesita, por tanto, es un método que otorgue a los defensores una ventana de tiempo mayor para obtener los parches antes de que la información acerca de la vulnerabilidad se distribuya. A día de hoy existen diversos mecanismos que están en funcionamiento, pero que arrojan resultados lejanos al 100% de efectividad deseado, como la inclusión de parches en las actualizaciones a nuevas versiones de software o las diversas listas de correo dedicadas a la seguridad de sistemas.

En busca de esa mayor efectividad, se está estudiando un nuevo método, que consiste en la distribución inicial de parches encriptados, perfectamente aplicables al sistema pero cuyo contenido no se puede consultar hasta que se distribuya posteriormente la clave de desencriptación. Este método, sin embargo, debe enfrentarse aún a diversos problemas de diseño para que sea realmente efectivo, como la posibilidad de ataques de denegación de servicio contra la distribución de la clave o los problemas legales de incompatibilidad con software GPL. Aunque a priori parece una solución que puede causar más problemas de los que resuelve, no hay duda que que es una opción interesante con la que nos gustaría contar en el futuro.

Protegerse de vulnerabilidades desconocidas en Linux

Tue, 23 Dec 2008 20:12:00 +0000

En artículos anteriores he comentado que la aplicación diligente de parches de seguridad es uno de los mecanismos disponibles para protegerse de vulnerabilidades conocidas (con lo que se hubiera evitado el desastre del gusano de SQL Server, ejemplo del que me serví para ilustrar dichos artículos), pero ¿cómo puede uno evitar, o al menos reducir la probabilidad, de que un atacante aproveche una vulnerabilidad desconocida?

En el caso de Linux, una de las soluciones más populares y recomendadas de entre las actualmente existentes es la de la aplicación al núcleo de diversos parches de implantación de sistemas de seguridad, como la protección frente a desbordamientos de buffers y pila, el confinamiento de procesos críticos en “cárceles”, los sistemas de detección de intrusiones o las políticas de control de acceso a recursos. Sin embargo, no todas las distribuciones Linux están aún convencidas de la necesidad de implementar alguna de estas soluciones en sus productos. Entre las principales razones esgrimidas para justificar este escepticismo se encuentra el respeto o miedo que genera incluir nuevo código directamente en el núcleo.

Aún así, existen diversas iniciativas que pretenden cumplir con el objetivo de ofrecer un núcleo realmente seguro, como SELinux, desarrollada con el apoyo de la Agencia de Seguridad Nacional (NSA) de Estados Unidos, o AppArmor, mantenida por Novell. Proyectos como éste confirman la existencia de una tendencia en la comunidad Linux hacia productos construidos en base a la seguridad como parámetro principal. Esperemos que esta tendencia se extienda y popularice para evitarnos en el futuro sorpresas desagradables.

Protección frente a amenzas en el correo electrónico

Thu, 18 Dec 2008 13:42:10 +0000

Tal y como están las cosas con el correo electrónico (spam, virus, phising y otras estafas, etc.), muchos usuarios se desesperan al darse cuenta de que se trata de una herramienta imprescindible en sus vidas cuya utilización conlleva un enorme riesgo. Cuando un cliente me pregunta si es posible minimizar el riesgo de infección, mi respuesta es siempre la misma: lo es, implantando un mecanismo de seguridad en tres niveles que puede llegar a proteger nuestros sistemas en un elevado porcentaje de posibilidades.

Si seguimos el camino que recorre un virus desde que entra en nuestra red hasta que se produce la infección, el primer nivel estaría situado en la pasarela de correo electrónico, un sistema que se encarga de recoger el correo que viene de Internet y de analizarlo en busca de virus y de correo basura. De este modo, los virus conocidos nunca entran en la red local, aunque para ello es fundamental que el antivirus del sistema se actualice a diario. Obviamente, este nivel no tiene sentido en el caso de usuarios domésticos, que no suelen ni necesitar ni contar con este tipo de sistemas. Por cierto, la utilidad de una pasarela de correo va más allá, ya que posibilita una gestión completa del correo electrónico, pudiendo crear mensajería interna, redirección y duplicación de mensajes o recolección desde buzones en diversos dominios, entre otras posibilidades.

El segundo nivel se sitúa en el sistema operativo. La mejor solución es utilizar Linux o cualquier otro sistema, preferentemente libre, que no sea susceptible de ser infectado por virus o que, al menos, controle el nivel de daños que pueda causar una infección. Si, por cualquier motivo, esto no es factible y hay que utilizar Windows, entonces tendremos que hacer el desembolso de un software antivirus de reconocida eficacia y que tenga la capacidad de filtrar los mensajes de correo, algo que no todos los paquetes traen de serie. En este caso, tendremos que actualizar el antivirus a diario, tal y como en el nivel anterior.

Por último, el tercer nivel debemos situarlo en los programas que utilicemos como navegador y como cliente de correo electrónico, ya que una buena parte de los virus actuales intentan aprovechar vulnerabilidades de estos programas, que no tienen por qué ser conocidas. La mejor opción es utilizar alternativas fiables, robustas y seguras, a la vez que contamos con todas las funcionalidades que necesitemos. Como navegador, como es de esperar recomiendo a mi favorito Mozilla Firefox, de licencia libre, mucho más avanzado que sus competidores, muy ligero y con una elevada compatibilidad con los estándares, lo que nos asegura una navegación fluída por la Web. En el caso del correo electrónico, existen paquetes libres y/o gratuitos muy populares, pero sin duda la mejor opción en el caso de una red local es el de implementar un webmail, al estilo de Yahoo! Mail o Gmail, de forma que los mensajes se muestran como una página web, incluyendo los adjuntos, lo que evita la ejecución de código malicioso incluido en los correos. Como en el caso de la pasarela, sus ventajas no se quedan ahí, ya que un webmail elimina la necesidad de mantener un programa de correo electrónico en cada PC, centraliza la administración en un servidor y permite la consulta del correo desde cualquier puesto con sólo arrancar el navegador e introducir nuestro usuario y contraseña.

Llevar a la práctica estos niveles implica un esfuerzo en tiempo y en dinero en cualquier caso, pero está claro que esta inversión siempre será menor que el coste de recuperar nuestros sistemas tras el ataque de un nuevo virus.

Problemas de seguridad en sistemas informáticos (y III)

Fri, 12 Dec 2008 23:02:54 +0000

En los artículos anteriores analicé el impacto del gusano “SQL Slammer”, que afectaba a sistemas Windows con SQL Server, y realicé una comparativa entre los modelos de seguridad de los sistemas propietarios y los sistemas libres. Es el momento de ver si las conclusiones obtenidas entonces son realmente válidas, basándome en un destacado caso de problema de seguridad detectada en un conocido software de licencia libre.

Pocas semanas después del ataque de “SQL Slammer”, allá por Febrero de 2003, el grupo X-Force de la empresa Internet Security Systems (ISS) descubrió una importante vulnerabilidad en el popular servidor de correo Sendmail. Tras elaborar el correspondiente informe y ponerse en contacto con los responsables del paquete, X-Force la dió a conocer al público a través de sus lista de correo.

Gracias a la disponibilidad del código fuente, alguien externo a los responsables del software fue capaz de auditarlo, algo imposible en entornos propietarios. Así mismo, al ofrecer información detallada al respecto, los distintos fabricantes de distribuciones Linux fueron capaces de elaborar parches que pusieron a disposición de sus usuarios inmediatamente. Finalmente, los administradores de los sistemas afectados contaron con los medios de atajar esa nueva amenaza con total garantía, siempre y cuando fueran técnicos cualificados y responsables que no pusieran en peligro sus sistemas por su negligencia (tal y como ocurrió con el “SQL Slammer”, cuya existencia y solución se conocían seis meses antes del ataque). Y todo esto en menos de una semana. Quedan claras por tanto las ventajas del software de código abierto frente al privativo desde el punto de vista de la seguridad.

El "spyware" (y III)

Wed, 10 Dec 2008 17:41:39 +0000

En el artículo anterior de la serie analicé los síntomas que nos podían indicar la presencia de spyware instalado en un sistema. ¿Cómo podemos protegernos de esta moderna plaga? En este sentido he elaborado una lista de consejos que espero resulten útiles a la hora de enfrentarnos al spyware.

Instalando una aplicación anti-spyware y realizando análisis periódicos del sistema. Si la herramienta incluye, protección en tiempo real, debe activarse para aumentar así la efectividad de la protección. Entre las mejores se encuentran los ya mencionados Spybot Search & Destroy o Anti-Malware.
Apoyando al software anti-spyware con otras herramientas de seguridad, como cortafuegos y antivirus.
Mostrando la máxima cautela al conectarse a redes P2P, ya que muchas de las aplicaciones más populares para compartir ficheros por Internet incluyen algún tipo de spyware en su instalación.
Teniendo cuidado con las cookies admitidas por nuestro navegador. Aunque no representan la peor forma de spyware, la información recogida en las mismas puede compararse con información recogida mediante otros métodos para obtener un perfil sorprendentemente detallado sobre el usuario y sus hábitos de navegación.
Eliminando el correo no solicitado sin llegar a abrirlo o previsualizarlo. Existen métodos de confección de mensajes de correo electrónico HTML contaminado que pueden activar fallos en Internet Explorer y otros programas populares para así espiar los datos del usuario.
No instalando nada sin saber antes de qué se trata exactamente. Esto incluye leerse la licencia del programa, dado que algunas indican si se instalará algún tipo de spyware adicionalmente.
Manteniéndose al tanto del siempre cambiante mundo del software espía. Para ello, recomiendo el Foro de InfoSpyware y el Spyware Information Center de CA. Conocer la amenaza es la mejor defensa que existe contra ella.

Problemas de seguridad en sistemas informáticos (II)

Fri, 05 Dec 2008 16:05:25 +0000

En el artículo anterior de esta serie analicé si el gran impacto que produjo el gusano “SQL Slammer” allá por Enero de 2003 en las plataformas Microsoft podría reproducirse en entornos de Software Libre. La conclusión fue que, desde el punto de vista del componente humano de los sistemas, sí era posible. Pero ¿y desde la consideración de la naturaleza de las propias plataformas?

Si hay algo de lo que se ha acusado recurrentemente a cualquier entorno propietario es precisamente de la falta de información para los administradores del sistema para enfrentarse a posibles problemas de seguridad. Dado que en la mayoría de los casos la única documentación disponible es la que genera el propio fabricante, el responsable del sistema se ve obligado a confiar la integridad de sus sistemas en el criterio y las capacidades de aquél. Esto es lo que se conoce como “seguridad a través de la oscuridad”, filosofía que cuenta con varios e importantes inconvenientes.

En primer lugar, como acabo de decir, la seguridad de nuestros sistemas se ve en manos de terceros. Así mismo, estamos a merced de la política de publicación de parches del fabricante, que no tiene por qué coincidir con las necesidades reales de los sistemas. También hay que considerar que, a pesar de que el fabricante oculte información, es posible (como ya se ha demostrado en numerosas ocasiones) que un cracker encuentre un agujero y que lo empiece a aprovechar activamente, algo de
lo que no estaría informado el administrador del sistema y ante lo que no podría hacer nada ya que el fabricante no se ha pronunciado al respecto, principalmente por puro desconocimiento de la existencia del problema. Por último, el hecho de no contar con los fuentes de la plataforma impide que cualquier profesional concienciado pueda auditarla y descubrir no sólo agujeros de seguridad sino incluso puertas traseras dejadas ahí maliciosamente por el propio fabricante (también se conocen casos).

Nada de lo descrito en el párrafo anterior ocurre en el ámbito del Software Libre, que defiende la filosofía de la “seguridad a través de la claridad”. Basta con leer el párrafo al contrario para conocer las ventajas de una plataforma abierta. Como ejemplo clarificador, sólo hay que pensar que cuando se descubre un fallo de seguridad, cualquier administrador medianamente responsable (recordemos el artículo anterior) podrá estar tan informado como cualquier cracker del problema, lo que elimina automáticamente la ventaja con que puedan contar estos malhechores.

Por tanto, si queremos la máxima seguridad en nuestros sistemas, debemos contar con dos cosas fundamentales: plataformas basadas en Software Libre y administradores cualificados. Con eso tendremos asegurado un 99,9% de éxito en la tarea de defender la integridad de nuestros sistemas. Contra el 0,1% restante hay poco que hacer, sólo esperar que no nos toque a nosotros, ya que queda en manos de lo que el profesor Andrew Tanenbaum denomina en sus libros como “la ira de Dios”: accidentes, catástrofes naturales, conflictos bélicos…

El "spyware" (II)

Wed, 03 Dec 2008 13:09:02 +0000

Si en el artículo anterior de la serie presenté la situación actual del spyware como una de las grandes lacras de Internet, en esta ocasión voy a enumerar los síntomas que pueden ayudarnos a detectar si nuestro sistema ha sido infiltrado por software espía. Dado que a día de hoy el spyware es un problema que afecta principalmente a los usuarios Windows, voy a centrarme en los síntomas aplicables a estos sistemas.

Al introducir una búsqueda en la barra de direcciones de Internet Explorer, en vez del motor de búsqueda habitual aparece un sitio desconocido que se encarga de realizar la búsqueda.
El software anti-spyware instalado deja de funcionar correctamente, con síntomas como que muestra mensajes de aviso de que le faltan ciertos ficheros de apoyo, se cierra espontáneamente o simplemente se estrella cada vez que se intenta ejecutar.
Aparece un nuevo elemento en la agenda de favoritos sin que el usuario lo haya puesto ahí consciente y voluntariamente. Si se intenta borrar, vuelve a aparecer más tarde.
El sistema se ejecuta claramente mucho más lento que antes y aparecen procesos no familiares que utilizan cerca del 100% de la CPU.
Cuando no se está conectado a Internet, las luces de envío y recepción del módem o router parpadean como si se estuviera navegando por la Web o descargando un fichero.
Aparece una barra de herramientas no solicitada en el navegador, que se resiste a ser eliminada.
El escritorio se ha llenado de iconos que no se corresponden con ninguna aplicación instalada y que suelen conducir a sitios web desconocidos.
Aparecen anuncios en ventanas emergentes cuando el navegador no está ejecutándose e incluso cuando ni siquiera el sistema está conectado a Internet.
La página de inicio habitual ha sido cambiada a otra no deseada. Aunque se establezca manualmente a su valor correcto, tarde o temprano vuelve a cambiarse a la página no deseada.
En el caso de que la conexión a Internet sea vía módem, la factura telefónica incluye llamadas a números de alto coste por minuto o a números en el extranjero.

Si se presentan varios de estos síntomas, sin duda el sistema está infectado por spyware y debe ser analizado por un buen escáner anti-spyware, como Spybot Search & Destroy o Anti-Malware. Aún cuando no parezca que ocurra nada malo en el sistema, no es mala idea realizar un análisis en busca de spyware con cierta periodicidad, ya que existe mucho software espía que oculta su actividad tras una normalidad aparente.

En el próximo artículo veremos cómo evitar la infiltración de spyware en nuestros sistemas.

Problemas de seguridad en sistemas informáticos (I)

Fri, 28 Nov 2008 20:59:43 +0000

La aparición en Enero de 2003 del infame gusano “SQL Slammer” en Internet provocó que, aún siendo específico de sistemas Windows (concretamente afectaba a SQL Server de Microsoft), muchos servidores basados en otros sistemas operativos se vieran afectados. El acceso a estos sistemas fue prácticamente imposible debido a la saturación en las redes provocada por el excesivo tráfico que el gusano generaba en pleno ataque. Este problema en la Red desencadenó la eterna discusión acerca de los problemas de seguridad en el software propietario en general y en los sistemas de Microsoft en particular. Yo sin embargo me hago otra pregunta: ¿es posible esta situación en el mundo del Software Libre?

Cualquier entidad que quiera tomarse en serio la seguridad de sus sistemas informáticos debe cumplir necesariamente con dos premisas: una política de seguridad clara, aprobada por la organización y plasmada por escrito, y un equipo de técnicos cualificados. La política de seguridad debe contemplar todos los aspectos relevantes, desde el acceso físico a los terminales hasta la caducidad de las contraseñas, pasando incluso por las sanciones ante diversos actos de los usuarios. Los técnicos deben estar en continua formación y perfectamente informados de la actualidad, así como ser responsables de la implantación de la política de seguridad.

Si no se cumple con estas condiciones, el riesgo de encontrarse entre las numerosas víctimas de un desastre como el producido por el “SQL Slammer” es elevadísimo. Por desgracia, este cuadro es más común de lo deseado, ya que no se puede explicar de otra forma que se pudiera aprovechar un fallo conocido y perfectamente documentado desde hace seis meses antes. Es decir, debido a la no inclusión de una política de aplicación de parches en la política de seguridad o a la escasa información/preparación de los técnicos responsables, numerosos sistemas se vieron afectados por el gusano y, como efecto directo, sus usuarios se vieron afectados dramáticamente. Inadmisible.

Si se ha leído con atención el párrafo anterior, es fácil darse cuenta de que no he mencionado ningún sistema operativo ni paquete de software concreto. Es lógico, ya que lo descrito es aplicable a cualquier sistema, incluso en el caso de OpenBSD, gestado con la seguridad en mente como premisa principal y que apenas ha emitido avisos de seguridad en once años. Basta un técnico mediocre para que tal fortaleza se venga abajo.

La conclusión es ya clara a estas alturas y el culpable ha sido así mismo señalado: cualquier sistema se puede ver en las mismas circunstancias que el servidor SQL de Microsoft por culpa de la propia naturaleza humana. La única solución, como he expuesto más arriba, es cumplir A RAJATABLA las dos premisas expuestas.

En un próximo artículo pretendo comparar la seguridad del Software Libre frente a la de los sistemas propietarios, en base a sus propias virtudes y defectos.

El "spyware" (I)

Tue, 25 Nov 2008 14:53:15 +0000

La primera vez que un usuario instala y ejecuta un software de anti-spyware en un equipo con Windows que haya sido utilizado para navegar por Internet o instalar programas gratuitos que se pueden encontrar fácilmente por la Red se puede dar de bruces con un resultado pavoroso: decenas de entradas relacionadas con spyware estaban instaladas y de cuya existencia el propio usuario no tenía ni idea.

¿Qué es esto del spyware? Se trata de software que suele instalar de forma automática y que tiene la función de recabar información de marketing sobre los propios usuarios del equipo. A continuación comienza a servirle publicidad dentro de ciertos programas (el método más llamativo es el de las ventanas emergentes de Internet Explorer conteniendo anuncios), convirtiendo al equipo en un nodo de una vasta red de distribución de publicidad. Existen numerosos casos en los que el spyware se instala sin previo aviso y recaba más información de la que debiera, mientras que en la mayoría de las ocasiones el spyware se oculta tras una larga licencia que nadie se lee y que todos aceptan cuando se pulsa el famoso botón de “Siguiente”, por lo que al final terminamos con software no deseado (y del que desconocemos su existencia) en nuestro equipo.

Originalmente, el spyware se incluía por lo general con programas comerciales con el objetivo de que el usuario pudiera utilizarlos gratuitamente a cambio de recibir publicidad personalizada. Entonces se denominaba adware y bastaba con eliminarlo para que el programa gratuito al que estaba asociado dejara de funcionar. Dado que solía tratarse de programas interesantes, el usuario se veía con muy pocas opciones de elección. Pero, ¿era lícito el adware? Dependía exclusivamente del asentimiento del usuario a su instalación. El problema es que en la mayoría de los casos, la instalación del adware se le ocultaba al usuario (convirtiéndose por tanto en spyware), lo cual era inadmisible.

Actualmente el spyware se ha convertido en un serio problema para los PC de escritorio, como si no tuvieran suficiente con los virus, gusanos, vulnerabilidades en los programas más populares, e-mails nocivos y demás “fauna” peligrosa. Es un problema de tal magnitud que algunos gobiernos nacionales están tomando conciencia del mismo y están empezando a actuar en consecuencia, principalmente mediante el desarrollo de leyes y normativas que regulen este acto de robo y vandalismo electrónico. Poco conocido hace unos años, el spyware es hoy en día tan común que está considerado por muchos como el mayor problema de Internet desde el spam. De hecho, Microsoft estima que el spyware es responsable de la mitad de los problemas de funcionamiento de los PCs que corren un sistema operativo de la familia Windows, llegándose en muchos casos a la inutilización total del equipo y, por tanto, a un coste extra en conceptos de reparación y tiempo de parada.

El ejemplo que mejor ilustra hasta dónde puede llegar el spyware es el de un reproductor multimedia conocido como BDE y que utilizaba los ciclos no usados por la CPU para “cederlos” a una vasta red de marketing diseñada por sus creadores (¡tremendo!). Hasta el “temible” Internet Explorer se presta a estas cuestiones y no es raro encontrar spyware que se ha introducido en el equipo por su culpa. En definitiva, no sólo nos espían sino que encima se permiten el lujo de malgastar los recursos de nuestro ordenador (lo mismo que hace un virus, entre otras cosas).

Por ello, es fundamental utilizar herramientas de detección de spyware para estar al tanto de qué se instala en un equipo con Windows. Mi mejor consejo sin embargo es la migración a un sistema robusto y seguro como Linux, el cual parece que aún no sufre los estragos del spyware, pero su infraestructura de seguridad interna, la transparencia de las operaciones realizadas bajo Linux y el sistema de configuración basado en simples ficheros de texto plano hacen que está posibilidad sea remota. Así mismo, la gran cantidad existente de alternativas de software sin “cargas oscuras” otorgan al usuario la libertad de elección que necesita para evitar esta plaga. En definitiva, es más que dudoso el éxito de estos espías en el sistema del pingüino. Quizá este sea el mejor momento para los usuarios de Windows de plantearse la migración a un sistema mejor y más seguro.

En próximos artículos veremos cómo detectar spyware instalado y cómo evitar la infiltración del mismo en nuestros sistemas.

Virus en Linux

Sun, 09 Nov 2008 23:08:21 +0000

Hace tiempo que existen virus específicos para Linux, como Code Red, X.C o Remote Shell. Este brote virulento contra el sistema del pingüino parece que tira por tierra el mito de la invulnerabilidad de Linux frente a los virus. Sin embargo, siempre que se habla de este tipo de “fauna” informática, se cometen demasiadas incorrecciones que no llevan más que a la completa desinformación del usuario, que a la postre es el mayor perjudicado porque no sabe cómo enfrentarse a este grave problema. La cuestión radica en que ni Linux es invulnerable a piezas de código malicioso ni todos los virus de los que tanto se habla son tales.

Linux es un sistema operativo que cumple con su función tan bien como cualquier otro. Eso implica que un usuario puede ejecutar código para utilizar los recursos de su máquina. Dado que un virus no es más que código ejecutable, aunque con ciertas características especiales como la autorreplicación en ficheros infectados, Linux es potencialmente vulnerable a estos elementos dañinos. Sin embargo, debido al robusto y bien definido sistema de protección de ficheros de Linux, un virus ejecutado como un usuario normal no puede hacer más daño del que le permiten los permisos asignados a dicho usuario, es decir, el sistema queda indemne mientras únicamente los ficheros de dicho usuario son atacados. Obviamente, si se ejecuta el virus como superusuario vamos listos, lo que supone un motivo de peso para utilizar esa cuenta nada más que en las ocasiones que lo requieran necesariamente.

Otra pega más que se encuentra un potencial virus es que no hay un único Linux, ni siquiera una única plataforma hardware sobre la que se ejecuta, lo que limita aún más la expansión del mismo. La consecuencia es que a los autores de virus no les compensa programar código vírico para Linux porque no causa apenas daño.

Sin embargo, Linux puede ser tan vulnerable a los ataques de piratas como cualquier otro sistema operativo. ¿Y qué son todos esos mal llamados virus sino la automatización de dichos ataques? Debido a la naturaleza de esas piezas de código, se trata realmente de gusanos, que van “reptando” por la Red en busca de vulnerabilidades en los sistemas, y de troyanos, en referencia al famoso Caballo y que engañan al usuario bajo una apariencia de programa útil e inocuo, descargando toda su maldad en el sistema del incauto una vez iniciada la ejecución. Ante esto, la mejor defensa es la información puntual acerca de los nuevos programas maliciosos que se expanden por Internet y de cómo atajarlos.

¿Y qué hay de los antivirus para Linux? Pues la mayoría no son ni más ni menos que analizadores de virus para Windows, lo que los convierte en herramientas útiles para el filtrado en servidores de correo electrónico. Afortunadamente ya existen alternativas que detectan gusanos y troyanos para Linux.

En definitiva, debemos mirar con recelo todas las noticias y rumores que hablen de virus para Linux de forma un tanto alegre y sin especificar el tipo de código que realmente son, amén de ofrecer respuestas a la nueva situación creada por el “bichito” en cuestión.