Activar el repositorio kde-unstable y tener lo último de KDE en Archlinux

Como usuario de Archlinux estoy acostumbrado a estar siempre a la última en cuanto a actualizaciones, especialmente porque soy de los que habilitan los repositorios inestables en la configuración de pacman. Sin embargo, en muchas ocasiones los diferentes proyectos que proveen aplicaciones, programas, entornos de escritorio, espacios de trabajo, van un tanto más adelante que los mantenedores de los repositorios oficiales de las distribuciones GNU/Linux que usamos a diario (incluso con los repositorios inestables) y mientras el proyecto está en fase más avanzada, notamos que no estamos tan a la última como deseamos.

Uno de los casos es el del proyecto KDE. Mientras la gente de KDE trabajaba en el lanzamiento de la versión 5.6.95 de su entorno de escritorio Plasma y al mismo tiempo la versión 5.7 de este proyecto entraba en fase Beta, yo me encontraba con la versión 5.6.5 en mi instalación de Archlinux.

$ plasmashell --version
plasmashell 5.6.5

Aquí comencé a preguntarme cómo podría disponer de las últimas actualizaciones, es decir, de la versión 5.6.95 próxima a publicarse, la cual incluye muchas de las novedades que vienen con la siguiente (Plasma 5.7). Pues bien, en Archlinux disponemos del repositorio kde-unstable y para habilitarlo debemos editar el archivo /etc/pacman.conf.

$ sudo nano /etc/pacman.conf

/etc/pacman.conf


REPOSITORIES

[kde-unstable]
Include = /etc/pacman.d/mirrorlist
 
[testing]

Básicamente hemos agregado [kde-unstable] a nuestro listado de repositorios personalizados. Es importante colocarlo encima de los demás para que tenga prioridad sobre estos.

Ahora bastará con actualizar el sistema y volver a ejecutar el comando plasmashell --version.

$ sudo pacman -Syyu
...

$ plasmashell --version
plasmashell 5.6.95

 

Bien, hasta acá este pequeño artículo. Debo aclarar que al momento de preparar la entrada, la versión 5.6.95 aún no se lanzaba oficialmente. Hoy ya está disponible en repositorios oficiales de Archlinux. Sin embargo, igual sirve para futuras actualizaciones en fase previa a su lanzamiento.

Anuncios

Implementar nuestra propia VPN con OpenVPN en Debian

Razones para montar un servidor VPN hay muchas. En mi caso es simple: por mi trabajo me toca viajar y estar lejos de casa muy seguido por lo que necesito acceder a mi red para realizar distintas tareas que requieren que mis equipos se vean unos a otros como si estuvieran conectados a la misma LAN, todo siempre de la manera más segura posible. Si bien es cierto que muchas de esas tareas las realizo sobre SSH, hay otras que prefiero hacerlas a través de un servicio VPN.

Esta entrada está enfocada en cómo implementar este tipo de servidores usando OpenVPN en una distribución Debian. Para tales fines, se puede montar un servidor utilizando un equipo antiguo que ya no utilices, o bien, disponer de algún dispositivo tipo RaspberryPI.

No hace falta aclarar que necesitamos una ip pública fija o en caso contrario, usar un servicio tipo NoIP para acceder al servidor desde fuera de la LAN. Para no extenderme demasiado, voy a pasar por alto los detalles sobre esto y voy a ir directamente al grano.

Instalación y configuraciones iniciales

Instalamos el servidor, las herramientas de administración de certificados y ufw para simplificar las configuraciones del firewall.

$ sudo apt update && apt install openvpn easy-rsa ufw

Posteriormente, vamos a descomprimir y copiar el archivo de configuración de ejemplo que viene con la documentación de openvpn al directorio correspondiente para luego editarlo.

$ sudo gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

$ sudo nano /etc/openvpn/server.conf

/etc/openvpn/server.conf

