Seguridad

Bien, llegó la hora. Es el momento de atacar el que sin duda es el anzuelo con el que el Sr. Google más nos tiene cogidos de los pelendengues. Todo ese conjunto de servicios con los que casi sin darnos cuenta nos hemos acostumbrado a vivir y que resultan más engorroso sustituir. Me estoy refiriendo, como no, a los servicios de sincronización de datos tales como calendarios, agendas telefónicas, fotografías, archivos, etc. En resumen, todo eso que de unos años a esta parte nos ha dado por llamar «la nube». Y bien llamado, porque la verdad es que es que un poco en las nubes hemos tenido que estar todo este tiempo para pensar que era buena idea dar todos nuestros datos privados a una empresa para que nos los guarde, y pensar que lo iba a hacer «gratis». En fin…

El problema

Ponga una «nube» en su vida, bien podría ser el eslógan de la última década. Práctico es, desde luego. Nos permite llevar nuestros datos de aquí para allá y mantenerlos sincronizados en distintos dispositivos, amén de proporcionarnos una sencillísima manera de mantener copias de seguridad. ¿Y qué es una «nube»? Pues lo cierto es que, en la práctica, una «nube» no es sino un ordenador conectado a internet 24×7, fiable y con buena conectividad para que esté siempre accesible. Y esto hace que la solución no sea tan inmediata como en los capítulos anteriores.

Después de darle unas cuantas vueltas, he reducido las posibles soluciones a estas tres posibilidades que voy a sugerir.

1. Contratar un servicio similar a Google pero de pago. Si estás pensando que menuda melonada acabo de proponer, porque para qué voy a pagar a una empresa para obtener lo mismo que me da Google gratis, igual conviene que le eches un vistazo al capítulo 1 y luego seguimos. Obviamente Google no es gratis; le estamos pagando con nuestros datos sacrificando nuestra privacidad. Visto así, la propuesta es en realidad muy sencilla: Tener lo mismo pero pagado con dinero en lugar de en especies, y así conservamos la privacidad.
2. Instalar nuestro propio servicio de sincronización en un servidor virtual alojado en un proveedor de alojamiento, similar a los que contratamos para albergar nuestras páginas web. En realidad esta sería la opción más recomendable, ya que nos permite mantener el control (casi) total de nuestros datos sin necesidad de tener que fiarnos (casi) de las políticas de privacidad de la empresa que decidamos contratar en la opción 1, y además nos vemos libres del engorro del mantenimiento del ordenador, el acceso a internet, las copias de seguridad, etc. A cambio debemos ser conscientes de que tendremos que abonar una cantidad mensual comparable a la de la opción 1, y que parámetros tales como el rendimiento de la máquina, la velocidad del acceso y, sobre todo, la capacidad del disco duro se verán muy influidos por la mensualidad que elijamos.
3. Instalar los servicios de sincronización en nuestro propio servidor físico, de nuestra propiedad particular y privada, y alojado en nuestro hogar o local. De entrada yo no lo recomendaría: es engorroso de mantener, dependemos de que no se nos corte la conexión a internet ni la alimentación eléctrica y encima hay que pagar la luz, que cada vez está más cara. A cambio… tendremos un control absoluto tanto sobre los datos como sobre los ajustes del servidor, no necesitaremos fiarnos de ningún tercero que pudiera eventualmente querer acceder de manera lícita o ilícita a nuestros datos y, además, tener un servidor propio resulta ser un juguete de lo más molón.

Llegados a este punto, quien me conozca un poco seguramente ya habrá adivinado la opción que yo he elegido para mi (una pista: la 1 no es). Quien elija la uno no necesita más instrucciones, ya que el servicio se las proporcionará. Y para todos los demás, digamos que la manera de proceder es prácticamente idéntica para los casos 2 y 3. Así, que vamos allá.

La solución

Así que hemos decidido instalar nuestro propia «nube», sea un en un servidor externo o uno propio, por lo que necesitaremos el software adecuado. Y, como siempre, no me voy a detener en analizar las posibles alternativas, sino que me limitaré a señalar la que ha sido adecuada para mí. Y en este caso, el ganador es NextCloud.

Se trata de un software de código abierto que proporciona todos los servicios en nube que utilizamos de manera habitual: calendarios, contactos, archivos, correo electrónico, comunicación… Su código está disponible para la descarga en su página web y está ampliamente documentado. Para su instalación no necesitamos demasiados recursos de computación. Un mini-pc hará la función perfectamente. Como mucho tendremos que asegurarnos de disponer de suficiente espacio de disco duro para nuestras necesidades y, aún en el peor de los casos, seguro que superamos ampliamente los ridículos 15 Gb que nos «regala» el Sr. Google.

