Si tienes un servidor Linux público, ya sea un VPS o un servidor dedicado, lo primero que tienes que hacer nada más comprarlo e instalarlo, es securizarlo.
De esta manera te evitaras sorpresas y ataques que son muy frecuentes, y descansaras un poco más tranquilo por las noches.

Para empezar, recomiendo totalmente utilizar un Firewall para tan solo escuchar a través de los puertos que necesitemos, y lo podemos hacer muy fácilmente con IPTABLES.

Sigue esta guía para hacerlo fácilmente -> Protege tu servidor con CSF y IPTables

 

 

Fail2Ban

Bloquea cualquier acceso no deseado

 

Lo primero, instalar Fail2Ban. Es el software principal para evitar accesos no deseados y ataques en tu servidor. Si tienes un Debian/Ubuntu, como siempre, solo tienes que ejecutar este comando:

[terminal]sudo apt-get install fail2ban[/terminal]

Una vez instalado, yo recomiendo endurecer un poco la configuración para que los baneos se hagan más pronto y duren más.
Para ello editaremos el fichero /etc/fail2ban/jail.conf

[terminal]sudo nano /etc/fail2ban/jail.conf[/terminal]

Una vez dentro, cambiaremos el valor de maxretry a las veces se pueda fallar al poner la contraseña, por defecto 6, yo lo suelo poner en 3.
Después tenemos el tiempo de baneo, que esta en 600 segundos, y yo, sin dudarlo, le añado un 0: 6000 segundos.

[terminal]bantime = 6000
maxretry = 3
[/terminal]

Si queremos añadir una IP a la whitelist, para que no se banee aunque se fallen más de 2 veces (una IP local, o si tienes una IP estática en casa o el trabajo) lo añadiremos en la linea ignoreip, separado por espacios:

[terminal]ignoreip = 127.0.0.1/8 192.168.1.1./24 80.80.80.80
[/terminal]

Ahora, si quieres ver un log de las IP’s que se van baneando, ejecuta este comando:

[terminal]sudo tail -f /var/log/fail2ban.log[/terminal]

 

 

Acceso SSH

Deshabilita el acceso a root y cambia el puerto

Es totalmente recomendable, y casi obligado, quitar el acceso por SSH con el usuario root, ya que la mayoría de robots de fuerza bruta es el primer usuario que prueban, y que si aciertan, les daria permisos de superuser. Así que, creamos un usuario nuevo para las conexiones por SSH, por ejemplo pepito.

[terminal]adduser pepito
[/terminal]

Le asignamos una contraseña segura y le damos permiso para ejecutar sudo y elevar permisos. Para ello, editamos el fichero sudoers:

[terminal]nano /etc/sudoers
[/terminal]

Y añadimos la siguiente linea:

[terminal]pepito ALL=(ALL:ALL) ALL[/terminal]

Guardamos, y ahora vamos a deshabilitar el usuario root por SSH, para ello, editamos el fichero de configuración del mismo:

[terminal]nano /etc/ssh/sshd_config[/terminal]

Y cambiamos la siguiente linea de yes a no:

[terminal]PermitRootLogin no[/terminal]

Ahora, añade al archivo el usuario pepito para que puedas acceder por SSH:

[terminal]AllowUsers pepito[/terminal]

Y si puedes, cambia el puerto para acceder, ya que el 22 es el por defecto, y casi todos los bots intentan atacar a ese puerto, así que escoge otro (en el ejemplo, el 2222):

[terminal]Port 2222[/terminal]

Recuerda permitir el puerto que hayas puesto en el Firewall, antes de reiniciar el servicio y te deje fuera.

 

 

Mod Security

Detecta ataques en tu servidor web

Para proteger tu servidor web frente a ataques contra tus sitios e inyecciones de SQL, la mejor opción es el modulo Mod Security para Apache.
Para instalarlo, es tan sencillo como ejecutar en tu terminal:

[terminal]apt-get install libapache2-modsecurity[/terminal]

O dependiendo de la versión de Apache que tengas, la versión 2:

[terminal]apt-get install libapache2-mod-security2[/terminal]

Una vez instalado, usaremos la configuración por defecto, que ya viene en un archivo que debemos renombrar:

[terminal]mv /etc/modsecurity/modsecurity.conf{-recommended,}[/terminal]