[…]
# Puerto para las conexiones VPN. Por defecto 1194
port 1194
[…]
# Protocolo a utilizar
;proto udp
proto tcp
[…]
# Tipo de túnel
# TUN emula un dispositivo punto a punto
# TAP simula una interfaz ethernet (bridge o puente)

;dev tun
dev tap
[…]
# Bits de las claves RSA
dh dh2048.pem
[…]
# Redirigir el tráfico web hacia el destino que corresponda
push “redirect-gateway local def1 bypass-dhcp”
[…]
# Configuración de los DNS
push “dhcp-option DNS 208.67.222.222”
push “dhcp-option DNS 208.67.220.220”
[…]
# Permisos de usuarios y grupos
user nobody
group nogroup
[…]

Ahora bien, debemos avisarle al sistema que todo el trafico proveniente desde los clientes tiene que continuar su camino hacia la Internet, de lo contrario, el tráfico se detendría en el servidor. Para esto, ejecutamos:

$ sudo echo 1 > /proc/sys/net/ipv4/ip_forward

$ sudo nano /etc/sysctl.conf

/etc/sysctl.conf

[…]
net.ipv4.ip_forward=1
[…]

Además de ejecutar el comando, editamos el archivo /etc/sysctl.conf para que esta configuración sea persistente, es decir, resistente a reinicios.

 

Configurar el firewall

Como ya mencioné, usaremos ufw para simplificar la administración del firewall para nuestra VPN. Lo primero será abrir el puerto y protocolos respectivos por dónde transitarán los paquetes y luego vamos a permitir el tráfico SSH, básicamente para poder acceder al servidor cuando lo necesitemos (recordemos que el servidor está en un equipo que no necesariamente tiene un monitor conectado).

$ sudo ufw allow ssh

$ sudo ufw allow 1194/udp

Establecemos las políticas y reglas en el firewall.

$ sudo nano /etc/default/ufw

/etc/default/ufw

[…]
DEFAULT_FORWARD_POLICY=”ACCEPT”
[…]

$ sudo nano /etc/ufw/before.rules

/etc/ufw/before.rules

[…]
#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
# ufw-before-input
# ufw-before-output
# ufw-before-forward
#
# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/8 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES
#
# Don’t delete these required lines, otherwise there will be errors
*filter
[…]

Finalmente, activamos el firewall

$ sudo ufw enable

 

Crear y configurar la autoridad certificadora (CA), los certificados (crt) y las claves (rsa-keys)

El paquete easy-rsa provee varios scripts que facilitan la tarea de crear y configurar los certificados y claves de identificación cliente-servidor

Copiamos los scripts predefinidos del paquete easy-rsa al directorio /etc/openvpn. Luego creamos el directorio /etc/openvpn/easy-rsa/keys donde se almacenarán los certificados y claves.

$ sudo cp -r /usr/share/easy-rsa/ /etc/openvpn

$ sudo mkdir /etc/openvpn/easy-rsa/keys

Editamos el archivo que contiene la información requerida para crear la autoridad certificadora. Los datos de país, ciudad, nombre y correos de la compañía, etcétera podemos completarlos con cualquier valor que deseemos. La clave (KEY_NAME) la llamaremos server para simplificar su uso e identificarla como la clave del servidor fácilmente.

$ sudo nano /etc/openvpn/easy-rsa/vars

/etc/openvpn/easy-rsa/vars

[…]
export KEY_COUNTRY=”US”
export KEY_PROVINCE=”TX”
export KEY_CITY=”Dallas”
export KEY_ORG=”My Company Name”
export KEY_EMAIL=”sammy@example.com”
export KEY_OU=”MYOrganizationalUnit”
[…]
export KEY_NAME=”server”
[…]

Generamos los parámetros Diffie-Hellman con el comando:

$ sudo openssl dhparam -out /etc/openvpn/dh2048.pem 2048

Cambiamos la sesión de la consola para trabajar como root. Nos movemos al directorio donde se encuentran los scripts e iniciamos la infraestructura de claves (PKI).

