Una guía práctica para asegurar y endurecer el Servidor HTTP Apache.

El Servidor Web es una parte crucial de las aplicaciones basadas en web. El Servidor Web Apache suele estar situado en el extremo de la red, por lo que se convierte en uno de los servicios más vulnerables a los ataques.

Su configuración por defecto proporciona mucha información sensible que puede ayudar al hacker a preparar un ataque a las aplicaciones. La mayoría de los ataques a aplicaciones web se producen a través de ataques XSS, fugas de información, gestión de sesiones e inyección SQL, que se deben a un código de programación débil y a la falta de saneamiento de la infraestructura de la aplicación web.

Una interesante investigación de Positive Technologies revela que el 52% de las aplicaciones escaneadas presentaban vulnerabilidades elevadas.

vulnerability-report

En este artículo, hablaré de algunas de las mejores prácticas para asegurar el servidor HTTP Apache en la plataforma Linux.

Las siguientes se han probado en la versión 2.4.x de Apache.

  • Esto supone que ha instalado Apache en la plataforma UNIX. Si no es así, puede consultar la guía de instalación de Apache.
  • Llamaré al directorio de instalación de Apache /opt/apache como $Web_Server a lo largo de esta guía.
  • Se le aconseja hacer una copia de seguridad del archivo de configuración existente antes de cualquier modificación.

Audiencia

Esta guía está diseñada para Administradores de Middleware, Soporte de Aplicaciones, Analistas de Sistemas, o cualquier persona que trabaje o desee aprender las guías de Hardening & Seguridad.

Es obligatorio un buen conocimiento del servidor web Apache y de los comandos UNIX.

Notas

Se requiere alguna herramienta para examinar las Cabeceras HTTP para algunas de las verificaciones de implementación. Hay dos formas de hacerlo.

  1. Utilice las herramientas de desarrollo incorporadas en el navegador para inspeccionar las cabeceras HTTP. Normalmente, está en la pestaña Red
  2. Utilice la herramienta de comprobación de cabeceras de respuesta HTTP en línea

Eliminar el banner de versión del servidor

Yo diría que esta es una de las primeras cosas a tener en cuenta, ya que no querrá exponer qué versión de servidor web está utilizando. Exponer la versión significa que está ayudando al hacker a acelerar el proceso de reconocimiento.

La configuración por defecto expondrá la versión de Apache y el tipo de sistema operativo como se muestra a continuación.

apache-server-banner
  • Vaya a la carpeta $Web_Server/conf
  • Modifique httpd.conf utilizando el editor vi
  • Añada la siguiente directiva y guarde el httpd.conf
ServerTokens Prod
ServerSignature Off
  • Reinicie apache

ServerSignature eliminará la información de versión de la página generada por Apache.

ServerTokens cambiará el encabezado a sólo producción, es decir, Apache

Como puede ver a continuación, la información sobre la versión y el sistema operativo ha desaparecido.

apache-server-banner-masked

Deshabilitar el listado de directorios en el navegador

Deshabilite el listado de directorios en un navegador, para que el visitante no vea todos los archivos y carpetas que tiene bajo la raíz o subdirectorio.

Probemos cómo se ve en la configuración por defecto.

  • Vaya al directorio $Web_Server/htdocs
  • Cree una carpeta y algunos archivos dentro de ella
# mkdir test
# touch hi
# touch hola

Ahora, intentemos acceder a Apache por http://localhost/test

apache-directory-listing

Como puede ver revela todos los archivos/carpetas que tiene y estoy seguro que no quiere exponer eso.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd. conf usando vi
  • Busque Directory y cambie la directiva Options a None o -Indexes
<directorio opt="" apache="" htdocs="">
Opciones -Indexes
</directorio>

(o)

<directorio opt="" apache="" htdocs="">
Opciones Ninguno
</directorio>
  • Reinicie Apache

Nota: si tiene varias directivas Directory en su entorno, debería considerar hacer lo mismo para todas.

Ahora, intentemos acceder a Apache mediante http://localhost/test

disabled-directory-listing

Como puede ver, muestra un error de prohibido en lugar de mostrar el listado de carpetas de prueba.

Etag

Permite a los atacantes remotos obtener información sensible como el número de inodo, el límite MIME multiparte y el proceso hijo a través de la cabecera Etag.

