Cómo instalar Apache con ModSecurity en Ubuntu 22.04 LTS

ModSecurity, a menudo denominado Modsec, es un firewall de aplicaciones web de código abierto y gratuito (WAF). ModSecurity se creó como un módulo para el servidor HTTP Apache. Sin embargo, desde sus inicios, 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 Apache.

Cómo funciona WAF, el motor ModSecurity se implementa delante de 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 de OWASP (CRS), 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 de OWASP con ModSecurity puede ayudar a proteger casi instantáneamente su servidor contra:

  • Malos agentes de usuario
  • DDOS
  • Scripting de sitios web cruzados
  • inyección SQL
  • Secuestro de sesión
  • Otras amenazas

Durante el tutorial, puede notar que está instalando la compilación de la versión 2 y esto se debe a que, a diferencia de Nginx, la versión beta de Apache para el conector Apache/Modsecurity se ha abandonado y no funcionará de manera efectiva, por lo que se recomienda permanecer en el construcción original. Todavía se están realizando actualizaciones, por lo que la versión dos no se abandona.

En el siguiente tutorial, aprenderá cómo instalar ModSecurity 3 y OWASP Core Rule Set con Apache en Ubuntu 22.04 LTS Jammy Jellyfish con configuraciones de ejemplo.

Anuncio

OWASP tiene tres versiones para instalar; Probé tanto el 3.3.2 como el 4.0.0 RC1, que trabajado.

Anuncio

Actualizar Ubuntu

Primero, actualice su sistema para asegurarse de que todos los paquetes existentes estén actualizados.

sudo apt update && sudo apt upgrade -y

Instalar Apache más reciente

En primer lugar, se recomienda eliminar cualquier instalación existente de Apache e instalar la última versión, que usaremos el PPA de Ondrey Surfury.

Eliminar la instalación existente de Apache

Detenga el servicio actual si está instalado con el siguiente comando.

Anuncio
sudo systemctl stop apache2

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

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

Agregar el último PPA de Apache

Ahora que ha eliminado su antiguo servicio Apache, importe el PPA.

Anuncio
sudo add-apt-repository ppa:ondrej/apache2 -y

Después de importar el repositorio que desea, use el siguiente comando para actualizar su lista de fuentes APT.

sudo apt update

Ahora que ha instalado el PPA y actualizó la lista de repositorios, instale Apache con el siguiente comando.

sudo apt install apache2 -y

Instalar/Habilitar ModSecurity Módulo Apache

El primer paso es instalar el módulo Apache incluido en el repositorio por defecto de Ubuntu 22.04 con el siguiente comando.

Anuncio
sudo apt install libapache2-mod-security2

Una vez instalado, habilite el módulo de la siguiente manera.

sudo a2enmod security2

Asegúrese de reiniciar su servicio Apache2 para reflejar el nuevo módulo y los cambios.

sudo systemctl restart apache2

Habilitar módulo ModSecurity

Las configuraciones de Apache ModSecurity se pueden encontrar en /etc/apache2/mods-enabled/security2.conf, que tendrá una línea que contiene lo siguiente.

