Cómo instalar ModSecurity 3 y el conjunto de reglas básicas de OWASP con Nginx en Debian 11 Bullseye

ModSecurity, a menudo conocido como Modsec, es un cortafuegos de aplicaciones web gratuito y de código abierto (WAF) . ModSecurity se creó como un módulo para el servidor Apache HTTP. Sin embargo, desde sus inicios, el WAF ha crecido y ahora cubre una variedad de capacidades de filtrado de solicitudes y respuestas del Protocolo de transferencia de hipertexto para varias plataformas, como Microsoft IIS, Nginx y, por supuesto, Apache.

Cómo funciona el WAF, el motor ModSecurity se implementa frente a la aplicación web, lo que permite que el motor escanee las conexiones HTTP entrantes y salientes. ModSecurity se usa más comúnmente junto con el Conjunto de reglas básicas (CRS) de OWASP , un conjunto de reglas de código abierto escrito en el lenguaje SecRules de ModSecurity y es muy apreciado en la industria de la seguridad.

El conjunto de reglas OWASP con ModSecurity puede ayudar a proteger su servidor casi instantáneamente contra:

• Malos agentes de usuario
• DDOS
• Secuencias de comandos entre sitios web
• Inyección SQL
• Secuestro de sesiones
• Otras amenazas

En el siguiente tutorial, aprenderá cómo instalar ModSecurity con Nginx en el escritorio o servidor Debian 11 Bullseye.

Requisitos

• SO recomendado: Diana de Debian 11.
• Cuenta de usuario: Una cuenta de usuario con sudo o acceso root.
• Paquetes requeridos: enumerados a lo largo del tutorial

Actualizar sistema operativo

Actualice su Debian sistema operativo para asegurarse de que todos los paquetes existentes estén actualizados:

sudo apt update && sudo apt upgrade -y

El tutorial usará el comando sudo y asumiendo que tiene estado sudo .

Para verificar el estado de sudo en su cuenta:

sudo whoami

Ejemplo de salida que muestra el estado de sudo:

[joshua@debian~]$ sudo whoami
root

Para configurar una cuenta Sudo existente o nueva, visite nuestro tutorial sobre Agregar un usuario a Sudoers en Debian .

Para usar la cuenta raíz , use el siguiente comando con la contraseña de root para iniciar sesión.

su

Instalar paquete CURL y DESCOMPRIMIR

El tutorial utiliza el comando curl and unzip durante ciertas partes. Para asegurarse de que esté instalado, ejecute el siguiente comando en su terminal:

sudo apt install curl unzip -y

Instalar Nginx más reciente

Primero, deberá instalar Nginx, y se recomienda hacerlo con la última versión estable o principal de Nginx. Antes de continuar, se recomienda eliminar cualquier instalación existente de Nginx e instale la última versión estable o principal de Nginx .

Eliminar la instalación existente de Nginx

Detenga el servicio Nginx actual:

sudo systemctl stop nginx

Ahora elimine la instalación de Nginx existente de la siguiente manera:

apt-get purge nginx -y && sudo apt autoremove nginx -y

Importar e instalar el repositorio Nginx más reciente

Para usar la última versión de nginx mainline o estable, primero deberá importar el repositorio.

Para importar el repositorio principal:

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x

Para importar un repositorio estable:

curl -sSL https://packages.sury.org/nginx/README.txt | sudo bash -x

Actualiza tu repositorio para reflejar el nuevo cambio:

apt update

Ahora que ha instalado el repositorio de Nginx y actualizó la lista de repositorios, instale Nginx con lo siguiente:

apt install nginx-core nginx-common nginx nginx-full

Tenga en cuenta que es posible que se le pida que mantenga o reemplace su /etc/nginx/ existente nginx.conf archivo de configuración durante la instalación. Se recomienda mantener su archivo de configuración actual presionando (n) . Se realizará una copia independientemente de la versión del mantenedor, y también puede verificar esto en el futuro.

Agregar el código fuente de Nginx al repositorio

Solo se instala el binario al instalar la última versión de Nginx mainline o estable de forma predeterminada. Sin embargo, necesitará la fuente para compilar Modsecurity más adelante en el tutorial.

Primero, abra el archivo de configuración en /etc/apt/sources.list.d con nano como se muestra a continuación:

Línea principal:

nano /etc/apt/sources.list.d/nginx-mainline.list

Estable:

nano /etc/apt/sources.list.d/nginx.list

Tanto en la línea principal como en la estable, cuando abra el archivo, solo verá una sola línea de la siguiente manera:

#Mainline File#
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
#Stable File#
deb-src https://packages.sury.org/nginx/ bullseye main

Debajo de la línea original, agregue la siguiente línea:

Línea principal:

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

Estable:

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

Ejemplo de cómo debería verse (solo ejemplo principal):

Descargar código fuente de Nginx

Deberá descargar el código fuente de Nginx para compilar el módulo dinámico de ModSecurity. . Para hacer esto, deberá descargar y almacenar el paquete fuente en la ubicación del directorio /etc/local/src/nginx .

Crear y configurar directorios

Cree la ubicación de la siguiente manera:

mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Opcional:asigne permisos al directorio si es necesario como se indica a continuación:

chown username:username /usr/local/src/ -R 

Instalar Dependencias y Ejecutar Descarga

A continuación, descargue el paquete fuente con lo siguiente:

apt install dpkg-dev -y && sudo apt source nginx

Tenga en cuenta que verá el siguiente mensaje de error como se muestra a continuación:

dpkg-source: info: extracting nginx in nginx-1.21.1
dpkg-source: info: unpacking nginx_1.21.1.orig.tar.gz
dpkg-source: info: unpacking nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
dpkg-source: info: applying 0002-define_gnu_source-on-other-glibc-based-platforms.patch
W: Download is performed unsandboxed as root as file 'nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Esto se puede ignorar con seguridad.

Verificar versión de origen

A continuación, enumere los archivos de directorios con ls comando de la siguiente manera:

ls

Debería ver el siguiente resultado en su /usr/src/local/nginx directorio:

nginx-1.21.1
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc

Luego, confirme que el paquete fuente es el mismo que su versión de Nginx instalada en su sistema operativo Debian. Para hacer esto, use el siguiente nginx -v comando de la siguiente manera:

sudo nginx -v

La fuente que descargó debe coincidir con la versión binaria instalada en su sistema.

Ejemplo:

nginx version: nginx/1.21.1

Instalar libmodsecurity3 para ModSecurity

El paquete libmodsecurity3 es la parte real del WAF que hace el filtrado HTTP para sus aplicaciones web. En Debian 11, puede instalarlo desde el repositorio predeterminado de Debian 11. Sin embargo, esto no se recomienda como con la mayoría de las versiones estables y, a menudo, se retrasa. En su lugar, compilará desde la fuente mucho más actualizada de la siguiente manera.

Clonar repositorio de ModSecurity de Github

El primer paso es el clon de Github, y si no tienes git instalado, deberás ejecutar el siguiente comando:

apt install git -y

A continuación, clone el repositorio GIT de libmodsecurity3 de la siguiente manera:

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

Una vez clonado, deberá CD al directorio:

cd /usr/local/src/ModSecurity/

Instalar dependencias libmodsecurity3

Para compilar, deberá instalar las siguientes dependencias de la siguiente manera:

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen -y

Ahora para terminar, instale los siguientes submódulos GIT de la siguiente manera:

git submodule init

Luego actualice los submódulos:

git submodule update

Creación del entorno ModSecurity

El siguiente paso ahora es construir primero el entorno. Utilice el siguiente comando:

./build.sh

A continuación, ejecute el comando de configuración:

./configure

Tenga en cuenta que posiblemente verá el siguiente error:

fatal: No names found, cannot describe anything.

Puede ignorar esto con seguridad y pasar al siguiente paso.

Compilación del código fuente de ModSecurity

Ahora que ha creado y configurado el entorno para libmodsecurity3, es hora de compilarlo con el comando make .

make

Un truco útil es especificar el -j ya que esto puede aumentar significativamente la velocidad de compilación si tiene un servidor potente. Por ejemplo, el servidor LinuxCapable tiene 6 CPU y puedo usar las 6 o al menos usar 4 o 5 para aumentar la velocidad.

make -j 6

Después de compilar el código fuente, ejecute el comando de instalación en su terminal:

make install

Tenga en cuenta que la instalación se realiza en /usr/local/modsecurity/, al que hará referencia más adelante en la guía.

Instalar conector ModSecurity-nginx

El conector ModSecurity-nginx es el punto de conexión entre nginx y libmodsecurity. Básicamente, es el componente que se comunica entre Nginx y ModSecurity (libmodsecurity3) .

Clonar repositorio ModSecurity-nginx de Github

Al igual que en el paso anterior para clonar el repositorio libmodsecurity3, deberá volver a clonar el repositorio del conector con el siguiente comando:

sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

Instalar Dependencias de ModSecurity-nginx

A continuación, directorio del CD en el directorio fuente de Nginx de la siguiente manera:

cd /usr/local/src/nginx/nginx-1.21.1

Tenga en cuenta que reemplace la versión de la guía con la versión actual de Nginx en su sistema.

Ahora, ejecute el comando en su terminal Debian para instalar las dependencias requeridas:

apt build-dep nginx && sudo apt install uuid-dev -y

A continuación, compilará el Conector ModSecurity-nginx módulo solo con –with-compat marcar de la siguiente manera:

./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Ahora hacer (crear) los módulos dinámicos con el siguiente comando:

make modules

A continuación, en el directorio fuente de Nginx, use el siguiente comando para mover el módulo dinámico que acaba de crear y que se guardó en la ubicación objs/ngx_http_modsecurity_module.so y cópielo en /usr/share/nginx/modules directorio.

sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/

Puede almacenar el módulo dinámico en cualquier lugar, siempre que especifique la ruta completa al cargar.

Cargar y configurar el conector ModSecurity-nginx con el servidor web Nginx

Ahora que ha compilado el módulo dinámico y lo ha ubicado en consecuencia, debe editar su /etc/nginx/nginx.conf archivo de configuración para que ModSecurity funcione con su servidor web Nginx.

Habilitar ModSecurity en nginx.conf

En primer lugar, debe especificar load_module y la ruta a su módulo modsecurity.

Abra nginx.conf con cualquier editor de texto. Para el tutorial, se usará nano:

sudo nano /etc/nginx/nginx.conf

A continuación, agregue la siguiente línea al archivo cerca de la parte superior:

load_module modules/ngx_http_modsecurity_module.so;

Si ha ubicado el módulo en otro lugar, asegúrese de incluir la ruta completa.

Ahora agregue el siguiente código debajo de HTTP {} sección de la siguiente manera:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

Ejemplo ÚNICAMENTE:

Si ha ubicado el módulo en otro lugar, asegúrese de incluir la ruta completa.

Guarde el nginx.conf archivo (CTRL+O), luego salga (CTRL+X) .

Crear y configurar directorios y archivos para ModSecurity

Deberá crear un directorio para almacenar los archivos de configuración y las reglas futuras, OWASP CRS para el tutorial.

Use el siguiente comando para crear el /etc/nginx/modsec directorio de la siguiente manera:

sudo mkdir /etc/nginx/modsec/

Ahora, debe volver a copiar el archivo de configuración de ModSecurity de muestra de nuestro directorio GIT clonado:

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Usando su editor de texto favorito, abra el archivo modsecurity.conf de la siguiente manera:

sudo nano /etc/nginx/modsec/modsecurity.conf

De forma predeterminada, la configuración de ModSecurity tiene el motor de reglas especificado como (DetectionOnly) , que en otras palabras, ejecuta ModSecurity y detecta todo el comportamiento malicioso, pero no bloquea o prohíbe la acción y registra todas las transacciones HTTP que marca. Esto solo debe usarse si tiene muchos falsos positivos o ha aumentado la configuración del nivel de seguridad a un nivel extremo y prueba para ver si se producen falsos positivos.

Para cambiar este comportamiento a (on) , busque lo siguiente en la línea 7 :

SecRuleEngine DetectionOnly

Cambie la línea a esto para habilitar ModSecurity:

SecRuleEngine On

Ahora, debe ubicar lo siguiente, que se encuentra en la línea 224 :

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Esto no es correcto y necesita ser cambiado. Modifique la línea a lo siguiente:

SecAuditLogParts ABCEFHJKZ

Ahora guarda el modsecurity.conf archivo usando (CTRL+O) luego salga (CTRL+X) .

La siguiente parte es crear el siguiente archivo modsec-config.conf . Aquí agregará el modsecurity.conf archivo a lo largo y más adelante en otras reglas como OWASP CRS , y si usa WordPress, el WPRS CRS conjunto de reglas.

Use el siguiente comando para crear el archivo y abrirlo:

sudo nano /etc/nginx/modsec/modsec-config.conf

Una vez dentro del archivo, agrega la siguiente línea:

Include /etc/nginx/modsec/modsecurity.conf

Guarde el modsec-config.conf archivo con (CTRL+O) luego (CTRL+X) salir.

Por último, copia el unicode.mapping de ModSecurity. archivo con el CP comando de la siguiente manera:

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

Ahora, antes de continuar, debe probar su servicio Nginx con el siguiente comando de terminal:

sudo nginx -t

Si ha configurado todo correctamente, debería obtener el siguiente resultado:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Para realizar los cambios en vivo, reinicie su servicio Nginx usando el comando systemctl:

sudo systemctl restart nginx

Instalar conjunto de reglas básicas de OWASP para ModSecurity

ModSecurity por sí solo no protege su servidor web y necesita tener reglas. Una de las reglas más famosas, respetadas y conocidas es el conjunto de reglas OWASP CRS. Las reglas son las más utilizadas entre los servidores web y otros WAF, y la mayoría de los otros sistemas similares basan la mayoría de sus reglas en este CRS. La instalación de este conjunto de reglas le brindará automáticamente una gran fuente de protección contra la mayoría de las amenazas emergentes en Internet al detectar a los actores malintencionados y bloquearlos.

Usando el comando wget, descargar el archivo OWASP CRS 3.3.2 de la siguiente manera:

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

Para aquellos que quieren vivir al límite, pueden descargar la compilación nocturna. Solo use nightly si está preparado para seguir compilando y revisando CoreRuleSet Github con frecuencia para obtener actualizaciones y tener más confianza para resolver problemas. Técnicamente, la noche puede ser más segura, pero potencialmente puede crear problemas.

Para usuarios novatos, use la versión estable y no use la versión a continuación.

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

Instale el paquete de descompresión si no tiene esto instalado en su servidor:

sudo apt install unzip -y

Ahora descomprime el maestro.zip archivar de la siguiente manera:

sudo unzip v3.3.2.zip -d /etc/nginx/modsec

Como antes, como el modsecurity.conf configuración de muestra, OWASP CRS viene con un archivo de configuración de muestra que debe cambiar de nombre. Lo mejor es usar el CP comando y guarde una copia de seguridad para el futuro en caso de que necesite reiniciar de nuevo.

sudo cp /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf

Para habilitar las reglas, abra /etc/nginx/modsec/modsec-config.conf utilizando cualquier editor de texto de nuevo:

sudo nano /etc/nginx/modsec/modsec-config.conf

Una vez dentro del archivo nuevamente, agregue las siguientes dos líneas adicionales:

Include /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3.2/rules/*.conf

Guarda el archivo (CTRL+O) y salir (CTRL+X) .

Como antes, debe probar las nuevas incorporaciones a su servicio Nginx antes de ponerlo en marcha:

sudo nginx -t

Debería obtener el siguiente resultado, lo que significa que todo funciona correctamente:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Reinicie su servicio Nginx para hacer los cambios en vivo de la siguiente manera:

sudo systemctl restart nginx

Uso y comprensión de OWASP CRS

OWASP CRS tiene bastantes opciones, la configuración predeterminada, sin embargo, lista para usar, protegerá la mayoría de los servidores de inmediato sin dañar a sus visitantes reales y a los buenos bots de SEO. A continuación, se cubrirán algunas áreas para ayudar a explicar. Sería mejor leer más para investigar todas las opciones en los archivos de configuración, ya que tienen bastantes datos de texto para explicar qué son.

Abra su CRS-setup.conf archivo de la siguiente manera:

nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf

Tenga en cuenta que esta es la configuración de la versión de desarrollo con elementos adicionales en comparación con la versión 3.3.

Desde aquí, puede modificar la mayoría de las configuraciones de OWASP CRS.

Puntuación OWASP CRS

Para desglosarlo, ModSecurity tiene dos modos:

Modo de puntuación de anomalías

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Modo autónomo

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

La puntuación de anomalías es generalmente para la mayoría de los usuarios el mejor modo para usar.

Hay cuatro niveles de paranoia:

• Paranoia Nivel 1 – Nivel predeterminado y recomendado para la mayoría de los usuarios.
• Paranoia Nivel 2 – Solo usuarios avanzados.
• Paranoia Nivel 3 – Solo usuarios expertos.
• Paranoia Nivel 4 – Nada recomendable, salvo circunstancias excepcionales.

# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Pruebe OWASP CRS en su servidor

Para probar si OWASP CRS está funcionando en su servidor, abra su navegador de Internet y use lo siguiente:

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

Deberías recibir un error prohibido 403. Si no es así, se ha perdido un paso.

El problema más común es que falta cambiar DetectionOnly a Encendido, como se cubrió anteriormente en el tutorial.

Lidiar con falsos positivos y exclusión de reglas personalizadas

Una de las tareas a menudo interminables es lidiar con los falsos positivos, ModSecurity y OWASP CRS hacen un gran trabajo juntos, pero cuesta su tiempo, pero dada la protección, vale la pena. Para empezar, nunca poner el nivel de paranoia en un nivel alto es la regla de oro.

Una buena regla general es ejecutar el conjunto de reglas durante algunas semanas o meses sin apenas falsos positivos, luego aumentar, por ejemplo, el nivel de paranoia 1 al nivel de paranoia 2, para que no se vea abrumado con una tonelada simultáneamente.

Excluir aplicaciones conocidas de falsos positivos

Modsecurity, de forma predeterminada, puede incluir en la lista blanca las acciones cotidianas que conducen a falsos positivos como se muestra a continuación:

#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 habilitar, por ejemplo, WordPress, phpBB y phpMyAdmin mientras usa los tres, elimine el comentario de las líneas y dejar el (1) número intacto, cambie los otros servicios que no usa, por ejemplo, Xenforo a (0) ya que no desea incluir en la lista blanca estas reglas.

Ejemplo a continuación:

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

También puede modificar la sintaxis, que sería más limpia. Por ejemplo:

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"

Como puede ver, se eliminan las opciones que no son necesarias y se agregan (“) al final de WordPress para una sintaxis correcta.

Exclusión de reglas antes de CRS

Para lidiar con las exclusiones personalizadas, primero debe cambiar el nombre de REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf archivo con el comando cp de la siguiente manera:

sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Un punto para recordar, al crear reglas de exclusión, cada una debe tener id: y ser única, de lo contrario, cuando pruebe su servicio Nginx, obtendrá un error. Ejemplo “id:1544,fase:1,log,allow,ctl:ruleEngine=off” , el id 1544 no se puede usar para una segunda regla.

Por ejemplo, algunos REQUEST_URI generarán falsos positivos. El siguiente ejemplo es dos con la baliza de velocidad de página de Google y el complemento WMUDEV 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"

Como puede ver, cualquier URL que comience con la ruta se permitirá automáticamente.

Otra opción es incluir en la lista blanca las direcciones IP, algunas formas de hacerlo:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
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"

El @ipMatch se puede utilizar más extensamente para las subredes. Si desea denegar una subred o dirección IP cambiar, permitir negar. Con un poco de conocimiento, también puede crear listas negras y listas blancas y configurar esto con fail2ban . Las posibilidades a menudo pueden ser infinitas.

Un último ejemplo es deshabilitar solo las reglas que desencadenan falsos positivos, sin incluir en la lista blanca toda la ruta, como vio en el primer ejemplo de REQUEST_URI. Sin embargo, esto requiere más tiempo y pruebas. Por ejemplo, desea eliminar las reglas 941000 y 942999 desde su área /admin/, ya que sigue provocando prohibiciones y bloqueos falsos para su equipo, busque en su archivo de registros de modsecurity el ID de la regla y luego deshabilite solo ese ID con RemoveByID como el siguiente ejemplo:

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

Se pueden encontrar ejemplos en la página wiki de ModSecurity GIT; LinuxCapable, en el futuro, creará un tutorial sobre esta parte, ya que hay mucho que cubrir.

Opcional:incluir Project Honeypot

Proyecto Honey Pot es el primer y único sistema distribuido para identificar a los spammers y los spambots que utilizan para extraer direcciones de su sitio web. Con el sistema Project Honey Pot, puede instalar direcciones etiquetadas personalizadas para la hora y la dirección IP de un visitante de su sitio. Si una de estas direcciones comienza a recibir correo electrónico, podemos decir que los mensajes son spam, el momento exacto en que se recopiló la dirección y la dirección IP que la recopiló.

ModSecurity puede tener la opción de integrar Project Honeypot, que consultará la base de datos y bloqueará cualquier dirección que esté en la lista negra de HoneyPot. Tenga en cuenta que usar esto puede generar falsos positivos, pero en general se considera muy confiable en comparación con alternativas similares.

Paso 1. Crea una cuenta una cuenta gratuita.

Paso 2. Una vez que se haya registrado e iniciado sesión, en el panel de control, busque la línea (Su http:BL API key) y haz clic en obtener uno .

Paso 3. Vuelva al archivo CRS-setup.conf abriéndolo con un editor de texto:

sudo nano /etc/nginx/modsec/coreruleset-3.3.3/crs-setup.conf

Paso 4. Encuentra la línea que comienza con #SecHttpBlKey, que está en la línea 629.

#SecHttpBlKey XXXXXXXXXXXXXXXXX
#SecAction "id:900500,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.block_search_ip=1,\
#  setvar:tx.block_suspicious_ip=1,\
#  setvar:tx.block_harvester_ip=1,\
#  setvar:tx.block_spammer_ip=1"

Paso 5. Cambie SecHttpBlKey XXXXXXXXXXXXXXXXX con su clave del Proyecto HoneyPot.

Ejemplo:

SecHttpBlKey amhektvkkupe

Paso 6. A continuación, descomente todas las líneas para habilitar la regla. Para desactivar una regla, en lugar de (1), poner (0) en su lugar, si desea tener alguna de las reglas deshabilitadas. De manera predeterminada, block_search_ip=0 es para los bots de los motores de búsqueda, no habilite esto a menos que desee que Bing, Google y otros buenos bots ingresen a su sitio.

SecHttpBlKey amhektvkkupe
SecAction "id:900500,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.block_search_ip=0,\
  setvar:tx.block_suspicious_ip=1,\
  setvar:tx.block_harvester_ip=1,\
  setvar:tx.block_spammer_ip=1"

Note, do not use amhektvkkupe. Use your key instead!

Step 7. Test Nginx to make sure no errors have occurred with the following:

sudo nginx -t

Example output if all correct:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Now restart your Nginx service:

sudo systemctl restart nginx

WordPress WPRS Rule Set for ModSecurity

Another option for WordPress users is to install and run alongside your OWASP CRS rule set, a well-known project entitled WPRS rule set. As this is optional and isn’t for everyone, the tutorial will not cover it in this section. However, if you would like to install this for extra protection if you use WordPress on your server, please visit our tutorial on Installing WordPress ModSecurity Rule Set (WPRS).

Create ModSecurity LogRotate File

Given how many lines and information it can log, ModSecurity will grow quite quickly. As you are compiling the module and it isn’t installed through any official repository from Debian, you will need to create your own log rotate file.

First, create and open your ModSecurity rotate file modsec :

sudo nano /etc/logrotate.d/modsec

Add the following code:

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

This will keep logs for 31 dias. If you prefer to have less, change 31 to say 7 days equally a week’s worth of logs. You should be rotating daily for ModSecurity. If you need to review the log files having a weekly file will be a disaster to sift through, given how large it will be.