Preliminares

La instalación de NextCloud debe hacerse sobre un típico sistema LAMP, acrónimo de Linux, Apache, MySQL y PHP. Es decir, un servidor Linux con servidor web, base de datos y php. Lo mismo que se utiliza para alojar una página web promedio y que cualquier proveedor de alojamiento ya proporciona.

Apache

Cuenta la leyenda que en aquellos tiempos en los que internet comenzaba a expandirse y yo todavía tenía pelo, un grupo de programadores decidió poner un poco de orden en aquellas salvajes llanuras de la World Wide Web. Así que se pusieron manos a la obra para crear un servidor web potente y versátil. Pero para no reinventar la rueda, lo que hicieron fue parchear («patch», en inglés) el servidor web por entonces más popular, creado por el Centro Nacional de Aplicaciones de Supercomputación (NCSA por sus siglas en inglés), el NCSA HTTPd. Que durante su desarrollo a manos de un puñado de frikis cachondos lo que comenzara siendo conocido como un «patched server» terminara llamándose «apache server» no tiene nada de sorprendente. Puedo imaginarme perfectamente a los ingenieros partiéndose de risa haciendo el indio mientras picaban código como locos…

Apache ha sido el líder indiscutible de la WWW desde su aparición hasta ahora, si bien últimamente ha empezado a perder terreno a favor de servidores más modernos.  En realidad, el Apache que vamos a instalar se llama Apache2. Se trata de la segunda versión del mítico Apache una vez que se decidieron a reescribirlo desde cero, como debe ser.

Algunas notas sobre su configuración

Los dos directorios con los que hay que bregar son los siguientes:

• La raíz para los archivos de los sitios web. Aquí crearemos un subdirectorio nuevo para cada nuevo sitio web que queramos servir.

cd /var/www/

• El directorio de configuración. Aquí hay subdirectorios para configurar tanto los módulos que queremos que use el servidor como los parámetros de funcionamiento de cada uno de los sitios web.

cd /etc/apache2

La instalación trae un sitio por defecto que nos servirá para comprobar que el servidor está funcionando. Dicho sitio se encuentra en /var/www/html y será accesible conectándonos directamente a la IP del servidor.

En la práctica, el sitio web consiste en un único archivo index.html. En el manual de Apache2 se suele indicar que para levantar nuestro sitio web lo que tenemos que hacer es sustituir este archivo por los archivos de nuestro sitio. Sin embargo yo prefiero crear una nueva carpeta y mantener el sitio por defecto. En caso de problemas, tener disponible un sitio por defecto para comprobar el funcionamiento básico del servidor me ha resultado útil más de una vez.

En mi caso, el sitio web adicional para nextcloud irá en: /var/www/nextcloud

sudo mkdir nextcloud

Sitios web

Cada uno de los sitios web que habilitemos en Apache2 lleva el nombre de Servidor Virtual (Virtual Host) Este esquema de configuración permite servir tantos sitios como queramos, distinguiendo unos de otros mediante el nombre DNS con el que accedamos al servidor y/o con el número de puerto. La configuración para cada sitio se guarda en un archivo en el siguiente directorio de sitios disponibles: /etc/apache2/sites-available/

Si miramos el contenido inicial de este directorio veremos dos plantillas preconfiguradas: una para sitios http normales y otra para sitios con SSL habilitado (sitios https). Normalmente en estos archivos especificamos cosas como el puerto, en nombre DNS con el cual nos conectamos, el directorio web, etc. Para configurar el sitio, copiaremos la plantilla deseada y la personalizaremos con un nombre de archivo que identifique a nuestro sitio y modificaremos los parámetros oportunamente.

Por ejemplo, puedo crear un sitio http en nextcloud.conf. Sin embargo, como voy a utilizar SSL, tendré que utilizar la plantilla preconfigurada para SSL que copiaré a un archivo nextcloud-ssl.conf.

Y ahora, para habilitar el sitio:

sudo a2ensite nextcloud.conf
sudo systemctl reload apache2

Y para deshabilitarlo:

sudo a2dissite nextcloud.conf
sudo systemctl reload apache2

Notar que después de habilitar o rehabilitar un sitio, es necesario recargar la configuración

