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
0 comentarios