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:
dpkg -l | grep ^ii > lista_paqs
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.
alias k='aptitude purge'
La lista de paquetes eliminados es:
apache2 apache2-data apache2-mpm-prefork apache2-utils apache2 apache2-data apache2-mpm-prefork apache2-utils apache2-bin apache2-doc bind9 bind9-host bind9utils postfix bsd-mailx bsdmainutils man-db cifs-utils cpio ed expat fetchmail finger fontconfig-config fontconfig ftp info install-info isc-dhcp-client isc-dhcp-common ldap-utils lynx lynx-cur m4 make makedev man-db manpages memtester mime-support mlocate net-tools odbcinst odbcinst1debian2:amd64 unixodbc patch postfix python quota samba samba-common samba-common-bin samba-dsdb-modules samba-libs:amd64 python-samba sasl2-bin sharutils wide-dhcpv6-client snmp syslinux tcpdump tcsh telnet tdb-tools tofrodos traceroute xinetd
Y para eliminar varios paquetes que empiezan por el mismo nombre, como las fuentes, unas cuantas tuberías y listo.
dpkg -l fonts* | grep ^ii | awk '{print $2}' | xargs aptitude purge -y
dpkg -l ttf* | grep ^ii | awk '{print $2}' | xargs aptitude purge -y
dpkg -l gcc* | grep ^ii | awk '{print $2}' | xargs aptitude purge -y
4. Creación y configuración de un usuario
Lo de conectarse como root
nunca ha sido una opción así que una de las primeras acciones es crear un usuario con el que conectarse.
adduser diego
No voy a explicar porqué debe usarse sudo
porque, como decía un profe en la universidad «es de sentido común».
aptitude install sudo
adduser diego sudo
chmod -R 700 /home/diego
5. SSH
Si ejecutamos nmap
sobre sobre el propio servidor descubriremos que ssh
es un chivato de cuidado.
diego@tola:~$ sudo nmap -sS -sV -P0 123.456.789 | grep ssh
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u1 (protocol 2.0)
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.
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
echo 'DebianBanner no' >> /etc/ssh/sshd_config
/etc/init.d/ssh restart
Ahora estará un poco más callado :).
diego@tola:~$ sudo nmap -sS -sV -P0 123.456.789 | grep ssh
22/tcp open ssh OpenSSH 6.7p1 (protocol 2.0)
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.
$ date
mar mar 15 18:36:25 EDT 2016
$ sudo dpkg-reconfigure tzdata
$ sudo aptitude install ntp
$ sudo /etc/init.d/ntp restart
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.
sudo aptitude install portsentry
sudo /etc/init.d/portsentry restart
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).
sudo aptitude install logcheck
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.
wget http://www.rfxn.com/downloads/maldetect-current.tar.gz
sudo tar xvfz maldetect-current.tar.gz -C /usr/local
sudo /usr/local/maldetect-1.5/install.sh
sudo rm -r /usr/local/maldetect-1.5
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.
sudo vi /usr/local/maldetect/conf.maldet
sudo sed -i 's/email_addr="[email protected]"/email_addr="[email protected]"/g' /usr/local/maldetect/conf.maldet
sudo /usr/local/maldetect/maldet -a
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.
#!/bin/bash
# script con las reglas del firewall para raspberry pi
# Diego Martínez Castañeda
sudo ufw allow 22 # ssh
sudo ufw allow 53 # dns
#sudo ufw allow 25 # smtp
#sudo ufw allow 110 # pop3
#sudo ufw allow 80/tcp # http
#sudo ufw allow 443/tcp # https
sudo ufw allow 9090/tcp # transmission
# por defecto, denegar
sudo ufw default deny
# listar reglas de forma numerada
sudo ufw status numbered
exit 0
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.
11 ideas sobre “Securizando un VPS”
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!
¡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
Gracias por el dato!
Es bueno ver actividad frecuente por esta pagina 😉 !
Saludos !
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 !!!
jooooder… ese comentario lo pones en una entrada y lo petamos :D.
A ver si hago algo con Apache en plan «Parte II» 😉
¡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,
La próxima prueba con debian 8 64 bits minimal, y te ahorras que instale apache2 y alguna morralla mas 🙂
creo recordar que era la versión mínima o que para 64 bits no había esa versión. De todas formas, estoy seguro que no era una instalación completa porque esas sí recuerdo haberlas descartado de mano.
saludos!
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.
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!