Nota: Estos comandos, en realidad, lo único que hacen es crear y destruir enlaces simbólicos en el directorio /etc/apache2/sites-enabled/ Si no utilizáramos el comando tendríamos que crear estos enlaces manualmente y el resultado sería el mismo. El mismo esquema es el que se utiliza para habilitar y deshabilitar módulos, como veremos a continuación.

Añadiendo algo de seguridad

Si queremos habilitar SSL, lo cual es sumamente recomendable, habilitaremos el siguiente módulo:

sudo a2enmod ssl
sudo systemctl reload apache2

 

Nota: Apache2 genera de manera automática un certificado que será utilizado por defecto cuando habilitemos ssh. Este certificado no está firmado por una autoridad de certificados («Certificate Authority, o CA), sino que está autofirmado. Básicamente, lo que esto implica es que no hay una entidad de un nivel superior que garantice que el servidor sea quien dice ser, sino que es el propio servidor el que se identifica a sí mismo. En condiciones normales esto se considera un riesgo de seguridad y el navegador que utilicemos para conectarnos al servidor nos advertirá de ello. Sin embargo, al ser nosotros mismos quienes gestionamos directamente el servidor, podemos obviar este aviso de manera segura (ya que, obviamente, nosotros ya sabemos quienes somos y no necesitemos que nadie nos lo confirme… ¿o no?). Lo importante es que el acceso a los datos se estará realizando por un canal cifrado, que es de lo que se trata. Sin embargo, si tal aviso nos resulta engorroso, somos un poco obsesivos o el servicio lo van a utilizar terceras personas que no tienen por qué fiarse de nosotros, podemos recurrir a un certificado gratuito generado y firmado por una CA de verdad, como es Let’s Encrypt.

 

Let’s Encrypt

Ahora, sí, resulta que quiero un certificado de verdad. En primer lugar instalo el programa Certbot. Se trata de un software que, mediante el protocolo ACME (Sí, no es coña) nos permite verificar que tenemos control sobre el dominio al cual irá asociado el certificado. Para ello será necesario tener previamente un sitio web funcionando con HTTP, en el puerto 80, en el mismo dominio para el cual voy a solicitar el certificado. Puede ser cualquier sitio, incluso el sitio por defecto de Apache2. Además, una vez instalado el certificado, el sitio se puede deshabilitar.

sudo apt update
sudo apt install software-properties-common
sudo apt install python3-certbot-apache

Ahora vamos a obtener e instalar el certificado. Y, como para casi todo en esta vida, hay dos posibles maneras: la fácil y la buena.

• La fácil consiste en una única instrucción que genera el certificado y configura Apache2 para usarlo, todo en uno.
• La buena: Solamente generamos el certificado y la configuración de Apache2 la gestionamos mano. Así nos enteramos de lo que estamos haciendo, lo cual es muy conveniente y tampoco es tan difícil, caramba!

Así que vamos con la buena. Primero, generamos el certificado.

sudo certbot certonly --apache

Me preguntará el dominio y una dirección de email administrativa de contacto y generará el certificado y la clave privada que dejará en los respectivos directorios:

/etc/letsencrypt/live/mi-dominio.com/fullchain.pem

/etc/letsencrypt/live/mi-dominio.com/privkey.pem

Y, ahora sí, configuramos nuestro sitio web añadiendo la ubicación del certificado al archivo de «Virtual Host» en Apache2

sudo nano /etc/apache2/sites-available/nextcloud-ssl.conf

SSLCertificateFile /etc/letsencrypt/live/mi-dominio.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mi-dominio.com/privkey.pem

Y no nos olvidemos de comentar las líneas que se refieren al certificado autofirmado, ya que no es el que queremos usar

#SSLCertificateFile     /etc/ssl/certs/ssl-cert-snakeoil.pem
#SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Y ya está listo. No olvidemos recargar el servicio Apache2

Algunas utilidades

Si queremos comprobar los certificados instalados

sudo certbot certificates

Si queremos eliminar algún certificado

sudo certbot delete --cert-name <nombre-certificado>

Si queremos renovar un certificado próximo a caducar (duran 90 días)

sudo certbot renew --cert-name <nombre-certificado>

Si sólo queremos comprobar el buen funcionamiento de la renovación

sudo certbot renew --dry-run

Nota: Tanto para la generación de un certificado como para su renovación será necesario tener un sitio web habilitado en el mismo dominio en el puerto 80, es decir, accesible con HTTP. Una vez instalado o renovado el certificado, el sitio web en el puerto 80 puede ser deshabilitado.

 

PHP

