Este tutorial le mostrará cómo instalar y usar ModSecurity con Nginx en servidores Debian/Ubuntu. ModSecurity es el cortafuegos de aplicaciones web de código abierto más conocido (WAF), que brinda protección integral para sus aplicaciones web (como WordPress, Nextcloud, Ghost, etc.) contra una amplia gama de ataques de Capa 7 (HTTP), como inyección SQL, secuencias de comandos entre sitios e inclusión de archivos locales.
Nota :Este tutorial funciona en todas las versiones actuales de Debian y Ubuntu, incluidas Debian 10, Ubuntu 18.04, Ubuntu 20.04 y Ubuntu 20.10.
Las aplicaciones web son intrínsecamente inseguras. Si es un administrador de WordPress, probablemente escuchará noticias de piratas informáticos que explotan vulnerabilidades en los complementos y temas de WordPress de vez en cuando. Es esencial que implemente un WAF en su servidor web, especialmente cuando tiene aplicaciones antiguas que no reciben actualizaciones. ModSecurity fue creado originalmente por Ivan Ristić en 2002, actualmente mantenido por Trustwave SpiderLabs. Es el WAF más implementado del mundo, utilizado por más de un millón de sitios web. cPanel, el panel de control de alojamiento más utilizado, incluye ModSecurity como su WAF.
Es posible que haya escuchado otros firewalls basados en host como iptables, UFW y Firewalld, etc. La diferencia es que funcionan en las capas 3 y 4 del modelo OSI y toman medidas según la dirección IP y el número de puerto. ModSecurity, o firewalls de aplicaciones web en general, está especializado para centrarse en el tráfico HTTP (capa 7 del modelo OSI) y actúa en función del contenido de la solicitud y respuesta HTTP.
ModSeguridad 3
ModSecurity fue diseñado originalmente para el servidor web Apache. Podía funcionar con Nginx antes de la versión 3.0, pero tenía un rendimiento deficiente. ModSecurity 3.0 (también conocido como libmodsecurity ) se lanzó en 2017. Es un lanzamiento histórico, especialmente para los usuarios de Nginx, ya que es la primera versión que funciona de forma nativa con Nginx. La advertencia de ModSecurity 3 es que todavía no tiene todas las características de la versión anterior (2.9), aunque cada nueva versión agregará algunas de las características que faltan.
Paso 1:Instale la última versión de Nginx en Debian/Ubuntu
ModSecurity se integra con Nginx como un módulo dinámico, lo que le permite compilar el código fuente de módulos individuales sin compilar Nginx.
El binario de Nginx debe compilarse con --with-compat argumento, que hará que los módulos dinámicos sean compatibles con su binario Nginx existente. Sin embargo, no todos los binarios de Nginx enviados desde el repositorio predeterminado de Debian/Ubuntu se compilan con el --with-compat argumento. Para facilitar las cosas, podemos instalar la última versión de Nginx desde ondrej/nginx-mainline PPA, que es mantenido por un desarrollador de Debian.
Nota :El repositorio nginx.org también proporciona la última versión de Nginx. Sin embargo, el ondrej/nginx-mainline PPA proporciona módulos dinámicos adicionales que pueden resultarle útiles, como el módulo Brotli.
Ubuntu
Si usa Ubuntu 16.04, 18.04, 20.04 o 20.10, ejecute los siguientes comandos para instalar la última versión de Nginx.
sudo add-apt-repository ppa:ondrej/nginx-mainline -y sudo apt update sudo apt install nginx-core nginx-common nginx nginx-full
Durante el proceso de instalación, puede indicarle que el distribuidor del paquete envió una versión actualizada del archivo de configuración principal. Se recomienda presionar n para mantener su versión actual. Siempre puedes examinar la diferencia más tarde.
De forma predeterminada, solo está habilitado el repositorio binario. También necesitamos habilitar el repositorio de código fuente para poder descargar el código fuente de Nginx. Edite el archivo del repositorio principal de Nginx.
sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list
Encuentra la línea que comienza con # deb-src .
# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main
Eliminar el # carácter para habilitar este repositorio de código fuente.
deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main
Guarde y cierre el archivo. Luego actualice el índice del repositorio.
sudo apt update
Debian
Si usa Debian 10 o Debian 11, ejecute los siguientes comandos para instalar la última versión de Nginx.
curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x sudo apt update sudo apt install nginx-core nginx-common nginx nginx-full
Durante el proceso de instalación, puede indicarle que el distribuidor del paquete envió una versión actualizada del archivo de configuración principal. Se recomienda presionar n para mantener su versión actual. Siempre puedes examinar la diferencia más tarde.
De forma predeterminada, solo está habilitado el repositorio binario. También necesitamos habilitar el repositorio de código fuente para poder descargar el código fuente de Nginx. Edite el archivo del repositorio principal de Nginx.
sudo nano /etc/apt/sources.list.d/nginx-mainline.list
Debería encontrar una sola línea que habilite el repositorio binario de Nginx. Agregue la siguiente línea para habilitar el repositorio de código fuente de Nginx en Debian 10.
deb-src https://packages.sury.org/nginx-mainline/ buster main
Si usa Debian 11, agregue la siguiente línea en su lugar.
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
Guarde y cierre el archivo. Luego actualice el índice del repositorio.
sudo apt update
Comprobación de los argumentos de configuración de Nginx
Ahora verifique los argumentos de configuración de Nginx con el siguiente comando:
sudo nginx -V
Todos los archivos binarios de Nginx en el PPA se compilan con --with-compat argumento.
Paso 2:Descargue el paquete fuente de Nginx
Aunque no necesitamos compilar Nginx en sí, necesitamos el paquete de código fuente de Nginx para compilar el módulo dinámico ModSecurity. Ejecute el siguiente comando para hacer un nginx directorio bajo /usr/local/src/ para almacenar el paquete de código fuente de Nginx. Reemplazar username con tu nombre de usuario real.
sudo chown username:username /usr/local/src/ -R mkdir -p /usr/local/src/nginx
cd en el directorio fuente de Nginx.
cd /usr/local/src/nginx/
Descargue el paquete fuente de Nginx con los siguientes comandos:
sudo apt install dpkg-dev apt source nginx
Si ve el siguiente mensaje de advertencia, puede ignorarlo con seguridad.
W: Download is performed unsandboxed as root as file 'nginx_1.19.5.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Consulte los archivos de código fuente descargados.
ls
Salida de muestra:
nginx-1.19.5 nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.debian.tar.xz nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.dsc nginx_1.19.5.orig.tar.gz
Asegúrese de que la versión del código fuente sea la misma que su versión binaria de Nginx (sudo nginx -v ).
Paso 3:Instalar libmodsecurity3
libmodseguridad es la biblioteca ModSecurity que realmente hace el filtrado HTTP para sus aplicaciones web. En Debian 10 y Ubuntu 20.04, 20.10, puede instalarlo con sudo apt install libmodsecurity3 , pero te recomiendo que lo compiles desde la fuente.
Para compilar libmodsecurity , primero clona el código fuente de Github.
sudo apt install git git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/ cd /usr/local/src/ModSecurity/
Instalar dependencias de compilación.
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
Instale los submódulos necesarios.
git submodule init git submodule update
Configure el entorno de compilación.
./build.sh ./configure
Si ve el siguiente error, puede ignorarlo.
fatal: No names found, cannot describe anything.
Compile el código fuente con el siguiente comando. Por defecto, make utilizará sólo un núcleo de CPU. Tengo 4 núcleos de CPU en mi servidor, así que especifico 4 trabajos (-j4 ) para make para acelerar el proceso de compilación. Cambiar 4 a su propia cantidad de núcleos de CPU.
make -j4
Después de make comando terminado sin errores, instale el binario.
sudo make install
Se instalará en /usr/local/modsecurity/ directorio.
Resolución de errores de compilación
error n.º 1
Si ve el siguiente error al ejecutar make comando, es probable que su servidor no tenga RAM.
g++: internal compiler error: Killed (program cc1plus)
Las siguientes líneas en /var/log/syslog El archivo indica que el servidor no tiene memoria, así que considere actualizar las especificaciones del servidor.
Alternativamente, puede crear un espacio de intercambio para resolver el problema de falta de memoria. Sin embargo, solo debe usarse como una medida temporal. El uso de espacio de intercambio en servidores SSD puede ser perjudicial para el rendimiento del sistema.
error n.º 2
Si ve el siguiente error al compilar ModSecurity,
utils/geo_lookup.cc: In member function ‘bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function<bool(int, const std::__cxx11::basic_string<char>&)>) const’: utils/geo_lookup.cc:124:32: error: invalid conversion from ‘const MMDB_s*’ to ‘MMDB_s*’ [-fpermissive] r = MMDB_lookup_string(&mmdb, target.c_str(), &gai_error, &mmdb_error);
Probablemente se deba a que instaló una versión obsoleta de libmaxminddb-dev . Puede eliminar este paquete.
sudo apt remove libmaxminddb-dev
E instale libgeoip-dev , que es una alternativa a libmaxminddb-dev .
sudo apt install libgeoip-dev
Luego vuelva a compilar ModSecurity.
make clean ./configure make -j4
Instale el binario.
sudo make install
Paso 4:Descargue y compile el código fuente del conector ModSecurity v3 Nginx
El conector ModSecurity Nginx enlaces libmodsecurity al servidor web Nginx. Clone el repositorio ModSecurity v3 Nginx Connector Git.
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
Asegúrese de estar en el directorio fuente de Nginx.
cd /usr/local/src/nginx/nginx-1.19.5/
Instale dependencias de compilación para Nginx.
sudo apt build-dep nginx sudo apt install uuid-dev
A continuación, configure el entorno con el siguiente comando. No compilaremos Nginx en sí, pero compilaremos el ModSecurity Nginx Connector módulo solamente. El --with-compat flag hará que el módulo sea compatible con su binario Nginx existente.
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
Cree el Conector ModSecurity Nginx módulo.
make modules
El módulo se guardará como objs/ngx_http_modsecurity_module.so . Cópielo en /usr/share/nginx/modules/ directorio.
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
Paso 5:Cargue el módulo conector ModSecurity v3 Nginx
Edite el archivo de configuración principal de Nginx.
sudo nano /etc/nginx/nginx.conf
Agregue la siguiente línea al principio del archivo.
load_module modules/ngx_http_modsecurity_module.so;
Además, agregue las siguientes dos líneas en el http {...} sección, por lo que ModSecurity se habilitará para todos los hosts virtuales de Nginx.
modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf;
Guarde y cierre el archivo. A continuación, cree el /etc/nginx/modsec/ directorio para almacenar la configuración de ModSecurity
sudo mkdir /etc/nginx/modsec/
Luego copie el archivo de configuración de ModSecurity.
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
Edite el archivo.
sudo nano /etc/nginx/modsec/modsecurity.conf
Busque la siguiente línea.
SecRuleEngine DetectionOnly
Esta configuración le dice a ModSecurity que registre las transacciones HTTP, pero no realiza ninguna acción cuando se detecta un ataque. Cámbielo a lo siguiente, para que ModSecurity detecte y bloquee los ataques web.
SecRuleEngine On
Luego busque la siguiente línea (línea 224), que le indica a ModSecurity qué información debe incluirse en el registro de auditoría.
SecAuditLogParts ABIJDEFHZ
Sin embargo, la configuración predeterminada es incorrecta. Sabrá por qué más adelante cuando explique cómo entender los registros de ModSecurity. La configuración debe cambiarse a la siguiente.
SecAuditLogParts ABCEFHJKZ
Si tiene un sitio web de codificación, es posible que desee deshabilitar la inspección del cuerpo de respuesta; de lo contrario, podría obtener errores prohibidos 403 simplemente cargando una página web con mucho contenido de código.
SecResponseBodyAccess Off
Guarde y cierre el archivo. A continuación, cree el /etc/nginx/modsec/main.conf archivo.
sudo nano /etc/nginx/modsec/main.conf
Agregue la siguiente línea para incluir el /etc/nginx/modsec/modsecurity.conf archivo.
Include /etc/nginx/modsec/modsecurity.conf
Guarde y cierre el archivo. También necesitamos copiar el archivo de mapeo Unicode.
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
Luego pruebe la configuración de Nginx.
sudo nginx -t
Si la prueba es exitosa, reinicie Nginx.
sudo systemctl restart nginx
Paso 6:habilitar el conjunto de reglas básicas de OWASP
Para que ModSecurity proteja sus aplicaciones web, debe definir reglas para detectar actores maliciosos y bloquearlos. Para los principiantes, es una buena idea instalar conjuntos de reglas existentes, para que pueda comenzar rápidamente y luego aprender los detalles más importantes en el camino. Hay varios conjuntos de reglas gratuitos para ModSecurity. El conjunto de reglas básicas de OWASP (CRS) es el conjunto de reglas estándar utilizado con ModSecurity.
- Es gratuito, mantenido por la comunidad y el conjunto de reglas más utilizado que proporciona una configuración predeterminada vendida para ModSecurity.
- Contiene reglas para ayudar a detener los vectores de ataque comunes, incluida la inyección SQL (SQLi), las secuencias de comandos entre sitios (XSS) y muchos otros.
- Puede integrarse con Project Honeypot.
- También contiene reglas para detectar bots y escáneres.
- Se ha ajustado a través de una amplia exposición para tener muy pocos falsos positivos.
Descargue el último OWASP CRS de GitHub.
wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
Extraiga el archivo.
tar xvf v3.3.0.tar.gz
Mueva el directorio a /etc/nginx/modsec/ .
sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/
Cambie el nombre de crs-setup.conf.example archivo.
sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Luego edite el archivo de configuración principal.
sudo nano /etc/nginx/modsec/main.conf
Agregue las siguientes dos líneas, lo que hará que Nginx incluya el archivo de configuración de CRS y las reglas individuales.
Include /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf Include /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf
Guarde y cierre el archivo. Luego pruebe la configuración de Nginx.
sudo nginx -t
Si la prueba es exitosa, reinicie Nginx.
sudo systemctl restart nginx
Paso 7:Aprenda cómo funciona OWASP CRS
Echemos un vistazo al archivo de configuración de CRS, que le proporciona una buena documentación sobre cómo funciona CRS.
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Puede ver que OWASP CRS puede ejecutarse en dos modos:
- modo independiente . Este es el modo tradicional utilizado en CRS v2.x. Si una solicitud HTTP coincide con una regla, ModSecurity bloqueará la solicitud HTTP inmediatamente y dejará de evaluar las reglas restantes.
- modo de puntuación de anomalías . Este es el modo predeterminado que se usa en CRS v3.x. ModSecurity comparará una solicitud HTTP con todas las reglas y agregará una puntuación a cada regla coincidente. Si se alcanza un umbral, la solicitud HTTP se considera un ataque y se bloqueará. La puntuación predeterminada para las solicitudes entrantes es 5 y para la respuesta saliente es 4.
Cuando se ejecuta en el modo de puntuación de anomalías, hay 4 niveles de paranoia.
- Paranoia nivel 1 (predeterminado)
- Paranoia nivel 2
- Paranoia nivel 3
- Paranoia nivel 4
Con cada aumento del nivel de paranoia, el CRS habilita reglas adicionales que le brindan un mayor nivel de seguridad. Sin embargo, los niveles más altos de paranoia también aumentan la posibilidad de bloquear tráfico legítimo debido a falsas alarmas.
Estos son los dos conceptos básicos que debe comprender antes de utilizar el CRS. Ahora podemos cerrar el archivo. Las reglas individuales de CRS se almacenan en /etc/nginx/modsec/coreruleset-3.3.0/rules/ directorio. Cada regla coincidente aumentará la puntuación de anomalía.
Paso 8:Prueba
Para verificar si ModSecurity está funcionando, puede lanzar un simple ataque de inyección SQL en su propio sitio web. (Tenga en cuenta que es ilegal realizar pruebas de seguridad en los sitios web de otras personas sin autorización). Ingrese la siguiente URL en su navegador web.
https://yourdomain.com/?id=3 or 'a'='a'
Si ModSecurity funciona correctamente, su servidor web Nginx debería devolver un mensaje de error 403 prohibido.
El navegador Firefox puede no mostrar el mensaje de error 403. Puedes presionar Ctrl+Shift+I para abrir la ventana de herramientas para desarrolladores y seleccionar la network pestaña. Luego presione F5 para recargar la página web. Ahora debería ver el código de error 403 en Firefox.
Si ModSecurity se ejecuta en DetectionOnly modo, no bloqueará este ataque de inyección SQL.
Paso 9:comprensión de los registros de ModSecurity
Es importante analizar los registros de ModSecurity, para que sepa qué tipo de ataques se dirigen a sus aplicaciones web y tome mejores medidas para defenderse de los actores de amenazas. Existen principalmente dos tipos de registros en ModSecurity:
- registro de depuración:deshabilitado por defecto.
- registro de auditoría:
/var/log/modsec_audit.log
Para comprender los registros de auditoría de ModSecurity, debe conocer las 5 fases de procesamiento en ModSecurity, que son:
- Fase 1:inspeccionar los encabezados de las solicitudes
- Fase 2:Inspeccionar el cuerpo de la solicitud
- Fase 3:inspeccionar los encabezados de respuesta
- Fase 4:inspeccionar el cuerpo de respuesta
- Fase 5:Acción (registro/bloqueo de solicitudes maliciosas)
También son dos tipos de archivos de registro.
- Serie :un archivo para todos los registros. Este es el valor predeterminado.
- Concurrente :varios archivos para iniciar sesión. Esto puede proporcionar un mejor rendimiento de escritura. Si nota que sus páginas web se ralentizan después de habilitar ModSecurity, puede optar por utilizar el tipo de registro simultáneo.
Los eventos en el registro se dividen en varias secciones.
- sección A:encabezado del registro de auditoría
- sección B:encabezado de solicitud
- sección C:cuerpo de la solicitud
- sección D:reservada
- sección E:organismo de respuesta intermediario
- sección F:encabezados de respuesta final
- sección G:reservada
- sección H:avance del registro de auditoría
- sección I:cuerpo de solicitud compacto alternativo, que excluye archivos
- sección J:información sobre los archivos cargados
- sección K:todas las reglas coincidentes con un evento, en orden de coincidencia
- sección Z:límite final
Si ejecuta un sitio web de alto tráfico, el registro de auditoría de ModSecurity puede volverse demasiado grande muy rápidamente, por lo que debemos configurar la rotación de registros para el registro de auditoría de ModSecurity. Cree un archivo de configuración logrotate para ModSecurity.
sudo nano /etc/logrotate.d/modsecurity
Agregue las siguientes líneas a este archivo.
/var/log/modsec_audit.log
{
rotate 14
daily
missingok
compress
delaycompress
notifempty
}
Esto rotará el archivo de registro todos los días (diariamente ), comprimiendo versiones antiguas (compress ). Los 14 archivos de registro anteriores se mantendrán (rotar 14 ), y no se producirá ninguna rotación si el archivo está vacío (notifempty ). Guarde y cierre el archivo.
Si su registro de ModSecurity está vacío, tal vez necesite reiniciar Nginx.
sudo systemctl restart nginx
Paso 10:Manejo de falsos positivos
ModSecurity es un firewall de aplicaciones web genérico y no está diseñado para una aplicación web específica. El conjunto de reglas básicas de OWASP también es un conjunto de reglas genérico sin una aplicación en particular en mente, por lo que es probable que vea falsos positivos después de habilitar ModSecurity y OWASP CRS. Si aumentas el nivel de paranoia en el CRS, habrá más falsos positivos.
Por ejemplo, de forma predeterminada, el CRS prohíbe la inyección de comandos de Unix como ingresar sudo en una página web, que es bastante común en mi blog. Para eliminar los falsos positivos, debe agregar exclusiones de reglas al CRS.
Exclusiones de reglas específicas de la aplicación
Hay algunas exclusiones preconstruidas específicas de la aplicación que se envían con OWASP CRS. Edite el crs-setup.conf archivo.
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Vaya a Exclusiones de reglas específicas de la aplicación sección y busque las siguientes líneas.
#SecAction \ # "id:900130,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.crs_exclusions_cpanel=1,\ # setvar:tx.crs_exclusions_drupal=1,\ # setvar:tx.crs_exclusions_dokuwiki=1,\ # setvar:tx.crs_exclusions_nextcloud=1,\ # setvar:tx.crs_exclusions_wordpress=1,\ # setvar:tx.crs_exclusions_xenforo=1"
Por ejemplo, si quiero habilitar las exclusiones de WordPress, las líneas anteriores deben cambiarse por las siguientes. Tenga cuidado con la sintaxis. No debe haber comentarios entre t:none,\ y setvar:tx.crs_exclusions_wordpress=1" . (La barra invertida \ carácter al final indica que la siguiente línea es una continuación de la línea actual.)
SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_wordpress=1" # setvar:tx.crs_exclusions_cpanel=1,\ # setvar:tx.crs_exclusions_drupal=1,\ # setvar:tx.crs_exclusions_dokuwiki=1,\ # setvar:tx.crs_exclusions_nextcloud=1,\ # setvar:tx.crs_exclusions_xenforo=1"
Guarde y cierre el archivo. Luego pruebe las configuraciones de Nginx.
sudo nginx -t
Si la prueba es exitosa, vuelva a cargar Nginx para que el cambio surta efecto.
sudo systemctl reload nginx
Tenga en cuenta que si tiene varias aplicaciones como (WordPress, Nextcloud, Drupal, etc.) instaladas en el mismo servidor, las exclusiones de reglas anteriores se aplicarán a todas las aplicaciones. Para minimizar los riesgos de seguridad, debe habilitar una regla de exclusión solo para una aplicación. Para hacerlo, vaya a /etc/nginx/modsec/coreruleset-3.3.0/rules/ directorio.
cd /etc/nginx/modsec/coreruleset-3.3.0/rules
Cambie el nombre de REQUEST-900-EXCLUSION-RULES-BEFORE-CRS archivo.
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Luego edite este archivo.
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Agregue la siguiente línea al final de este archivo. Si su WordPress está usando blog.yourdomain.com subdominio y el encabezado de solicitud enviado desde el navegador del visitante contiene este subdominio, luego ModSecurity aplicará las exclusiones de reglas para WordPress.
SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"
Si ha instalado Nextcloud en el mismo servidor, también puede agregar la siguiente línea en este archivo, de modo que si un visitante accede a su subdominio de Nextcloud, ModSecurity aplicará las exclusiones de la regla de Nextcloud.
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
Guarde y cierre este archivo. Luego pruebe las configuraciones de Nginx.
sudo nginx -t
Si la prueba es exitosa, vuelva a cargar Nginx para que el cambio surta efecto.
sudo systemctl reload nginx
Exclusiones de reglas personalizadas
Es posible que habilitar las exclusiones de reglas específicas de la aplicación preconstruidas no elimine todos los falsos positivos. Si es así, debe examinar el registro de auditoría de ModSecurity (/var/log/modsec_audit.log ), verifique qué regla causó el falso positivo y agregue sus exclusiones de reglas personalizadas en REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf archivo.
La sección H en el registro de auditoría le indica qué regla coincide. Por ejemplo, si trato de usar el <code>...</code> HTML en el formulario de comentarios, ModSecurity bloquea mi comentario. El siguiente registro me dice que la solicitud HTTP coincidió con una regla en REQUEST-941-APPLICATION-ATTACK-XSS.conf (línea 527). El ID de la regla es 941310. El URI de la solicitud es /wp-comments-post.php .
Se detecta como un ataque de filtro XSS de codificación incorrecta. Sin embargo, quiero que los usuarios puedan usar <code>...</code> y <pre>...</pre> etiqueta HTML en el formulario de comentarios, así que creé una regla de exclusión. Agregue la siguiente línea al final de REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf archivo.
SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"
Esta línea le dice a ModSecurity que si el URI de la solicitud es /wp-comments-post.php , luego no aplique la regla ID 941310. Guarde y cierre el archivo. Luego pruebe la configuración de Nginx.
sudo nginx -t
Si la prueba es exitosa, vuelva a cargar Nginx.
sudo systemctl reload nginx
Si un falso positivo coincide con varios ID de reglas, puede agregar exclusiones de reglas en una línea de la siguiente manera:
SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160,ctl:ruleRemoveById=941310,ctl:ruleRemoveById=942100"
Nota :No se recomienda deshabilitar demasiadas reglas de nivel 1 en OWASP CRS, ya que hará que su sitio web sea pirateado con mucha más facilidad. Desactive las reglas solo si sabe lo que está haciendo.
Inclusión de direcciones IP en la lista blanca
Si desea deshabilitar ModSecurity para su propia dirección IP, pero dejarlo habilitado para todas las demás direcciones IP, agregue la siguiente regla personalizada en REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf expediente. Reemplazar 12.34.56.78 con tu dirección IP real.
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"
Para incluir en la lista blanca una subred, use la siguiente sintaxis, que incluirá en la lista blanca el 10.10.10.0/24 red.
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"
Guarde y cierre el archivo. Luego pruebe las configuraciones de Nginx.
sudo nginx -t
Si la prueba es exitosa, reinicie Nginx para que el cambio surta efecto.
sudo systemctl restart nginx
Reglas de encadenamiento
Si su Nginx tiene varios hosts virtuales, es posible que desee incluir su dirección IP en la lista blanca para un host virtual específico. Necesitas encadenar dos reglas así:
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain" SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:none"
La chain palabra clave al final de la primera regla indica que el ruleEngine=off solo se tomarán medidas si la condición de la siguiente regla también es verdadera.
(Opcional) Integrar ModSecurity con Project Honeypot
Project Honeypot mantiene una lista de direcciones IP maliciosas conocidas, disponible de forma gratuita para el público. ModSecurity puede integrarse con Project Honeypot y bloquear direcciones IP en la lista de Project Honeypot.
Tenga en cuenta que el uso de Project Honeypot hará que su sitio web sea más lento para los nuevos visitantes, porque su servidor web deberá enviar una consulta a Project Honeypot antes de que pueda enviar una respuesta al nuevo visitante. Sin embargo, una vez que los datos de reputación de IP se almacenan en caché en su servidor web, el impacto en el rendimiento será mínimo.
Para usar Project Honeypot, primero cree una cuenta gratuita en su sitio web. Luego vaya al panel de control de su cuenta y haga clic en get one enlace para solicitar una clave de acceso a la lista negra de HTTP.
A continuación, edite el crs-setup.conf archivo.
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Encuentra las siguientes líneas.
#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"
Eliminar el principio # caracteres para descomentarlos y agregar su clave API HTTPBL obtenida de Project Honeypot.
Tenga en cuenta que block_search_ip debe establecerse en 0 (deshabilitado), ya que no queremos bloquear los rastreadores de los motores de búsqueda. Guarde y cierre el archivo. Luego recarga Nginx.
sudo systemctl reload nginx
Ahora ModSecurity consultará Project Honeypot en todas las solicitudes HTTP. Para probar si esto funcionaría, edite el archivo /etc/nginx/modsec/main.conf.
sudo nano /etc/nginx/modsec/main.conf
Agregue la siguiente línea al final de este archivo. Esto nos permite pasar una dirección IP en una URL. (Una vez que la prueba sea exitosa, puede eliminar esta línea del archivo).
SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'
Guarde y cierre el archivo. Pruebe las configuraciones de Nginx.
sudo nginx -t
Luego recarga Nginx.
sudo systemctl reload nginx
Vaya al sitio web de Project Honeypot y busque una dirección IP maliciosa, por ejemplo, 134.119.218.243. Ejecute el siguiente comando para probar la lista negra de HTTP.
curl -i -s -k -X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'
Su servidor web debería devolver una respuesta prohibida 403, debido a la dirección IP en Project Honeypot.
Cómo usar Brotli con ModSecurity en Nginx
Tradicionalmente, las páginas web se comprimen con GZIP para una mayor velocidad de carga. Desarrollado por Google, Brotli es un nuevo algoritmo de compresión que proporciona una mejor relación de compresión. Es compatible con todos los principales navegadores web. Para usar Brotli en Nginx, primero debe instalar el módulo Brotli Nginx desde ondrej/nginx-mainline APP.
sudo apt install libnginx-mod-brotli
Luego abra el archivo de configuración principal de Nginx.
sudo nano /etc/nginx/nginx.conf
Agregue las siguientes líneas en el http {...} contexto.
brotli on;
brotli_comp_level 6;
brotli_static on;
brotli_types application/atom+xml application/javascript application/json application/rss+xml
application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype
application/x-font-ttf application/x-javascript application/xhtml+xml application/xml
font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon
image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;
Save and close the file, then test Nginx configurations.
sudo nginx -t
If the test is successful, restart Nginx.
sudo systemctl restart nginx
Now go to the home page your website, open the developer tools in your web browser (In Firefox you can press Ctrl+Alt+I to open it up). Select the Network tab, and press F5 to reload the web page. Click on the main HTML page.
Check the response header on the right sidebar. If the content-encoding is set to br , then you have successfully enabled Brotli compression in Nginx.
If the content-encoding is gzip , then your Nginx web server is still using GZIP.
Upgrading Nginx
ModSecurity integrates with Nginx as a dynamic module, so every time the Nginx binary is upgraded, you need to rebuild the ModSecurity module for Nginx. This will make your application offline for a few minutes.
If a newer version of Nginx is available in the repository, the sudo apt upgrade command will upgrade Nginx. The newer version of Nginx is not going to be compatible with the previously compiled ModSecurity module. If Nginx is upgraded by the sudo apt upgrade command, it will fail to restart as shown in the screenshot below.
And if you run sudo nginx -t command, it tells you that Nginx expects a new version of the ModSecurity module.
My advice is to prevent Nginx from being upgraded when you run sudo apt upgrade dominio. This can be achieved by the following command:
sudo apt-mark hold nginx
Now if you run sudo apt update;sudo apt upgrade , and the package manager tells you that the nginx package is held back from upgrading, then it means there’s a new nginx version available in the repository.
You should download the new Nginx source package and compile the ModSecurity module again. Move the newly-compiled ModSecurity module to /usr/share/nginx/modules/ directorio. Basically that means you need to remove everything under /usr/local/src/ directory (sudo rm /usr/local/src/* -rf ) and go through step 2 and step 4 again.
Then unhold Nginx.
sudo apt-mark unhold nginx
And upgrade Nginx.
sudo apt upgrade nginx
Once the upgrade is complete, hold Nginx again.
sudo apt-mark hold nginx
To show what packages are held, run
apt-mark showhold
Nginx Plus
If you use the commercial Nginx Plus web server, then ModSecurity is included in the Nginx Plus binary. It’s known as the NGINX WAF .
If you don’t want to spend time re-compiling the ModSecurity source code, then you might want to purchase Nginx Plus, as the ModSecurity module is pre-compiled in the Nginx Plus binary. Benefits of Using ModSecurity 3.0 with NGINX Plus:
- You don’t need to compile the ModSecurity dynamic module yourself; NGINX, Inc. provides a precompiled module for you, saving time and effort.
- NGINX, Inc. has extensively tested the dynamic module, so you know it’s suitable for production usage.
- NGINX, Inc. continually tracks changes and updates the module for every important change and security vulnerability, so you don’t have to do this yourself.
- Each new release of NGINX Plus includes a new version of the dynamic module, so you can upgrade without having to re-compile ModSecurity.
- You get 24×7 support with both installation of the ModSecurity and the OWASP Core Rule Set, as well as troubleshooting and debugging assistance.
How to Disable ModSecurity for a Virtual Host
In this tutorial, I added the following line in the http {...} context.
modsecurity on;
This will enable ModSecurity for all Nginx server blocks (aka virtual hosts). If you want to disable ModSecurity for a specific server block, then edit the server block file (/etc/nginx/conf.d/example.com.conf ) and add the following line to the server {...} context.
modsecurity off;
Reload Nginx for the change to take effect.
sudo systemctl reload nginx
FAQ
Static Module vs Dynamic Module in Nginx
- A static module must be compiled with Nginx and it’s integrated with Nginx as one binary. It can’t be unloaded from Nginx.
- A dynamic module is a separate package from the main Nginx binary. It can be loaded and unloaded in Nginx.
What does Binary Compatible Mean?
- If a dynamic module is not binary compatible, then the module and Nginx should be compiled together. If there’s an existing Nginx binary installed from a software repository using
apt-get, it must be removed and you need to install the compiled Nginx binary in order to use the dynamic module. - If a dynamic module is binary compatible, then this module can be compiled individually without compiling Nginx. The module can be used with your existing Nginx binary installed from a software repository. It’s not perfect, though.
No matter a module is static or dynamic, binary compatible or non binary compatible, if you upgrade the Nginx binary later, you need to compile the module again.
Upgrade Server RAM
ModSecurity can use a fair amount of RAM. If you can see the following error in your Nginx error log (/var/log/nginx/error.log), it means your server is short of RAM.
fork() failed while spawning "worker process" (12: Cannot allocate memory) sendmsg() failed (9: Bad file descriptor) sendmsg() failed (9: Bad file descriptor) sendmsg() failed (9: Bad file descriptor)
You need to restart Nginx and upgrade server RAM, then the above error is not going to happen again.
How to Upgrade OWASP CRS
Besides upgrading the ModSecurity Nginx module, you also need to upgrade the core rule set when a new version comes out. The process is straightforward.
- Go through step 6 again to install the new version of core rule set.
- Then go to step 10. Copy of your custom rules in the
crs-setup.confandREQUEST-900-EXCLUSION-RULES-BEFORE-CRSarchivo.
Next, test Nginx configurations.
sudo nginx -t
If the test is successful, reload Nginx for the change to take effect.
sudo systemctl reload nginx
How do you know if the new version is working? Launch a simple SQL injection attack like in step 8 and check your server logs. It will show you the CRS version that’s preventing this attack.