Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Tutorial Apache modsecurity (WAF)


Este tutorial muestra cómo instalar y usar ModSecurity con Apache en servidores Debian/Ubuntu. ModSecurity es un cortafuegos de aplicaciones web (WAF) de código abierto muy conocido, que proporciona una protección completa para sus aplicaciones web (como WordPress, Nextcloud, Moodle, Ghost, etc.) contra una amplia gama de ataques de Capa 7 (HTTP), como inyección SQL, cross-site scripting e inclusión de archivos locales (LFI)


Las aplicaciones web son intrínsecamente inseguras. Si eres un administrador de WordPress, probablemente escuche noticias de vulnerabilidades en plugins y temas de WordPress de vez en cuando. Es esencial que despliegues un WAF en tu servidor web, especialmente cuando tienes aplicaciones antiguas que no reciben actualizaciones. ModSecurity fue creado originalmente por Ivan Ristić en 2002, y actualmente lo mantiene Trustwave SpiderLabs. Es el WAF más desplegado del mundo, utilizado por más de un millón de sitios web. cPanel, el panel de control de hosting más utilizado, incluye ModSecurity como su WAF.

Puede que haya oído hablar de otros cortafuegos basados en host como iptables, UFW y Firewalld, etc. La diferencia es que estos trabajan en las capas 3 y 4 del modelo OSI y toman acciones basadas en la dirección IP y el número de puerto. ModSecurity, o los cortafuegos de aplicaciones web en general, está especializado para centrarse en el tráfico HTTP (capa 7 del modelo OSI) y toma acciones basadas en el contenido de la petición y respuesta HTTP.

ModSecurity 3

ModSecurity fue diseñado originalmente para el servidor web Apache. Podía funcionar con Nginx antes de la versión 3.0 pero sufría de bajo rendimiento. ModSecurity 3.0 (también conocido como libmodsecurity) fue lanzado en 2017. Es un hito, especialmente para los usuarios de Nginx, ya que es la primera versión que funciona de forma nativa con Nginx. La advertencia de ModSecurity 3 es que todavía no tiene todas las características de la versión anterior (2.9), aunque cada nueva versión añadirá algunas de las características que faltan. Los usuarios de Nginx deberían usar ModSecurity 3. Sin embargo, si usas Apache, se recomienda seguir usando la rama 2.9 por el momento.


Instalación básica

El módulo ModSecurity para Apache está incluido en el repositorio por defecto de Debian/Ubuntu. Para instalarlo, ejecuta:

sudo apt install libapache2-mod-security2

A continuación, habilita este módulo

sudo a2enmod security2

Reinicia Apache para que el cambio surta efecto.

sudo systemctl restart apache2


Configurar ModSecurity

En el fichero de configuración /etc/apache2/mods-enabled/security2.conf, puede encontrar la siguiente línea.


