Archivo de la etiqueta: gnu/linux

Conectarse a un servidor ssh inaccesible atravesando otro servidor ssh intermedio

Estoy en casa cuando repentinamente recuerdo que dejé una tarea pendiente en la oficina para la cuál necesito acceder a mi equipo. Es viernes por la tarde y la inminente llegada del fin de semana representa un problema: en la oficina ya todos se fueron y nadie en su sano juicio regresaría para terminar el trabajo. Por suerte, estoy consciente de que la computadora está encendida y el servidor ssh está corriendo. Pero claro, cómo acceder remotamente cuando la máquina no es accesible desde Internet. La buena noticia es que hay un servidor en la red al que sí puedo conectarme por ssh desde casa y desde allí ingresar al equipo.

Este tipo de escenarios, que a mi me gusta llamar SSH Multi-Huésped, es algo común entre los administradores de sistemas y existen muchos métodos para resolver la conexión: desde un rudimentario, inseguro e ineficiente direccionamiento de puertos hasta una conexión ssh en escalas, algo así:

usuario@casa$ ssh usuarioservidor@servidor
Password for usuarioservidor@servidor:
Last login: Fri Dec  2 17:01:43 2016 from 'ip_casa'

usuarioservidor@servidor$ ssh usuariooficina@oficina
Password for usuariooficina@oficina:
Last login: Fri Dec  2 17:02:15 2016 from 'ip_servidor'

usuariooficina@oficina $

Está claro que no es la manera que una administrador de sistemas usaría. La alternativa es habilitar el direccionamiento del agente a través de los equipos y pasarle la opción -t para forzar la asignación de una pseudo-tty para contar con una shell interactiva.
 

usuario@casa $ ssh -A -t usuarioservidor@servidor ssh -A usuariooficina@oficina
Password for usuarioservidor@servidor:
Password for usuariooficina@oficina:
Last login: Fri Dec  2 17:05:39 2016 from 'ip_casa'

usuariooficina@oficina $

Bonito ¿no? No, es horrible. Basta imaginar que el camino entre el equipo de mi casa y el de la oficina tuviera tres o cuatro máquinas intermedias. Ni hablar si lo que buscamos es copiar un archivo desde un extremo al otro con scp. Sin duda, estos métodos carecen de toda elegancia. Lo que yo necesito es realizar esta operación de una manera simple, transparente y eficiente.

Para esto contamos con dos herramientas: por una lado, tenemos netcat (Netcat – Wikipedia, la enciclopedia libre), que debe estar instalado en las máquinas intermedias; por otro, la opción ProxyCommand habilitada en nuestro cliente ssh. Para configuralo, hay que añadir algunas líneas al final del archivo de configuración /etc/ssh/ssh_config en el equipo desde el cual iniciamos la conexión.
 

usuario@casa $ sudo nano /etc/ssh/ssh_config

/etc/ssh/ssh_config

[…]
Host oficina
User usuariooficina
HostName oficina
Port 22
ProxyCommand ssh -q usuarioservidor@servidor nc %h %p

Para explicar un poco el contenido agregado al archivo:
Host es un nombre arbitrario que nos servirá para identificar fácilmente el huésped al que buscamos conectarnos
User, Hostname y Port representan las variables que netcat usará para conectar los húespedes
ProxyCommand: aquí se ejecuta el comando requerido para iniciar la conexión. La opción -q (quiet mode) suprime los mensajes de advertencia y diagnóstico; nc ejecuta netcat propiamente dicho y los valores %h y %p se obtienen de User-HostName y Port respectivamente

 

usuario@casa $ ssh oficina
Password for usuarioservidor@servidor:
Password for usuariooficina@oficina:
Last login: Fri Dec  2 17:10:05 2016 from 'ip_casa'

usuariooficina@oficina $

El procedimiento es simple y transparente. Como es natural, la cadena de equipos intermedios puede poseer más de un huésped y por supuesto, es posible configurar un sin número de conexiones diferentes. Además, con este método es posible la copia de manera sencilla de archivos desde y hacia el equipo remoto con scp, el uso del protocolo sftp, la conexión a través del gestor de archivos y como si esto fuera poco, podemos dirigir aplicaciones gráficas a través de X-forwarding. Aquí algunos ejemplos:

usuario@casa $ scp oficina:/ruta/archivo_remoto /ruta/archivo_local
Copia del archivo_remoto desde el equipo en la oficina hacia la máquina en casa.

 

usuario@casa $ ssh -X oficina pcmanfm
Ejecutando el gestor de archivos pcmanfm del equipo en la oficina en la máquina en casa a través de X-forwarding.

 

