Guía de seguridad y refuerzo del servidor web Apache

Publicado: 2015-02-14

Una guía práctica para proteger y fortalecer el servidor Apache HTTP.

El servidor web es una parte crucial de las aplicaciones basadas en web. Apache Web Server a menudo se coloca en el borde de la red, por lo que se convierte en uno de los servicios más vulnerables a los ataques.

Tener una configuración predeterminada proporciona mucha información confidencial que puede ayudar a los piratas informáticos a prepararse para un ataque a las aplicaciones. La mayoría de los ataques a aplicaciones web son a través de XSS, fuga de información, gestión de sesiones y ataques de inyección SQL que se deben a un código de programación débil y a la falta de sanitización de la infraestructura de la aplicación web.

Una investigación interesante realizada por Positive Technologies revela que el 52 % de la aplicación escaneada tenía vulnerabilidades altas.

informe de vulnerabilidad

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

Los siguientes se prueban en la versión Apache 2.4.x.

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

Audiencia

Está diseñado para administradores de middleware, soporte de aplicaciones, analistas de sistemas o cualquier persona que trabaje o desee aprender las pautas de protección y seguridad.

El conocimiento justo del servidor web Apache y el comando UNIX es obligatorio.

notas

Necesita alguna herramienta para examinar los encabezados HTTP para parte de la verificación de implementación. Hay dos maneras de hacer esto.

  1. Utilice herramientas de desarrollador integradas en el navegador para inspeccionar los encabezados HTTP. Por lo general, está en la pestaña Red
  2. Use la herramienta de verificación de encabezado de respuesta HTTP en línea

Eliminar el banner de la versión del servidor

Diría que esta es una de las primeras cosas a considerar, ya que no desea exponer qué versión del servidor web está utilizando. Exponer la versión significa que está ayudando al hacker a acelerar el proceso de reconocimiento.

La configuración predeterminada 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 usando el editor vi
  • Agregue la siguiente directiva y guarde el httpd.conf
 ServerTokens Prod ServerSignature Off
  • reiniciar apache

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

ServerTokens cambiará Header a producción solamente, es decir, Apache

Como puede ver a continuación, la información de la versión y el sistema operativo se ha ido.

apache-server-banner-enmascarado

Deshabilitar la lista del navegador de directorios

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

Probemos cómo se ve en la configuración predeterminada.

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

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 de que no quiere exponer eso.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi
  • Busque Directorio y cambie la directiva Opciones a Ninguno o –Índices
 <Directory /opt/apache/htdocs> Options -Indexes </Directory>

(o)

 <Directory /opt/apache/htdocs> Options None </Directory>
  • reiniciar apache

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

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

lista de directorios deshabilitados

Como puede ver, muestra un error prohibido en lugar de mostrar la lista de carpetas de prueba.

Etiqueta

Permite a los atacantes remotos obtener información confidencial como el número de inodo, el límite MIME de varias partes y el proceso secundario a través del encabezado Etag.

Para evitar esta vulnerabilidad, implementémosla de la siguiente manera. Esto es necesario para corregir el cumplimiento de PCI.

  • Vaya al directorio $Web_Server/conf
  • Agregue la siguiente directiva y guarde el httpd.conf
 FileETag None
  • reiniciar apache

Ejecute Apache desde una cuenta sin privilegios

Una instalación predeterminada se ejecuta como nadie o daemon. Usar 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.

  • Crea un usuario y un grupo llamado 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
  • Modificar httpd.conf usando vi
  • Busque la directiva de usuario y grupo y cambie como apache de cuenta sin privilegios
 User apache Group apache
  • Guarde el httpd.conf
  • reiniciar apache

grep para ejecutar el proceso http y asegurarse de que se esté ejecutando con el usuario de 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 debe iniciarse con la raíz.

Proteger el permiso del directorio binario y de configuración