Ningún misterio en este punto, sobre todo si seguimos las instrucciones de instalación de Nextcloud en las que se instalan todos los módulos recomendados. Únicamente recordar que siempre resulta muy conveniente colocar en el directorio raíz de nuestro sitio web un archivo de tipo php que llame a la instrucción phpinfo(). De esta manera contamos con una sencilla pero eficaz herramienta de depuración que nos permita comprobar el correcto funcionamiento de nuestra instalación de PHP. Para simplificar las cosas, el archivo en cuestión se llamará, simplemente, phpinfo.php

nano phpinfo.php
<?php

// Muestra toda la información, por defecto INFO_ALL
phpinfo();

?>

 

MariaDB

Éste es el nombre de uno de los sistemas de gestión de bases de datos relacionales de código abierto más populares en la actualidad y que, de hecho, es el aconsejado para la instalación de Nextcloud.

Si bien en el encabezamiento del artículo hablábamos de que la M de un sistema LAMP hacía referencia a MySQL, MariaDB es una opción equivalente y que, en general, es más recomendada. Sus principales impulsores fueron los mismos que crearon MySQL con la diferencia de que ésta fue desarrollada en Oracle Corporation mientras que para MariaDB se creo una fundación que se comprometió a mantener el código bajo licencia GPL. Este compromiso nunca lo tuvo Oracle, más allá de una cierta voluntad inicial, y lo cierto es que algunos módulos de MySQL ya están bajo licencia privativa. Teniendo en cuenta que MariaDB es totalmente compatible con MySQL y que las malas lenguas dicen que rinde mejor, la elección parece clara.

Configuración

Una vez instalada, el primer paso es conectar con el motor de base de datos. Observar que ejecutamos el comando con sudo, de manera que no es necesario identificarse específicamente para la base de datos.

sudo mariadb

En primer lugar creamos la base de datos

CREATE DATABASE nextcloud_db;

A continuación creamos un usuario y le otorgamos permisos

GRANT ALL PRIVILEGES ON nextcloud_db.* TO 'nextcloud_usr'@localhost IDENTIFIED BY 'password';

Y no nos olvidemos de aplicar los cambios

FLUSH PRIVILEGES;

Y por si os lo estabais preguntando, la razón del curioso nombre de esta base de datos reside en la tradición de su principal creador, un tal Ulf Michael Widenius (al que, por razones obvias, sus amigos llaman Monty) de incluir en la denominación de sus creaciones los nombres de sus hijos. Así, su primer hijo, My, dio lugar a MySQL, mientras que su segunda hija, María, inspiró MariaDB. Muy tierno, el tío Monty.

Instalación de Nextcloud

Existen varios métodos para instalar un servidor de Nextcloud. La instalación web es posiblemente la más sencilla de todas y tiene la ventaja de que el procedimiento es idéntico tanto si la instalación la hacemos en un espacio de alojamiento compartido como en un servidor personal. Consiste, básicamente, en descargar un archivo llamado setup-nextcloud.php, colocarlo en la raíz de nuestro sitio web y dirigirnos a él desde cualquier navegador. Nos aparecerá un asistente de instalación y lo único que tenemos que hacer es seguir las instrucciones e ir aportando la información necesaria.

Por cierto, en el momento de escribir esta entrada lo cierto es que encontré la web de Nextcloud un tanto confusa, así que para ahorrar trabajo el manual de instalación se encuentra aquí, con un práctico ejemplo de instalación en Ubuntu. Respecto a la descarga del archivo php para la instalación en web, el enlace proporcionado en dicho manual no es de mucha utilidad, y al final no me quedó otra que recurrir a la misma página de github donde se encuentra el proyecto. Supongo que poco a poco irán poniendo orden.

Ubicación del directorio de datos

Un tema importante, por cuestión de seguridad, se refiere al hecho de que los archivos se encuentran por defecto dentro del directorio web mientras que el archivo .htacces está desactivado. Recordemos que el archivo .htaccess es un método clásico que permite restringir el acceso a los directorios que se encuentran dentro del directorio de nuestra web. Sin embargo, este método no es del todo fiable y, además, compromete el rendimiento del servidor. Es por ello que, por defecto, se encuentra deshabilitado. Una discusión interesante se encuentra en el siguiente artículo:

https://httpd.apache.org/docs/2.4/howto/htaccess.html#when

