El Spam es uno de los mayores quebraderos de cabeza tanto para los administradores de sistemas como para el usuario final de Internet, y parece q lo seguira siendo durante un tiempo… Centrándonos en el usuario final, gracias a unos simples consejos podemos reducir el correo basura en nuestras cuentas de correo en un porcentaje muy alto.

• Registros en sitios web: La mayor parte de los internautas se registran continuamente en foros, blogs, tiendas y todo tipo de webs online, el resultado suele ser que nuestra dirección de correo electrónico queda almacenada en decenas de bases de datos, para posteriormente (en gran parte de los casos) ser usadas para envío de boletines y/o publicidad.Es recomendable en estos casos tener una dirección de correo electrónico alternativa, y usarla para todos estos registros, de este modo nuestro e-mail habitual quedará libre de este tipo de correos.
• Buzones globales: Este tipo de buzones, también conocido como cuentas atrapalo todo o catch all son uno de los mayores focos de spam. Básicamente, estas cuentas recogen los correos de todas aquellas cuentas de nuestro dominio que reciben emails y no existen.Solución: No utilizar nunca configuraciones de buzón global en nuestras cuentas de correo.
• Filtros en clientes de correo: La mayor parte de clientes de correo (Outlook, Thunderbird…) cuentan con filtros internos para detectar correos basura. Conviene activarlos
• Sentido común: Consejo que se suele presuponer y es desgraciadamente poco habitual. Controla a quién das tu dirección e-mail, evita publicarla en foros, sitios web, mantén limpio de virus, troyanos, spyware y demás tu ordenador…

Como podéis observar, son consejos muy básicos, pero eficaces. ¿Algún consejo para añadir?

Voy a recopilar una serie de entradas que tenía publicadas en otro blog. En esta primera voy a tratar un tema delicado, las operaciones bancarias a través de Internet.

Dejando a un lado el phising (que abarcaría otro artículo completo), muy a menudo escuchamos, ya sea a través de conocidos o por los medios, que suceden graves delitos relacionados con robos de tarjetas y demás información sensible a través de Internet.

Hoy en día gran parte de los internautas realizan compras online, y podríamos asegurar que un porcentaje realmente elevado no toma ninguna medida de seguridad a la hora de hacerlo. Independientemente de la seguridad que nos pueda ofrecer la tienda online, banco o sitio web contra el que realizamos la operación, no servirán de nada sino hacemos lo mismo en nuestro ordenador.

Mis consejos para realizar operaciones bancarias por Internet de forma segura son los siguientes:

Evitar el pago con tarjeta de crédito, utilizar métodos alternativos.

Cuando hablo de métodos alternativos, no solamente me refiero a pagar por transferencia bancaria u otro medio de pago tradicional. El pago por PayPal está muy extendido por las tiendas online (permite la transferencia de dinero entre usuarios que tengan correo electrónico, sin facilitar ningún dato de tus tarjetas de crédito).

Los keylogger son tu mayor enemigo.

Un Keylogger es un tipo de software que se encarga de registrar las pulsaciones que se realizan en el teclado, para memorizarlas en un fichero y/o enviarlas a través de internet. Se propagan como un virus y están muy extendidos en sistemas con Microsoft Windows. Si tu ordenador está infectado con uno, al teclear tu tarjeta de crédito o cualquier otro dato sensible puedes estar enviandolo por Internet a los delincuentes (quienes almacenan miles de datos bancarios para su utilización de forma ilegal).

La principal solución para combatir un Keylogger es la utilización de un buen antivirus, antispyware y demás herramientas, además de mantener actualizado el sistema siempre con los últimos parches de seguridad.

Uso de un Live-CD.

Soy de la opinión de que el punto número 2 no te dará el 100% de garantías de estar limpio de este tipo de malware, así que os recomiendo utilizar un Live-CD cuando vayáis a efectuar compras online, operaciones bancarias, etc.

Definición de Live-CD (Wikipedia):

Es un sistema operativo (normalmente acompañado de un conjunto de aplicaciones) almacenado en un medio extraíble, tradicionalmente un CD o un DVD (de ahí sus nombres), que puede ejecutarse desde éste sin necesidad de instalarlo en el disco duro de una computadora, para lo cual usa la memoria RAM como disco duro virtual y el propio medio como sistema de archivos.