De forma predeterminada, el permiso para el binario y la configuración es 755, lo que significa que cualquier usuario de un servidor puede ver la configuración. Puede prohibir que otro usuario ingrese a la carpeta conf y bin.

  • Ir al directorio $Web_Server
  • Cambiar el permiso de la carpeta bin y conf
 # chmod –R 750 bin conf

Protección de la configuración del sistema

En una instalación predeterminada, los usuarios pueden anular la configuración de Apache usando .htaccess. Si desea evitar que los usuarios cambien la configuración de su servidor apache, puede agregar 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
  • Buscar Directorio en un nivel raíz
 <Directory /> Options -Indexes AllowOverride None </Directory>
  • Guarde el httpd.conf
  • reiniciar apache

Métodos de solicitud HTTP

El protocolo HTTP 1.1 admite muchos métodos de solicitud que pueden no ser necesarios y algunos de ellos tienen un riesgo potencial.

Por lo general, es posible que necesite métodos de solicitud GET, HEAD, POST en una aplicación web, que se pueden configurar en la directiva de directorio respectiva.

La configuración predeterminada admite el método OPCIONES, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT en el protocolo HTTP 1.1.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi
  • Busque Directorio y agregue lo siguiente
 <LimitExcept GET POST HEAD> deny from all </LimitExcept>
  • reiniciar apache

Desactivar solicitud HTTP de seguimiento

De forma predeterminada, el método de seguimiento está habilitado en el servidor web Apache.

Tener esto habilitado puede permitir un ataque de Cross Site Tracing y potencialmente dar una opción a un pirata informático para robar información de cookies. Veamos cómo se ve en la configuración predeterminada.

  • Haga una IP de servidor web telnet con puerto de escucha
  • Realice una solicitud de TRACE como se muestra a continuación
 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 200 OK Date: Sat, 31 Aug 2013 02:13:24 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 20 TRACE / HTTP/1.1 Host: test 0 Connection closed by foreign host. #

Como puede ver en la solicitud TRACE anterior, ha respondido a mi consulta. Vamos a desactivarlo y probarlo.

  • Vaya al directorio $Web_Server/conf
  • Agregue la siguiente directiva y guarde el httpd.conf
 TraceEnable off
  • reiniciar apache

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

 #telnet localhost 80 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. TRACE / HTTP/1.1 Host: test HTTP/1.1 405 Method Not Allowed Date: Sat, 31 Aug 2013 02:18:27 GMT Server: 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 Method Not Allowed</title> </head><body> <h1>Method Not Allowed</h1> <p>The requested method TRACE is not allowed for the URL /.</p> </body></html> Connection closed by foreign host. #

Como puede ver en la solicitud TRACE anterior, ha bloqueado mi solicitud con el método HTTP 405 no permitido.

Ahora, este servidor web no permite la solicitud de TRACE y ayuda a bloquear el ataque de Cross Site Tracing.

Establecer cookie con HttpOnly y bandera segura

Puede mitigar la mayoría de los ataques comunes de Cross Site Scripting utilizando HttpOnly y el indicador de seguridad 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
  • Agregue la siguiente directiva y guarde el httpd.conf
 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
  • reiniciar apache

Ataque de clickjacking

Clickjacking es una vulnerabilidad de aplicación web bien conocida.

  • Asegúrese de que mod_headers.so esté habilitado en su httpd.conf
  • Vaya al directorio $Web_Server/conf
  • Agregue la siguiente directiva y guarde el httpd.conf
 Header always append X-Frame-Options SAMEORIGIN
  • reiniciar apache

apache-x-frame-opciones

X-Frame-Options también admite dos opciones más que expliqué aquí.

Lado del servidor incluir

