Azure WAF Mod Security de casa en nuestros despliegues web.

Estimados amigos de Inseguros !!!

Esta gente de Microsoft se ha vuelto loca !!! En un click podemos instalar un servidor web iis con mysql y por ejemplo, un CMS Wordpress. Pero lo más gracioso es que con dos líneas podemos habilitar gratis Mod Security !!!

En esta web hemos hablado bastante de Mod security:

Reglas para Mod Security Free. Comodo y Atomic.

Introduccion a Mod Security y reglas free Owasp.

Consola web para Mod Security.

Mod Security y detener subida de ficheros maliciosos usando File Inspection con tus Home-Made Script.

Prevención de fugas de información en logs. Campo Passwords y Mod security

En todas las auditorias web que hago, cuando no encuentro WAF lo suelo categorizar como deficiencia muy alta. No vulnerabilidad, que es distinto. A no ser que uses un waf dedicado, o un CDN tipo cloudflare, o uses un Firewall Next Generation, IPS o similar, estás dejando todo el tráfico web que pase por delante de Firewall tradicional, por mucho que cueste 100€ o 100.000€. Si no hay inspección de paquetes en capa 7 no estás haciendo nada.

Dicho esto, con Azure podemos usar ModSec de manera sencilla con los despliegues de App.

El proceso es sencillo. Dentro de nuestra Aplicación Azure, ya sea un portal prefabricado o desarrollo propio, accedemos a las herramientas y accedemos a Kudu, una herramienta que nos permite acceder al sistema de ficheros de nuestra APP. Recuerda que en el sistema cloud de aplicación como servicio nosotros no manejamos el servidor web, esto sería plataforma como servicio. Tampoco manejamos el sistema operativo, esto sería infraestructura como servicio...

Ahora creamos el fichero web.config si no lo teníamos creado. En mi caso habilito Mod security y configuro que no se puedan bajar los ficheros .conf. ****esto quiere decir que todos los IIS que tienen Azure vienen con el modulo de Mod Security instalado. que fuerteeeeeeeeeee me pareceeeeeeeee***

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Ahora creo el fichero modsecurity.conf con esta configuración que al menos me funciona.

# based on modsecurity.conf-recommended

# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection

# only to start with, because that minimises the chances of post-installation

# disruption.

#

SecRuleEngine On

# -- Request body handling ---------------------------------------------------

# Allow ModSecurity to access request bodies. If you don't, ModSecurity

# won't be able to see any POST parameters, which opens a large security

# hole for attackers to exploit.

#

SecRequestBodyAccess On

# Enable XML request body parser.

# Initiate XML Processor in case of xml content-type

#

# Enable JSON request body parser.

# Initiate JSON Processor in case of JSON content-type; change accordingly

# if your application does not use 'application/json'

#

# Maximum request body size we will accept for buffering. If you support

# file uploads then the value given on the first line has to be as large

# as the largest file you are willing to accept. The second value refers

# to the size of data, with files excluded. You want to keep that value as

# low as practical.

#

SecRequestBodyLimit 13107200

SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart

# parser reachers this limit, it will start using your hard disk for

# storage. That is slow, but unavoidable.

#

SecRequestBodyInMemoryLimit 131072

# What do do if the request body size is above our configured limit.

# Keep in mind that this setting will automatically be set to ProcessPartial

# when SecRuleEngine is set to DetectionOnly mode in order to minimize

# disruptions when initially deploying ModSecurity.

#

SecRequestBodyLimitAction Reject

# Verify that we've correctly processed the request body.

# As a rule of thumb, when failing to process a request body

# you should reject the request (when deployed in blocking mode)

# or log a high-severity alert (when deployed in detection-only mode).

#

# PCRE Tuning

# We want to avoid a potential RegEx DoS condition

#

SecPcreMatchLimit 1000

SecPcreMatchLimitRecursion 1000

# Some internal errors will set flags in TX and we will need to look for these.

# All of these are prefixed with "MSC_".  The following flags currently exist:

#

# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.

#

# -- Response body handling --------------------------------------------------

# Allow ModSecurity to access response bodies. 

# You should have this directive enabled in order to identify errors

# and data leakage issues.

# 

# Do keep in mind that enabling this directive does increases both

# memory consumption and response latency.

#

#SecResponseBodyAccess On

# Which response MIME types do you want to inspect? You should adjust the

# configuration below to catch documents but avoid static files

# (e.g., images and archives).