Entonces, para mantener a salvo nuestros archivos, lo mejor es colocar el directorio de datos fuera de la raíz de documentos del sitio web. El problema es que, una vez realizada la instalación, para mover el directorio de datos no basta con modificar la entrada en el archivo de configuración, sino que habría que corregir múltiples entradas en la base de datos. Este procedimiento está oficialmente desaconsejado por el equipo de Nextcloud, que recomienda, en su lugar, seleccionar el directorio definitivo durante la instalación.

Nota sobre permisos: Es importante que el directorio de datos pertenezca al usuario y grupo www-data que es bajo el que se ejecuta Apache2. También es importante que dicho directorio no se encuentre dentro de una ruta que lo haga inaccesible debido a la falta de acceso de ejecución sobre alguno de los directorios de la misma. En mi caso, el directorio de usuario pertenece a www-data:www-data con permisos 750 y se encuentra dentro de una unidad de disco montada en un directorio con propiedad root:root y permisos 755. Si nos fijamos, es el mismo esquema que siguen los directorios de usuario dentro de /home en una instalación regular de Linux.

Arranque y optimización

Una vez instalado el servidor podemos acceder al panel de control del mismo en la dirección https://<mi_dominio//index.php/apps/dashboard/

Una vez allí, una página me mostrará una lista de asuntos que resulta necesario optimizar. Esta lista puede variar de un servidor a otro. Aquí me limitaré a comentar algunos de los cambios que, según mi experiencia, suelen ser los más habituales, o bien aquellos con los que me he ido encontrando a lo largo de la experimentación con Nextcloud.

Es habitual tener que introducir algunas modificaciones en el archivo de configuración de PHP, php.ini Para ello, lo primero es localizar dicho archivo de configuración, ya que según la instalación pueden existir varios y es necesario saber cuál es el que se está cargando. La manera de averiguarlo es consultar el archivo de depuración de PHP mencionado antes, es decir, la página phpinfo.php

En mi caso: /etc/php/8.1/fpm/php.ini

Un cambio clásico suele ser el ajuste del límite de memoria al valor recomendado: 128M -> 512M

Como siempre, cualquier cambio a la configuración de PHP requiere reiniciar el servicio

sudo systemctl restart php8.1-fpm

También suele ser frecuente la recomendación de instalar algunos paquetes adicionales, tales como php-imagick  y para el soporte svg, libmagickcore-6.q16-6-extra (que, por cierto, viene entre los paquetes sugeridos)

php-intl

A vueltas con Cron

Un error común que se nos muestra en la sección de vista general incluye el siguiente mensaje:

No se ha podido ejecutar el trabajo cron vía CLI. Han aparecido los siguientes errores técnicos:
Tu directorio de datos es inválido Asegúrate de que existe un archivo llamado «.ocdata» en la raíz del directorio de datos.

Y además en rojo, lo que acojona un poco. Al parecer tiene que ver con la manera en la que el servidor ejecuta las tareas de manera periódica. Desconozco la razón del aviso, pero una manera de solucionarlo es seleccionar CRON en la sección de Ajustes básicos y añadir una tarea que viene en el propio directorio de instalación de Nextcloud ya que, al parecer, esta tarea no se registra sola:

sudo su

crontab -u www-data -e

*/5 * * * * /usr/bin/php /var/www/nextcloud/cron.php

También nos podemos encontrar con un error al intentar conectar con los protocolos CalDAV. Esto es debido a que la resolución correcta de las rutas de cada protocolo se encuentran especificadas en el archivo .htaccess, el cual, como ya hemos visto, está deshabilitado por defecto. Una solución es habilitarlo sólo para nuestro sitio web añadiendo estas línes al archivo de «Virtual Host»:

<Directory /var/www/nextcloud/>
                AllowOverride All
</Directory>

Cache

Instalo la cache con apt install php-apcu

Se creará el archivo de configuración de php /etc/php/8.1/conf.d/20-apcu.ini En él añado las siguientes líneas (encontradas por ahí…)

apc.enabled=1
apc.file_update_protection=2
apc.optimization=0
apc.shm_size=256M
apc.include_once_override=0
apc.shm_segments=1
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600
apc.num_files_hint=1024
apc.enable_cli=0
apc.max_file_size=5M
apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0

Le indico a nextcloud que utilice apcu en su archivo de configuración

sudo nano /var/www/nextcloud/config/config.php

'memcache.distributed' => '\\OC\\Memcache\\APCu',
'memcache.local' => '\\OC\\Memcache\\APCu',

Reinicio, y a funcionar

sudo systemctl restart php8.1-fpm.service
sudo systemctl restart apache2.service