La inclusión del lado del servidor (SSI) tiene el riesgo de aumentar la carga en el servidor. Si ha compartido el entorno y las aplicaciones web de mucho tráfico, debería considerar deshabilitar SSI agregando la directiva Incluye en Opciones.

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

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi
  • Busque Directorio y agregue Incluye en la directiva Opciones
 <Directory /opt/apache/htdocs> Options –Indexes -Includes Order allow,denyAllow from all </Directory>
  • reiniciar apache

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

Protección X-XSS

La protección de Cross Site Scripting (XSS) se puede omitir en muchos navegadores. Puede aplicar esta protección para una aplicación web si el usuario la deshabilitó. Esto es utilizado por la mayoría de las compañías web gigantes como Facebook, Twitter, Google, etc.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi y agregue la siguiente directiva de encabezado
 Header set X-XSS-Protection "1; mode=block"
  • reiniciar apache

Como puede ver, XSS-Protection se inyecta en el encabezado de respuesta.

apache-xss

Deshabilitar el protocolo HTTP 1.0

Cuando hablamos de seguridad, debemos proteger tanto como podamos. Entonces, ¿por qué usamos una versión HTTP anterior del protocolo? ¿También los deshabilitamos?

HTTP 1.0 tiene una debilidad de seguridad relacionada con el secuestro de sesiones. Podemos deshabilitar esto usando el módulo mod_rewrite.

  • Asegúrese de cargar el módulo mod_rewrite en el archivo httpd.conf
  • Habilite la directiva RewriteEngine de la siguiente manera y agregue la condición Rewrite para permitir solo HTTP 1.1
 RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1.1$ RewriteRule .* - [F]

Configuración del valor de tiempo de espera

De forma predeterminada, 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 reducir el valor del tiempo de espera a unos 60 segundos.

  • Vaya al directorio $Web_Server/conf
  • Abra httpd.conf usando vi
  • Agregue lo siguiente en httpd.conf
 Timeout 60

SSL

Tener SSL es una capa adicional de seguridad que está agregando a la aplicación web. Sin embargo, la configuración SSL predeterminada genera ciertas vulnerabilidades y debería considerar ajustar esas configuraciones.

Clave SSL

Romper la clave SSL es difícil, pero no imposible. Es solo una cuestión de poder computacional y tiempo.

Como sabrá, con una PC de la era 2009 funcionando durante unos 73 días, puede aplicar ingeniería inversa a una clave de 512 bits.

Entonces, cuanto mayor sea la longitud de la clave, más complicado será romper la clave SSL. La mayoría de las empresas web gigantes usan claves de 2048 bits, como se muestra a continuación, ¿por qué nosotros no?

  • Outlook.com
  • Microsoft.com
  • vivir.com
  • Skype.com
  • Apple.com
  • yahoo.com
  • Bing.com
  • hotmail.com
  • Twitter.com

Puede usar OpenSSL para generar CSR con 2048 bits como se muestra a continuación.

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

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

 SSLCertificateFile #Certificate signed by authority SSLCertificateChainFile #Certificate signer given by authority SSLCertificateKeyFile #Key file which you generated above
  • Reinicie el servidor web Apache e intente acceder a la URL con https

Cifrado SSL

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

El cifrado de datos se basará en la configuración de cifrado SSL de su servidor web. Por eso es importante configurar SSL Cipher, 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 muestra a continuación para aceptar solo algoritmos de cifrado más altos
 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 agregando ! al principio.

Deshabilitar SSL v2 y v3

SSL v2 y v3 tiene muchas fallas de seguridad, y si está trabajando en la prueba de penetración o el cumplimiento de PCI, entonces se espera que cierre el hallazgo de seguridad para deshabilitar 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 acepte solo el TLS más reciente 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 muestra a continuación para aceptar solo TLS 1.2+
 SSLProtocol –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 de certificado SSL/TLS en línea para encontrar cualquier error de configuración.

Mod Seguridad

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