De esta manera me ocupo de terminar el trabajo pendiente y me dispongo a disfrutar de una tarde de viernes como es debido.
 

Tor+Privoxy en GNU/Linux con OpenRC

Quienes usamos OpenRC sabemos que al momento de instalar un paquete debemos tener en cuenta que por lo general existe una versión específica para este init. Además, en muchos casos no alcanza simplemente con instalar el paquete correspondiente, sino que también los archivos de configuración suelen requerir diferentes parámetros.

Este es el caso del sistema de enrutamiento por capas TOR, el que habitualmente instalo junto a Privoxy para integrarlo como una cadena de proxys.

Dado que actualmente uso Manjaro OpenRC, los comandos están enfocados en esta distribución.
$ sudo pacman -S tor-openrc privoxy-openrc proxychains torsocks lynx
Instalo los paquetes necesarios en su versión para OpenRC y además añado proxychains y torsocks para integrar los proxys al uso en consola de comandos.

Posteriormente, se edita el archivo de configuración de Privoxy, indicándole la dirección ip de escucha y añadiendo al final del archivo la línea de encadenamiento al proxy socks.

$ sudo nano /etc/privoxy/conf

/etc/privoxy/conf

[…]
listen-address 127.0.0.1:8118
[…]
forward-socks5 / 127.0.0.1:9050 .

Luego, hay que trabajar sobre la configuración de TOR. Para esto, se hace una copia de seguridad del archivo original y se crea un nuevo archivo que contenga las líneas requeridas para que OpenRC gestione el daemon.

$ sudo mv /etc/tor/torrc.bck

$ sudo nano /etc/tor/torrc

/etc/tor/torrc

User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
DataDirectory /var/lib/tor/data

Sólo resta añadir los servicios al inicio y arrancarlos.

$ sudo rc-update add tor default

$ sudo rc-update add privoxy default

$ sudo sudo service tor start

$ sudo service privoxy start

Por último, comprobamos que todo funciona correctamente.

$ proxychains lynx check.torproject.org 
Congratulations. This browser is configured to use Tor.
This page is also available in the following languages: [English____________________] Go

Congratulations. This browser is configured to use Tor.

Your IP address appears to be: xxx.xxx.xxx.xxx

Cifrado extremo en GNU/Linux (Segunda Parte)

Lo prometido es deuda y llega la Segunda Parte de este artículo sobre cifrado en GNU/Linux. En la entrada anterior escribí acerca de cifrado de datos en el disco duro y realicé una simulación sencilla para ayudarnos a entender un poco mejor cómo efectuar las tareas de cifrado utilizando las herramientas más comunes. Y aunque este tipo de cifrado digamos “local” es muy importante, hoy por hoy para casi todo lo que hacemos en nuestros equipos utilizamos una conexión a Internet y, por lo tanto, los datos e información transmitidos pueden ser interceptados por alguna persona, empresa, organismo gubernamental o simplemente un “bot” que esté a la espera de obtener algo valioso de nosotros. La necesidad de cifrar los datos que viajan a través de las redes es evidente. Esta vez escribiré acerca de esto, es decir, qué tratamiento en términos de cifrado debemos darle a las operaciones de navegación, correo electrónico, comunicación y conectividad en general.

Evitando filtraciones en las peticiones DNS

Cuando realizamos una petición DNS los datos transmitidos, tanto de ida como de vuelta, no siempre son anónimos ni están cifrados de manera predeterminada, independientemente si usamos Tor para navegar o si estamos visitando un sitio con seguridad SSL/TLS (https). Dado que las peticiones DNS representan uno de los principales eslabones de la cadena en una conexión web, es importante asegurarnos que los datos transmitidos sean cifrados. Para esto contamos con una herramienta muy útil: dnscrypt.

Dnscrypt funciona de manera análoga a un proxy, cifrando el intercambio de datos entre nuestro equipo y los servidores DNS.

Petición DNS (sin cifrar) -> dnsmasq -> dnscrypt (cifrado) -> Servidor DNS cifrado

Ahora bien, para implementar esta herramienta iremos a nuestra consola de comandos.

Como es habitual en el blog, trabajaré en Archlinux o derivadas.
$ sudo pacman -S dnscrypt-proxy dnsmasq

$ sudo nano /etc/resolv.conf

/etc/resolv.conf

# nameserver ip_servidor_dns_publico
# nameserver ip_router
nameserver 127.0.0.1

