Me voy a mi nube (II)

(Enlace a Me voy a mi nube I)

Nos habíamos quedado en instalar todas las actualizaciones disponibles para el servidor, pero antes de continuar me gustaría evaluar después de un par de meses el servicio que presta Edis.

En este tiempo me he encontrado con los siguientes pros y contras:

• Al principio parecía que, aunque las aplicaciones iban muy bien, la conexión por ssh tenía bastante latencia y algunas veces no se conectaba a la primera. Pero la verdad es que hace tiempo que eso no me pasa.
• El servicio técnico responde. Yo me he comunicado en inglés pero también lo pueden hacer en español. Por email te ayudan rápido y bien.
• Tuvieron una incidencia de seguridad con una aplicación web que es el panel de control de tu servidor (que por cierto está muy bien) y la tuvieron clausurada unas semanas. No depende de ellos porque el software se lo proporciona un tercero. Por un lado está mal que tuvieran esa brecha, pero por otro lado lo detectaron y le pusieron remedio.
  Cuando tuve que hacer una conexión de emergencia SSH -porque la había liado parda configurando un firewall- y no pude conectarme porque no estaba disponible el panel, sin problema me ejecutaron el comando que necesitaba, sin coste alguno y rápidamente.
• Para algunas personas el hecho de que no esté en España puede ser un problema, para mi no, los CPDs están en Austria, país que considero serio y al ser de la UE está sujeto a protección de datos. Pero para quien lo necesite también tienen VPS con CPDs en Madrid, más caros.
• Me cambiaron la IP del servidor -avisando- pero como tengo un dominio contratado lo único que tuve que hacer fue cambiar el registro DNS.
• Envía una notificación por correo electrónico cada vez que se accede al panel de administración del sercidor. Si no has accedido tú y recibes el correo… ya sabes.

Así que, por el servicio que da y el precio que tiene, yo lo recomendaría. Pero bueno que no gano nada, era solo para contar como me había ido una de las múltiples opciones disponibles. Pasemos a la configuración.

Seguridad y otras configuraciones

Seguro que hay algún experto en seguridad que haría las cosas mejor, yo no lo soy, he ido reuniendo información que me ha parecido útil. Me he basado también en un artículo de Linux Magazine [1] donde montaban un servidor de juegos (Xonotic) y la parte de configuración de la seguridad y actualizaciones me pareció útil para cualquier proyecto. El resto ha venido de enlaces diversos.

En los ejemplos a partir de ahora, cada vez que aparezcan los corchetes significará que habrá que sustituirlo todo -incluidos corchetes- por el valor que te hayan dado. Por ejemplo si tienes la IP de tu servidor 151.230.11.40 -no, no es la mia ;)- entonces sustituimos [IP] por 151.230.11.40.

Por cierto, asumo que sabemos conectarnos a la máquina por SSH desde Linux. Para hacer todas estas tareas desde un PC Windows tenemos el PuTTY, de desafortunado nombre español. También se asume cierto soltura en la línea de comandos y el manejo de algún editor de textos como joe, nano, vi, etc.

Vamos a empezar viendo algunas configuraciones básicas, pero no todas para no aburrir. En esta entrada terminaré instalando la primera aplicación (OwnCloud) para abordar en la siguiente lo que quede de seguridad y el resto de las aplicaciones.

Todo lo que voy a hacer va sobre Debian 7 64bit así que si usas otro sistema puede que haya diferencias, sobre todo si no es derivado de Debian.

Usuarios y grupos

Hay que crear el usuario que tendrá acceso al servidor por SSH. Éste tendrá el mínimo privilegio posible y una vez dentro se hará login con el usuario root. La primera vez sí que nos conectaremos con el usuario root directamente. La empresa con quien termines contratando el servidor te dirá la IP y la contraseña de root.

ssh root@[IP]

Una vez que nos pida la contraseña y estemos dentro:

adduser [usuario]
groupadd – –system [grupo]
usermod -G [grupo] [usuario]

