Instalar y habilitar Mod_Security y verificar sus reglas en Linux

Generalidades:

ModSecurity es un firewall de aplicaciones Web embebible que se ejecuta como módulo del servidor web Apache, provee protección contra diversos ataques hacia aplicaciones Web y permite monitorear tráfico HTTP, así como realizar análisis en tiempo real sin necesidad de hacer cambios a la infraestructura existente. El módulo cuenta con diversas funcionalidades como son:

• Filtrado de Peticiones: Los pedidos HTTP entrantes son analizados por el módulo mod_security antes de pasarlos al servidor Web Apache, a su vez, estos pedidos son comparados contra un conjunto de reglas predefinidas para realizar las acciones correspondientes. Para realizar este filtrado se pueden utilizar expresiones regulares, permitiendo que el proceso sea flexible.
• Técnicas antievasión: las rutas y los parámetros son normalizados antes del análisis para evitar técnicas de evasión.
• Elimina múltiple barras (//)
• Elimina directorios referenciados por si mismos (./)
• Se trata de igual manera la \ y la / en Windows.
• Decodificación de URL
• Reemplazo de bytes nulos por espacios (%00)
• Comprensión del protocolo HTTP: Al comprimir el protocolo HTTP, ModSecurity puede realizar filtrados específicos y granulares.
• Análisis Post Payload: Intercepta y analiza el contenido transmitido a través del método POST.
• Log de Auditoría: Es posible dejar traza de auditoría para un posterior análisis forense.
• Filtrado HTTPS: Al estar embebido como módulo, tiene acceso a los datos después de que estos hayan sido descifrados.
• Verificación de rango de Byte: Permite detectar y bloquear shellcodes, limitando el rango de los bytes.
• Cinco fases de procesamiento, incluyendo: encabezados del pedido (request headers), cuerpo del pedido (request body), encabezados de respuesta (response headers), cuerpo de respuesta (response body) y almacenamiento en bitácora (logging).
• Opciones de transformación por regla.
• Variables transaccionales.
• Persistencia de datos (utilizado en seguimientos de direcciones IP, sesiones de aplicación, y usuarios de aplicación).
• Soporte para ranking de anomalías y correlación básica de eventos (los contadores pueden ser automáticamente decrementados con el paso del tiempo, las variables pueden expirar).
• Soporte para aplicaciones Web e IDs de sesión.
• Soporte para XML (parseo, validación, XPath).
• Bloqueo de IP
• Instalación de mod_security en un servidor de Desarrollo:

Para instalar mod_security de la forma más sencilla en CentOS debemos habilitar previamente el repositorio EPEL (Extra Packages for Enterprise Linux) ejecutando:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

Para verificarlo podemos listar los repositorios existentes con:

yum repolist

Esto puede tomar algunos minutos debido a que debe actualizarse la lista de contenidos de c/u de los repositorios. Una vez ejecutado mostrará:

repo id repo name status

addons CentOS-5 – Addons enabled : 0

base CentOS-5 – Base enabled : 2535

epel Extra Packages for Enterprise Linux 5 – enabled : 4066

extras CentOS-5 – Extras enabled : 327

updates CentOS-5 – Updates enabled : 620

Luego, para instalar un paquete los comandos serían:

yum search nombre-paquete

yum install nombre-paquete

Ahora, para instalar mod_security debemos ejecutar:

yum install mod_security

Esto tomará pocos minutos y debemos responder “y” a lo que nos pregunte. Adicionalmente instalará “Lua” para el correcto funcionamiento de mod_security.

En los servidores de desarrollo los archivos de configuración están ubicados en:

Archivo principal de configuración de mod_security:

/etc/httpd/conf.d/mod_security.conf

Resto de archivos de configuración para mod_security:

• /etc/httpd/modsecurity.d/

Configuración especial a adecuar para los requermientos específicos antes de su uso:

• /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf

Uso de mensajes de depuración para las reglas y problemas asociados a mod_security:

• /var/log/httpd/modsec_debug.log

Todas las solicitudes que disparan eventos de mod_security o errores son registrados en:

• /var/log/httpd/modsec_audit.log

Para poder proteger al servidor de los ataques web debemos editar:

nano /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf

Buscamos el parámetro SecRuleEngine y lo colocamos en “On”:

SecRuleEngine On

Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:

/usr/sbin/httpd -t

Si todo está bien mostrará “Syntax OK”.

Ahora debemos re-arrancar al apache:

service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)

