Securizando un VPS

Hace ya tiempo que busqué y alquilé el VPS (Virtual Private Server) más barato que pude encontrar, animado por dabo, que mantenía (y con razón) que por unos euros al mes tienes un juguete con el mantenerte bastante en forma en esto del sysadmining. Tras darle muchos usos, alguno incluso para el que no estaba preparado y no podía con ellos, se quedó con un apache2 y un par de blogs en wordpress durante el último año. Pero he decidio hacer de él un servidor de provecho y eso pasa por una reinstalación (aka limpieza) y configuración.

Ésta es una guía no exhaustiva de los pasos que sigo para dejar el servidor un poco más seguro tras la instalación.

1. Reinstalar el VPS

Desde el panel de control del VPS (al menos en mi caso), elijo una Debian GNU/Linux 8 de 64 bits y le digo que si, que estoy seguro de que se puede cargar el servidor y reinstalar. Al cabo de unos minutos asigno una nueva contraseña de root y me conecto por ssh.

2. Cerrar puertos abiertos (de más)

Ejecuto netstat -pta y detengo todos aquellos servicios que no sean ssh. En este caso, apache2 y postfix. En alguna ocasión me he encontrado con un montón de servicios instalados y funcionando, algunos de ellos inseguros por definición, así que antes de seguir, cerrojo.

3. Borrado de paquetes

Igual que con los servicios funcionando (o precisamente por eso), hay bastantes paquetes que a mi juicio sobran y que desinstalo por real decreto. Y si, algunos de los paquetes que elimino los instalaré más tarde pero será bajo demanda, porque decido instalar el servicio y configurarlo y no porque tenga que venir preinstalado. Llamadme exagerao pero, en un VPS donde no puedes instalar un escritorio, ¿para qué hacen falta fuentes truetype?

En esta ocasión, partí de una lista total de 380 paquetes y los reduje hasta los 290. La lista la genero mediante el comando:

Normalmente, en otra pestaña del terminal abro otra sesión ssh y creo un alias para que sólo sea copiar y pegar nombres de paquetes.

La lista de paquetes eliminados es:

Y para eliminar varios paquetes que empiezan por el mismo nombre, como las fuentes, unas cuantas tuberías y listo.

4. Creación y configuración de un usuario

Lo de conectarse como rootnunca ha sido una opción así que una de las primeras acciones es crear un usuario con el que conectarse.

No voy a explicar porqué debe usarse sudo porque, como decía un profe en la universidad “es de sentido común”.

5. SSH

Si ejecutamos nmap sobre sobre el propio servidor descubriremos que ssh es un chivato de cuidado.

Así que para vamos a pedirle que de menos información y a evitar que root pueda iniciar sesión a través de este protocolo.

Ahora estará un poco más callado :).

6. NTP

El VPN que estoy configurando está situado en la costa oeste americana a siete horas de diferencia y eso puede (y lo hace, vaya si lo hace) complicar bastante las cosas. Así que se impone el ajuste de la zona horaria y la instalación de un servidor de hora.

7. Securización extra

1. portsentry

No está de más tener un perro guardian que vigile todos los recovecos de la casa y eso precisamente hace portsentry. Audita los puertos inactivos del sistema en busca de actividad e informa si la encuentra donde no debe.

Si ejecutamos un netstat -pta veremos que hay servicios que antes no estaban y que ni tan siquiera están instalados, como finger.

2. logwatch

Un estupendo servicio que lee los logs del sistema y nos avisa en caso de que algo no le cuadre. Es un poco pesado en la configuración pero merece mucho la pena. Unas excelentes guías para la configuración de logcheck son las de Un pingüino en mi ascensor: Vigilando los logs con logcheck (I) y Vigilando los logs con logcheck (II).

3. maldet

maldet es un software muy interesante que escanea en busca de malware, se actualiza automáticamente y emite unos informes con todos los cambios que encuentra y que pueden ser de interés. No tiene paquete debian por lo que se descarga e instala.

En este punto tenemos un directorio, /usr/local/maldetect con el software instalado, por eso se borra el directorio de instalación en la última línea.

Lo configuramos y ejecutamos.

4. iptables (o ufw)

A estas alturas un firewall resulta imprescindible, ya estés configurando un servidor en el otro lado del mundo o una raspberry pi para tu red local. De hecho, es más importante en el caso de la raspi porque el servidor está protegido por la empresa que te lo alquila. Haz la prueba, instala ufw en tu raspi y échale un ojo a los logs, te garantizo que querrás llorar. Si iptables te asusta (a mí me pasó durante un tiempo), instala ufw que es su cara amable y de lenguaje llano. Si no te asusta, usálo a discrección porque es uno de esos programas sin los que linux estaría cojo.

Aquí dejo el script con las reglas para ufw que uso en una de mis raspberries.

Y hasta aquí, la configuración básica. Obviamente se complica cuando instalamos algún servicio porque hay que habilitarlo en el firewall, configurarlo adecuadamente y ajustar algunas cosas más. Pero esa es la magia de este juego al que es difícil cansarse de jugar.

 

Diego Martínez Castañeda

linux user, debian user, blogger, podcaster, geek, nerd y escritor sin ideas, nadador sin ganas y ciclista convencido. Asturiano en Mérida.

 

