Guía de seguridad y endurecimiento del servidor web Apache

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.

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.

Utilice las herramientas de desarrollo incorporadas en el navegador para inspeccionar las cabeceras HTTP. Normalmente, está en la pestaña Red
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.

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.

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

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

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

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.

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

Abra Firefox y acceda a su aplicación y ponga la etiqueta