Para prevenir esta vulnerabilidad, implementémosla como se indica a continuación. Esto es necesario arreglar para el cumplimiento de PCI.

  • Vaya al directorio $Web_Server/conf
  • Añada la siguiente directiva y guarde el httpd.conf
FileETag Ninguno
  • Reinicie apache

Ejecute Apache desde una cuenta sin privilegios

Una instalación por defecto se ejecuta como nobody o daemon. Utilizar un usuario separado sin privilegios para Apache es bueno.

La idea aquí es proteger otros servicios en ejecución en caso de cualquier agujero de seguridad.

  • Cree un usuario y un grupo llamados apache
# groupadd apache
# useradd -G apache apache
  • Cambie la propiedad del directorio de instalación de apache a un usuario sin privilegios recién creado
# chown -R apache:apache /opt/apache
  • Vaya a $Web_Server/conf
  • Modifique httpd.conf utilizando vi
  • Busque la directiva de usuario y grupo y modifíquela como cuenta sin privilegios apache
Usuario apache 
Grupo apache
  • Guarde el httpd.conf
  • Reinicie Apache

grep para el proceso http en ejecución y asegúrese de que se está ejecutando con el usuario apache

# ps -ef |grep http

Debería ver que un proceso se está ejecutando con root. Eso es porque Apache está escuchando en el puerto 80 y tiene que iniciarse con root.

Proteger el permiso de los directorios binario y de configuración

Por defecto, el permiso para binarios y configuración es 755 lo que significa que cualquier usuario en un servidor puede ver la configuración. Puede desautorizar a otro usuario para que entre en la carpeta conf y bin.

  • Vaya al directorio $Web_Server
  • Cambie el permiso de las carpetas bin y conf
# chmod -R 750 bin conf

Protección de la configuración del sistema

En una instalación por defecto, los usuarios pueden anular la configuración de apache mediante .htaccess. Si desea impedir que los usuarios modifiquen la configuración de su servidor apache, puede añadir AllowOverride a None como se muestra a continuación.

Esto debe hacerse en el nivel raíz.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi
  • Busque el directorio a nivel de raíz
<directorio> 
Opciones -Indexes 
AllowOverride Ninguno
</directorio>
  • Guarde el httpd.conf
  • Reinicie Apache

Métodos de petición HTTP

El protocolo HTTP 1.1 soporta muchos métodos de petición que pueden no ser necesarios y algunos de ellos tienen un riesgo potencial.

Típicamente usted puede necesitar los métodos de petición GET, HEAD, POST en una aplicación web, los cuales pueden ser configurados en la respectiva directiva Directory.

La configuración por defecto soporta los métodos OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT en el protocolo HTTP 1.1.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf utilizando vi
  • Busque el directorio y añada lo siguiente
<limitexcept get="" post="" head="">
denegar desde todos
</limitexcept>
  • Reinicie Apache

Desactivar Rastreo de Peticiones HTTP

Por defecto el método Trace está habilitado en el servidor web Apache.

Tenerlo habilitado puede permitir un ataque de Cross Site Tracing y potencialmente dar una opción a un hacker para robar información de cookies. Veamos como se ve en la configuración por defecto.

  • Haga un telnet IP del servidor web con el puerto de escucha
  • Haga una petición TRACE como se muestra a continuación
#telnet localhost 80 
Probando 127.0.0.1...
Conectado a localhost.
El carácter de escape es '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 200 OK
Date: Sat, 31 Aug 2013 02:13:24 GMT
Servidor: Apache
Codificación de transferencia: chunked
Tipo de contenido: message/http 20
RASTREAR / HTTP/1.1
Anfitrión: test 
0
Conexión cerrada por host ajeno.
#

Como puede ver en la solicitud TRACE anterior, ha respondido a mi consulta. Desactivémoslo y probémoslo.

  • Vaya al directorio $Web_Server/conf
  • Añada la siguiente directiva y guarde el httpd.conf
TraceEnable off
  • Reinicie apache

Haga un telnet IP del servidor web con el puerto de escucha y haga una petición TRACE como se muestra a continuación

#telnet localhost 80
Probando 127.0.0.1...
Conectado a localhost.
El carácter de escape es '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 405 Método no permitido
Fecha: Sat, 31 Aug 2013 02:18:27 GMT
Servidor: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> 
<title>405 Método no permitido</title> </head><body> 
<h1>Método no permitido</h1>
<p>El método solicitado TRACE no está permitido para la URL /.</p> </body></html>
Conexión cerrada por host ajeno.
#