Hemos creado el usuario que queremos que tenga acceso a la máquina y hemos creado un grupo de de sistema. A continuación hemos añadido el usuario al grupo creado. Espero que no haga falta recordar que las contraseñas seguras combinan mayúsculas con minúsculas, sean largas (más de 10 caracteres al menos), tengan números y algún que otro símbolo que no sea letra ni número.

Idioma

Ajustamos el idioma para el sistemas y la localización.

1. Editar /etc/locale.gen y descomentar la línea es_ES.UTF-8 UTF-8. Guardar y salir.
2. Ejecutar locale-gen
3. Editar /etc/bash.bashrc y añadir al final la línea export LC_ALL=es_ES.UTF-8.

Todavía tendríamos que salir de la sesión y volver a entrar pero como lo haremos en el siguiente paso, seguimos…

Asegurar el acceso SSH

Es conveniente no permitir el acceso por SSH del usuario root, limitar el tiempo disponible para hacer el login y cambiar el puerto para evitar a los «script kiddies» que van por ahí simplemente buscando puertos SSH por defecto (puerto 22). Hay que editar el archivo /etc/ssh/sshd_config y buscar la siguientes líneas y dejarlas como aparece aquí:

• PermitRootLogin no
• LoginGraceTime 30
• Port [puerto]

Finalmente reiniciamos el servicio SSH y finalizamos la sesión:

service sshd restart
exit

Si desde nuestro equipo intentamos conectar con cualquier usuario al puerto estándar debería fallar:

ssh [IP]

Si intentamos conectar con el usuario root al puerto elegido también debería fallar:

ssh root@[IP] -p [puerto]

Y lo que debería funcionar es conectar con el usuario admitido y al puerto elegido:

ssh [usuario]@[IP] -p [puerto]

Una vez dentro podemos convertirnos en root. Lo que hace la opción – es proporcionar un entorno que se parezca lo máximo posible al del usuario que hizo login, por ejemplo teniendo definidas las variables de entorno que éste definió.

su –

Ponerle nombre a la criatura

Podemos hacer algo más divertido para variar. Para no tener que recordar la IP podemos contratar un nombre de dominio y apuntarlo hacia el servidor. El coste de un dominio de segundo nivel (org.es, nom.es, com.es, etc.) es ridículo. En Red Coruña (proveedor con el que trabajo muy bien) cuestan 1,45€ al año.

No puedo decir como se configura correctamente en cada panel de control de cada registrador de dominios, pero en esencia lo que hay que hacer es ir a la gestión de las zonas de DNS de tu registro. Esto se presentará como una lista tal que así:

• [nombre].org.es. NS ns1.redcoruna.com.
• [nombre].org.es. NS ns2.redcoruna.com.
• …
• [nombre].org.es. A [IP]

Para una introducción a las zonas DNS está [2]. En tu lista aparecerán un montón de entradas y la que tenemos que añadir es la última que está en negrita. Se trata de un registro tipo A (Address – (Dirección) registro que se usa para traducir nombres de servidores de alojamiento a direcciones IPv4) desde la URL elegida hacia la IP proporcionada por el proveedor de VPS. Guardaremos los cambios, pero no serán inmediatamente efectivos, se tienen que propagar por la jerarquía DNS y eso tarda generalmente no más de 24 horas, quizá se propague mucho antes. Con esto ya podríamos hacer, si por ejemplo eligiéramos nimbo como nombre:

ssh [usuario]@nimbo.org.es -p [puerto]

Algunos parámetros del kernel

¿quien dijo miedo? Vamos a habilitar e inhabilitar algunas cosas relacionadas con la red para mejorar la seguridad y la velocidad. Abriremos para edición el archivo /etc/sysctl.conf.

Descomentamos dos líneas que sirven para prever ciertos ataques de spoofing. Activa la verificación de la dirección de origen en las interfaces de red:

et.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

Descomentamos las dos líneas siguientes para no aceptar redirecciones ICMP (previene ataques Man In The Middle):

net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

Como no somos un router no tenemos porque reenviar redirecciones ICMP ni aceptar paquetes source de IP, descomentar:

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

Actualizamos los cambios del kernel directamente:

sysctl -p /etc/sysctl.conf

Actualizaciones desatendidas

No es nada recomendable actualizar un sistema completo en producción cada vez que existan actualizaciones como haríamos con nuestro PC de casa, pero sí es recomendable instalar con regularidad las actualizaciones de seguridad. Y qué mejor manera de hacerlo que instalarlas automáticamente.

aptitude install unattended-upgrades

Abrimos para edición el archivo /etc/apt/apt.conf.d/10periodic. Este es el archivo que se encarga de que se ejecuten las actualizaciones una vez al día. Añadimos las siguientes líneas:

APT::Periodic::Enable «1»;
APT::Periodic::Update-Package-Lists «1»;
APT::Periodic::Download-Upgradeable-Packages «1»;
APT::Periodic::AutocleanInterval «7»;
APT::Periodic::Unattended-Upgrade «1»;
APT::Periodic::RandomSleep «900»;

Ahora abrimos para edición el archivo /etc/apt/apt.conf.d/50unattended-upgrades. Al principio hay una sección llamada Unattended-Upgrade::Origins-Pattern { ... }. Dentro de ella hay patrones de orígenes de software que queremos que se actualicen automáticamente. Yo he descomentado los de seguridad, que en mi caso es la línea "origin=Debian,archive=stable,label=Debian-Security";.

Después de cambiar estos dos ficheros reiniciamos el servicio:

service unattended-upgrades restart

Y ya está listo. Podemos consultar los logs de vez en cuando para ver qué se hace. En mi caso se ve como el 18/07/2013 se actualizaron una serie de paquetes relacionados con php5.

cat /var/log/unattended-upgrades/unattended-upgrades.log | grep -i «are upgraded»

Con el resultado:

2013-07-18 02:24:29,106 INFO Packages that are upgraded: libapache2-mod-php5 php-pear php5 php5-cli php5-common php5-curl php5-gd php5-intl php5-mysql php5-sqlite

Apache, PHP, MySQL y OwnCloud

Ahora dejamos instalado Apache con soporte PHP y MySQL y les damos un repaso para hacerlo fuertes y seguros. Como paso final dejaremos funcionando nuestras primera aplicación en la nube, el gran proyecto OwnCloud [3] que sustituye a DropBox y similares: tus datos, tu control.

Apache con PHP

Una instalación básica es tan fácil como:

apt-get install apache2 apache2-mpm-prefork

Una visita a http://[IP] debería mostrar la página «It works!». El Apache está corriendo, vamos a instalar el módulo de PHP5. Recuerdo lo complicado que se hacía esto hace unos años. Hoy no hay que tocar ni una línea en ningún archivo. Si se instala PHP desde los repositorios los scripts de instalación te configuran el módulo y hasta te recargan el Apache.

apt-get install php5 – –install-suggests

En este caso instalamos también los paquetes sugeridos porque nos pueden ser de utilidad. Ahora debería estar funcionando Apache + PHP5. Para comprobarlo hacemos lo siguiente:

cd /var/www
touch phpinfo.php
chown www-data:www-data phpinfo.php

Se ha creado un archivo y cambiado el propietario a www-data y el grupo www-data, que es el usuario bajo el que se ejecuta Apache. Un servidor web nunca debe correr como root y es aconsejable que se ejecute con un usuario determinado con los mínimos privilegios posibles. Abrimos el archivo para edición y escribimos la línea siguiente:

<?php phpinfo(); ?>

Guardamos los cambios y realizamos una visita a http://[IP]/phpinfo.php. La página resultante prueba que PHP está funcionando y además aporta mucha información útil sobre tu instalación en lo que se refiere a rutas, módulos instalados y datos del entorno. Aunque recomiendo borrar phpinfo.php ya que podriá convertirse en una ayuda a un posible atacante. Lo podemos crear en cualquier momento rápidamente.

Vitaminando y mineralizando Apache

El conocimiento de esta sección ha sido extraído principalmente de una magnífica serie de artículos en [4]. Vamos a ver lo que se puede aplicar a este caso.