Viene como un módulo que tienes que compilar e instalar. Si no puede permitirse un cortafuegos comercial para aplicaciones web, esta sería una excelente opción.

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

  • Protección HTTP: detección de violaciones del protocolo HTTP y una política de uso definida localmente
  • Búsquedas en listas negras en tiempo real: utiliza la reputación de IP de terceros
  • Detección de malware basada en la web: identifica el contenido web malicioso comparándolo con la API de navegación segura de Google.
  • Protecciones de denegación de servicio HTTP: defensa contra inundaciones HTTP y ataques HTTP DoS lentos.
  • Protección contra ataques web comunes: detección de ataques de seguridad de aplicaciones web comunes
  • Detección de automatización: detección de bots, rastreadores, escáneres y otra actividad superficial maliciosa
  • Integración con AV Scanning para carga de archivos: identifica archivos maliciosos cargados a través de la aplicación web.
  • Seguimiento de datos confidenciales: realiza un seguimiento del uso de la tarjeta de crédito y bloquea las fugas.
  • Protección de troyanos: detección de acceso a caballos de Troya.
  • Identificación de defectos de la aplicación: alertas sobre configuraciones incorrectas de la aplicación.
  • Detección y ocultación de errores: ocultación de mensajes de error enviados por el servidor.

Descarga e instalación

Los siguientes requisitos previos deben estar instalados en el servidor donde desea utilizar Mod Security con Apache. Si alguno de estos no existe, la compilación de Mod Security fallará. Puede usar 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í

  • Transferir 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 –
  • Ir a la carpeta extraída modsecurity-apache_2.7.5
 # cd modsecurity-apache_2.7.5
  • Ejecute el script de configuración que incluye la ruta apxs a Apache existente
 # ./configure –with-apxs=/opt/apache/bin/apxs
  • Compilar e instalar con make script
 # make # make install
  • Una vez finalizada la instalación, verá mod_security2.so en la carpeta de módulos en /opt/apache

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

Configuración

Para usar la función de seguridad Mod con Apache, tenemos que cargar el módulo de seguridad Mod 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 Mod Security rastrea y utiliza.

  • Agregue 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
  • reiniciar el servidor web apache

¡Mod Security ya está instalado!

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

La regla básica más reciente se puede descargar siguiendo un enlace, que es gratuito. https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

  • Copie el zip de la regla principal descargado en la carpeta /opt/apache/conf
  • Descomprimir el archivo de reglas básicas
  • Es posible que desee cambiar el nombre de la carpeta a algo corto y fácil de recordar. En este ejemplo, cambiaré el nombre a crs.
  • Vaya a la carpeta crs y cambie el nombre de modsecurity_crs10_setup.conf.example a modsecurity_crs10_setup.conf

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

  • Agregue 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.

  • reiniciar 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 la aplicación web Mod Security.

Empezando

Comencemos con algunas de las configuraciones críticas en Mod Security para fortalecer y proteger 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 como ejemplo.

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

Reglas básicas: estas reglas se someten a pruebas exhaustivas y probablemente la proporción de falsas alarmas sea menor.

Reglas experimentales : estas reglas tienen un propósito experimental y es posible que tenga una falsa alarma alta. Es importante configurar, probar e implementar en UAT antes de usarlos en un entorno de producción.

Reglas opcionales : estas reglas opcionales pueden no ser adecuadas para todo el entorno. Según sus requisitos, puede usarlos.

Si está buscando protección contra CSRF, seguimiento de usuarios, secuestro de sesiones, etc., entonces puede considerar usar reglas opcionales. Tenemos las reglas básicas, opcionales y experimentales después de extraer el archivo zip crs descargado de la página de descarga de OWASP.