Esta medida nos garantiza que el sistema está limpio de virus y software malicioso siempre que lo utilicemos. Existen gran variedades de Live-CD GNU/Linux que podemos utilizar para esta tarea, muchos de los cuales únicamente arrancan un navegador (Firefox):

• Ubuntu Live CD
• Knopixx
• Webconverger (Sólo contiene firefox).

Hay centenares de LiveCD, GoblinX, Frenzy, Mutagenix, Anonym.OS, CDlinux… tenéis una lista completa aquí.

Despídete de Windows

La última regla y también la más radical. Personalmente os recomiendo el uso de un Live-CD o directamente no utilizar Windows a la hora de realizar operaciones bancarias, manejar y guardar información sensible en el PC, etc.

Los virus en GNU/Linux, BSD o Mac OS X están mucho menos difundidos y tus posibilidades de sufrir este problema serán mínimas o nulas. Sé que esto último es muy complicado, pero por lo menos espero que hagáis caso de alguna de las recomendaciones expuestas en este artículo para evitar males mayores.

En Unix existen tres bits de permisos especiales que pueden ser asignados a directorios y/o ficheros ejecutables, setuid (set user information), setgid (set group information) y sticky.

setuid

EL bit setuid es asignable a ficheros ejecutables, y permite que cuando un usuario ejecute dicho fichero, el proceso adquiera los permisos del propietario del fichero ejecutado. El ejemplo más claro de fichero ejecutable y con el bit setuid el

.

sirve para ejecutar una shell con identificadores de grupo y de usuario distintos al nuestro, por ello ha de tener este bit y así permitir adquirir al usuario temporalmente permisos administrativos para poder hacer el cambio de usuario.

Podemos ver que el bit está asignado (s) haciendo un ls:

$ ls -l /bin/su
-rwsr-xr-x 1 root root 31012 2009-04-04 07:49 /bin/su

Para asignar este bit a un fichero:

# chmod u+s /bin/su

Y para quitarlo:

# chmod u-s /bin/su

Lógicamente, conviene utilizar este bit con extremo cuidado ya que puede provocar una escalada de privilegios en situaciones inseguras. Para que veáis un ejemplo de lo que se podría hacer.

El usuario “alex” no tiene permisos para ejecutar correctamente un fdisk -l:

alex@linux:~$ fdisk -l

La salida es 0, pero si asignamos el bit setuid al binario de fdisk…

# ls -l /sbin/fdisk
-rwsr-xr-x 1 root root 93048 2009-02-18 20:43 /sbin/fdisk

Probamos de nuevo a ejecutar fdisk con el usuario “alex” y conseguimos privilegios de root:

alex@linux:~$ fdisk -l

Disco /dev/sda: 160.0 GB, 160041885696 bytes
255 cabezas, 63 sectores/pista, 19457 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x000c3c51

Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sda1   *           1        3232    25959424    7  HPFS/NTFS
/dev/sda2            3233        9683    51817657+  83  Linux
/dev/sda3            9684        9855     1381590   82  Linux swap / Solaris
/dev/sda4            9856       19457    77128065   83  Linux

Luego nos acordamos de volver a quitarlo:

# chmod u-s /sbin/fdisk

setgid

Si el bit setuid permitía que el proceso adquiriera los permisos del propietario del fichero ejecutado, setgid hace lo mismo pero adquiriendo los privilegios del grupo asignado al fichero, también es asignable a directorios. Este bit entonces será muy útil cuando varios usuarios de un mismo grupo necesiten trabajar con recursos dentro de un mismo directorio.

En el siguiente ejemplo asignamos el bit setgid la carpeta /compartido, le asignamos permisos totales para el propietario y el grupo (770) y el bit segid (2):

$ mkdir compartido && chmod 2770 /compartido

Si hacemos un ls veremos el bit asignado:

$ ls -l
drwxrws--- 2 alex alex      4096 2011-04-24 21:27 compartido

Ahora vamos a hacer la prueba de crear un fichero dentro del directorio. Lo vamos a crear estando autenticados como root, pero al tener el bit setgid le asignará el grupo “alex” en lugar de root.