Como pudo ver en la solicitud TRACE anterior, ha bloqueado mi solicitud con HTTP 405 Método no permitido.

Ahora, este servidor web no permite la petición TRACE y ayuda en el bloqueo del ataque Cross Site Tracing.

Puede mitigar la mayoría de los ataques comunes de Cross Site Scripting utilizando HttpOnly y Secure flag en una cookie. Sin tener HttpOnly y Secure, es posible robar o manipular la sesión y las cookies de la aplicación web, y es peligroso.

  • Asegúrese de que mod_headers.so está habilitado en su httpd.conf
  • Vaya al directorio $Web_Server/conf
  • Añada la siguiente directiva y guarde el httpd.conf
Edición de encabezado Set-Cookie ^(.*)$ $1;HttpOnly;Secure
  • Reinicie apache

Ataque Clickjacking

Clickjacking es una conocida vulnerabilidad de las aplicaciones web.

  • Asegúrese de que mod_headers.so está habilitado en su httpd.conf
  • Vaya al directorio $Web_Server/conf
  • Añada la siguiente directiva y guarde el httpd.conf
Añada siempre el encabezado X-Frame-Options SAMEORIGIN
  • Reinicie apache
apache-x-frame-options

X-Frame-Options admite dos opciones más, que explico aquí.

Server Side Include

Server Side Include (SSI) tiene el riesgo de aumentar la carga del servidor. Si tiene un entorno compartido y aplicaciones web con mucho tráfico, debería considerar desactivar SSI añadiendo Includes en la directiva Options.

El ataque SSI permite explotar una aplicación web inyectando scripts en las páginas HTML o ejecutando códigos de forma remota.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf utilizando vi
  • Busque el directorio y añada la directiva Includes in Options
<directorio opt="" apache="" htdocs="">
Opciones -Indexes -Includes
Ordenar allow,denyAllow de todos
</directorio>
  • Reinicie Apache

Nota: si tiene varias directivas Directory en su entorno, debería considerar hacer lo mismo para todas.

Protección X-XSS

La protección Cross Site Scripting (XSS) puede ser eludida en muchos navegadores. Usted podría aplicar esta protección para una aplicación web si fuera desactivada por el usuario. Esto es utilizado por la mayoría de las empresas web gigantes como Facebook, Twitter, Google, etc.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf utilizando vi y añada la siguiente directiva Header
Header set X-XSS-Protection "1; mode=block"
  • Reinicie Apache

Como puede ver, XSS-Protection es el inyectado en la cabecera de respuesta.

apache-xss

Desactivar el protocolo HTTP 1.0

Cuando hablamos de seguridad, debemos proteger todo lo que podamos. Entonces, ¿por qué utilizamos versiones antiguas del protocolo HTTP, deshabilitémoslas también?

HTTP 1.0 tiene debilidades de seguridad relacionadas con el secuestro de sesión. Podemos deshabilitar esto utilizando el módulo mod_rewrite.

  • Asegúrese de cargar el módulo mod_rewrite en el archivo httpd.conf
  • Habilite la directiva RewriteEngine como sigue y añada la condición Rewrite para permitir sólo HTTP 1.1
RewriteEngine Activado
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]

Configuración del valor de tiempo de espera

Por defecto, el valor de tiempo de espera de Apache es de 300 segundos, lo que puede ser víctima de un ataque Slow Loris y DoS. Para mitigar esto, puede bajar el valor de tiempo de espera a unos 60 segundos.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi
  • Añada lo siguiente en httpd.conf
Tiempo de espera 60

SSL

Tener SSL es una capa adicional de seguridad que está añadiendo a la aplicación Web. Sin embargo, la configuración por defecto de SSL conduce a ciertas vulnerabilidades, y usted debería considerar ajustar esas configuraciones.

Clave SSL

Vulnerar la clave SSL es difícil, pero no imposible. Es sólo una cuestión de potencia de cálculo y tiempo.

Como ya sabrá, utilizando un PC de la era de 2009 crackeando durante unos 73 días se puede aplicar ingeniería inversa a una clave de 512 bits.