Este archivo de configuración de reglas está disponible en las carpetas crs/base_rules, crs/opcional_rules y crs/experimental_rules. Vamos a familiarizarnos con algunas de las reglas básicas.

  • modsecurity_crs_20_protocol_violations.conf: esta regla protege contra las vulnerabilidades del protocolo, como la división de respuestas, el contrabando de solicitudes, el uso de un protocolo no permitido (HTTP 1.0).
  • modsecurity_crs_21_protocol_anomalies.conf: Esto es para protegerse de una solicitud, que falta con Host, Accept, User-Agent en el encabezado.
  • modsecurity_crs_23_request_limits.conf: esta regla depende de la aplicación específica, como el tamaño de la solicitud, el tamaño de 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:Detectar robots maliciosos
  • modsecurity_crs_40_generic_attacks.conf: esto es para proteger contra 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 solicitud de inyección de SQL ciega.
  • modsecurity_crs_41_xss_attacks.conf:Protección contra solicitud de Cross-Site Scripting.
  • modsecurity_crs_42_tight_security.conf:Detección y protección de cruce de directorios.
  • modsecurity_crs_45_trojans.conf: esta regla para detectar la salida de administración de archivos genéricos, la carga de la página de puerta trasera HTTP, la firma conocida.
  • modsecurity_crs_47_common_exceptions.conf: Esto se usa como un mecanismo de excepción para eliminar los falsos positivos comunes que se pueden encontrar como una conexión ficticia interna de Apache, un ping de SSL, etc.

Inicio sesión

El registro es una de las primeras cosas que debe configurar para que pueda tener registros creados para lo que está haciendo Mod Security. Hay dos tipos de registro disponibles; Registro de depuración y auditoría.

Registro de depuración: sirve 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 están marcados por la regla Mod Security. Mod Security le brinda la flexibilidad de configurar el registro de auditoría, depuración o ambos.

Por defecto, la configuración escribirá ambos registros. Sin embargo, puede cambiar según sus requisitos. El registro se controla en la directiva SecDefaultAction . Veamos la configuración de registro predeterminada en setup.conf

 SecDefaultAction “phase:1,deny,log”

Para registrar Depuración, Registro de auditoría: use "registro" Para registrar solo el registro de auditoría: use "nolog,auditlog" Para registrar solo el registro de depuración: use "log,noauditlog" Puede especificar la ubicación del registro de auditoría que se almacenará y que está controlada por SecAuditLog directiva.

Escribamos el registro de auditoría en /opt/apache/logs/modsec_audit.log agregando como se muestra a continuación.

  • Agregue la directiva SecAuditLog en setup.conf y reinicie el servidor web Apache
 SecAuditLog /opt/apache/logs/modsec_audit.log
  • Después del reinicio, debería ver que se genera modsec_audit.log

Habilitar motor de reglas

De forma predeterminada, la regla del motor está desactivada, lo que significa que si no habilita el motor de reglas, no está utilizando todas las ventajas de Mod Security.

La activación o desactivación de Rule Engine está controlada por la directiva SecRuleEngine .

  • Agregue la directiva SecRuleEngine en setup.conf y reinicie el servidor web Apache
 SecRuleEngine On

Hay tres valores para SecRuleEngine:

  • Activado: para habilitar el motor de reglas
  • Desactivado: para deshabilitar el motor de reglas
  • Solo detección: habilita Rule Engine pero nunca ejecuta ninguna acción como bloquear, denegar, eliminar, permitir, proxy o redirigir

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

Protección de tipo de ataque común

Ahora el servidor web está listo para protegerse con tipos de ataques comunes como XSS, inyección de SQL, violación de protocolo, etc., ya que instalamos Core Rule y activamos Rule Engine. Probemos algunos de ellos.

Ataque XSS

  • Abra Firefox y acceda a su aplicación y coloque la etiqueta <script> al final o URL
  • Supervise modsec_audit.log en la carpeta apache/logs

Notará que Mod Security bloquea la solicitud ya que contiene la etiqueta <script> que es la raíz del ataque XSS.