$ su
# touch test
root@sistemas:/home/alex/compartido# ls -l
total 0
-rw-r--r-- 1 root alex 0 2011-04-24 21:28 test
# whoami
root

En lugar de modo octal podéis asignar también los permisos setgid del siguiente modo:

$ chmog g+s /compartido

Y quitarlo:

$ chmog g-s /compartido

sticky

Este bit suele asignarse en directorios a los que todos los usuarios tienen acceso, y permite evitar que un usuario pueda borrar ficheros/directorios de otro usuario dentro de ese directorio, ya que todos tienen permiso de escritura. Seguro que lo estáis pensando, este bit se asigna siempre en /tmp y /var/tmp.

tmp tiene permisos 777, el bit sticky se asignaría del siguiente modo:

# chmod 1777 /tmp

También así:

chmod o+t /tmp

Y para quitarlo:

chmod o-t /tmp

Si hacemos un ls veremos la “t” asignada:

drwxrwxrwt  13 root root  4096 2011-04-24 20:55 tmp

Esta es una visión general de estos tres bits especiales asignables a ficheros ejecutables y directorios en Unix/Linux.

Con unos sencillos pasos (esta entrada está basada en este artículo de wiki.cpaneldirect.net) es posible integrar el servidor ftp pure-ftpd con el antivirus clamav. Gracias a esto automatizaremos la revisión en busca de virus en todos los ficheros que se suban por FTP.

Lo primero que debemos hacer es instalar clamav. Si el sistema es RHEL, CentOS, etc podemos instalarlo por yum (tendremos que tener el repositorio DAG):

# yum install clamav

Damos por supuesto que pure-ftpd está instalado y configurado, así que entramos directamente en materia. Lo primero es modificar la configuración de pure-ftpd y habilitar la llamada de scripts cuando se realicen subidas al servidor:

# vim /etc/pure-ftpd.conf

Descomentamos la línea CallUploadScript yes:

# If your pure-ftpd has been compiled with pure-uploadscript support,
# this will make pure-ftpd write info about new uploads to
# /var/run/pure-ftpd.upload.pipe so pure-uploadscript can read it and
# spawn a script to handle the upload.

CallUploadScript yes

Ahora tenemos que modificar el script de arranque de pure-ftpd para añadir la llamada al binario encargado de esta tarea (pure-uploadscript).

Justo debajo de la línea (sección START):

$DAEMONIZE $fullpath /etc/pure-ftpd.conf -O clf:/var/log/xferlog $OPTIONS --daemonize

Añadimos:

$DAEMONIZE /usr/sbin/pure-uploadscript -B -r /var/run/pure-ftpd/clamscan.sh

Y justo debajo de esta (sección STOP):

kill $(cat /var/run/pure-ftpd.pid)

Añadimos esta:

kill $(cat /var/run/pure-ftpd/pure-uploadscript.pid)

Ahora creamos el script encargado de revisar los ficheros en busca de virus, lo llamaremos /var/run/pure-ftpd/clamscan.sh, y contendrá lo siguiente.

#!/bin/sh

# /usr/local/bin/clamdscan is faster if clamd is running
CLAMLOC='/usr/local/bin/clamscan';

if [ ! -x $CLAMLOC ]; then
        echo 'clamscan not found';
        exit;
fi
if [ "$1" = "" ]; then
        echo 'Variable is blank';
        exit;
fi
if [ ! -f "$1" ]; then
        echo "$1 file not found"
        exit;
fi

# maybe you would prefer --move=/DIRECTORY instead of remove
$CLAMLOC --remove $1

Como podéis ver, en este script los ficheros que se detecten como maliciosos se eliminan, si queremos que los mueva a una ruta distinta en lugar de borrar usamos –move=/DIRECTORY.

Personalmente veía de gran utilidad que me avisara por correo electrónico, así que podéis usar esta variación del script si queréis en la que el fichero no se toca y si se detecta que es un virus se avisa por correo:

#!/bin/bash
# /usr/local/bin/clamdscan is faster if clamd is running
CLAMLOC='/usr/bin/clamscan';

if [ ! -x $CLAMLOC ]; then
        echo 'clamscan not found';
        exit;
fi
if [ "$1" = "" ]; then
	echo 'Variable is blank';
	exit;
fi
if [ ! -f "$1" ]; then
	echo "$1 file not found"
	exit;