Por tanto, cuanto mayor sea la longitud de la clave, más complicado resultará descifrar la clave SSL. La mayoría de las empresas web gigantes utilizan claves de 2048 bits, como se indica a continuación, así que ¿por qué nosotros no?

  • Outlook.com
  • Microsoft.com
  • Live.com
  • Skype.com
  • Apple.com
  • Yahoo.com
  • Bing.com
  • Hotmail.com
  • Twitter.com

Puede utilizar OpenSSL para generar CSR con 2048 bits como se indica a continuación.

openssl req -out geekflare.csr -newkey rsa:2048 -nodes -keyout geekflare.key

Generará una CSR que deberá enviar a una autoridad de certificación para que la firme. Una vez que reciba el archivo de certificado firmado, puede añadirlo en el archivo httpd-ssl.conf

SSLCertificateFile #Certificado firmado por la autoridad
SSLCertificateChainFile #Firmante del certificado dado por la autoridad
SSLCertificateKeyFile #Archivo de claves que generó anteriormente
  • Reinicie el servidor web Apache e intente acceder a la URL con https

Cifrado SSL

El cifrado SSL es un algoritmo de encriptación que se utiliza como clave entre dos ordenadores a través de Internet. El cifrado de datos es el proceso de convertir texto plano en códigos cifrados secretos.

Es en base a la configuración del Cifrado SSL de su servidor web que la encriptación de datos tendrá lugar. Así que es importante configurar el Cifrado SSL, que es más fuerte y no vulnerable.

  • Vaya a la carpeta $Web_Server/conf/extra
  • Modifique la directiva SSLCipherSuite en httpd-ssl.conf como se indica a continuación para aceptar sólo algoritmos de cifrado superiores
SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4
  • Guarde el archivo de configuración y reinicie el servidor apache

Nota: si tiene muchos cifrados débiles en su informe de auditoría SSL, puede rechazarlos rápidamente añadiendo ! al principio.

Desactivar SSL v2 & v3

SSL v2 & v3 tiene muchos fallos de seguridad, y si usted está trabajando hacia la prueba de penetración o el cumplimiento PCI, entonces se espera que cierre el hallazgo de seguridad para desactivar SSL v2/v3.

Cualquier comunicación SSL v2/v3 puede ser vulnerable a un ataque Man-in-The-Middle que podría permitir la manipulación o divulgación de datos.

Implementemos el servidor web apache para que sólo acepte la última versión de TLS y rechace la solicitud de conexión SSL v2/v3.

  • Vaya a la carpeta $Web_Server/conf/extra
  • Modifique la directiva SSLProtocol en httpd-ssl.conf como se indica a continuación para aceptar sólo TLS 1.2 
SSLProtocolo -ALL TLSv1.2

Una vez que haya terminado con la configuración SSL, es una buena idea probar su aplicación web con la herramienta en línea de certificados SSL/TLS para encontrar cualquier error de configuración.

Mod Seguridad

Mod Security es un cortafuegos de aplicaciones web de código abierto, que puede utilizar con Apache.

Viene como un módulo que tiene que compilar e instalar. Si no puede permitirse un cortafuegos de aplicaciones web comercial, ésta sería una excelente opción.

Para proporcionar una protección genérica de las aplicaciones web, las reglas básicas utilizan las siguientes técnicas:

  • Protección HTTP – detección de violaciones del protocolo HTTP y de una política de uso definida localmente
  • Búsquedas en la lista negra en tiempo real – utiliza la reputación IP de terceros
  • Detección de malware basado en la web – identifica contenido web malicioso mediante comprobación con la API de navegación segura de Google.
  • Protecciones contra denegación de servicio HTTP – defensa contra inundaciones HTTP y ataques DoS HTTP lentos.
  • Protección contra ataques web comunes – detección de ataques comunes a la seguridad de las aplicaciones web
  • Detección automatizada – detección de bots, rastreadores, escáneres y otras actividades maliciosas de superficie
  • Integración con el escaneado AV de cargas de archivos – identifica los archivos maliciosos cargados a través de la aplicación web.
  • Seguimiento de datos sensibles – Rastrea el uso de tarjetas de crédito y bloquea las filtraciones.
  • Protección contra troyanos – Detecta el acceso a caballos troyanos.
  • Identificación de defectos de la aplicación – alerta sobre los errores de configuración de la aplicación.
  • Detección y ocultación de errores – Disimula los mensajes de error enviados por el servidor.

Descarga e instalación