Ataque de cruce de directorio: - Los ataques de cruce de directorio pueden causar mucho daño al aprovechar estas vulnerabilidades y acceder al archivo relacionado con el sistema. Ejemplo: /etc/passwd, .htaccess, etc.

  • Abra Firefox y acceda a su aplicación con directorio transversal
  • Supervise modsec_audit.log en la carpeta apache/logs
 http://localhost/?../.../boot
  • Notará que Mod Security bloquea la solicitud, ya que contiene recorrido de directorio.

Cambiar banner de servidor

Anteriormente en esta guía, aprendió cómo eliminar Apache y el tipo de sistema operativo, la ayuda de la versión de la directiva ServerTokens.

Vayamos un paso adelante, ¿qué tal si mantenemos el nombre del servidor como desees? Es posible con la directiva SecServerSignature en Mod Security. Ves que es interesante.

Nota: para usar Mod Security para manipular Server Banner desde un encabezado, debe establecer ServerTokesn en Full en httpd.conf del servidor web Apache.

  • Agregue la directiva SecServerSignature con su nombre de servidor deseado en setup.conf y reinicie el servidor web Apache
 SecServerSignature YourServerName

Ex:

 [/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf SecServerSignature geekflare.com [/opt/apache/conf/crs] #

Configuración general

Veamos algunas de las configuraciones generales como mejores prácticas.

Configurar escuchar

Cuando tiene varias interfaces e IP en un solo servidor, se recomienda tener la directiva Escuchar configurada con una IP y un número de puerto absolutos.

Cuando deja la configuración de apache en Escuchar en todas las IP con algún número de puerto, puede crear el problema al reenviar la solicitud HTTP a algún otro servidor web. Esto es bastante común en el entorno compartido.

  • Configure la directiva Listen en httpd.conf con IP y puerto absolutos como se muestra en el ejemplo a continuación
 Listen 10.10.10.1:80

Registro de acceso

Es esencial configurar correctamente el registro de acceso en su servidor web. Algunos de los parámetros importantes para capturar en el registro serían el tiempo necesario para atender la solicitud, ID DE SESIÓN.

De forma predeterminada, Apache no está configurado para capturar estos datos. Tienes que configurarlos manualmente de la siguiente manera.

  • Para capturar el tiempo necesario para atender la solicitud y el ID DE SESIÓN en un registro de acceso
  • Agregue %T y %sessionID en httpd.conf bajo la directiva LogFormat
 LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

Puede consultar http://httpd.apache.org/docs/2.2/mod/mod_log_config.html para obtener una lista completa de los parámetros admitidos en la directiva LogFormat en Apache Web Server.

Deshabilitar la carga de módulos no deseados

Si ha compilado e instalado todos los módulos, entonces hay muchas posibilidades de que tenga muchos módulos cargados en Apache, que pueden no ser necesarios.

La mejor práctica es configurar Apache con los módulos requeridos en sus aplicaciones web. Los siguientes módulos tienen problemas de seguridad y es posible que le interese deshabilitarlos en httpd.conf del servidor web Apache.

WebDAV (Creación y control de versiones distribuidos basados ​​en la web) Este módulo permite a los clientes remotos manipular archivos en el servidor y someterlos a varios ataques de denegación de servicio. Para deshabilitar el seguimiento de comentarios en httpd.conf

 #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so #Include conf/extra/httpd-dav.conf

Módulo de información El módulo mod_info puede filtrar información confidencial usando .htaccess una vez que se carga este módulo. Para deshabilitar el seguimiento de comentarios en httpd.conf

 #LoadModule info_module modules/mod_info.so

Referencia: Esto no sería posible sin la guía del siguiente enlace:

  • http://httpd.apache.org/docs/2.4/
  • http://www.modsecurity.org/documentation/
  • https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Esas fueron algunas de las mejores prácticas que puede usar para proteger su servidor web Apache.

Consulte este enlace si desea implementar una página de error personalizada en Apache.

Si es nuevo en Apache HTTP, le recomendaría tomar el curso de administración de Apache HTTP.