Si bien mod_security nos proporciona una capa más de seguridad en nuestro servidor web Apache, pueden darse casos en los que queden bloqueadas peticiones legítimas que tendremos que dejar pasar por nuestro WAF. Por norma general siempre hay que personalizar o bien las reglas o el comportamiento global del módulo para añadir ciertas excepciones.
Algunos problemas y quebraderos de cabeza surgen con el bloqueo de crawlers web legítimos evitando así que nuestro contenido sea correctamente indexado. Pongamos como ejemplos a Google, Bing… Éstos tienen sus propios bots que deberán tener acceso a nuestra web, siempre siguiendo las normas de robots.txt si están “bien educados”.
Las reglas de mod_security que suelen dar problemas con crawlers son la 920300 para Core Rule Set 3 y la 960015 en versiones inferiores.
El método descrito a continuación se basa en el filtrado de la variable REMOTE_HOST, por lo que es necesario que tengamos la siguiente directiva en nuestro Apache:
HostNameLookups On
La parte menos atractiva de esto es que tiene un impacto negativo en rendimiento. Existe una alternativa -que implica cambios adicionales- basada en scripts LUA descrita hace tiempo en el blog de modsecurity.
Para no bloquear a googlebot podríamos proceder de las siguientes maneras:
- La forma más segura de hacerlo es comprobar en cada petición HTTP el dominio de origen. ¿Por qué? La mayoría de bots/crawlers tienen dominios personalizados que nos dan una pista de que son legítimos. Por ejemplo, para Googlebot tenemos googlebot.com tal y como se describe oficialmente en la web de soporte para Webmasters de Google.
Podemos crear una regla (le he dado el ID 123456) para no aplicar la regla 960015 en las peticiones que lleguen de googlebot.com:
SecRule REMOTE_HOST "@endsWith googlebot.com" "phase:1,nolog,allow,ctl:ruleRemoveById=960015,id:123456"
Si tenemos Core Rule Set 3 aplicaríamos
ruleRemoveById=920300 - También podemos aplicar la directiva
SecRuleRemoveByIdpara quitar las reglas que den problemas a nivel global. Resulta menos granular ya que desactivamos estas reglas completamente para todo tipo de petición. No obstante nos evitaríamos activar HostnameLookups:# Para Core Rule Set inferior a versión 3 la regla que da problemas es 960015: SecRuleRemoveById 960015 # Core Rule Set (CRS) Version 3 con la regla equivalente 920300 SecRuleRemoveById 920300
La personalización de mod_security para cada entorno es un mundo. No sólo para el caso de los crawlers descrito en el artículo, sino que si tenemos un CMS como pueda ser WordPress, Drupal o Joomla, nos tocará casi seguro ajustar el comportamiento de las reglas o del módulo a nivel global para hacerlo compatible y llevadero con la plataforma que estemos utilizando.
Si quisiéramos aplicar este método para otros crawlers tendremos que buscar información específica (ej.: bingbot) y ajustar las directivas de forma acorde.