fi
EMAIL="test@micorreo.com"  # Aqui pon tu dirección de correo electronico

# maybe you would prefer --move=/DIRECTORY instead of remove
$CLAMLOC $1 2>/dev/null | grep "FOUND"
if [ "$?" == "0" ]; then
        echo "Script $1 subido por $UPLOAD_USER." | mail -s "[$(hostname)] Upload de fichero malicioso" $EMAIL
fi

Modificamos los permisos del script a 755:

# chmod 755 /var/run/pure-ftpd/clamscan.sh

Y reiniciamos pure-ftpd:

# /etc/init.d/pure-ftpd restart

Ahora solo queda esperar o probar, podéis subir por FTP un fichero malicioso (shell en php, código ofuscado, etc) para verificar el funcionamiento.

El otro día aprendimos a securizar la gestión de claves en Linux mediante PAM, pero olvidé comentar un punto importante dentro de la gestión de contraseñas en un sistema GNU/Linux, se trata de la caducidad y expiración de claves de usuario.

Mediante passwd podemos forzar que la clave de un usuario caduque pasados X días., Así mismo, también podemos configurar el número de días que el usuario será avisado antes del cambio obligado de clave y el número de días una vez pasado este límite hasta que la cuenta se desactive.

Estos tres parámetros son los siguientes:

-x, --maxdays DÍAS_MÁX        establece a DÍAS_MÁX el número máximo de días antes del cambio de la contraseña
-w, --warndays DÍAS_AVISO     establece los días de aviso de expiración a DÍAS_AVISO
-i, --inactive INACTIVO       establece la inactividad de la contraseña tras su expiración a INACTIVO

Vamos a poner un ejemplo, si quisieramos que la clave del usuario “pruebas” caducara pasados 180 días, que le avisara durante los cinco últimos días de validez de la clave, y que si tras pasados 15 días sin modificar la clave se bloqueara, utilizaríamos la siguiente línea de comandos:

# passwd pruebas -x 180 -w 5 -i 15

Linux-PAM es un módulo del kernel Linux que permite configurar y personalizar el modo en el que se generan y mantienen las claves de usuarios dentro del sistema. En esta entrada vamos a centrarnos en como conseguir que los usuarios de un sistema Linux tengan claves seguras.

Básicamente, lo que vamos a hacer es forzar al usuario a que cumpla ciertos requisitos a la hora de crear o cambiar una clave, por ejemplo que la clave tenga un mínimo de caracteres, que contenga símbolos, números o letras mayúsculas, evitar que repitan las mismas claves, etc.

En sistemas CentOS, RHEL y derivados, esta gestión la hacemos dentro del fichero de configuración de PAM /etc/pam.d/system-auth, en Debian creo recordar que era en el fichero /etc/pam.d/common-password.

En CentOS, encontraremos una línea que contendrá lo siguiente (entre otros parámetros):

password    requisite     pam_cracklib.so .......

En dicha línea podemos añadir los parámetros correspondientes para securizar el sistema de claves, en el siguiente ejemplo hemos añadido que el mínimo de caracteres sea 6 (minlen), que sea obligatorio un símbolo (ocredit) y una letra mayúscula (ucredit):

password    requisite     pam_cracklib.so try_first_pass retry=3 minlen=6 ocredit=-1 ucredit=-1

Otros parámetros son por ejemplo remember=N que indica el histórico de claves a revisar para evitar que repitan la misma clave. Recomiendo revisar la documentación de este módulo en www.kernel.org para exprimir y encontrar todas sus posibilidades.

Como requisito hay que tener el siguiente paquete instalado en el sistema:

cracklib.i386 : biblioteca para el control de las contraseñas.

NOTA: Hay que tener en cuenta que todos estos parámetros no tienen efecto cuando cambiamos las claves con el usuario root, solo se aplican cuando se cambian desde el resto de usuarios.

Hoy vamos a ver como conseguir establecer conexiones cifradas mediante SSH (Openssh) a protocolos/servicios que no están sirviendo su tráfico encriptado. La mayoría de vosotros sabréis que es sencillo “esnifar” el tráfico dentro de una misma red, gracias a este encapsulamiento de tráfico (que es muy sencillo) podemos cifrar el tráfico entre dos equipos independientemente de que el servicio lo ofrezca sin ningún tipo de cifrado. Eso sí, hay que tener conexión vía ssh al servidor destino.