Y reiniciamos el servicio:

[terminal]service apache2 reload[/terminal]

Ya encontraremos el fichero de log en el sistema:

[terminal]ls -l /var/log/apache2/modsec_audit.log[/terminal]

Ahora modificaremos las opciones del archivo de configuración, ya que por defecto el modulo no bloquea nada, solo detecta. Para ello abriremos el archivo:

[terminal]nano /etc/modsecurity/modsecurity.conf[/terminal]

Y buscaremos la siguiente opcion:

[terminal]SecRuleEngine DetectionOnly[/terminal]

Y la dejaremos en On:

[terminal]SecRuleEngine On[/terminal]

Otra directiva para modificar es SecResponseBodyAccess. Esto configura si los «response bodies» se almacenan en búfer. Esto solo es necesario si se requiere detección y protección contra fugas de datos. Por lo tanto, dejarlo activado utilizará más recursos y también aumentará el tamaño del archivo de log. Así que buscaremos esta opción:

[terminal]SecResponseBodyAccess On[/terminal]

Y la dejaremos así:

[terminal]SecResponseBodyAccess Off[/terminal]

También podemos modificar el limite de tamaño para el post en el servidor web, cambiando los valores de estas opciones:

[terminal]SecRequestBodyLimit[/terminal]
[terminal]SecRequestBodyNoFilesLimit[/terminal]

Para hacerte la vida más fácil, hay muchas reglas que ya están instaladas junto con mod_security. Se llaman CRS (Core Rule Set) y se encuentran este directorio:

[terminal]ls -l / usr / share / modsecurity-crs /
total 40
drwxr-xr-x 2 root root 4096 Oct 20 09:45 activated_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 base_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 experimental_rules
drwxr-xr-x 2 root root 4096 Oct 20 09:45 lua
-rw-r – r– 1 root root 13544 2 jul 2012 modsecurity_crs_10_setup.conf
drwxr-xr-x 2 root root 4096 Oct 20 09:45 optional_rules
drwxr-xr-x 3 root root 4096 oct. 20 09:45 util[/terminal]

La documentación está disponible en

[terminal]ls -l / usr / share / doc / modsecurity-crs /
total 40
-rw-r – r– 1 root root 469 jul 2 2012 changelog.Debian.gz
-rw-r – r– 1 root root 12387 18 de jun. de 2012 changelog.gz
-rw-r – r– 1 root root 1297 jul 2 2012 copyright
drwxr-xr-x 3 root root 4096 Oct 20 09:45 ejemplos
-rw-r – r– 1 root root 1138 Mar 16 2012 README.Debian
-rw-r – r– 1 root root 6495 Mar 16 2012 README.gz[/terminal]

Para cargar estas reglas, debemos decirle a Apache que busque en estos directorios. Edite el archivo modsecurity.conf.

[terminal]nano /etc/apache2/mods-enabled/modsecurity.conf[/terminal]

Agrega las siguientes directivas dentro de <IfModule security2_module> </ IfModule>:

[terminal]include «/usr/share/modsecurity-crs/*.conf»
include «/usr/share/modsecurity-crs/activated_rules/*.conf»[/terminal]

El directorio activated_rules es similar al directorio de mods habilitado de Apache. Las reglas están disponibles en directorios:

[terminal]/ usr / share / modsecurity-crs / base_rules
/ usr / share / modsecurity-crs / optional_rules
/ usr / share / modsecurity-crs / experimental_rules[/terminal]

Los enlaces simbólicos se deben crear dentro del directorio activated_rules para activarlos. Vamos a activar las reglas de inyección de SQL.

[terminal]cd / usr / share / modsecurity-crs / activated_rules /
ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf.[/terminal]

Apache tiene que volver a cargarse para que las reglas se activen:

[terminal]service apache2 reload[/terminal]

Espero que os haya servido como punto de partida para proteger un servidor Linux.

Las fuente para la configuración de ModSecurity es esta -> https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu

 

 


Xavi Gonzalez

Actualmente DevOps Engineer en MotoGP (Dorna Sports). Apasionado de GNU/Linux y del software libre. Me gusta trastear con cualquier gadget, y rodar en moto.

0 comentarios

Deja una respuesta

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *