Cómo instalar ModSecurity 2 con Apache en Debian 12 o 11

ModSecurity 2 es un firewall de aplicaciones web (WAF) esencial para proteger los servidores HTTP Apache, que ofrece monitoreo en tiempo real y filtrado basado en reglas. Instalado en un servidor Linux Debian 12 u 11, ModSecurity ayuda a prevenir inyecciones SQL, ataques de secuencias de comandos entre sitios (XSS) y otros ataques. El repositorio Digitalwave ModSecurity simplifica la instalación, lo que garantiza que esté utilizando la última versión estable.

Para mejorar la seguridad, el conjunto de reglas básicas (CRS) de OWASP proporciona reglas preconfiguradas que se dirigen a vulnerabilidades comunes. Su configuración permite a los administradores reforzar las defensas con una configuración manual mínima. Esta guía le mostrará cómo instalar ModSecurity 2 en Debian utilizando el repositorio Digitalwave y configurar el CRS de OWASP para una protección óptima.

Actualización de los paquetes del sistema Debian para la instalación de ModSecurity 2

Nuestro primer paso es asegurarnos de que nuestro sistema Debian esté actualizado. De esta manera, mantendremos actualizados todos los paquetes existentes, garantizaremos un rendimiento óptimo y minimizaremos los riesgos de seguridad. Para lograrlo, ejecute el siguiente comando:

sudo apt update && sudo apt upgrade

Después de actualizar el sistema, compruebe si Apache está instalado. Si no es así, utilice el siguiente comando para instalarlo:

sudo apt install apache2

Importar módulo ModSecurity PPA

Configuración del repositorio requerido

La siguiente tarea de nuestra lista es instalar el módulo ModSecurity para Apache. La versión disponible en los repositorios predeterminados de Debian puede no ser la más reciente y su uso puede provocar errores inmediatos. En su lugar, importaremos un repositorio de terceros para instalar el módulo ModSecurity más reciente para Apache. Este repositorio de terceros, mantenido por Digitalwave, es conocido por sus binarios estables.

Comience instalando un conjunto de paquetes necesarios:

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

Luego procedemos a importar el repositorio PPA del módulo ModSecurity 2 Clave GPG:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

Después de adquirir la clave GPG, agregue el repositorio a su sistema:

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

Priorización del nuevo repositorio PPA del módulo Apache

Una vez que el repositorio está instalado, ahora es necesario ajustar la política APT para priorizar este repositorio para paquetes específicos relacionados con ModSecurity. El siguiente comando logra esto:

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

A continuación, ejecute una actualización de APT para reflejar la fuente recién importada:

sudo apt update

Además, para confirmar las preferencias, puede confirmar este cambio de política con lo siguiente:

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

Instalar el módulo ModSecurity 2

Ahora que el repositorio está listo, proceda con la instalación del módulo libapache2-mod-security2:

sudo apt install libapache2-mod-security2

Después de la instalación, el módulo debe estar habilitado. Para ello, utilice el siguiente comando:

sudo a2enmod security2

Reiniciando el servicio Apache

Por último, reiniciamos el servicio Apache para asegurarnos de que todos los cambios surtan efecto y el módulo ModSecurity recién agregado esté correctamente integrado:

sudo nano /etc/apache2/mods-enabled/security2.conf

Habilitar el módulo ModSecurity 2 en Apache HTTP

Cómo acceder al archivo de configuración de ModSecurity

El archivo de configuración de Apache ModSecurity se encuentra en /etc/apache2/mods-enabled/security2.conf. Acceda a este archivo mediante el editor de texto nano (o el editor de texto que prefiera) con el siguiente comando:

sudo nano /etc/apache2/mods-enabled/security2.conf

Busque la línea que dice:

IncludeOptional /etc/modsecurity/*.conf

Asegúrese de que esta línea no esté comentada, ya que incluye otros archivos de configuración necesarios del directorio /etc/modsecurity. Debe estar sin comentarios de forma predeterminada.

Modificación de la configuración de ModSecurity 2

Necesitamos cambiar el nombre del archivo de configuración recomendado por modsecurity.conf a modsecurity.conf para activarlo. Esto se puede hacer con el siguiente comando:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Ahora, abramos este archivo de configuración recién nombrado:

sudo nano /etc/modsecurity/modsecurity.conf

El motor de reglas de ModSecurity está configurado en DetectionOnly de manera predeterminada en este archivo. Esto significa que identificará y registrará comportamientos potencialmente maliciosos sin bloquearlos. Para cambiar esto y habilitar las capacidades de bloqueo de ModSecurity, busque la línea SecRuleEngine (alrededor de la línea 7) y reemplace DetectionOnly por On.

De:

SecRuleEngine DetectionOnly

A:

SecRuleEngine On

Ajuste de la configuración de registro para Apache

Más abajo en el archivo de configuración, encontrará la línea SecAuditLogParts (alrededor de la línea 224). La configuración predeterminada para esta línea no es del todo correcta; debe ajustarse para registrar toda la información de las transacciones con precisión.

Cambiar:

SecAuditLogParts ABDEFHIJZ

A:

SecAuditLogParts ABCEFHJKZ

Con estas modificaciones implementadas, guarde los cambios y salga del editor.

Reiniciar Apache para aplicar los cambios

Nuestro último paso en este proceso es reiniciar el servicio Apache para que los cambios en la configuración de ModSecurity surtan efecto. Esto se logra mediante el siguiente comando:

sudo systemctl restart apache2

Instalar el conjunto de reglas básicas de OWASP para ModSecurity2

ModSecurity por sí solo no protege su servidor web. Requiere un conjunto de reglas para identificar amenazas potenciales y bloquear actividades maliciosas. El conjunto de reglas básicas (CRS) de OWASP (Open Web Application Security Project) es un conjunto de reglas muy valorado que utilizan varios servidores web y firewalls de aplicaciones web (WAF). La implementación de este conjunto de reglas proporciona a su servidor una protección sólida contra una variedad de amenazas que surgen en Internet.

Antes de continuar, es esencial verificar que tiene la última versión de OWASP CRS visitando el sitio Página de etiqueta de lanzamiento de OWASPEste paso garantiza que descargue e instale las medidas de seguridad más actualizadas para su servidor.

Creación del directorio principal para OWASP CRS

Primero, creemos el directorio principal principal para OWASP usando el comando mkdir:

sudo mkdir /etc/apache2/modsec/

Descargar el archivo CRS de OWASP en Debian

A continuación, utilizaremos el comando wget para obtener el archivo de OWASP CRS 3.3.4, que es la versión estable al momento de escribir este artículo. Recuerde que debe verificar la versión mediante el enlace mencionado anteriormente.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip

La versión nocturna puede ofrecer medidas de seguridad más actualizadas, pero podría causar problemas debido a su estado de desarrollo. Para los nuevos usuarios, es recomendable utilizar la versión estable para evitar posibles complicaciones.

Nota: Debes verificar constantemente si hay actualizaciones; las reglas estables no cambian semanalmente sino cada trimestre o a menos que se requiera una actualización urgente.

Extrayendo el archivo

Con el archivo descargado, podemos extraerlo en el directorio que creamos anteriormente:

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

Recuerde cambiar los comandos según la versión de OWASP CRS que haya descargado.

Configuración del conjunto de reglas

El CRS de OWASP tiene un archivo de configuración de muestra que deberías renombrar y conservar el original como copia de seguridad. Puedes hacerlo usando el comando 'cp':

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Nota: Recuerde reemplazar /coreruleset-3.3.4/ con la versión exacta del OWASP CRS que eligió.

Habilitando las reglas

Para activar las reglas, abra el archivo /etc/apache2/mods-enabled/security2.conf:

sudo apt install unzip -y

Luego, inserte las siguientes dos líneas:

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

Nota: Nuevamente, asegúrese de reemplazar /coreruleset-3.3.4/ con la versión exacta de OWASP CRS que ha seleccionado, ya que el coreruleset que descargará probablemente será más nuevo que el ejemplo de la guía.

Además, comente o elimine la siguiente línea:

IncludeOptional /usr/share/modsecurity-crs/*.load

Una vez hecho esto, guarde y salga del archivo:

Reiniciar Apache para aplicar los cambios

El último paso es reiniciar el servicio Apache para garantizar que los cambios surtan efecto:

sudo systemctl restart apache2

Introducción al conjunto de reglas básicas de OWASP y ModSecurity 2

El conjunto de reglas básicas (CRS) de OWASP es una herramienta integral con numerosas opciones personalizables. Su configuración predeterminada proporciona mejoras de seguridad inmediatas para la mayoría de los servidores sin afectar a los visitantes genuinos ni a los robots de optimización de motores de búsqueda (SEO). Analizaremos algunos aspectos importantes del CRS en esta sección, pero siempre es beneficioso explorar los archivos de configuración para comprender por completo todas las opciones disponibles.

Ajuste de la configuración del CRS

Comenzamos abriendo el archivo crs-setup.conf donde se pueden modificar la mayoría de las configuraciones de CRS:

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Entendiendo el sistema de puntuación CRS

ModSecurity funciona en dos modos distintos:

• Modo de puntuación de anomalías: recomendado para la mayoría de los usuarios, este modo asigna una "puntuación de anomalías" cada vez que una regla coincide. Después de procesar las reglas entrantes y salientes, se verifica la puntuación de anomalías y, si es necesario, se activa una acción disruptiva. Esta acción suele adoptar la forma de un error 403. Este modo proporciona información de registro precisa y ofrece mayor flexibilidad para establecer políticas de bloqueo.
• Modo autónomo: en este modo, se aplica una acción de forma instantánea cada vez que se cumple una regla. Si bien puede reducir el uso de recursos, ofrece menos flexibilidad y genera registros de auditoría menos informativos. El proceso de coincidencia de reglas se detiene cuando se cumple la primera regla y se ejecuta la acción especificada.

Comprender los niveles de paranoia

El OWASP CRS define cuatro niveles de paranoia:

• Paranoia Nivel 1: El nivel predeterminado es adecuado para la mayoría de los usuarios.
• Paranoia Nivel 2: Para usuarios avanzados.
• Paranoia Nivel 3: Para usuarios expertos.
• Paranoia Nivel 4: Sólo recomendable en circunstancias extraordinarias.

Los niveles más altos de paranoia permiten reglas adicionales, aumentan la seguridad y aumentan la probabilidad de bloquear el tráfico legítimo debido a falsos positivos. Es fundamental elegir un nivel de paranoia que se ajuste a su experiencia y necesidades de seguridad.

Prueba de OWASP CRS en su servidor

Para garantizar que el CRS de OWASP esté funcionando correctamente en su servidor, utilice su navegador de Internet para acceder a la siguiente URL. Recuerde reemplazar “yourdomain.com” por su dominio real:

https://www.yourdomain.com/index.html?exec=/bin/bash

Si recibe un error 403 Forbidden, OWASP CRS funcionará como se espera. De lo contrario, es posible que haya un error en el proceso de configuración que requiera su atención; el problema más común puede ser olvidarse de cambiar DetectionOnly a On o algo similar.

Abordar los falsos positivos y las reglas de exclusión personalizadas

Gestionar los falsos positivos con ModSecurity y el conjunto de reglas básicas (CRS) de OWASP puede ser una tarea continua. Sin embargo, la sólida defensa que ofrecen estos sistemas contra una amplia gama de amenazas hace que este esfuerzo sea esencial. Para minimizar los falsos positivos inicialmente, es recomendable establecer un nivel de paranoia bajo.

Si ejecuta el conjunto de reglas en un nivel de paranoia más bajo durante varias semanas o incluso meses, puede reducir la probabilidad de que se produzca una cantidad abrumadora de falsos positivos. Este enfoque le da tiempo para familiarizarse con las alertas y las respuestas adecuadas antes de aumentar gradualmente el nivel de paranoia para lograr una seguridad más estricta.

Gestión de falsos positivos en aplicaciones conocidas en Debian con OWASP, ModSecurity 2

ModSecurity incluye la capacidad de incluir en la lista blanca determinadas acciones que pueden generar falsos positivos de forma involuntaria. Por ejemplo:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Para incluir en la lista blanca aplicaciones como WordPress, phpBB y phpMyAdmin, elimine los comentarios de las líneas correspondientes y mantenga el valor (1). Para evitar que se incluyan en la lista blanca servicios que no se utilizan, ajuste el valor a (0).

La configuración actualizada podría verse así:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

En este caso, se han eliminado las opciones extrañas, dejando la sintaxis correcta para las configuraciones que necesita.

Creación de exclusiones de reglas antes de la implementación de CRS

Para crear exclusiones personalizadas, comience por cambiar el nombre del archivo “REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” utilizando el siguiente comando:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Recuerde, cada regla de exclusión debe tener un 'número de identificación' único para evitar errores durante las pruebas del servicio Apache2.

Por ejemplo, algunas “REQUEST_URI” pueden generar falsos positivos. El siguiente ejemplo ilustra dos casos de este tipo relacionados con la baliza Google PageSpeed ​​y el complemento WPMU DEV para WordPress:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Estas reglas permiten automáticamente cualquier URL que comience con la ruta especificada.

También puedes incluir en la lista blanca direcciones IP específicas:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

En la primera regla, se incluye en la lista blanca una única dirección IP, mientras que la segunda utiliza la directiva '@ipMatch' para una coincidencia de subredes más amplia. Para bloquear una subred o una dirección IP, simplemente reemplace 'permitir' por 'denegar'. Esta flexibilidad le permite crear listas blancas y negras detalladas, que se pueden integrar con Fail2Ban para una estrategia de seguridad mejorada.

Deshabilitar reglas específicas en Debian con OWASP, ModSecurity 2

En lugar de incluir en la lista blanca una ruta completa, otro enfoque consiste en deshabilitar reglas específicas que causan falsos positivos persistentes. Si bien este método requiere más pruebas, ofrece beneficios a largo plazo.

Por ejemplo, si las reglas 941000 y 942999 en el área “/admin/” activan falsos positivos para su equipo, puede localizar el ID de la regla en sus registros de ModSecurity y deshabilitar solo esos ID específicos usando el comando “RemoveByID”:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Monitoreo de registros e identificación de patrones

El monitoreo continuo de registros es esencial al manejar falsos positivos con Apache, ModSecurity y OWASP. Ayuda a identificar patrones que desencadenan falsos positivos, lo que le permite crear reglas personalizadas para abordarlos.

Por ejemplo, si ciertas reglas específicas generan constantemente falsos positivos, puede crear una regla de exclusión para gestionar esos casos específicos. Este enfoque personalizado garantiza una gestión más eficaz de los falsos positivos.

Al revisar periódicamente sus registros y ajustar sus reglas, puede mantener un entorno más seguro y eficiente para sus aplicaciones.

Rotación de registros para ModSecurity 2

Debido a la naturaleza dinámica de las transacciones web, los registros de ModSecurity pueden crecer rápidamente, lo que hace que la gestión eficaz de los registros sea crucial. La rotación de registros es una herramienta útil para gestionar estos registros, aunque no está configurada de forma predeterminada en ModSecurity. Esta sección le guiará en la configuración de la rotación de registros específicamente para ModSecurity.

Creación de un archivo de rotación de ModSecurity

En primer lugar, debe crear un archivo dedicado para la rotación de registros de ModSecurity. Para ello, utilice el siguiente comando para crear y abrir un nuevo archivo llamado modsec:

sudo nano /etc/logrotate.d/modsec

Configuración del archivo de rotación

En el archivo de configuración de ModSecurity (modsec) recién creado, agregue lo siguiente:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

Esta configuración conserva los registros durante 31 días, pero puedes modificar el número para adaptarlo a tus necesidades. Por ejemplo, si la cambias a "rotar 7", conservarás los registros de una semana.

La directiva 'daily' garantiza que los registros se roten todos los días, mientras que 'compress' ahorra espacio al comprimir los registros antiguos. La opción 'delaycompress' retrasa la compresión hasta el segundo ciclo de rotación y 'missingok' evita errores si el archivo de registro no está disponible. Además, 'notifempty' garantiza que los archivos de registro vacíos no se roten.

Consejo: Se recomienda rotar los registros diariamente para evitar trabajar con archivos de registro demasiado grandes, que pueden hacer que el análisis requiera más tiempo.

Conclusión

Ya ha instalado ModSecurity 2 en su servidor Debian 12 o 11 utilizando el repositorio Digitalwave y ha configurado el conjunto de reglas básicas de OWASP. Con estas herramientas, su servidor está equipado para bloquear muchas amenazas comunes de aplicaciones web.

Recuerde actualizar periódicamente el CRS y controlar si hay falsos positivos o vulnerabilidades no detectadas. La realización de pruebas y ajustes constantes es fundamental para mantener una configuración de seguridad sólida.