Vamos a verlo con ejemplos ya que resulta más sencilla la explicación de este modo. Pongamos el caso de que queremos conectar de forma segura al sitio web http://test.com. Este sitio web no sirve el contenido por protocolo seguro así que todo el tráfico se podrá visualizar sin problemas desde cualquier equipo de esta red local, por ejemplo con el programa Wireshark (analizador de protocolos de red) lo podemos verificar.

Primero accedemos directamente desde el navegador desde http://test.com, el analizador de tráfico muestra todos los paquetes de información sin cifrar:

Ahora, lo que vamos a hacer es crear un tunel de cifrado entre las dos máquinas. Utilizaremos el puerto local 9999 para servir el contenido que previamente encapsulamos por conexión segura desde el servidor que sirve todos los datos (test.com). Para ello creamos una conexión SSH al servidor destino y creamos un tunel entre nuestro puerto 9999 local y el puerto remoto 80 (http):

# ssh alex@test.com -L 9999:pruebas.com:80 -N

Nota: si queréis que el proceso quede en segundo plano y no aparezca la shell ssh en la consola debéis usar el parámetro

.

hace que no se puedan ejecutar comandos SSH en el servidor remoto.

Ahora, podemos acceder al mismo sitio web (http://test.com) desde nuestro equipo, de forma local a través del puerto 9999. Simplemente ponemos en el navegador:

http://localhost:9999

Vemos que efectivamente, al acceder de este modo estamos sirviendo el mismo contenido pero esta vez completamente cifrado:

Una vez conocida la sintaxis del tunneling (

) podemos aplicar este mismo recurso a cualquier otro servicio (http, ftp, smtp, pop).

Como información extra os dejo una excelente explicación de Tunel SSH poor parte de la Wikipedia:

El protocolo SSH (secure shell) se utiliza con frecuencia para tunelizar tráfico confidencial sobre Internet de una manera segura. Por ejemplo, un servidor de ficheros puede compartir archivos usando el protocolo SMB (Server Message Block), cuyos datos no viajan cifrados. Esto permitiría que una tercera parte, que tuviera acceso a la conexión (algo posible si las comunicaciones se realizan en Internet) pudiera examinar a conciencia el contenido de cada fichero trasmitido.
Para poder montar el sistema de archivo de forma segura, se establece una conexión mediante un túnel SSH que encamina todo el tráfico SMB al servidor de archivos dentro de una conexión cifrada SSH. Aunque el protocolo SMB sigue siendo inseguro, al viajar dentro de una conexión cifrada se impide el acceso al mismo.
Por ejemplo, para conectar con un servidor web de forma segura, utilizando SSH, haríamos que el cliente web, en vez de conectarse al servidor directamente, se conecte a un cliente SSH. El cliente SSH se conectaría con el servidor tunelizado, el cual a su vez se conectaría con el servidor web final. Lo atractivo de este sistema es que hemos añadido una capa de cifrado sin necesidad de alterar ni el cliente ni el servidor web.

En caso de que ClamAV haya sido instalado a través de un gestor como YUM o APT no deberíais tener problema, porque automáticamente debería haberse añadido un cron diario o semanal que haga esta tarea de forma periódica.

En caso contrario, para actualizar la base de datos de ClamAV se utiliza el comando freshclam. Ejecutado tal cual debería funcionar correctamente, aunque como es normal se puede personalizar su ejecución mediante parámetros.

El script que se añade al cron.daily por defecto instalando por yum es el siguiente. Podéis crearlo dentro de /etc/cron.daily para que se ejecute a diario:

#!/bin/sh

### A simple update script for the clamav virus database.
### This could as well be replaced by a SysV script.

### fix log file if needed
LOG_FILE="/var/log/clamav/freshclam.log"
if [ ! -f "$LOG_FILE" ]; then
    touch "$LOG_FILE"
    chmod 644 "$LOG_FILE"
    chown clamav.clamav "$LOG_FILE"
fi

/usr/bin/freshclam \
    --quiet \
    --datadir="/var/clamav" \
    --log="$LOG_FILE" \
    --daemon-notify="/etc/clamd.conf"