$ sudo chattr +i /etc/resolv.conf
En primera instancia, instalamos los paquetes necesarios. Luego, editamos el archivo /etc/resolv.conf comentando todas las líneas que apuntan a servicios DNS y agregamos la línea al final, de manera que las peticiones DNS se realicen de manera local, es decir, en el propio equipo o localhost. Luego de guardar el archivo, cambiamos sus atributos a sólo lectura para evitar que el gestor de conexiones de red (NetworkManager) sobre-escriba la configuración después de un reinicio. Si además hemos agregado DNS desde la interfaz gráfica de NetworkManager debemos borrarlos.
$ sudo systemctl enable dnscrypt-proxy

$ sudo systemctl edit dnscrypt-proxy.socket --full

dnscrypt-proxy.socket

[…]
[Socket]
ListenStream=127.0.0.1:40
ListenDatagram=127.0.0.1:40
[…]

Habilitamos el servicio y editamos el archivo del Socket en SystemD. Apuntamos al puerto #40 debido a que dnsmasq utiliza por defecto el puerto #53.
Por defecto, dnscrypt utilizara “dnscrypt.eu-nl” como servidor DNS externo. En caso que deseemos cambiar este servidor, debemos editar la unidad de servicio de SystemD de la siguiente manera.
$ systemctl edit dnscrypt-proxy.service --full

dnscrypt-proxy.socket

[…]
[Service]
[…]
-R nombre_del_servidor_DNS
[…]

Un listado de los servidores disponibles con sus características se encuentra en /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv.
$ sudo nano /etc/dnsmasq.conf

/etc/dnsmasq.conf

[…]
no-resolv
server=127.0.0.1#40
listen-address=127.0.0.1
[…]

Editamos el archivo de configuración de dnsmasq de manera que las peticiones sean redirigidas hacia dnscrypt. Luego, habilitamos e iniciamos los servicios en SystemD.
$ sudo systemctl restart dnscrypt-proxy.service

$ sudo systemctl enable dnsmasq

$ sudo systemctl start dnsmasq

$ sudo systemctl restart NetworkManager.service

 

Con esto bastará entonces para cifrar todo el tráfico DNS redirigiendo las peticiones a través de dnscrypt. Si deseamos realizar una prueba del funcionamiento, podemos ir al sitio https://dnsleaktest.com y ejecutar una Prueba Extendida. Además, si utilizamos Wireshark y ejecutamos un filtro con la dirección IP del servidor DNS externo, podremos verificar que la conexión está siendo cifrada.

Preparar y configurar tu navegador web

La mayoría de los navegadores soporta complementos o extensiones que nos permiten mejorar nuestra experiencia en la web. Muchos de estos complementos están enfocados en la seguridad y el cifrado. Por ejemplo, si sos de los que usan Firefox, seguramente tendrás instalado HTTPS-Everywhere, SSleuth. Descentraleyes, Greasemonkey con scripts tales como HTTP-to-HTTPS redirector o Green SSL Password Fields, entre otros.

Prestar atención al tipo de seguridad y cifrado que ofrecen los sitios por los que navegamos se vuelve una tarea imprescindible cuando se trata, por ejemplo, de la página de Banca en Línea del Banco, sitios de compras online, proveedor de correo electrónico con interfaz web y tantos otros sitios donde administramos información sensible.

Cifrado de correo electrónico y chat

GPG (GNU Privacy Guard) es sin duda la herramienta por excelencia para cifrado de correo electrónico y conversaciones de chat sobre XMPP en GNU/Linux, aunque eso no es todo, ya que permite cifrar el contenido de directorios y archivos, además de servir para gestionar claves y firmas de paquetes y medios de instalación (ISO’s) de distribuciones. Como si esto fuera poco, si tenés un gestor, depósito o cartera de contraseñas, podés cifrar esas claves mediante GPG.

En general, los clientes más comunes de correo electrónico y chat permiten configurar el agente para GPG por defecto, de manera que cada vez que redactemos un correo el propio cliente nos permitirá definir si este mensaje será cifrado y/o firmado o bien cuando recibamos un correo cifrado, el agente se encargará de descifrarlo para nosotros. En cuanto a los clientes de chat, habitualmente aparece un ícono con la forma de un candado para activar el cifrado de la conversación en la que nos encontramos.

Por su parte, las claves y firmas GPG en nuestro sistema pueden ser administradas con la herramienta homónima desde la consola o bien con un cliente GPG con interfaz gráfica como Kleopatra (orientado al entorno de escritorio KDE) que incluye integración para el gestor de archivos Dolphin, facilitando el cifrado de archivos.