#

SecResponseBodyMimeType text/plain text/html text/xml

# Buffer response bodies of up to 512 KB in length.

SecResponseBodyLimit 524288

# What happens when we encounter a response body larger than the configured

# limit? By default, we process what we have and let the rest through.

# That's somewhat less secure, but does not break any legitimate pages.

#

SecResponseBodyLimitAction ProcessPartial

# -- Filesystem configuration ------------------------------------------------

# The location where ModSecurity stores temporary files (for example, when

# it needs to handle a file upload that is larger than the configured limit).

# 

# This default setting is chosen due to all systems have /tmp available however, 

# this is less than ideal. It is recommended that you specify a location that's private.

#

SecTmpDir c:\inetpub\temp\

# The location where ModSecurity will keep its persistent data.  This default setting 

# is chosen due to all systems have /tmp available however, it

# too should be updated to a place that other users can't access.

#

SecDataDir c:\inetpub\temp\

# -- File uploads handling configuration -------------------------------------

# The location where ModSecurity stores intercepted uploaded files. This

# location must be private to ModSecurity. You don't want other users on

# the server to access the files, do you?

#

#SecUploadDir /opt/modsecurity/var/upload/

# By default, only keep the files that were determined to be unusual

# in some way (by an external inspection script). For this to work you

# will also need at least one file inspection rule.

#

#SecUploadKeepFiles RelevantOnly

# Uploaded files are by default created with permissions that do not allow

# any other user to access them. You may need to relax that if you want to

# interface ModSecurity to an external program (e.g., an anti-virus).

#

#SecUploadFileMode 0600

# -- Debug log configuration -------------------------------------------------

# The default debug log configuration is to duplicate the error, warning

# and notice messages from the error log.

#

#SecDebugLog /opt/modsecurity/var/log/debug.log

#SecDebugLogLevel 3

# -- Audit log configuration -------------------------------------------------

# Log the transactions that are marked by a rule, as well as those that

# trigger a server error (determined by a 5xx or 4xx, excluding 404,  

# level response status codes).

#

#SecAuditEngine RelevantOnly

#SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.

#SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This is much easier to look at, but

# assumes that you will use the audit log only ocassionally.

#

#SecAuditLogType Serial

#SecAuditLog c:\inetpub\log\modsec_audit.log

# Specify the path for concurrent audit logging.

#SecAuditLogStorageDir c:\inetpub\log\

# -- Miscellaneous -----------------------------------------------------------

# Use the most commonly used application/x-www-form-urlencoded parameter

# separator. There's probably only one application somewhere that uses

# something else so don't expect to change this value.

#

SecArgumentSeparator &

# Settle on version 0 (zero) cookies, as that is what most applications

# use. Using an incorrect cookie version may open your installation to

# evasion attacks (against the rules that examine named cookies).

#

SecCookieFormat 0

# Specify your Unicode Code Point.

# This mapping is used by the t:urlDecodeUni transformation function

# to properly map encoded data to your language. Properly setting

# these directives helps to reduce false positives and negatives.

#

#SecUnicodeCodePage 20127

#SecUnicodeMapFile unicode.mappinga

# Improve the quality of ModSecurity by sharing information about your

# current ModSecurity version and dependencies versions.

# The following information will be shared: ModSecurity version,

# Web Server version, APR version, PCRE version, Lua version, Libxml2

# version, Anonymous unique id for host.

SecStatusEngine On

Ahora creamos otros fichero que denomino modsecurity_iis.conf con el siguiente contenido:

Include modsecurity.conf

Include D:\home\site\wwwroot\rules\*.conf

Creamos el directorio de rules.

Ahora la partida de pecho ha sido averiguar que el actual conjunto de reglas OWasp versión 3 no funciona con esta versión de modsecurity. He cargado mil reglas, probado, escrito. Al final, me he dado cuenta que el conjunto de regla válido es el 2.3, disponible aquí. https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v2.2/master/base_rules

En este ejemplo el sistema se ha puesto en modo On, es decir, va a parar cualquier intento que catalogue como ataque. Recuerda que hay que hacer primero una limpieza de falsos positivos, mediante la opción DetectionOnly.

Si quieres ver el log por defecto el sistema lo escribe en D:\home\LogFiles>eventlog.xml

El log que ves es una prueba simple, lanzando un nikto sobre la url para que detecte el User_Agent

Ya no tienes excusa para no instalar un sistema Waf