$ su -
Contraseña:

# cd /etc/openvpn/easy-rsa

# . ./vars

Limpiamos las claves que hayan sido generadas previamente y que ya no se usan, construimos el certificado y la clave del servidor.

# ./clean-all

# ./build-ca

# ./build-key-server server
El último comando descrito creará los archivos ca.crt, server.crt y server.key y los alojará en el directorio /etc/openvpn/easy-rsa/keys.

Ahora, volveremos al archivo de configuración del servidor para configurar la ruta de los archivos generados con easy-rsa.

$ sudo nano /etc/openvpn/server.conf

/etc/openvpn/server.conf

[…]
ca easy-rsa/keys/server.crt
cert easy-rsa/keys/server.crt
key easy-rsa/keys/server.key # Este archivo debería permanecer secreto
[…]

Ya estamos en condiciones de iniciar el servidor.

$ sudo service openvpn start

 

Configuración de los clientes

El primer paso será construir la clave de identificación del cliente

$ su -
Contraseña:

# cd /etc/openvpn/easy-rsa

# ./build-key cliente1
Donde cliente1, cliente2, clienteN serán el nombre que le daremos a cada cliente que deseemos conectar

Ahora trabajaremos en el archivo de configuración. Primero, copiamos el archivo de ejemplo en la documentación de openvpn y lo abrimos para su edición:

$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/easy-rsa/keys/cliente1.ovpn

$ sudo nano /etc/openvpn/easy-rsa/keys/cliente1.ovpn

/etc/openvpn/easy-rsa/keys/cliente1.ovpn

[…]
# Tipo de túnel
;dev tun
dev tap
[…]
# Protocolo
;proto udp
proto tcp
[…]
# Dirección y puerto del servidor
remote ip_del_servidor 1194
remote miservidor.com 1194
remote miservidor2.org 1194
[…]
# Parámetros SSL/TLS
ca .vpn/ca.crt
cert .vpn/cliente1.crt
key .vpn/cliente1.key
[…]
# Privilegios de usuario
user nobody
group nobody
[…]

A partir de este momento dejamos el servidor y comenzamos a trabajar en el equipo cliente.

Creamos un directorio oculto en /home y mediante el uso de alguna herramienta de transferencia de archivos debemos copiar los archivos necesarios desde el servidor al cliente.

$ mkdir .vpn

$ scp usuario@ip_del_servidor:/etc/openvpn/easy-rsa/keys/{ca.crt,cliente1.crt,cliente1.key,cliente1.ovpn} .vpn/
Aquí utilizo scp (SSH) para transferir los archivos desde el servidor hacia el directorio oculto /home/.vpn en el cliente.

El último paso será iniciar el cliente. Si este cliente corre un sistema GNU/Linux, ejecutaremos en la consola:

$ sudo openvpn --config .vpn/cliente1.ovpn
Nota: en algunos sistemas es necesario ejecutar como superusuario

Seguridad adicional con TLS-AUTH

OpenVPN nos ofrece la posibilidad de mejorar la seguridad en la identificación a través de la verificación de las negociaciones mediante el uso de una firma de tipo HMAC. Para habilitar esta función, trabajaremos en la configuración tanto del servidor como del cliente.

En el servidor generamos la clave secreta y luego editamos el archivo de configuración:

$ sudo openvpn -genkey -secret ta-key

$ sudo nano /etc/openvpn/server.conf

/etc/openvpn/server.conf

[…]
tls-auth ta.key 0
[…]

Nota: en el servidor el valor es 0 (tráfico entrante)

En el cliente, copiamos la clave ta.key en el directorio de configuración de openvpn y editamos el archivo de configuración del cliente

$ sudo nano /etc/openvpn/cliente1.ovpn

/etc/openvpn/server.conf

[…]
tls-auth ta.key 1
[…]

Nota: en el servidor el valor es 1 (tráfico saliente)

OpenVPN en dispositivos móviles