Anuncio
IncludeOptional /etc/modsecurity/*.conf

Ejemplo:

Cómo instalar Apache con ModSecurity en Ubuntu 22.04 LTS

Apache cargará todos los * .conf archivos de la /etc/modsecurity/ directorio, pero tendrá que cambiar el nombre del modsecurity.conf-recomendado archivo de configuración primero.

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

Luego, usando su editor de texto favorito en Ubuntu, abra el modsecurity.conf archivo de la siguiente manera.

sudo nano /etc/modsecurity/modsecurity.conf

De forma predeterminada, la configuración de ModSecurity tiene el motor de reglas especificado como (Solo detección), que en otras palabras, ejecuta ModSecurity y detecta todo el comportamiento malicioso, pero no bloquea ni prohíbe acciones 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.

En el archivo de configuración, cambie este comportamiento a (en), que se encuentra en la línea 7.

SecRuleEngine DetectionOnly

Cambie la línea a esto para habilitar ModSecurity:

Anuncio
SecRuleEngine On

Ejemplo:

Anuncio
Cómo instalar Apache con ModSecurity en Ubuntu 22.04 LTS

Ahora, necesitas ubicar lo siguiente SecAuditLogParts, que se encuentra en la línea 224.

# Log everything we know about a transaction.
SecAuditLogParts ABDEFHIJZ

Esto no es correcto y debe cambiarse. Modifique la línea a lo siguiente:

SecAuditLogParts ABCEFHJKZ

Ahora guarda el El uso de archivos (CTRL + O), luego salir (CTRL + X).

Vea también  Cómo instalar SeaMonkey en Ubuntu 22.10/22.04/20.04

Reinicie su servicio Apache usando el comando systemctl para hacer los cambios en vivo.

sudo systemctl restart apache2

Instale el 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.

Anuncio
Anuncio

Asegúrate de leer Página de etiquetas de lanzamiento de OWASP para ver cuál es la última, ya que el siguiente ejemplo puede haber cambiado en el futuro.

Primero, cree el directorio que será el padre principal de OWASP.

sudo mkdir /etc/apache2/modsec/

Usando el  comando wget, descargar el archivo OWASP CRS 3.3.2, que a partir de esta fecha es el último estable, pero tenga en cuenta que hace cuatro días, la versión preliminar se eliminó, por lo que mi consejo es consultar el enlace unas líneas más arriba para ver cómo se ven los lanzamientos para el conjunto de reglas básico.

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.

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

En el momento de la creación del tutorial, la versión preliminar v4.0.0-RC1 también está disponible, como se mencionó anteriormente.

Anuncio
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.0.0-rc1.zip

Instale la Descomprimir paquete si no tiene esto instalado en su servidor.

sudo apt install unzip -y

Ahora descomprima el archivo.

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

Recuerde, si ha descargado v4.0 o nightly, cambie los comandos para reflejar esto.

OWASP CRS viene con un archivo de configuración de muestra que debe cambiar de nombre. Lo mejor es utilizar el comando CP y mantener una copia de seguridad para el futuro en caso de que necesite reiniciar de nuevo.

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

Recuerde que el comando anterior es solo un ejemplo, asegúrese de cambiar /coreruleset-3.3.2/ con la versión exacta de OWASP que decidas.

Para habilitar las reglas, abra el /etc/etc/apache2/mods-enabled/security2.conf como sigue.

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

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

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

Recuerde que el comando anterior es solo un ejemplo, asegúrese de cambiar /coreruleset-3.3.2/ con la versión exacta de OWASP que decidas.

Además, borre la siguiente línea o elimínela.

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

Ejemplo:

Cómo instalar Apache con ModSecurity en Ubuntu 22.04 LTS

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

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

Anuncio
sudo systemctl restart apache2

Uso y comprensión del conjunto de reglas básicas de OWASP

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

Abre tu CRS-setup.conf archivo.

Anuncio
sudo nano /etc/apache2/modsec/coreruleset-3.3.2/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.

Puntaje OWASP CRS

Para desglosarlo, ModSecurity tiene dos modos:

Modo de puntuación de anomalías

Anuncio
# -- [[ 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

Anuncio
# -- [[ 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 de usar.

Vea también  Cómo instalar el código de Visual Studio en Ubuntu 22.10/22.04/20.04

Hay cuatro niveles de paranoia:

  • Paranoia Nivel 1 - Nivel predeterminado y recomendado para la mayoría de usuarios.
  • Paranoia Nivel 2 - Solo usuarios avanzados.
  • Paranoia Nivel 3 - Solo usuarios expertos.
  • Paranoia Nivel 4 - No se recomienda en absoluto, excepto en 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 403 error prohibido. Si no es así, se ha omitido un paso.

Ejemplo:

Anuncio
Anuncio
Cómo instalar Apache con ModSecurity en Ubuntu 22.04 LTS

Falta cambiar el problema más común Solo detección a On, como se cubrió anteriormente en el tutorial.

Manejo de falsos positivos y exclusión de reglas personalizadas

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

Una buena regla general es ejecutar el conjunto de reglas durante unas pocas semanas o meses sin casi ningún falso positivo, luego aumentar, por ejemplo, el nivel de paranoia 1 al nivel de paranoia 2, para que no se vea abrumado por una tonelada simultáneamente.

Vea también  Cómo instalar Okular en Linux Mint 21 LTS

Exclusión de aplicaciones conocidas de falsos positivos

Modsecurity, de forma predeterminada, puede incluir en la lista blanca las acciones diarias 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 como usas los tres, descomentar las líneas y deja el (1) número intacto, cambie los otros servicios que no utiliza, por ejemplo, Xenforo a (0) ya que no desea incluir estas reglas en la lista blanca.

Anuncio

Ejemplo a continuación:

Anuncio
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.

Reglas de exclusión antes de CRS

Para hacer frente a las exclusiones personalizadas, en primer lugar, debe cambiar el nombre del REQUEST-900-EXCLUSION-RULES-ANTES-CRS-SAMPLE.conf presentar ante la comando cp como sigue:

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

Un punto a recordar al crear reglas de exclusión, cada una debe tener id: y sea único, o de lo contrario, cuando pruebe su servicio Apache2, obtendrá un error.

Anuncio

Ejemplo "Id: 1544, fase: 1, log, allow, ctl: ruleEngine = off", la identificación 1544 no se puede utilizar 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:

Anuncio
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 direcciones IP en la lista blanca; algunas maneras en que puede hacer esto:

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"

Los programas @ipPartido se puede utilizar más extensamente para las subredes. Si desea denegar un cambio de subred o dirección IP, permita denegar. Con un poco de conocimiento, también puede crear listas negras y listas blancas y configurarlas con fail2ban. Las posibilidades a menudo pueden ser infinitas.

Anuncio

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, si desea eliminar reglas 941000 y 942999 a partir de su /administración/ 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 Eliminar por ID como el siguiente ejemplo:

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

Se pueden encontrar ejemplos en ModSecurity GIT página wiki.

Anuncio

Conjunto de reglas de WordPress WPRS para ModSecurity

Otra opción para WordPress los usuarios es instalar y ejecutar junto con su conjunto de reglas OWASP CRS, un proyecto bien conocido titulado Conjunto de reglas WPRS. Como esto es opcional y no es para todos, el tutorial no lo cubrirá en esta sección.

Sin embargo, si desea instalar esto para obtener protección adicional si usa WordPress en su servidor, visite nuestro tutorial en Instalación de WordPress ModSecurity Rule Set (WPRS).

Anuncio

Cree el archivo ModSecurity LogRotate.

Los registros de ModSecurity pueden crecer demasiado, por lo que debe configurar la rotación de registros, ya que esto no se hace por usted.

Primero, cree y abra su archivo de rotación ModSecurity modsec.

sudo nano /etc/logrotate.d/modsec

Agrega el siguiente código:

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

Esto mantendrá los registros durante 31 días. Si prefiere tener menos, cambie de 31 a 7 días, lo que equivale a una semana de registros. Debería estar rotando diariamente para ModSecurity. Si necesita revisar los archivos de registro, tener un archivo semanal será un desastre para revisar, dado lo grande que será.

Anuncio

Comentarios y Conclusión

En general, implementar ModSecurity en su servidor proporcionará protección instantánea. Sin embargo, la paciencia, el tiempo y la dedicación al aprendizaje serán una gran característica. Lo último que desea es bloquear los bots de SEO o, lo que es más importante, los usuarios reales que podrían ser clientes potenciales.

Anuncio


¿No es lo que estabas buscando? Intente buscar tutoriales adicionales.

Deja un comentario