Extra: el uso de una VPN

Las Redes Privadas Virtuales son una herramienta muy poderosa cuando de privacidad y anonimato se trata. Por supuesto, esto dependerá del servicio que utilicemos, cuya oferta es muy variada en cuanto a precio y prestaciones. Sin embargo, la mayoría de los servicios de pago más serios garantizan dos principios fundamentales. En primer lugar, al redirigir todo el tráfico que sale y llega a nuestro equipo a través de estas redes, nuestra dirección IP pública quedará “enmascarada” detrás de la VPN, manteniéndonos anónimos. En segundo lugar y no menos importante, una VPN cifrará los datos mediante el uso de algunos de los métodos que la mayoría conoce, a saber SSL/TLS, PPTP, L2TP, entre otros.

Por otra parte, gracias a proyectos como OpenVPN, podemos montar nuestro propio servidor para estos fines, teniendo el control completo del servicio y sus prestaciones, lo que representa una ventaja notable.

Extra extra: cifrado en teléfonos

Los dispositivos móviles del tipo Android, o su alternativa Cyanogenmod traen por defecto soporte para cifrado completo de los datos del equipo. Por su parte, dnscrypt nos explica en su sitio web cómo usar su herramienta para teléfonos de esta clase, pero en mi caso particularmente, no he tenido tiempo de probarlo, por lo que no entraré en detalles sobre esto. Lo que sí haré será darles una lista de algunas de las herramientas que uso en mi equipo con Cyanogenmod y que se encuentran en los repositorios de F-Droid, a saber:

  • OpenKeychain (GPLv3+): cliente para OpenPGP con integración para K-9 Mail, Conversations, oandbackups, cifrado y firmado de archivos, y más
  • OpenVPN for Android (GPLv2): cliente para gestionar conexiones VPN
  • K-9 Mail (Apache2): cliente de correo electrónico. Permite configurar OpenKeychain como agente GPG predeterminado
  • Conversations (GPLv3): cliente para XMPP. Además de OpenPGP tiene soporte para Cifrado end-to-end con OTR y OMEMO
  • Twik (GPLv3): aplicación que funciona como asistente para generar y almacenar contraseñas seguras
  • Silence (GPLv3): aplicación para enviar mensajes SMS cifrados

Dejaré el cliente de mensajería instantánea Telegram fuera de la lista debido a que, si bien es una aplicación libre (GPLv2+) con cifrado end-to-end, los servicios y protocolos detrás de la aplicación y que por lo tanto la hacen funcionar no son libres.

Bien, hasta acá el artículo. Seguramente habrán muchas cosas que quedaron en el tintero. Por razones de tiempo y espacio he decidido abreviar tanto como pude. Quedaré atento a sus sugerencias y comentarios. Recordemos que la fuerza y la grandeza de GNU/Linux está en la comunidad y son ustedes los que tienen la oportunidad de ampliar y mejorar esta entrada. Siéntanse en libertad de hacerlo.

Cifrado extremo en GNU/Linux (Primera Parte)

Si bien es cierto que el tema de cifrado está muy de moda en estos tiempos, también es cierto que me apasiona todo lo referido al mismo y por eso me debía un artículo al respecto. Si has leído alguna de mis publicaciones anteriores ya sabés que la seguridad, la privacidad, el anonimato son prioridades en mi vida por las redes y la informática y me gusta pensar y actuar en este sentido. Por lo tanto, cifro tanto como puedo y si no puedo, también lo cifro. De ahí, el título de este artículo: en esta entrada voy a hacer un recorrido por las distintas etapas del proceso y las herramientas que uso para un cifrado de pies a cabeza en un sistema operativo GNU/Linux.

Etapa 0: pensar antes de actuar

Antes de empezar a meter dedo en el teclado es muy importante tomarse un tiempo para definir objetivos. Esto permitirá optimizar tiempos, elegir las herramientas adecuadas y tener resultados de calidad. Para esto conviene que tengamos claridad respecto de los ataques a los que podemos estar expuestos, el tipo de dispositivo que estamos cifrando (laptop, escritorio, móvil) y el destino o uso que le damos a este dispositivo (servidor, uso hogareño, trabajo).

Por ejemplo, el cifrado que necesitamos en una computadora de escritorio que tengamos en casa no tiene por qué ser el mismo (aunque puede serlo) que para una máquina de las mismas características pero que está en nuestro lugar de trabajo y que compartimos con otros usuarios. Por otro lado, también podemos hacer una distinción si el equipo en casa sólo lo usamos para navegar o escuchar música o si lo usamos para guardar documentos con información de tipo sensible, como documentos legales. Insisto, podremos usar el mismo cifrado, pero no necesariamente debemos hacerlo.