Si sos de los que usan su teléfono para todo, inclusive trabajar, podrás utilizar el servicio VPN que acabamos de implementar para conectarte a tu red de área local. Para esto, instalaremos una aplicación que podemos encontrar en los repositorios de F-Droid: “OpenVPN for Android”.

Una vez instalada, copiamos al dispositivo los archivos necesarios (digamos: ca.crt, cliente_cyanogenmod.crt, cliente_cyanogenmod.key, cliente_cyanogenmod.ovpn), iniciamos la aplicación, seleccionamos los archivos y configuramos según los datos que correspondan a la conexión.

Palabras finales

Para finalizar el artículo es mi deber aclararles que para no extenderme demasiado decidí no entrar en detalle respecto de cómo asegurar el servidor contra los distintos ataques que pueda recibir, por lo que será tarea para ustedes ponerse a investigar y a trabajar en la seguridad de su servidor VPN.

Limitar la cuota de disco de los usuarios del sistema [Cuadernillo Técnico]

Establecer un límite o cuota de espacio disponible para almacenamiento en una partición determinada para los distintos usuarios de un sistema GNU/Linux puede ser de gran utilidad en muchos escenarios. En esta entrada voy a enfocarme especialmente en cómo implementar esta característica en una distribución de tipo Archlinux.

Instalar y habilitar

En primer lugar, instalamos los paquetes necesarios y editamos el archivo /etc/fstab

$ sudo pacman -S quota-tools

$ sudo nano /etc/fstab

/etc/fstab

/dev/sdaX /home ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv2 1 1

Como se ve, hemos añadido las opciones para establecer el uso de cuotas para usuarios (usrjquota), grupos (grpjquota)y el formato (jqfmt) en la partición /dev/sdaX que el sistema monta en el punto /home.
Personalmente tengo preferencia por habilitar “Journaling” para las cuotas de disco y utilizo el formato vfsv2. Encontrarás más información sobre esto en https://wiki.archlinux.org/index.php/Disk_quota.

Lo siguiente será remontar la partición /home y crear el índice

$ su -
Contraseña:************

# mount -vo remount /home

# quotacheck -vgum /home
Verás que he tenido que cambiar la sesión en la consola e iniciar como root. Esto es necesario para poder remontar la partición /home. El comando quotacheck creará los archivos de índice aquota*. En caso que hayas habilitado cuotas para más de una partición, el comando correspondiente es quotacheck -vguma.

Finalmente, habilitamos el servicio:

# quotaon -av

 

Configurar

Para configurar las cutoas que deseamos establecer para cada usuario debemos ejecutar como root:

# edquota usuario
Reemplazando el usuario por el correspondiente a quien editaremos sus cuotas.
Disk quotas for user usuario (uid xxxx):
Filesystem   blocks     soft        hard        inodes    soft     hard
/dev/sda1    657313     10000000    15000000    100       0        0

Por último, establecemos el período de gracia para superar el valor soft de la cuota:

# edquota -t

 

¿Qué representan los valores en cada columna? Pues bien:

blocks/inodes: es la cantidad de datos en bloques/inodes que tiene escritos el usuario actualmente.

soft: es el límite de datos en Kilobytes (1GB=1.000.000KB) que el usuario puede escribir antes de ser advertido sobre el uso de su cuota. A partir de que el usuario alcance este valor, podrá continuar almacenando datos por encima del mismo durante el período de gracia establecido con edquota -t. El valor 0 implica “sin límite”.

hard: es el valor límite máximo que el usuario puede escribir en el disco, es decir, nunca podrá superar este valor. El valor 0 implica “sin límite”.

Las modificaciones en la configuración de las cuotas es un aspecto que requiere especial atención. Esto se debe a que si aumentamos el valor de las cuotas para un usuario, éste podrá aumentar su nivel de datos almacenados de manera inmediata y sin problema. Sin embargo, al reducir el valor de una cuota, si el usuario tiene actualmente una cantidad de datos escritos mayor al nuevo límite permitido, no podrá iniciar sesión en el sistema.

