Asegurar un servidor privado virtual (II) - El sistema operativo

La seguridad en un servidor hay que verla como un conjunto que está formado por piezas pequeñas. Si una de esas piezas falla, el conjunto se ve comprometido. Podemos encontrar varias de estas piezas en un servidor privado virtual (VPS). La primera es el sistema operativo. Su función es gestionar todos los elementos del sistema y proporcionar la infraestructura al contenido que ve un usuario. Para mostrar la información al usuario es necesario abrir puertos por los que se manda la información. El último elemento es el gestor de contenidos que muestra la información al usuario.

Es necesario que todas las partes estén bien protegidas para evitar problemas. Hay dos tipos de servidores dependiendo de si están en pre-producción o en producción. La diferencia entre ambos es que en el primero podemos hacer pruebas mientras que en el segundo las pruebas están prohibidas. Un error en un servidor de producción puede afectar al contenido que mostramos al usuario. Si no tenemos un servidor de pre-producción podemos usar una máquina virtual para las pruebas. Podéis preguntar cualquier duda en los comentarios del artículo o bien en las redes sociales.

Autor de la fotografía del artículo: Bob Mical

El sistema operativo

Las distribuciones de GNU/Linux pueden ser de dos tipos dependiendo de la duración que tenga el soporte. Por ejemplo, Ubuntu 13.10 tiene 6 meses de soporte, en cambio Ubuntu 14.04 tiene 5 años de soporte. La cifra aumenta si usamos CentOS 6 que tiene soporte hasta finales de 2020. A diferencia de un PC de escritorio, un VPS necesita una distribución con un tiempo de soporte grande. En principio puede parecer poco importante este factor, pero hay que recordar que junto con el sistema operativo tenemos muchas aplicaciones asociadas. Actualizar el sistema cada 6 meses puede darnos trabajo extra que no tendríamos que realizar si usáramos Ubuntu 14.04 o CentOS 6.4. Es mejor hacer el trabajo una vez cada varios años que repetirlo dos veces al año.

El tiempo de soporte es importante por las actualizaciones. Llamamos ventana de tiempo al tiempo que pasa desde que se descubre un fallo de seguridad hasta que el fabricante lo arregla. Si usamos una distribución que no tiene soporte ese tiempo no tiene limite y tendremos un equipo vulnerable a los ataques. Aparte de la ventana de tiempo que he comentado, existe otro intervalo de tiempo variable que pasa hasta que aplicamos la actualización. Para reducir este tiempo lo más sencillo es configurar el sistema para que aplique de forma automática las actualizaciones. Es suficiente con actualizar cada 12 / 24 horas. Normalmente lo haremos en las horas que el servidor tenga menos carga. Si hay una actualización de Apache, MySQL o de aplicaciones similares el servidor estará parado durante ese tiempo.

Configurar la actualización automática del sistema operativo

Los pasos para configurar las actualizaciones automáticas dependen de si usamos Debian / Ubuntu o Fedora / CentOS. La idea es simple y consiste en ejecutar el comando que actualiza el sistema en una tarea de cron. Cron es una aplicación que permite programar acciones en intervalos de tiempo concretos. Por ejemplo, podemos ejecutar un comando cada 12 o 24 horas dependiendo de las necesidades que tengamos. El siguiente ejemplo corresponde a Ubuntu pero será similar en Fedora / CentOS.

sudo apt-get install cron-apt

Una vez está instalado, tenemos el archivo de configuración en la ruta /etc/cron.d/cron-apt. Lo podemos editar con nano

nano /etc/cron.d/cron-apt

El contenido del archivo es el siguiente:

# Regular cron jobs for the cron-apt package # # Every night at 1 o'clock. 0 1 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt # Every hour. # 0 * * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

Las líneas que se ejecutan son las que no están comentadas con #. El primer dígito indica el día de la semana en el que se ejecutará el comando. En este caso (0) se ejecutará todos los días. El siguiente valor corresponde a la hora. En el ejemplo el sistema pondrá las actualizaciones todos los días a la 1 de la mañana. La hora corresponde a la hora del servidor por lo que tendremos que asegurarnos que la hora local y la del servidor coincide.

Si se encuentran en diferentes zonas horarias es posible cambiar la zona horaria con el comando

sudo dpkg-reconfigure tzdata

Selección de la zona horaria

Zona horaria dentro de Europa

Después de cambiar la hora hay que reiniciar cron para que trabaje con la nueva zona horaria

sudo service cron restart

Las conexiones

En GNU/Linux tenemos dos tipos de usuarios en el sistema. Por una parte tenemos los usuarios normales que sólo tienen permisos de escritura en su carpeta de usuario. Por otra parte tenemos el usuario root, que es el administrador del sistema y tiene acceso total. Cuando trabajamos con un VPS no tenemos acceso físico a la máquina y trabajamos con una conexión remota por SSH. Al mismo tiempo que nosotros usamos esa conexión, muchos atacantes intentarán acceder de esta forma. Para ello utilizarán el usuario root y contraseñas genéricas que se encuentren en un diccionario de palabras. Si hemos usado una contraseña que sea una palabra conocida es cuestión de tiempo que accedan al sistema.

Hay varias formas de protegerse de estos accesos que veremos en el siguiente artículo. La primera consiste en crearnos un usuario nuevo en el sistema y con permisos para usar sudo (conseguir permisos de root). El siguiente paso es obvio y consiste en desactivar el acceso como root. Con estas dos medidas evitamos la mayor parte de los accesos. La tercera medida consiste en el bloqueo de una dirección IP si falla varias veces la contraseña. Si tomamos las tres medidas conseguiremos asegurar la conexión SSH. No son las únicas formas de protegernos. Existe una aplicación llamada DenyHost que se encarga de analizar los registros del sistema para detectar patrones o detectar intrusiones. También podemos filtrar las conexiones por país para evitar la mayoría de intentos.

Un certificado digital es un archivo que tiene una parte pública y una privada que básicamente nos identifican ante un tercero (de forma muy simplificada). Podemos usarlos al conectarnos con el servidor de forma que si la conexión entrante al servidor no se identifica con el certificado digital no podrá hacer nada aunque conozca nuestra contraseña. El inconveniente de este método es que si perdemos los archivos tampoco podremos acceder nosotros al servidor.