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:

sudo apt-get install fail2ban

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

sudo nano /etc/fail2ban/jail.conf

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.

bantime = 6000

maxretry = 3

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:

ignoreip = 127.0.0.1/8 192.168.1.1./24 80.80.80.80

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

sudo tail -f /var/log/fail2ban.log

 

 

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.

adduser pepito

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

nano /etc/sudoers

Y añadimos la siguiente linea:

pepito ALL=(ALL:ALL) ALL

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

nano /etc/ssh/sshd_config

Y cambiamos la siguiente linea de yes a no:

PermitRootLogin no

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

AllowUsers pepito

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):

Port 2222

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:

apt-get install libapache2-modsecurity

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

apt-get install libapache2-mod-security2

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

mv /etc/modsecurity/modsecurity.conf{-recommended,}

Y reiniciamos el servicio:

service apache2 reload

Ya encontraremos el fichero de log en el sistema:

ls -l /var/log/apache2/modsec_audit.log

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:

nano /etc/modsecurity/modsecurity.conf

Y buscaremos la siguiente opcion:

SecRuleEngine DetectionOnly

Y la dejaremos en On:

SecRuleEngine On

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:

SecResponseBodyAccess On

Y la dejaremos así:

SecResponseBodyAccess Off

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

SecRequestBodyLimit

SecRequestBodyNoFilesLimit

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:

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

La documentación está disponible en

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

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

nano /etc/apache2/mods-enabled/modsecurity.conf

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

include “/usr/share/modsecurity-crs/*.conf”

include “/usr/share/modsecurity-crs/activated_rules/*.conf”

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

/ usr / share / modsecurity-crs / base_rules

/ usr / share / modsecurity-crs / optional_rules

/ usr / share / modsecurity-crs / experimental_rules

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

cd / usr / share / modsecurity-crs / activated_rules /

ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf.

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

service apache2 reload

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