Por último les dejo una lista de comandos útiles:

$ repquota /particion
Indica las cuotas aplicadas a una determinada particion.
$ quota -u usuario

$ quota -g grupo
Indica la cuota que aplican a un usuario/grupo.
$ edquota -p usuario1 usuario2 usuarion

$ edqouta -g -p grupo1 grupo2 grupon
Copia la configuración de cuotas del usuario1 a los otros usuarios/grupos descritos.
$ quotastats
Muestra las estadísticas asociadas al uso de las cuotas.

 

Bueno, hasta acá esta entrega de mi Cuadernillo Técnico: anotaciones que he llevado a lo largo de varios años como ayuda memoria para configurar e implementar herramientas en mis sistemas GNU/Linux. Espero les sea de utilidad.

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

 

Navegá anónimo mediante Tor [Cuadernillo Técnico]

Hace unas semanas, en el artículo Cuidá tu privacidad en la Red, mencioné la utilidad de la red Tor para navegar de manera anónima en la red. Sin entrar en demasiados detalles, lo que hace el servicio de Tor es redirigir la conexión a través de una red distribuida permitiendo que nuestra dirección IP quede oculta a lo largo de esta red. Si deseás más detalles de cómo funciona esto, la página web del proyecto ofrece mucha información.

En este artículo voy a detallar los pasos necesarios para tener instalado y configurado Tor en nuestra máquina con GNU/Linux. Dado que utilizo Archlinux, los comandos estarán enfocados en esta distribución. Sin embargo, son fácilmente transferibles a cualquier otra. Por ejemplo: si usás Debian cambiá “pacman -S” por “apt-get install”, etcétera (hay algunos paquetes que pueden cambiar de nombre, por lo que debés tener en cuenta eso también).

Instalación y Configuración de Tor con Privoxy

Privoxy es un servidor Proxy enfocado en la privacidad (de ahí el nombre). Debido a que Tor funciona como Proxy tipo Socks (más específicamente Socks5), Privoxy tomará el control del tráfico HTTP para redirigirlo hacia Tor. Lo primero entonces que haremos será instalar los paquetes necesarios:

$ sudo pacman -S tor privoxy

El primer paso luego de la instalación será configurar Privoxy:

Remplazá “editor” por tu editor de textos preferido: nano, vim, kate, gedit, etcétera.
$ sudo "editor" /etc/privoxy/config