Para verificar que todo esta OK podemos ejecutar:

tail -f /var/log/httpd/error_log (ó según la ubicación del archivo puede ser tail -f /usr/local/apache/logs/error_log)

Esto debe mostrar algo como:

[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations

Ahora para verificar además que el PHP es capaz de procesar el mod_security debe tener incluído este módulo. Para verificarlo debemos crear el archivo phpinfo.php en un directorio web con el siguiente contenido:

<?php phpinfo();?>

Luego ejecutar el archivo vía web y deberá mostrar el listado de módulos y configuración del PHP. Buscamos mod_security y debería conseguirse en pantalla mod_security2 indicando así que efectivamente podrá procesarlo.

Para probar si el mod_security esta haciendo su labor, debemos ejecutar cualquier archivo web y colocar alguna palabra (comado) prohibido, por ejemplo:

http://phpinfo.desh/index.html?name=wget

Esto debería generar un Error 403 (No tiene permiso para acceder al URL requerido).

Manejo de mod_security en los Servidores de Producción basados en cPanel/WHM

Para activar el Mod_security en los servidores de producción solo debemos hacer lo siguiente:

WHM > Plugins > Mod Security > Edit Config > Default Configuration > Save Configuration

Y ya quedará funcionando con las reglas estándar de WHM/cPanel.

Adicionalmente, es importante conocer lo siguiente:

En los servidores de producción los archivos de configuración están ubicados en:

Archivo principal de configuración de mod_security:

• /usr/local/apache/conf/modsec.conf (si el servidor esta basado en Apache 1.X)
• /usr/local/apache/conf/modsec2.conf (si el servidor esta basado en Apache 1.X)

Resto de archivos de configuración para mod_security:

• /usr/local/apache/conf/modsec2.user.conf (reglas personalizadas del administrador)
• /usr/local/apache/conf/modsec2.user.conf.default (reglas predeterminadas. Se usan si se copian al anterior)

Uso de mensajes de depuración para las reglas y problemas asociados a mod_security:

• /usr/local/apache/logs/modsec_debug.log

Todas las solicitudes que disparan eventos de mod_security o errores son registrados en:

• /usr/local/apache/logs/modsec_audit.log

Para poder proteger al servidor de los ataques web debemos editar:

• nano /usr/local/apache/conf/modsec2.conf (ó modsec.conf si es Apache 1.X)

Buscamos el parámetro SecRuleEngine y lo colocamos en “On”:

SecRuleEngine On
Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:

/usr/sbin/httpd -t

Si todo está bien mostrará “Syntax OK”.

Ahora debemos re-arrancar al apache:

service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)

Para verificar que todo esta OK podemos ejecutar:

tail -f /usr/local/apache/logs/error_log

Esto debe mostrar algo como:

[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations

Ahora para verificar además que el PHP es capaz de procesar el mod_security debe tener incluído este módulo. Para verificarlo debemos crear el archivo phpinfo.php en un directorio web con el siguiente contenido:

<?php phpinfo();?>

Luego ejecutar el archivo vía web y deberá mostrar el listado de módulos y configuración del PHP. Buscamos mod_security y debería conseguirse en pantalla mod_security2 indicando así que efectivamente podrá procesarlo.

Para probar si el mod_security esta haciendo su labor, debemos ejecutar cualquier archivo web y colocar alguna palabra (comado) prohibido, por ejemplo:

http://dominio.com/index.html?name=wget

Esto debería generar un Error 403 (No tiene permiso para acceder al URL requerido).

Manejo de Reglas

IMPORTANTE: Las reglas de mod_security 1.X son únicamente para Apache 1.X mientras que las reglas de mod_security 2.x con para el Apache 2.x. No existe compatibilidad entre la sintaxis de las reglas 1.X y las reglas 2.X. Para este curso sólo explicamos lo referente a Apache 2.x debido a que la versión 1.x se considera obsoleta. Debemos estar pendientes de utilizar las reglas correctas porque si se usan las incorrectas el Apache podría fallar. En cualquier cambio que se haga al archivo de configuración de reglas deberá crearse un respaldo previamente para luego retornarlo en el caso de falla.

Para saber si php ha sido compilado con mod_security debemos ejecutar desde php la función phpinfo() y buscar mod_security (para apache 1.x) ó mod_security2 (para apache 2.x).

Reglas Básicas para Apache 2.X (mod_security2) para Servidores de Producción:

Para aplicar estas reglas en Apache 2.X donde se ha compilado el mod-security2 debemos:

Verificar la existencia de /usr/local/apache/conf/modsec2.conf

Si no existe debemos entrar por WHM y recompilar el Apache y PHP marcando la opción mod_security para que lo inicialice. Luego continuamos con la instalación de las reglas de seguridad propias.

Editar:

nano /usr/local/apache/conf/modsec2.conf

Verificar que su contenido sea:

LoadFile /opt/xml2/lib/libxml2.so
LoadFile /opt/lua/lib/liblua.so
LoadModule security2_module modules/mod_security2.so
<IfModule mod_security2.c>
SecRuleEngine On
# See http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf
# "Add the rules that will do exactly the same as the directives"
# SecFilterCheckURLEncoding On
# SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_audit.log
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:406"
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow
Include "/usr/local/apache/conf/modsec2.user.conf"
</IfModule>

Editar nano modsec2.user.conf:

nano /usr/local/apache/conf/modsec2.user.conf

Colocar en el archivo:

# Deprectaed due to security issues so it shoudl be off: http://blog.modsecurity.org/2008/08/transformation.html
SecCacheTransformations Off
# Check Content-Length and reject all non numeric ones
SecRule REQUEST_HEADERS:Content-Length "!^\d+$" "deny,log,auditlog,msg:'Content-Length HTTP header is not numeric', severity:'2',id:'960016'"
# Do not accept GET or HEAD requests with bodies
SecRule REQUEST_METHOD "^(GET|HEAD)$" "chain,deny,log,auditlog,msg:'GET or HEAD requests with bodies', severity:'2',id:'960011'"
SecRule REQUEST_HEADERS:Content-Length "!^0?$"
# Require Content-Length to be provided with every POST request.
SecRule REQUEST_METHOD "^POST$" "chain,deny,log,auditlog,msg:'POST request must have a Content-Length header',id:'960012',severity:'4'"
SecRule &REQUEST_HEADERS:Content-Length "@eq 0"
# Don't accept transfer encodings we know we don't know how to handle
SecRule HTTP_Transfer-Encoding "!^$" "deny,log,auditlog,msg:'ModSecurity does not support transfer encodings',id:'960013',severity:'5'"
# Check decodings
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "@validateUrlEncoding" \
"chain, deny,log,auditlog,msg:'URL Encoding Abuse Attack Attempt',id:'950107',severity:'4'"
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\%(?![0-9a-fA-F]{2}|u[0-9a-fA-F]{4})"
NOTA: La regla 950801 debe eliminarse porque causa problemas con los acentos y las ñ.
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "@validateUtf8Encoding" "deny,log,auditlog,msg:'UTF8 Encoding Abuse Attack Attempt',id:'950801',severity:'4'"
# Proxy access attempt
SecRule REQUEST_URI ^http:/ "deny,log,auditlog,msg:'Proxy access attempt', severity:'2',id:'960014'"
#
# Restrict type of characters sent
SecRule REQUEST_FILENAME|REQUEST_HEADERS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer \
"@validateByteRange 1-255" \
"log,auditlog,msg:'Request Missing an Accept Header', severity:'2',id:'960015',t:urlDecodeUni,phase:1"
SecRule ARGS|ARGS_NAMES "@validateByteRange 1-255" \
"deny,log,auditlog,msg:'Invalid character in request',id:'960901',severity:'4',t:urlDecodeUni,phase:2"
# allow request methods
SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD))$" \
"phase:1,log,auditlog,msg:'Method is not allowed by policy', severity:'2',id:'960032'"
# Restrict file extension
# removed exe so that frontpage will work
# Restricted HTTP headers
SecRule REQUEST_HEADERS_NAMES "\.(?:Lock-Token|Translate|If)$" \
"deny,log,auditlog,msg:'HTTP header is restricted by policy',id:'960038',severity:'4'"
SecRule HTTP_User-Agent "(?:\b(?:m(?:ozilla\/4\.0 compatible
|etis)|webtrends security analyzer|pmafind)\b|n(?:-stealth|sauditor|essus|ikto)|b(?:lack ?widow|rutus|ilbo)|(?:jaascoi|paro)s|internet explorer|webinspect|\.nasl)" \
"deny,log,auditlog,msg:'Request Indicates a Security Scanner Scanned the Site',id:'990002',severity:'2'"
SecRule REQUEST_HEADERS_NAMES "\bacunetix-product\b" \
"deny,log,auditlog,msg:'Request Indicates a Security Scanner Scanned the Site',id:'990901',severity:'2'"
SecRule REQUEST_FILENAME "^/nessustest" \
"deny,log,auditlog,msg:'Request Indicates a Security Scanner Scanned the Site',id:'990902',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "(?:m(?:ozilla\/(?:4\.0 \(compatible; advanced email extractor|2\.0 compatible;newtactivex;win32
)|ailto:craftbot\@yahoo\.com)|e(?:mail(?:(?:collec|harves|magne)t|(?: extracto|reape)r|siphon|wolf)|(?:collecto|irgrabbe)r|xtractorpro|o browse)|a(?:t(?:tache|hens)|utoemailspider|dsarobot)|w(?:eb(?:emailextrac| by mail)|3mir)|f(?:astlwspider|loodgate)|p(?:cbrowser|ackrat|surf)|(?:digout4uagen|takeou)t|(?:chinacla|be)w|hhjhj@yahoo|rsync|shai|zeus)" \
"deny,log,auditlog,msg:'Rogue web site crawler',id:'990012',severity:'2'"
SecRule REQUEST_HEADERS:User-Agent "(?:\b(?:(?:indy librar|snoop)y|microsoft url control|lynx)\b|d(?:ownload demon|isco)|w(?:3mirror|get)|l(?:ibwww|wp)|p(?:avuk|erl)|cu(?:sto|rl)|big brother|autohttp|netants|eCatch)" \
"chain,log,auditlog,msg:'Request Indicates an automated program explored the site',id:'990011',severity:'5'"
SecRule REQUEST_HEADERS:User-Agent "!^apache.*perl"
# Session fixation
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\.cookie\b.*?;\W*?(?:expires|domain)\W*?=|\bhttp-equiv\W+set-cookie\b)" \
"capture,ctl:auditLogParts=+E,log,auditlog,msg:'Session Fixation. Matched signature <%{TX.0}>',id:'950009',severity:'2'"
# Blind SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:ys\.(?:user_(?:(?:t(?:ab(?:_column|le)|rigger)|object|view)s|c(?:onstraints|atalog))|all_tables|tab)|elect\b.{0,40}\b(?:substring|ascii|user))|m(?:sys(?:(?:queri|ac)e|relationship|column|object)s|ysql.user)|c(?:onstraint_type|harindex)|attnotnull)\b|(?:locate|instr)\W+\()|\@\@spid\b)" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950007',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:(?:s(?:ys(?:(?:(?:process|tabl)e|filegroup|object)s|c(?:o(?:nstraint|lumn)s|at)|dba|ibm)|ubstr(?:ing)?)|user_(?:(?:(?:constrain|objec)t|tab(?:_column|le)|ind_column|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|(?:dba|mb)_users|xtype\W+\bchar|rownum)\b|t(?:able_name\b|extpos\W+\())" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'Blind SQL Injection Attack. Matched signature <%{TX.0}>',id:'950904',severity:'2'"
# SQL injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "(?:\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresultset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|(?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950001',severity:'2'"
SecRule REQUEST_FILENAME|ARGS|REQUEST_HEADERS|!REQUEST_HEADERS:Referer "\b(?:user_(?:(?:object|table|user)s|password|group)|a(?:tt(?:rel|typ)id|ll_objects)|object_(?:(?:nam|typ)e|id)|pg_(?:attribute|class)|column_(?:name|id)|substr(?:ing)?|table_name|mb_users|rownum)\b" \
"capture,t:replaceComments,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection Attack. Matched signature <%{TX.0}>',id:'950906',severity:'2'"
# XSS
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:\b(?:on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|background-image|mocha):|type\b\W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b| [vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|shell|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[|script|meta)|(?:\.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|innerhtml)|\@import)\b)" \
"capture,ctl:auditLogParts=+E,log,auditlog,msg:'Cross-site Scripting (XSS) Attack. Matched signature <%{TX.0}>',id:'950004',severity:'2'"
# file injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:\b(?:\.(?:ht(?:access|passwd|group)|www_?acl)|global\.asa|httpd\.conf|boot\.ini)\b|\/etc\/)" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'Remote File Access Attempt. Matched signature <%{TX.0}>',id:'950005',severity:'2'"
# Command access
SecRule REQUEST_FILENAME "\b(?:n(?:map|et|c)|w(?:guest|sh)|cmd(?:32)?|telnet|rcmd|ftp)\.exe\b" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'System Command Access. Matched signature <%{TX.0}>',id:'950002',severity:'2'"
# Command injection
SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:\b(?:(?:n(?:et(?:\b\W+?\blocalgroup|\.exe)|(?:map|c)\.exe)|t(?:racer(?:oute|t)|elnet\.exe|clsh8?|ftp)|(?:w(?:guest|sh)|rcmd|ftp)\.exe|echo\b\W*?\by+)\b|c(?:md(?:(?:32)?\.exe\b|\b\W*?\/c)|d(?:\b\W*?[\\\/]|\W*?\.\.)|hmod.{0,40}?\+.{0,3}x))|[\;\|\`]\W*?\b(?:(?:c(?:h(?:grp|mod|own|sh)|md|pp|c)|p(?:asswd|ython|erl|ing|s)|n(?:asm|map|c)|f(?:inger|tp)|(?:kil|mai)l|(?:xte)?rm|ls(?:of)?|telnet|uname|echo|id)\b|g(?:\+\+|cc\b))|\/(?:c(?:h(?:grp|mod|own|sh)|pp|c)|p(?:asswd|ython|erl|ing|s)|n(?:asm|map|c)|f(?:inger|tp)|(?:kil|mai)l|g(?:\+\+|cc)|(?:xte)?rm|ls(?:of)?|telnet|uname|echo|id)(?:[\'\"\|\;\`\-\s]|$))" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'System Command Injection. Matched signature <%{TX.0}>',id:'950006',severity:'2'"
SecRule "ARGS|ARGS_NAMES|REQUEST_HEADERS|!REQUEST_HEADERS:User-Agent" \
"\bwget\b" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'System Command Injection. Matched signature <%{TX.0}>',id:'950907',severity:'2'"
# SSI injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "<!--\W*?#\W*?(?:e(?:cho|xec)|printenv|include|cmd)" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'SSI injection Attack. Matched signature <%{TX.0}>',id:'950011',severity:'2'"
# PHP injection
SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|REQUEST_HEADERS "(?:(?:\b(?:f(?:tp_(?:nb_)?f?(?:ge|pu)t|get(?:s?s|c)|scanf|write|open|read)|gz(?:(?:encod|writ)e|compress|open|read)|s(?:ession_start|candir)|read(?:(?:gz)?file|dir)|move_uploaded_file|(?:proc_|bz)open)|\$_(?:(?:pos|ge)t|session))\b|<\?(?!xml))" \
"capture,ctl:auditLogParts=+E,deny,log,auditlog,msg:'PHP Injection Attack. Matched signature <%{TX.0}>',id:'950013',severity:'2'"

Salir y Guardar.

Reglas Avanzadas para Apache 2.X (mod_security2) para Servidores de Desarrollo

Para aplicar estas reglas en Apache 2.X en los servidores de desarrollo debemos cumplir con el siguiente procedimiento:

Cargar el Kit de Reglas Avanzadas de mod_security2 de TecnoSoluciones (reglas-mod_security2.zip) en el directorio del usuario que se conecta por SFTP (ej. /home/tecno).

Descomprimir el archivo con: unzip reglas-mod_security2.zip

Esto creará dos directorios: /home/tecno/base_rules y /home/tecno/more_rules

Cambiarse al directorio de reglas del mod_security y crear ambos directorios, para pasar luego los archivos creados para los mismos con:

cd /etc/httpd/modsecurity.d/
mkdir /etc/httpd/modsecurity.d/base_rules
mkdir /etc/httpd/modsecurity.d/more_rules
cp /home/tecno/base_rules/* /etc/httpd/modsecurity.d/base_rules/
cp /home/tecno/more_rules/* /etc/httpd/modsecurity.d/more_rules/

Editar el archivo de configuración de mod_security y agregar los include de los archivos de las reglas con:

nano /etc/httpd/conf.d/mod_security.conf

Ubicar el bloque que dice <IfModule mod_security2.c> “¦. </IfModule> y colocar justo al final antes del cierre del bloque </IfModule> lo siguiente:

#Reglas adicionales de TecnoSoluciones (Incluye reglas de GotRoot)
Include modsecurity.d/base_rules/modsecurity_crs_20_protocol_violations.conf
Include modsecurity.d/base_rules/modsecurity_crs_21_protocol_anomalies.conf
Include modsecurity.d/base_rules/modsecurity_crs_23_request_limits.conf
Include modsecurity.d/base_rules/modsecurity_crs_30_http_policy.conf
Include modsecurity.d/base_rules/modsecurity_crs_35_bad_robots.conf
Include modsecurity.d/base_rules/modsecurity_crs_40_generic_attacks.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_phpids_converter.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_phpids_filters.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include modsecurity.d/base_rules/modsecurity_crs_41_xss_attacks.conf
Include modsecurity.d/base_rules/modsecurity_crs_42_tight_security.conf
Include modsecurity.d/base_rules/modsecurity_crs_45_trojans.conf
Include modsecurity.d/base_rules/modsecurity_crs_47_common_exceptions.conf
Include modsecurity.d/base_rules/modsecurity_crs_48_local_exceptions.conf
Include modsecurity.d/base_rules/modsecurity_crs_49_enforcement.conf
Include modsecurity.d/base_rules/modsecurity_crs_49_inbound_blocking.conf
Include modsecurity.d/base_rules/modsecurity_crs_50_outbound.conf
Include modsecurity.d/base_rules/modsecurity_crs_59_outbound_blocking.conf
Include modsecurity.d/base_rules/modsecurity_crs_60_correlation.conf
Include modsecurity.d/base_rules/modsecurity_localrules.conf
#Include modsecurity.d/more_rules/00_asl_rbl.conf
#Include modsecurity.d/more_rules/00_asl_whitelist.conf
Include modsecurity.d/more_rules/05_asl_exclude.conf
Include modsecurity.d/more_rules/05_asl_scanner.conf
Include modsecurity.d/more_rules/10_asl_antimalware.conf
Include modsecurity.d/more_rules/10_asl_rules.conf
Include modsecurity.d/more_rules/11_asl_data_loss.conf
Include modsecurity.d/more_rules/20_asl_useragents.conf
Include modsecurity.d/more_rules/30_asl_antimalware.conf
Include modsecurity.d/more_rules/30_asl_antispam.conf
Include modsecurity.d/more_rules/30_asl_antispam_referrer.conf
Include modsecurity.d/more_rules/40_asl_apache2-rules.conf
Include modsecurity.d/more_rules/50_asl_rootkits.conf
Include modsecurity.d/more_rules/60_asl_recons.conf
Include modsecurity.d/more_rules/99_asl_exclude.conf
Include modsecurity.d/more_rules/99_asl_jitp.conf
Include modsecurity.d/more_rules/trusted-domains.conf

Salir y Guardar el archivo

Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:

/usr/sbin/httpd -t

Si todo está bien mostrará “Syntax OK”.

Ahora debemos re-arrancar al apache:

service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)

Para verificar que todo esta OK podemos ejecutar:

tail -f /var/log/httpd/error_log

Esto debe mostrar algo como:

[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations

Reglas Avanzadas para Apache 2.X (mod_security2) para Servidores de Producción:

NOTA: Estas reglas aún no han sido depuradas para ser colocadas en nuestros servidores de producción por lo que deben revisarse primero para no crear fallas.

Para aplicar estas reglas en Apache 2.X en los servidores de Producción basados en cPanel/WHM debemos cumplir con el siguiente procedimiento:

Cargar el Kit de Reglas Avanzadas de mod_security2 de TecnoSoluciones (reglas-mod_security2.zip) en el directorio del usuario que se conecta por SFTP (ej. /home/adminX1).

Descomprimir el archivo con: unzip reglas-mod_security2.zip

Esto creará dos directorios: /home/adminx1/base_rules y /home/ adminx1/more_rules

Cambiarse al directorio de reglas del mod_security y crear ambos directorios, para pasar luego los archivos creados para los mismos con:

cd /usr/local/apache/conf/
mkdir /usr/local/apache/conf/base_rules
mkdir /usr/local/apache/conf/more_rules
cp /home/adminx1/base_rules/* /usr/local/apache/conf/base_rules
cp /home/adminx1/more_rules/* /usr/local/apache/conf/more_rules

Editar el archivo de configuración de mod_security para el usuario y agregar los include de los archivos de las reglas con:

/usr/local/apache/conf/modsec2.user.conf

Colocar lo siguiente:

#Reglas adicionales de TecnoSoluciones (Incluye reglas de GotRoot)
Include /usr/local/apache/conf/base_rules/modsecurity_crs_20_protocol_violations.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_21_protocol_anomalies.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_23_request_limits.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_30_http_policy.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_35_bad_robots.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_40_generic_attacks.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_phpids_converter.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_phpids_filters.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_41_xss_attacks.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_42_tight_security.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_45_trojans.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_47_common_exceptions.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_48_local_exceptions.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_49_enforcement.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_49_inbound_blocking.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_50_outbound.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_59_outbound_blocking.conf
Include /usr/local/apache/conf/base_rules/modsecurity_crs_60_correlation.conf
Include /usr/local/apache/conf/base_rules/modsecurity_localrules.conf
#Include /usr/local/apache/conf/more_rules/00_asl_rbl.conf
#Include /usr/local/apache/conf/more_rules/00_asl_whitelist.conf
Include /usr/local/apache/conf/more_rules/05_asl_exclude.conf
Include /usr/local/apache/conf/more_rules/05_asl_scanner.conf
Include /usr/local/apache/conf/more_rules/10_asl_antimalware.conf
Include /usr/local/apache/conf/more_rules/10_asl_rules.conf
Include /usr/local/apache/conf/more_rules/11_asl_data_loss.conf
Include /usr/local/apache/conf/more_rules/20_asl_useragents.conf
Include /usr/local/apache/conf/more_rules/30_asl_antimalware.conf
Include /usr/local/apache/conf/more_rules/30_asl_antispam.conf
Include /usr/local/apache/conf/more_rules/30_asl_antispam_referrer.conf
Include /usr/local/apache/conf/more_rules/40_asl_apache2-rules.conf
Include /usr/local/apache/conf/more_rules/50_asl_rootkits.conf
Include /usr/local/apache/conf/more_rules/60_asl_recons.conf
Include /usr/local/apache/conf/more_rules/99_asl_exclude.conf
Include /usr/local/apache/conf/more_rules/99_asl_jitp.conf
Include /usr/local/apache/conf/more_rules/trusted-domains.conf

Salir y Guardar el archivo

Para probar que no existan problemas de sintaxis en el Apache debemos ejecutar:

/usr/sbin/httpd -t

Si todo está bien mostrará “Syntax OK”.

Ahora debemos re-arrancar al apache:

service httpd restart (ó con /etc/rc.d/init.d/ httpd restart)

Para verificar que todo esta OK podemos ejecutar:

tail -f /usr/local/apache/logs/error_log

Esto debe mostrar algo como:

[Sat Feb 27 03:01:08 2010] [notice] Digest: done
[Sat Feb 27 03:01:08 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 03:01:08 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
[Sat Feb 27 04:48:26 2010] [notice] caught SIGTERM, shutting down
[Sat Feb 27 04:48:27 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 27 04:48:28 2010] [notice] ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/) configured.
[Sat Feb 27 04:48:28 2010] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 27 04:48:28 2010] [notice] Digest: done
[Sat Feb 27 04:48:29 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sat Feb 27 04:48:29 2010] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations

Enlaces a Recursos:

http://www.modsecurity.org/

http://www.cyberciti.biz/faq/rhel-fedora-centos-linux-enable-epel-repo/

http://www.isecauditors.com/es/iseclab4.html#Capitulo4

http://www.infosecwriters.com/text_resources/pdf/Defending-web-services.pdf

http://www.securityfocus.com/infocus/1739

http://www.securityfocus.com/columnists/418