Los siguientes requisitos previos deben estar instalados en el servidor en el que desee utilizar Mod Security con Apache. Si alguno de ellos no existe, la compilación de Mod Security fallará. Puede utilizar yum install en Linux o Centos para instalar estos paquetes.

  • apache 2.x o superior
  • paquete libpcre
  • paquete libxml2
  • paquete liblua
  • paquete libcurl
  • paquete libapr y libapr-util
  • módulo mod_unique_id incluido con el servidor web Apache

Ahora, descarguemos la última versión estable de Mod Security 2.7.5 desde aquí

  • Transfiera el archivo descargado a /opt/apache
  • Extraiga modsecurity-apache_2.7.5.tar.gz
# gunzip -c modsecurity-apache_2.7.5.tar.gz | tar xvf -
  • Vaya a la carpeta extraída modsecurity-apache_2.7.5
# cd modsecurity-apache_2.7.5
  • Ejecute el script configure incluyendo la ruta apxs al Apache existente
# ./configure -with-apxs=/opt/apache/bin/apxs
  • Compile e instale con el script make
# make
# make install
  • Una vez realizada la instalación, vería mod_security2.so en la carpeta modules bajo /opt/apache

Con esto concluye, ha instalado el módulo Mod Security en el servidor web Apache existente.

Configuración

Para utilizar la función Mod security con Apache, tenemos que cargar el módulo mod security en httpd.conf. El módulo mod_unique_id es un requisito previo para Mod Security.

Este módulo proporciona una variable de entorno con un identificador único para cada solicitud, que es rastreado y utilizado por Mod Security.

  • Añada la siguiente línea para cargar el módulo para Mod Security en httpd.conf y guarde el archivo de configuración
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
  • Reinicie el servidor web apache

¡Mod Security ya está instalado!

Lo siguiente que tiene que hacer es instalar la regla central de Mod Security para aprovechar al máximo su función.

Puede descargar la última Core Rule desde el siguiente enlace, que es gratuito. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Copie el zip de core rule descargado en la carpeta /opt/apache/conf
  • Descomprima el archivo core rule
  • Si lo desea, puede cambiar el nombre de la carpeta por algo corto y fácil de recordar. En este ejemplo, cambiaré el nombre a crs.
  • Vaya a la carpeta crs y renombre modsecurity_crs10_setup.conf.example a modsecurity_crs10_setup.conf

Ahora, habilitemos estas reglas para que funcione con el servidor web Apache.

  • Añada lo siguiente en httpd.conf
<ifmodule security2_module="">
Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf
</ifmodule>