IncludeOptional /etc/modsecurity/*.conf 


Esto significa que Apache incluirá todos los ficheros *.conf en el directorio /etc/modsecurity/. Necesitamos renombrar el archivo modsecurity.conf-recommended para que funcione. 

modsecurity en Apache 2.4

 

 


modSecurity filtra ataques por XSS, SQL Injection, comportamientos anómalos en protocolos, robots, troyanos, LFI ... incorporando además reglas específicas para algunos de los gestores de contenido más populares como Joomla o Wordpress. modSecurity también funciona con nginx e IIS.

modSecurity es un firewall de aplicaciones Web embebible bajo licencia GNU que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorizar tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente.

ModSecurity cuenta con una consola de administración que permite recopilar registros de monitorización y alertas en tiempo real así como de opciones automatizadas de mantenimiento, entre otras características.


yum install mod_security mod_security_crs

Edita el fichero /etc/httpd/conf.d/mod_security.conf


  • On: The rules are enforced and connections will be terminated when matching rules are found.
  • Detect Only: The rules are enforced and connections will be logged when matching rules are found. Not traffic will be dropped.
  • Off: Rules are not enforced.

Mod Security Config File – /etc/httpd/conf.d/mod_security.conf
Debug Log – /var/log/httpd/modsec_debug.log
Audit log – /var/log/httpd/modsec_audit.log
Rules – /etc/httpd/modsecurity.d/activated_rules

#SecRuleEngine DetectionOnly
SecRuleEngine On
SecAuditLog /var/log/apache2/modsec_audit.log


Para entender los registros de auditoría de ModSecurity, necesita conocer las 5 fases de procesamiento en ModSecurity, que son:

  • Phase 1: Inspeccionar las cabeceras de la petición
  • Phase 2: Inspeccionar el cuerpo de la petición
  • Phase 3: Inspeccionar las cabeceras de la respuesta
  • Phase 4: Inspeccionar el cuerpo de la respuesta
  • Phase 5: Acción (registrar/bloquear peticiones maliciosas)

También hay dos tipos de archivos de registro.

  • Serial: un archivo para todos los registros. Este es el predeterminado.
  • Concurrent: varios archivos de registro. Esto puede proporcionar un mejor rendimiento de escritura. Si nota que sus páginas web se ralentizan después de activar ModSecurity, puede elegir usar el tipo de registro concurrente.

Los eventos en el registro se dividen en varias secciones (sections)

sección A: cabecera del registro de auditoría
sección B: cabecera de la petición
sección C: cuerpo de la petición
sección D: reservado
sección E: cuerpo de la respuesta intermedia
sección F: cabecera de la respuesta final
sección G: reservada
sección H: tráiler del registro de auditoría
sección I: alternativa al cuerpo compacto de la solicitud, que excluye los archivos
sección J: información sobre los archivos cargados
sección K: todas las reglas coincidentes con un evento, por orden de coincidencia
sección Z: límite final


Si tienes un sitio web con mucho tráfico, el log de auditoría de ModSecurity puede volverse demasiado grande muy rápidamente, por lo que necesitamos configurar la rotación de logs para el log de auditoría de ModSecurity. Crea un fichero de configuración logrotate para ModSecurity.


sudo nano /etc/logrotate.d/modsecurity

Añada las siguientes líneas a este fichero.

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

Esto rotará el archivo de registro cada día (daily), comprimiendo las versiones antiguas (compress). Los 10 archivos de registro anteriores se mantendrán (rotate 10), y no se producirá ninguna rotación si el archivo está vacío (notifempty). 


Excluir reglas por ID (identificador)
SecRuleRemoveById 920350


Excluir rango de reglas:

 SecRuleRemoveById "9000-9010"

Excluir reglas según tipo:

SecRuleRemoveByTag "WEB_ATTACK/XSS"  

OWASP ModSecurity CRS incluye:

  • AUTOMATION/MALICIOUS
  • AUTOMATION/MISC
  • AUTOMATION/SECURITY_SCANNER
  • LEAKAGE/SOURCE_CODE_ASP_JSP
  • LEAKAGE/SOURCE_CODE_CF
  • LEAKAGE/SOURCE_CODE_PHP
  • WEB_ATTACK/CF_INJECTION
  • WEB_ATTACK/COMMAND_INJECTION
  • WEB_ATTACK/FILE_INJECTION
  • WEB_ATTACK/HTTP_RESPONSE_SPLITTING
  • WEB_ATTACK/LDAP_INJECTION
  • WEB_ATTACK/PHP_INJECTION
  • WEB_ATTACK/REQUEST_SMUGGLING
  • WEB_ATTACK/SESSION_FIXATION
  • WEB_ATTACK/SQL_INJECTION
  • WEB_ATTACK/SSI_INJECTION
  • WEB_ATTACK/XSS 

 

Excluir reglas según directorio:
<LocationMatch "/wp-admin/post.php">
    SecRuleRemoveById 980130 941180 949110
</LocationMatch>


Excluir reglas según IP (WhiteList) (cambia IP por tu dirección IP)
SecRule REMOTE_ADDR "@IPMatch IP" "id:932160,ctl:ruleEngine=Off"
SecRule REMOTE_ADDR "@IPMatch IP" "id:980130,ctl:ruleEngine=Off"

SecRule REMOTE_ADDR "@ipMatch IP" "id:980130,phase:2,t:none,log,allow"
SecRule REMOTE_ADDR "@ipMatch IP" "id:941180,phase:2,t:none,log,allow"

Para la IP 127.0.0.1

SecRule REMOTE_ADDR "^127\.0\.0\.1" "id:1004,phase:1,allow,ctl:ruleEngine=off"

Para una subred 10.10.10.0/24
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"




Ejemplo configuración básico:
<IfModule mod_security2.c>
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream
SecDataDir /tmp
</IfModule>

Parámetros

  • SecRuleEngine

    • on aplica las reglas a las solicitudes recibidas

    • off no aplica las reglas

    • DetectionOnly aplica las reglas pero no realiza ningún tipo de acción de bloque. Es la configuración aconsejada cuando se instala el modulo. Solamente después de probar el servidor y tener la certeza que todo funciona bien, se puede cambiar a on

  • SecRequestBodyAccess

    • on el modulo tiene acceso a los anexos presentes en las solicitudes recibidas, que, como dijimos anteriormente, son las que se utilizan para lanzar ataques

    • off no se accede a los anexos

  • SecRule es el parámetro que se puede repetir más de una vez en el archivo y es donde se definen las reglas generales del modulo. El parámetro tiene la siguiente sintaxis:

    • variable

    • operator

    • action

    • ejemplo: en el archivo la primera vez que aparece es para permitir parsear los anexos XML

  • SecRequestBodyLimit: el tamaño máximo de un anexo que mod_security aceptará en el área de trabajo. El valor es en byte y el predefinido es 13107200 que corresponde a 12,5 MByte. Si llega alguna solicitud con un anexo de tamaño más grande, el servidor web contestará con el siguiente mensaje de error: 413 Request Entity Too Large. Limite máximo intrínseco al modulo: 1 GB

  • SecRequestBodyNoFilesLimit: el tamaño máximo de una anexo que mod_security aceptará cuando no se trata de un archivo. El valor predefinido corresponde a 128KBytes

  • SecRequestBodyInMemoryLimit: el tamaño máximo de una anexo que mod_security aceptará en la memoria de trabajo. El valor predefinido corresponde a 128 KBytes

  • SecRequestBodyLimitAction: controla que tipo de acción se toma cuando llega una solicitud con un anexo de tamaño más grande al definido en el parámetro SecRequestBodyLimit:

    • reject: se rechaza

    • ProcessPartial: se procesa parcialmente hasta llegan al tamaño máximo definido. IMPORTANTE: si SecRuleEngine = DetectionOnly el valor de este parámetro se configurará automáticamente en ProcessPartial

  • SecResponseBodyAccess: se define si los anexos presentes en las repuestas (no en las solicitudes) se aceptarán en el área de trabajo de mod_security.

    • On: activo

    • Off: no activo

  • SecResponseBodyMimeType: que tipo de anexo de las respuestas se analizarán si el parámetro anterior está en On:

    • text/plain: texto plano

    • text/html: formato HTML

    • text/xml: formato XML

  • SecResponseBodyLimit: tamaño maximo aceptado para el anexo presente en una respuesta; valor predefinido 524288 correspondiente a 512KBytes

  • SecResponseBodyLimitAction: acción que se tomará si el tamaño del anexo de la respuesta supera el valor presente en el parametro anterior

    • Reject: se rechaza

    • ProcessPartial: se procesa parcialmente hasta llegan al tamaño máximo definido

  • SecTmpDir: carpeta donde mod_security guardará los archivos temporales

    • /tmp/

  • SecDataDir: carpeta donde mod_security guardará los archivos persistentes

    • /tmp/

  • SecDebugLog: carpeta y archivo donde se guardará el debug del programa

    • /var/log/modsecurity/debug.log

  • SecDebugLogLevel

    • 0: LOG desactivado

    • 1: errores

    • 2: Advertencias

    • 3: noticias

    • 4: detalles de como las transacciones se han procesado

    • 5: como la anterior añadiendo más datos de las transacciones

    • 9: cualquier tipo de operación realizada por el modulo

  • SecAuditEngine RelevantOnly

  • SecAuditLogParts ABIJDEFHZ

  • SecAuditLogType Serial

  • SecAuditLog /var/log/modsecurity/audit.log

 

Reglas OWASP ModSecurity Core Rule Set (CRS)



Para hacer que ModSecurity proteja tus aplicaciones web, necesita definir reglas para detectar actores maliciosos y bloquearlos. Para los principiantes, es una buena idea instalar conjuntos de reglas existentes, para que pueda empezar rápidamente y luego aprender los detalles más adelante. Hay varios conjuntos de reglas gratuitos para ModSecurity. El OWASP Core Rule Set (CRS) es el conjunto de reglas estándar usado con ModSecurity.

  • Es gratuito, mantenido por la comunidad y el conjunto de reglas más utilizado que proporciona una configuración por defecto vendida para ModSecurity.
  • Contiene reglas para ayudar a detener vectores de ataque comunes, incluyendo SQL injection (SQLi), cross-site scripting (XSS), y muchos otros.
  • Puede integrarse con Project Honeypot y Fail2ban
  • También contiene reglas para detectar bots y escáneres.
  • Ha sido ajustado a través de una amplia exposición para tener muy pocos falsos positivos.
Cuando se instala ModSecurity desde el repositorio por defecto de Debian/Ubuntu, el paquete modsecurity-crs también se instala como dependencia. Este paquete contiene el conjunto de reglas del núcleo OWASP versión 3.x. Sin embargo, puede quedar desactualizado. Si te preocupa la seguridad, deberías utilizar la última versión del conjunto de reglas básicas.


Descarga la última versión de OWASP CRS desde GitHub.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.5.tar.gz

Extrae el archivo.

tar xvf v3.3.5.tar.gz

Crea un directorio para almacenar los archivos CRS.

sudo mkdir /etc/apache2/modsecurity-crs/

Mueve el directorio extraído a /etc/apache2/modsecurity-crs/.

sudo mv coreruleset-3.3.5/ /etc/apache2/modsecurity-crs/

Ves al directorio.

cd /etc/apache2/modsecurity-crs/coreruleset-3.3.5/

Cambia el nombre del archivo crs-setup.conf.example.

sudo mv crs-setup.conf.example crs-setup.conf

Edita el archivo /etc/apache2/mods-enabled/security2.conf.

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

Busca la siguiente línea, que carga los archivos CRS por defecto.

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

Cambia por la siguiente, para que se utilice el último CRS de OWASP.

IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.5/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.5/rules/*.conf

Cómo funciona OWASP CRS

Echemos un vistazo al archivo de configuración de CRS, que te proporciona una buena documentación sobre cómo funciona CRS.

sudo nano /etc/apache2/modsecurity-crs/coreruleset-3.3.5/crs-setup.conf

Puedes ver que OWASP CRS puede ejecutarse en dos modos:

  • modo autónomo. Este es el modo tradicional usado en CRS v2.x. Si una petición HTTP coincide con una regla, ModSecurity bloqueará la petición HTTP inmediatamente y dejará de evaluar las reglas restantes.
  • Modo de puntuación de anomalías. Este es el modo por defecto usado en CRS v3.x. ModSecurity comprobará una petición HTTP con todas las reglas, y añadirá una puntuación a cada regla que coincida. Si se alcanza un umbral, entonces la petición HTTP se considera un ataque y será bloqueada. La puntuación por defecto para peticiones entrantes es 5 y para respuestas salientes es 4.

Cuando se ejecuta en modo de puntuación de anomalías, hay 4 niveles de paranoia.

  • Paranoia nivel 1 (por defecto)
  • Paranoia nivel 2
  • Paranoia nivel 3
  • Paranoia nivel 4
Con cada aumento del nivel de paranoia, el CRS activa reglas adicionales que le proporcionan un mayor nivel de seguridad. Sin embargo, los niveles de paranoia más altos también aumentan la posibilidad de bloquear parte del tráfico legítimo debido a falsas alarmas.

Estos son los dos conceptos básicos que hay que entender antes de utilizar el SIR. Ahora podemos cerrar el archivo. Las reglas individuales del CRS se almacenan en el directorio /etc/apache2/modsecurity-crs/coreruleset-3.3.5/rules/. Cada regla coincidente incrementará la puntuación de anomalía.

Encadenamiento de reglas


Si tu servidor Apache tiene múltiples hosts virtuales, puede que quieras poner tu dirección IP en la lista blanca de un host virtual específico. Necesitas encadenar dos reglas de la siguiente manera

SecRule REMOTE_ADDR "@ipMatch 12.34.56.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:none"


La palabra clave chain al final de la primera regla indica que la acción ruleEngine=off sólo se llevará a cabo si la condición de la siguiente regla también es verdadera.
 

Par resolver el primero problema se añade Nextcloud a la lista blanca de mod_security:

nano /etc/httpd/modsecurity.d/crs-setup.conf

al final del archivo se añade:

SecAction \

"id:900130,\

phase:1,\

nolog,\

pass,\

t:none,\

setvar:tx.crs_exclusions_nextcloud=1"

se guardan los cambios. Para el segundo punto hay que aumentar el valor del parámetro SecRequestBodyLimit con una valor adecuado al tamaño de loas archivos que se manejan con Nextcloud ya que los archivos, del cliente al servidor, viajan como anexos a través del servidor web.

 

Falsos Positivos 

Editar el fichero

crs-setup.conf

Ves a la sección Exclusiones de reglas específicas de la aplicación y busca las siguientes líneas.

 

#SecAction \
# "id:900130,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.crs_exclusions_cpanel=1,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_dokuwiki=1,\
# setvar:tx.crs_exclusions_nextcloud=1,\
# setvar:tx.crs_exclusions_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=1"


Por ejemplo, si quiero activar las exclusiones de WordPress, las líneas anteriores deben cambiarse por las siguientes:


SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_wordpress=1"


Exclusiones para un subdominio:

SecRule REQUEST_HEADERS:Host "@streq blog.elhacker.net" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"

Por ejemplo un subdominio con nextcloud:

SecRule REQUEST_HEADERS:Host "@streq nextcloud.elhacker.net" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"

modsecurity + Fail2ban + AbuseIpDB

modsecurity se puede integrar fácilmente con Fail2Ban


[apache-modsecurity]
enabled = true
filter = apache-modsecurity
#logpath  = /var/log/httpd/modsec_audit.log
backend = pyinotify
action = abuseipdb[abuseipdb_category="15,21"]
bantime = 1h
logencoding = UTF-8

Habilitar y configurar la regla de protección de denegación de servicio (DoS)

Para habilitar y configurar la regla de protección Denegación de servicio (DoS), siga los siguientes pasos:

  1. Habilite la regla de protección DoS cambiando el nombre de REQUEST-912-DOS-PROTECTION.conf.disabled a REQUEST-912-DOS-PROTECTION.conf (o quite .disabled de la extensión rulename) en la carpeta dispatcher/src/conf.d/modsec/crs/rules.

  2. Configure la regla definiendo las variables DOS_COUNTER_THRESHOLD, DOS_BURST_TIME_SLICE, DOS_BLOCK_TIMEOUT.

    1. Crear un archivo de crs-setup.custom.conf en la carpeta dispatcher/src/conf.d/modsec/crs.
    2. Añada el siguiente fragmento de regla al archivo recién creado.

     

# The Denial of Service (DoS) protection against clients making requests too quickly.
# When a client is making more than 25 requests (excluding static files) within
# 60 seconds, this is considered a 'burst'. After two bursts, the client is
# blocked for 600 seconds.
SecAction \
    "id:900700,\
    phase:1,\
    nolog,\
    pass,\
    t:none,\
    setvar:'tx.dos_burst_time_slice=60',\
    setvar:'tx.dos_counter_threshold=25',\
    setvar:'tx.dos_block_timeout=600'"
En esta configuración de regla de ejemplo, DOS_COUNTER_THRESHOLD tiene 25, DOS_BURST_TIME_SLICE tiene 60 segundos y el tiempo de espera de DOS_BLOCK_TIMEOUT es de 600 segundos. Esta configuración identifica más de dos incidencias de 25 solicitudes, excluidos los archivos estáticos, en un plazo de 60 segundos que cumplen los requisitos de ataque DoS, lo que provoca que el cliente solicitante se bloquee durante 600 segundos (o 10 minutos).

 

# Variables:
# IP:DOS_BLOCK              Flag if an IP address should be blocked
# IP:DOS_BLOCK_COUNTER      Counter of blocked requests
# IP:DOS_BLOCK_FLAG         Flag keeping track of alert. Flag expires after 60 seconds.
# IP:DOS_BURST_COUNTER      Burst counter
# IP:DOS_COUNTER            Request counter (static resources are ignored)
# TX:DOS_BLOCK_COUNTER      Copy of IP:DOS_BLOCK_COUNTER (needed for display reasons)
# TX:DOS_BLOCK_TIMEOUT      Period in seconds a blocked IP will be blocked
# TX:DOS_COUNTER_THRESHOLD  Limit of requests, where a burst is identified
# TX:DOS_BURST_TIME_SLICE   Period in seconds when we will forget a burst
# TX:STATIC_EXTENSIONS      Paths which can be ignored with regards to DoS


Fuentes:

https://www.linuxbabe.com/security/modsecurity-apache-debian-ubuntu


1 comentarios :

Anónimo dijo...

bla bla bla

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.