Por lo tanto, en esta etapa de planificación cabrá hacerse preguntas del tipo: ¿Contra qué clase de ataques deseamos protegernos? ¿Cuál será la estrategia apropiada para cifrar? ¿Cómo trataremos los datos temporales como el espacio de intercambio (swap), logs, etcétera? ¿Qué trato se le dará a un sistema con múltiples usuarios? ¿Cómo y en qué momento se accederá a los datos cifrados?

Etapa 1: cifrado total o parcial de un disco duro o de una partición de disco duro

Cifrar el disco duro y los datos de usuarios es primordial para proteger nuestra privacidad. La principal ventaja de cifrar un disco o partición de disco radica en que impide el acceso físico no autorizado a los datos contenidos en dicho dispositivo y su manipulación. Las herramientas que disponemos para realizar este tipo de cifrado están categorizadas de varias maneras. En cuanto a mí, tengo preferencia por dos de ellas: ecryptfs para cifrar directorios y archivos; dm-crypt para cifrar un disco duro completo o alguna de sus particiones.

Por otra parte, muchas distribuciones GNU/Linux como Manjaro, openSUSE, CentOS, Debian y Ubuntu, por nombrar sólo algunas, nos dan la oportunidad de configurar características de cifrado del sistema, particiones y datos de usuario (/home) directamente al el momento de la instalación. En mi opinión esto es algo fantástico y lo he utilizado siempre al trabajar con este tipo de distribuciones.

De manera entonces que no quedan excusas para proteger nuestros datos y nuestro sistema, basta con elegir un método, las herramientas y poner manos a la obra. A continuación voy a realizar una simulación a modo de ejemplo para la cual escogí a Manjaro como distribución. Digamos entonces que ya instalé el sistema escogiendo las opciones de cifrado de mi preferencia quedando mi configuración de la siguiente manera:

/dev/sda1: partición de arranque (/boot) sin cifrar

/dev/sda2: partición raíz (/), cifrada con LUKS

/dev/sda3: directorio de datos de usuario (/home). En este caso lo dejo sin cifrar para hacerlo luego utilizando la herramienta ecryptfs.

/dev/sda4: espacio de intercambio (swap). También quedará sin cifrar en este momento, ya que trataré este punto en la etapa siguiente.

Ahora bien, he iniciado el equipo, ingresé la clave de cifrado para el sistema y estoy en la pantalla del gestor de inicio, esperando para ingresar la contraseña. Lo primero que haremos una vez iniciada la sesión será instalar las actualizaciones del sistema para tenerlo a la fecha para luego buscar e instalar los paquetes necesarios. Abrimos una consola de comandos y ejecutamos:

$ sudo pacman-mirrors -g && sudo pacman -Syy

$ sudo pacman -S manjaro-keyring archlinux-keyring

$ sudo pacman -Syu
(Este comando lo ejecutamos cuando iniciamos Manjaro por primera vez. Lo que hace es: optimizar la lista de mirrors, actualizar la base de datos de repositorios, instalar las claves y firmas de Manjaro y Archlinux, actualizar el sistema)
$ sudo pacman -S ecryptfs-utils keyutils rsync lsof
(Notaremos que estos paquetes ya vienen instalados en Manjaro)

Ahora ya estamos listos para cifrar el directorio /home de nuestro usuario. Para esto, cerramos la sesión de escritorio y abrimos una sesión en tty2 presionando Ctrl+Alt+F2 iniciando como usuario root:

tty2

hostname login: root
Password: ******************
Last Login […]

# killall -u usuario && ps -U usuario
(Es necesario que el usuario a quien vamos a cifrar su directorio /home no tenga ningún proceso en ejecución y que dicho directorio no esté montado)

El siguiente paso consiste en asegurarnos que el nuevo directorio /home cifrado será desbloqueado y montado al momento de que el usuario inicie sesión y no posteriormente como si se tratara de un directorio cualquiera. Para esto, modificaremos el archivo “/etc/pam.d/system-auth” de la siguiente forma:

# nano /etc/pam.d/system-auth

/etc/pam.d/system-auth

Posterior a la línea “auth required pam_unix.so” escribimos

auth     required pam_ecryptfs.so     unwrap

Arriba de la línea “password required pam_unix.so” escribimos

password     optional      pam_ecryptfs.so

Posterior a la línea “session required pam_unix.so” escribimos

session     optional      pam_ecryptfs.so     unwrap

Guardamos y cerramos el archivo

Finalmente, nos encontramos en condiciones de cifrar el directorio:

# modprobe ecryptfs

# ecryptfs-migrate-home -u usuario
Passphrase: ************
(Cargamos el módulo y realizamos la migración a un directorio cifrado. Este proceso puede tomar mucho tiempo dependiendo de la cantidad del tamaño del directorio) (Es muy importante que la Passphrase sea la misma que la clave de inicio de sesión del usuario. Esto servirá para que desbloquee el directorio en forma automática al iniciar sesión)
(Finalizado el proceso, cerramos la sesión y cambiamos a tty1 con Ctrl+Alt+F1 e iniciamos sesión normalmente con el usuario)  (Durante el proceso, ecryptfs hará una copia de seguridad creando un directorio /home/usuario.datos_aleatorios el cual puede ser borrado una vez verificado que todo esté en su lugar)

Hasta acá hemos realizado una instalación en limpio de una distribución GNU/Linux cifrando el directorio raíz al momento de configurar las particiones y luego hemos cifrado el directorio /home/usuario para proteger los datos allí almacenados. Hemos iniciado sesión con este usuario y hemos verificado que esté todo funcionando correctamente. Ahora podremos reiniciar el sistema y pasar a la próxima etapa del proceso…

Etapa 2: tratamiento del espacio de intercambio

En términos muy simples, el espacio de intercambio o swap corresponde a una porción del disco donde van siendo descargados datos temporales desde la memoria de lectura del sistema. Aquí van quedando almacenados datos muy sensibles, como por ejemplo credenciales de sitios web, contraseñas y más. No hay que pensar demasiado para notar las amenazas a la privacidad y la importancia que representa cifrar esta información, sobre todo si consideramos que al hibernar o suspender un equipo, todo va a parar a swap.

Siguiendo con la simulación anterior, vamos ahora a proceder con el cifrado de esta partición. Para esto, simplemente ejecutaremos:

$ sudo ecryptfs-setup-swap -f
(El script modificará el archivo /etc/fstab comentando las líneas que tengan particiones swap automontadas y añadiendo al final “/dev/mapper/cryptwap1 none swap sw 0 0” para montar la nueva partición swap cifrada)
(Además, modificará el archivo /etc/cryptswap añadiendo la línea “cryptswap1 UUID=id_de_la_particion_swap /dev/urandom swap,offset=1024,cipher=aes-xts-plain64”)
$ swapon -s
(Verificamos que haya quedado cifrado correctamente)
Nombre del fichero   Tipo        Tamaño    Utilizado  Prioridad
/dev/dm-1            particion   2097180   164        -1

Breve Pausa: gestión de contraseñas

Aunque las he nombrado a lo largo de toda la entrada, es el momento de hacer una pausa y dedicarle un apartado especial a las contraseñas. Muchos estudios se han realizado al respecto y se ha encontrado que la mayoría de las personas utilizan claves que son muy fácilmente desbloqueables, como por ejemplo la misma palabra que describe al usuario o al sistema operativo (algo así como usuario: root, contraseña: manjaro), fechas de nacimiento, nombre de sus hijos o mascotas y un largo etcétera. Sumado a esto, muchas personas utilizan la misma clave para todo, quizá con algún pequeño cambio.

De nada servirá que cifremos si vamos a utilizar contraseñas de este tipo. Para que cualquier acción que tomemos con el fin de proteger nuestra privacidad y nuestra información tenga sentido debemos utilizar contraseñas fuertes. Mi recomendación al respecto es generar claves de muchos dígitos, en especial si la cantidad es un número primo (19, 31). Además, esta contraseña debe ser una combinación de letras, números y caracteres especiales (siempre que lo permita) y estos números no deben remplazar letras: la clave “milanesasconpure” es tan mala como “m1l4n3545c0n9ur3”.

Claro, una contraseña de las características descritas es muy difícil de recordar. Para ayudarnos tenemos algunos métodos, como por ejemplo, usar una contraseña que responda a los movimientos para piano de una melodía especial. Otra forma que muchos utilizan es cifrar también sus contraseñas mediante el uso de una aplicación específica para estos fines, de manera que sólo debemos recordar una única contraseña maestra que sirve para desbloquear (individualmente) las contraseñas cifradas.

Etapa 3: archivos y directorios

Pues bien, ya hemos hablado de las contraseñas y toca ahora que veamos cómo crear un directorio Privado donde podremos almacenar datos de manera cifrada y que, al contrario del cifrado completo del directorio /home, este será desbloqueado y montado sólo al momento en que lo necesitemos para luego ser desmontado nuevamente. Esto nos permitirá tener estos datos resguardados mientras utilizamos el equipo, impidiendo el acceso físico y remoto no autorizado a los mismos. Comenzaremos como siempre, abriendo una consola y ejecutando:

$ ecrytpfs-setup-private --nopwcheck --noautomount
Este script creará los directorios ocultos ~/.Private y ~/.ecryptfs (sin no existen previamente). La opción –nopwcheck sirve para utilizar una contraseña distinta a la de inicio de sesión del usuario; la opción –noautomount se explica a sí misma. Durante el proceso se solicitarán dos claves: una para login y otra para montaje. La segunda será la clave que desbloquee el directorio, la primera será la clave bajo la que será cifrada la clave de montaje, por lo cuál, al momento de montar el directorio, se solicitará únicamente la primera contraseña.

Para montar y desmontar este directorio cifrado, ejecutaremos respectivamente:

$ encryptfs-mount-private

$ encryptfs-umount-private

 

Final de la Primera Parte

En esta entrada hemos visto cómo resguardar los datos en nuestro disco duro (permanentes y temporales) mediante el uso de las herramientas de cifrado que disponemos para optimizar este proceso. Pero para llevar este cifrado al extremo debemos pensar que como usuarios de un sistema efectuamos un gran número de operaciones con nuestros equipos: navegamos por la vasta red de Internet, enviamos y recibimos correo electrónico, guardamos información en servicios de almacenamiento en “nube”, descargamos paquetes que luego instalamos, enviamos mensajes de chat y mucho más.

No es necesario aclarar la importancia que implica realizar estas operaciones de manera segura mediante el cifrado de la información. Quedo entonces comprometido a publicar la Segunda Parte de este artículo donde trataré todos los temas pendientes y sumaré una pequeña perlita sobre herramientas de cifrado para dispositivos móviles.


Fuentes:
https://wiki.archlinux.org/index.php/Disk_encryption
https://wiki.archlinux.org/index.php/Dm-crypt
https://wiki.archlinux.org/index.php/ECryptfs
https://wiki.archlinux.org/index.php/Security#Choosing_secure_passwords

 

La experiencia Plasma 5

Un poco de contexto

Hace unas semanas decidí hacer una instalación en limpio de Archlinux en mi escritorio y esta vez elegí como entorno KDE Plasma 5 (5.6.1 para ser específicos), dejando atrás a XFCE, el escritorio “libre de colesterol” famoso por ser ligero y altamente configurable, el cual me venía acompañando incondicionalmente por los últimos 5 o 6 años.

En el pasado no le había dado una verdadera oportunidad al escritorio de KDE por razones que son más bien excusas. Lo cierto es que no me gustaba realmente, y lo poco que me llamaba la atención quedaba empañado ante el hecho de ser reconocido como uno de los entornos de escritorio menos amigable con los recursos de la máquina. Luego, llamó especialmente mi atención cuando recientemente leí sobre este nuevo proyecto de KDE denominado Plasma 5 que venía a patear el tablero de la mejor manera que podría hacerlo: un nuevo entorno basado en Qt enfocado en la personalización, el buen gusto por el estilo y que prometía ser muy generoso con los recursos del sistema.

Sin embargo, y a pesar de haberlo probado en máquinas virtuales y en mi disco duro por varios días y de haber notado que efectivamente es agradable visualmente y que “vuela” en cuanto a rendimiento, seguía dándome la impresión de que algo le faltaba, aunque honestamente quizá era a mí a quien le faltaba hacer click para vencer la inercia de tantos años con xfce. Después de varias vueltas mientras pasaba por un proceso de aburrimiento con el escritorio del ratoncito, decidí volver a intentar con Plasma 5.

Lo que sigue es el resultado de mi experiencia.

Anécdotas iniciales

Lo primero que me encontré al iniciar sesión fue con una gran ignorancia sobre este entorno de escritorio. Claro, al ser una instalación sobre Arch y haber instalado sólo el paquete correspondiente al entorno en sí, sin instalar ninguna otra aplicación además de un emulador de terminal como para tener desde donde trabajar una vez iniciado el sistema con interfaz gráfica tenía una vaga idea por dónde empezar: instalé Firefox para tener desde dónde obtener la información que necesitaba.