En la configuración anterior, estamos cargando el archivo de configuración principal de Mod Security modsecurity_crs_10_setup.conf y las reglas base base_rules/*.conf proporcionadas por Mod Security Core Rules para proteger las aplicaciones web.

  • Reinicie el servidor web apache

¡Ha configurado con éxito Mod Security con Apache!

Bien hecho. Ahora, el servidor web Apache está protegido por el cortafuegos de aplicaciones web Mod Security.

Comenzando

Comencemos con algunas de las configuraciones críticas en Mod Security para endurecer y asegurar las aplicaciones web.

En esta sección, haremos todas las modificaciones de configuración en /opt/apache/conf/crs/modsecurity_crs_10_setup.conf.

Nos referiremos a /opt/apache/conf/crs/modsecurity_crs_10_setup.conf como setup.conf en esta sección a modo de ejemplo.

Es importante entender cuáles son las reglas OWASP que se proporcionan de forma gratuita. Hay dos tipos de reglas proporcionadas por OWASP.

ReglasBase – estas reglas están fuertemente probadas, y probablemente el ratio de falsas alarmas sea menor.

ReglasExperimentales – estas reglas son para un propósito experimental, y puede tener una alta falsa alarma. Es importante configurarlas, probarlas e implementarlas en UAT antes de utilizarlas en un entorno de producción.

ReglasOpcionales – estas reglas opcionales pueden no ser adecuadas para todo el entorno. Puede utilizarlas en función de sus necesidades.

Si está buscando protección contra CSRF, rastreo de usuarios, secuestro de sesión, etc., entonces puede considerar el uso de reglas opcionales. Disponemos de las reglas base, opcionales y experimentales tras extraer el archivo zip crs descargado de la página de descargas de OWASP.

El archivo de configuración de estas reglas está disponible en la carpeta crs/base_rules, crs/optional_rules y crs/experimental_rules. Familiaricémonos con algunas de las reglas base.

  • modsecurity_crs_20_protocol_violations.conf: Esta regla protege de vulnerabilidades de protocolo como la división de respuestas, el contrabando de peticiones, el uso de protocolos no permitidos (HTTP 1.0).
  • modsecurity_crs_21_protocol_anomalies.conf: Esto es para protegerse de una petición, a la que le falte Host, Accept, User-Agent en la cabecera.
  • modsecurity_crs_23_request_limits.conf:Esta regla tiene la dependencia de la aplicación específica como el tamaño de la solicitud, el tamaño de la carga, la longitud de un parámetro, etc.
  • modsecurity_crs_30_http_policy.conf:Esto es para configurar y proteger métodos permitidos o no permitidos como CONNECT, TRACE, PUT, DELETE, etc.
  • modsecurity_crs_35_bad_robots.conf:Detecta robots maliciosos
  • modsecurity_crs_40_generic_attacks.conf:Sirve para protegerse de la inyección de comandos del sistema operativo, la inclusión remota de archivos, etc.
  • modsecurity_crs_41_sql_injection_attacks.conf:Esta regla para proteger SQL y la petición de inyección SQL ciega.
  • modsecurity_crs_41_xss_attacks.conf:Protección frente a peticiones Cross-Site Scripting.
  • modsecurity_crs_42_tight_security.conf:Detección y protección de Directory Traversal.
  • modsecurity_crs_45_trojans.conf:Esta regla para detectar salida genérica de gestión de ficheros, carga de página backdoor HTTP, firma conocida.
  • modsecurity_crs_47_common_exceptions.conf:Se utiliza como mecanismo de excepciones para eliminar los falsos positivos comunes que se puedan encontrar, como la conexión ficticia interna de Apache, el pinger SSL, etc.

Registro

El registro es una de las primeras cosas a configurar para que pueda tener registros creados de lo que Mod Security está haciendo. Hay dos tipos de registro disponibles; Debug & Audit log.

Debug Log: esto es para duplicar los mensajes de error, advertencia y aviso de Apache del registro de errores.

Registro de Auditoría: esto es para escribir los registros de transacciones que son marcados por la regla de Mod Security Mod Security le da la flexibilidad de configurar el registro de Auditoría, Depuración o ambos.

Por defecto la configuración escribirá ambos registros. Sin embargo, puede cambiarla en función de sus necesidades. El registro se controla en la directiva SecDefaultAction. Veamos la configuración de registro por defecto en setup.conf

SecDefaultAction "fase:1,denegar,log"

Para registrar Debug, Audit log – use «log» Para registrar sólo audit log – use «nolog,auditlog» Para registrar sólo debug log – use «log,noauditlog» Puede especificar la ubicación del registro de auditoría que se almacenará, que está controlada por la directiva SecAuditLog.

Vamos a escribir el registro de auditoría en /opt/apache/logs/modsec_audit.log añadiendo como se muestra a continuación.

  • Añada la directiva SecAuditLog en setup.conf y reinicie el servidor web Apache
SecAuditLog /opt/apache/logs/modsec_audit.log
  • Tras el reinicio, debería ver que se genera modsec_audit.log

Habilite el motor de reglas

Por defecto el Motor de Reglas está Desactivado lo que significa que si no habilita el Motor de Reglas no estará utilizando todas las ventajas de Mod Security.

La habilitación o deshabilitación de Rule Engine es controlada por la directiva SecRuleEngine.

  • Añada la directiva SecRuleEngine en setup.conf y reinicie el servidor web Apache
SecRuleEngine Activado

Hay tres valores para SecRuleEngine:

  • On – para activar Rule Engine
  • Off – para desactivar Rule Engine
  • DetectionOnly – habilitar Rule Engine pero nunca ejecuta ninguna acción como bloquear, denegar, descartar, permitir, proxy o redirigir

Una vez que Rule Engine está activado – Mod Security está listo para proteger con algunos de los tipos de ataque comunes.

Protección contra tipos de ataque comunes

Ahora el servidor web está listo para proteger con tipos de ataque comunes como XSS, Inyección SQL, Violación de Protocolo, etc. ya que hemos instalado Core Rule y encendido Rule Engine. Vamos a probar algunos de ellos.

Ataque XSS

  • Monitorice el modsec_audit.log en la carpeta apache/logs

Notará que Mod Security bloquea la solicitud ya que contiene la etiqueta