El archivo es bastante extenso y a su vez completamente explicativo. Lo que a nosotros nos interesa es la dirección IP por dónde escuchará el servicio. Debemos asegurarnos que dicha línea esté descomentada (sin el signo # por delante) y que apunte a la máquina (Host) y puerto donde se ejecutará el servidor. Aquí se presentan dos opciones: la primera, el servicio sólo se utilizará para el tráfico de la máquina donde se instaló (o localhost); la segunda, el servicio se ejecutará en una red de computadoras (física o virtual) y estará disponible para toda la red. De esta manera, la línea “listen-address” debe quedar así:

Para el ejemplo se usa una red de tipo 192.168.x.x/24 y los puertos por defecto (Privoxy: 8118; Tor: 9050)

/etc/privoxy/config

[…]
listen-address 127.0.0.1:8118
[…]
ó
[…]
listen-address 192.168.x.x:8118
[…]

Luego, habrá que indicarle a Privoxy que redirija todo el tráfico hacia Tor. Para esto, vamos al final del archivo (/etc/privoxy/config) y agregamos la siguiente línea:

/etc/privoxy/config

[…]
forward-socks5 127.0.0.1/9050 .

Notar el punto al final de la línea: es importante colocarlo para que funcione correctamente de acuerdo a las reglas de direccionamiento de Privoxy.

Respecto de la configuración de Tor, usaremos la que viene por defecto. En caso que quisiéramos modificarla, bastará con editar el archivo correspondiente (/etc/tor/torrc).

Gestión del Servicio

Queda entonces iniciar ambos servidores y dejarlos habilitados para que inicien con en el arranque:

Importante: tener en cuenta que el gestor de servicios cambia dependiendo de la distribución
$ sudo systemctl enable tor.service

$ sudo systemctl start tor.service

$ sudo systemctl enable privoxy.service

$ sudo systemctl start privoxy.service

 

Configuración de aplicaciones

El último paso para comenzar a navegar anónimo a través de Tor es configurar tus aplicaciones. Para aquellas que soporten Proxy tipo Socks5, la configuración será:

Dirección del Servidor: 127.0.0.1 (o IP del servidor si está en otra máquina)
Puerto: 9050

Para aplicaciones con Proxy HTTP (por ejemplo, un navegador web):

Dirección del Servidor: 127.0.0.1 (o IP del servidor si está en otra máquina)
Puerto: 8118

Para comprobar que estás navegando a través de Tor, abrí tu navegador web e ingresá a: https://check.torproject.org. La página te mostrará el mensaje:

“Congratulations. This browser is configured to use Tor”

Monitorizar el tráfico a través de Tor

El proyecto Tor ofrece un paquete llamado Arm desde el cual podemos monitorizar el tráfico que pasa a través del servidor y la red. Para ejecutar el programa, además de instalarlo, debemos hacer algunas modificaciones en el archivo de configuración de Tor. Por lo tanto:

$ sudo pacman -S arm

$ sudo "editor" /etc/tor/torrc
Aquí debemos descomentar (quitar el símbolo # al principio) dos líneas y agregar una.

/etc/tor/torrc

ControlPort 9051
CookieAuthentication 1
DisableDebbugerAttatchment 0

Luego de guardar los cambios, reiniciamos los servicios:

$ sudo systemctl restart tor.service

$ sudo systemctl restart privoxy.service

Finalmente, ejecutamos el monitor con:

$ sudo arm

 

Aún queda trabajo por hacer

Bueno, hasta acá hemos logrado instalar y configurar Tor para movernos anónimamente a lo largo de las redes. Con esto ya tenemos bastante. Sin embargo, con un poco de trabajo adicional podremos ganar en eficiencia y mejorar el rendimiento a la vez que cuidamos nuestro anonimato y seguridad. En esta ocasión sólo voy a mencionar algunas de estas acciones a tener en cuenta, dejando su aplicación y uso para futuros artículos.

En primer lugar, podemos agregar un sistema de caché proxy como Polipo o Squid y configurarlo para que nuestros proxys funcionen en cadena. Conceptualmente, nuestros proxys quedan encadenados de manera que el Tráfico HTTP se redirige a Privoxy, el cual envía el tráfico a través de Polipo (caché proxy) que a su vez lo reenvía hacia Tor. Para configurarlo, basta con instalar Polipo o Squid y redirigir el tráfico de acuerdo se muestra en la cadena:

Tráfico HTTP -> Privoxy -> Polipo/Squid -> Tor

Por otra parte, podemos enrutar las peticiones DNS hacia Tor mediante el uso de herramientas como dnsmasq. Sin embargo, estas peticiones no están cifradas por lo que es muy recomendable el uso de otra herramienta como DNSCrypt, la cual cifra las peticiones DNS a través de una lista de servidores soportados.

La relevancia del Software Libre en el anonimato

Para finalizar, quiero hacer hincapié en un tema que será recurrente en este blog. Como escribí en su momento, la privacidad en las redes es un asunto importante que nos concierne a todos. La existencia de proyectos de Software Libre como Tor o DNSCrypt y los programas descritos en este artículo facilitan disponer de herramientas de gran utilidad para cuidar dicha privacidad y nos permiten construir una Sociedad más justa y libre.

Esta guía es un pedacito del Cuadernillo de Anotaciones que llevo en mi aprendizaje. Espero que les sirva.

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.