11 thoughts on “Securizando un VPS

  1. Gran post, lo guardo para algunas referencias como el tema de limpiar paquetes/procesos innecesarios . Por que siempre es bueno ver un TOP limpio 😀 .

    Podrás comentar que servicio estas usando? (entiendo si lo queres reservar) . Últimamente estuve utilizando el “Oceano Digital” (:p) y estuve teniendo bastantes probleams con el tema de mail y reputación de ip. La respuesta de ellos es que alquilan servidores para desarrollo y no se hacen cargo de eso (tienen razon en parte).

    Como siempre gracias por el post, siempre viene bien ver como trabajan otros para aprender algo nuevo.

    Saludos!

    1. ¡Hola!

      un top limpio no sólo es bueno, es un pequeño placer :D.

      No tengo ningún inconveniente en comentar qué servicio uso, lo que no quería es hacerles publicidad de buenas a primeras sin que me dieran mi parte por desviar tanto tráfico :D. Se llama URPad.net y fueron los más baratos cuando me puse a buscar un VPS. Tengo que añadir que lo busqué fuera de la UE para evitar el IVA porque el mismo servicio salía un veintitantos más caro dentro de Europa y como no alojo nada que necesite ser declarado, me salía más a cuenta.

      El único inconveniente, que ahora ya lo mencionan en la web y antes no, es que la RAM real del VPS son 512 MB y tienes otros 512 MB de swap para usar pero que no te da el mismo rendimiento ni de casualidad (no es RAM, ¿cómo podría?). También está el hecho de que usan KVM y todo está en un fichero, no puedes crear particiones, por ejemplo, algo deseable para según qué servicios. Pero para un uso normal, es recomendable.

      Como siempre, la idea que subyace bajo todas estas entradas laaaaargas es mostrar cómo hago ciertas cosas y aprender de otros, así que estoy encantado de que haya servido en su propósito :D.

      saludos,
      diego

  2. Ahí te veo compañero ! Eso es empezar en un entorno “limpito” ;).

    Por aportar algo al post (que me encanta como bien sabes). Para mejorar el rendimiento y quitar carga al sistema / Apache.

    aptitude install php5-xcache memcache | en la conf de xcache no hay que tocar mucho salvo tamaño del cache, variable y poco más (en /etc/php5/conf.d) y a memcache con los 64 mb que se instala va bien aunque algo más según tipo de VPS se puede usar.

    Para además de que no accedan como root vía ssh echo de menos algo tipo Denyhosts que si bien está fuera de Jessie, se instala sin problema con algún pequeño hack y ya trabaja con iptables, install: http://bit.ly/1PcmHqy

    De otro modo, Fail2ban en su conf básica ya para intentos de conexión / ataque hacia SSH (y otros muchos más servicios pudiendo añadir expresiones regulares en las diferentes “jails”).

    Estaría bien repasar temas de configuración y servers arrancados en Apache y en /etc/apache2/conf-enabled editar el fichero security.conf y:

    ServerTokens Prod
    ServerSignature Off

    Para no revelar la versión de Apache tras un reload (prometo en un post explicar las diferencias de Apache 2.2 y 2.4 que es el que tenemos en Debian 8). También está bien pasar por la conf de PHP y en php.ini dejar expose_php a off para que no cante versiones de PHP / Apache y en disabled_functions dejarlo así: (e ir abriendo si hace falta alguna función)

    disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,system, exec, passthru, shell, shell_exec, popen, pclose, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, phpinfo, proc_open, show_source, passthru

    Sin olvidar pasar por /etc/mysql/my.conf y repasar un poco la conf de MySQL ayudados por MySQLtuner (aptitude install mysqltuner) buena info de apoyo aquí: http://www.jabenitez.com/2013/09/27/mysql-optimizacion-de-la-configuracion-del-servidor-y-utilidades-interesantes/

    Y para acabar, sobre logwatch que lo has mencionado, mi consejo es que actives la opción “html” en la salida del fichero. Verás que bien llega todo ordenadito en el mail

    Un abrazo y buen trabajo bro !!!

  3. ¡Dabo que grande eres! Sin peloteo. Bueno, porque voy a mentir, un poco si… xD

    Gracias por tus consejos. ¡Sigue así en tu línea!

    Saludos,

  4. Otra mejora posible es que toda esta configuración la integres en un gestor de configuración (Puppet, Chef, Ansible…), incluso aunque sólo tengas una máquina.

    Con esto ganas (entre otros) que toda la «descripción» de la configuración de tu servidor esté definida en un mismo lugar. Esto incluye entre otras muchas cosas qué paquetes deben estar, qué paquetes deben no estar, qué tienen que contener los archivos de configuración, etc. Esta descripción se convierte en versionable si la gestionas con git, subversion o similar.

    Reinstalar el servidor (o una réplica) se reduce así a instalar el sistema base, instalar el gestor de configuración con la definición de tu servidor, y dejar que él te lo deje en el estado en el que debe estar todo (únicamente deberás recuperar los datos desde backup).

    Muy interesante maldet, no conocía.

    1. hola Alberto.

      El uso de gestores de configuración, puppet concretamente, está en mi libreta de cosas por hacer por lo que tu explicación me ha venido muy bien, gracias. Entiendo que lo ideal sería usarlo con un git debajo.

      Esta mañana me han recomendado por twitter lynis, como auditor del servidor, por si no lo conocías tampoco.

      saludos!

Comments are closed.