Hay módulos de Apache instalados por defecto que pueden no ser necesarios. Solo quitaremos aquéllos de los cuales estamos seguros que no vamos a necesitar. Se quitan porque cada extra en un sistema es un sitio más donde atacar. Siempre lo podemos volver a activar cuando lo necesitemos. Un modo de saber qué módulos están activos es invocar el script de inhabilitar módulos (pulsar Ctrl+C si no queremos inhabilitar ninguno en ese momento).

a2dismod

Cada uno verá lo que quiere desactivar. Hay que tener en cuenta las diferencias de versiones de Apache. En versiones más antiguas que la que estoy usando en Debian 7 (la 2.2.22-13) pueden venir activados módulos que yo tengo desactivados por defecto, pero que es conveniente quitar. En mi caso voy a hacer:

a2dismod status
a2dismod cgi
a2dismod autoindex
a2dismod proxy_http
a2dismod proxy
service apache2 restart

La información de lo que hacen todos los módulos de Apache se puede encontrar en [5]. Para activar módulos está el programa a2enmod.

Vamos a tocar algunos parámetros del servidor. Abrimos para edición el archivo /etc/apache2/apache2.conf y dejamos como aparece aquí la siguientes línea:

Timeout 50

Reducir el TimeOut puede ayudar a prevenir ataques de denegación de servicio.

Ahora abrimos el archivo /etc/apache2/conf.d/security. En primer lugar modificamos ServerTokens. Esto configura el nivel de información del servidor que viaja en las cabeceras HTTP de respuesta. Cuanto menos se sepa mejor y por tanto comentamos todas las líneas descomentadas y añadimos nosotros:

ServerTokens Prod

Que es la configuración de mínima información para entornos de producción. Podemos ver cuanta información envía el servidor antes y después de este cambio con el plugin de firefox Live HTTP Headers [6]. En mi caso si pongo ServerTokens Full salen 18 líneas de información variada y jugosa para atacantes, entre ellas:

Server: Apache/2.2.22 (Debian) PHP/5.4.4-14+deb7u3
X-Powered-By: PHP/5.4.4-14+deb7u3

Ahora configuro a ServerTokens Prod. Después de cada cambio hay que reiniciar el servidor (service apache2 restart). Solo salen 9 líneas de información y respecto al software de servidor dice un escueto:

Server: Apache

Esto evita que los atacantes intenten aprovecharse de vulnerabilidades conocidas de determinadas versiones del servidor web, php o del sistema operativo. Ya no pueden ir a lo seguro. Finalmente, también en el archivo security, descomentamos las tres últimas líneas que comienzan por Header y dejamos si no lo está ServerSignature Off.

Vamos al modo paranoico, quitando por defecto el acceso a todo el sistema de directorios. Así, los accesos que se necesiten se van concediendo más tarde aplicación por aplicación. Para ello tenemos que descomentar (ya va siendo hora de que la RAE agregue este palabro) lo siguiente en el archivo /etc/apache2/conf.d/security:

<Directory />
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

Para terminar reiniciamos el servidor.

service apache2 restart

MySQL

Vamos con la instalación:

apt-get install mysql-server

Hay una serie de recomendaciones de seguridad tras la instalación limpia de MySQL que se resumen en la ejecución de programa que te lo hace todo:

mysql_secure_installation

Que te permitirá hacer:

• Establecer contraseña para la cuenta de root. Hazla muy segura y recuérdala bien.
• Eliminar cuentas de usuarios anónimos.
• Eliminar las bases de datos de test.

Aquí dejamos por ahora MySQL y en la primera aplicación veremos un ejemplo de como crear usuarios y tablas. Ese ejemplo nos valdrá para cualquier aplicación posterior que instalemos.

La primera aplicación: OwnCloud

Lo primero que instalemos es casi evidente. Creo que en lo primero que se piensa es en tener un sustituto de DropBox y similares. Uno al que no le tengas que ceder obligatoria y subrepticiamente los derechos de tus propios documentos y en los que no tengas la seguridad absoluta de cómo se están tratando y con qué fin.