Acá empezaron las dudas: las aplicaciones GTK se portan mal en KDE Plasma. Un error aquí fue asumir que la integración entre Plasma 5 con aplicaciones GTK era total cuando no lo es. Descubrí que apenas existe una manera de hacer estas aplicaciones se vean más o menos bien, cosa que no es tan así. La navegación con Firefox me resultó insoportable pero al menos sirvió para definir qué aplicaciones instalaría y cuáles no, además de pasearme por la ArchWiki en busca de los detalles necesarios.

Ya con la información y varios programillas instalados pude configurar gran parte del sistema. Esto también fue útil para saber que finalmente me libraría de un navegador que nunca me gustó demasiado pero que siempre utilicé por razones prácticas: en entornos GTK, el navegador de Mozilla es lo mejorcito que hay (al menos para mi gusto).

La fase de aprendizaje: los primeros problemas

Como mencioné, Firefox no va a ningún lado en KDE. La Archwiki menciona una versión desarrollada por gente de OpenSUSE con especial integración para Plasma y que está en los repositorios de AUR. No la instalé por razones ya sabidas. Me incliné entonces por Konqueror: navegador y gestor de archivos todo en uno fue todo lo que necesité saber para decidirme por usarlo. Los problemas aparecieron en forma de mensajes que alertaban sobre ciertas implementaciones al momento de iniciar sesión a mi cuenta de pump.io (en el nodo microca.st). Debo agradecer aquí a Jan, un compañero en redes libres que además es el desarrollador de Dianara, un grandioso cliente de escritorio para redes pump.io. Gracias a él, entendí que Konqueror funciona por defecto con el limitado motor KHTML pero que también soporta otros motores, entre ellos WebKit, que en Arch viene empaquetado como “kwebkitpart”. Problema resuelto.

El resto significó pasar por el proceso de re-aprender principalmente cómo funcionan las pequeñas cosas en Plasma pero que siempre son detalles importantes: dónde están los directorios con archivos de configuración, cómo trabaja el gestor de ventanas y el compositor, dónde se configura cada aspecto del escritorio y el sistema, etcétera. No es para nada difícil ni complicado para quienes usan GNU/Linux por varios años, pero requiere dedicarle su tiempo y prestarle atención a los detalles.

La etapa del disfrute

Superada ya la fase anterior, llegó rápidamente la etapa en que empecé a disfrutar de este entorno de escritorio. No cabe duda sobre lo bien que la gente de KDE está haciendo las cosas. Esto se nota en cada aspecto de Plasma 5.6.1: hay estabilidad, buen diseño, excelente funcionalidad, simplicidad, personalización al extremo y un uso de recursos que da gusto. Esto me deja en una situación muy particular: no tengo que prestarle demasiada atención al entorno de escritorio, lo que me da más tiempo para ocuparme de todo lo demás, algo que nunca me había ocurrido con XFCE.

Me he encontrado con excelentes aplicaciones para este escritorio, entre las que puedo destacar: la ya mencionada Dianara, Cantata como cliente de reproducción para MPD, el lector de fuentes RSS Akregator, el emulador de terminal Konsole, el cliente de correo KMail que me ha impresionado por su funcionalidad e integración con firmado y cifrado de correo, superando ampliamente al cliente de Mozilla, Thunderbird y para interactuar con mi equipo móvil con CyanogenMod está KDEConnect.

Me ha encantado por su parte que cada aspecto del sistema sea susceptible de ser personalizado, todo se puede modificar a gusto del usuario y las opciones son geniales con excelentes animaciones, efectos de escritorio, fuentes, esquemas de color y un largo etcétera. Respecto a esto, otro de los motivos que me llevó a buscarle la vuelta a Plasma 5 es el Artwork Antü, obra de un chico chileno llamado Fabián del Blog Pingüinos y un Café, quien ha hecho un trabajo fascinante, cuidando mucho los detalles y con muy buen sentido de lo estético, dándole a Plasma una apariencia muy disfrutable.

Conclusión

Ayer leí un artículo Adrián Perales en el que menciona su Paseo por algunos escritorios de GNU/Linux y estoy de acuerdo con él en que “El escritorio sigue siendo importante”. Con tantas opciones la elección se vuelve algo muy personal. Mi recomendación es que prueben tantos como puedan y que lo hagan de manera regular: un entorno que hoy no nos gusta, puede encantarnos en el futuro y al contrario, nuestro escritorio preferido de hoy puede dejar de gustarnos más adelante.

En mi caso, tengo argumentos para decir que KDE Plasma 5 ha llegado para quedarse y estará en mi escritorio por el tiempo que siga siendo lo que es hoy: un entorno bien hecho desde sus fundamentos.