Ahí entra en juego el tremendo esfuerzo de OwnCloud. Si vamos a owncloud.com tenemos a la vertiente empresa con soporte comercial. Si vamos a owncloud.org llegamos a la parte interesante. Se trata del mismo software que da soporte a owncloud.com libre y gratuitamente descargable. Puedes probarlo antes para trastear un poco. Comenzamos:

cd /var/www
wget http://download.owncloud.org/community/owncloud-5.0.10.tar.bz2
tar xjf owncloud-5.0.10.tar.bz2
chmod -Rf www-data:www-data owncloud

Hay varias formas de instalarlo y he elegido la manual. Así que vamos a ir instalando las dependencias:

apt-get install php5-gd php-xml-parser php5-intl
apt-get install php5-sqlite php5-mysql php5-pgsql smbclient curl libcurl3 php5-curl

Ahora hay que activar un módulo de Apache que se encarga de reescribir URLs y se usa mucho en OwnCloud:

a2enmod rewrite
service apache2 restart

Esto último no es estrictamente necesario pero nos puede venir bien en el futuro si queremos separar los sitios web en un mismo apache. No es lo mismo tener subdirectorios dentro de la aplicación por defecto que tener varios sitios con configuraciones personalizadas. Para ello hacemos lo siguiente:

touch /etc/apache2/sites-available/owncloud

Y luego abrimos owncloud con nuestro editor favorito y metemos una configuración básica como:

<Directory /var/www/owncloud/>
AllowOverride all
</Directory>

Guardamos el archivo y activamos el sitio en la configuración de Apache:

a2ensite owncloud
service apache2 reload

Vamos a crear ahora la base de datos. Tenemos que recordar bien la contraseña de root de MySQL y que sea muy segura. Y también tenemos que recordar o apuntar en algún sitio las contraseñas de las diversas bases de datos que se vayan creando. Por el principio de mínima exposición, cada base de datos llevará su usuario MySQL distinto y solo tendrá permisos para esa base de datos. Los pasos que haremos aquí serán similares para cualquier base de datos MySQL que tengamos que montar en el futuro:

mysql -uroot -p
create database owncloud
grant all privileges on owncloud.* to ‘[USUARIO]’ identified by ‘[CONTRASEÑA]’
flush privileges
exit

El usuario y contraseña que elijamos son para que la aplicación owncloud se conecte a la base de datos y no tiene nada que ver con el usuario con el que finalmente accedamos nosotros a owncloud. Pero conviene elegir una contraseña segura y apuntarla en algún lugar que no sea el propio servidor claro 🙂 Finalmente estamos en disposición de ir a http://[IP]/owncloud y completar el proceso de instalación [7]. Cuando nos conectemos por primera vez nos dará opción de descargar programas de sincronización para todas las plataformas móviles y no móviles y así tendremos nuestro sustituto de dropbox y similares bajo nuestro exclusivo control.

Esta entrada se me ha hecho más larga que a Enjuto un día sin internet y creo que a vosotros también así que vamos a dejarlo aquí y en la próxima entrega vamos a seguir mejorando la seguridad y seguiremos instalando más aplicaciones interesantes: cliente web de chat xmpp -jabber-, sustituto de delicious, sustituto de google reader y muchas cositas más.

Espero que no haya nada que chirríe demasiado a los cracks de la seguridad y de sistemas en general. Si es así por favor indicadlo educadamente, que yo también estoy aprendiendo, y lo corregiré.

Referencias:

1. Artículo «Servidor de Juegos» de la revista Linux Magazine en su número 84. Recomiendo la subscripción a esta gran revista, la edición digital sale muy bien de precio. Aquí hay una muestra en la Edición Comunidad gratuita con licencia CC
2. DNS en Wikipedia
3. OwnCloud
4. Fortificar Apache
5. Módulos de Apache 2.22
6. Live HTTP Headers
7. Instalación manual owncloud (inglés)

Perpetrado el 03 de septiembre de 2013 por una IN (Inteligencia Natural), la mia, con cierto esfuerzo.

Archivado en categoría(s) GNU/Linux, Internet, Seguridad, Software Libre, Tecnología