Para evitar que las carpetas de los clientes a las que les coloquen permisos 777 queden desprotegidas permitiendo la ejecución de archivos, hay que cargar un archivo .htaccess en las mismas con el siguiente contenido:
# ATENCION - NO ELIMINE ESTE ARCHIVO - PROTECCION 777 # Prohibida la ejecucion de archivos en carpetas 777 <filesmatch "\.(js|php*|css|pl|cgi|htm|html|jsp)$"> deny from all </filesmatch>
Debemos cargar este archive en la carpeta:
/home/adminXX/proteccion
Donde adminXX corresponde al usuario creado inicialmente para la administración del servidor.
Luego de cargado el archivo debemos asegurar que sea propiedad de root, para ello ejecutamos:
cd /home/adminXX/proteccion chown root:root .htaccess
Ahora debemos crear el cron que deberá ejecutarse a las 3:00 AM todos los días, para ello ejecutamos:
Parar y desinstalar el servicio “PC/SC smart card daemon“ que no se usa y puede representar vulnerabilidades:
service pcscd stop chkconfig pcscd off
Parar y desinstalar el servicio “Bluetooth H.I.D. Server“ que no se usa y puede representar vulnerabilidades:
service hidd stop chkconfig hidd off
Parar y desinstalar el servicio Avahi que permite detectar automáticamente los recursos de una red local y conectarse a ella, que no se usa y puede representar vulnerabilidades:
service avahi-daemon stop chkconfig avahi-daemon off
Parar y desinstalar el servicio Anacron que es un programador de tareas similar a cron, con la diferencia de que no necesita que el sistema esté en ejecución (Se puede utilizar para ejecutar los procesos que cron ejecuta normalmente de forma diaria, semanal y mensual), que no se usa y puede representar vulnerabilidades:
service anacron stop chkconfig anacron off
Parar y desinstalar el servicio Bluetooth, que no se usa y puede representar vulnerabilidades:
service bluetooth stop chkconfig bluetooth off
Parar y desinstalar el servicio rpcidmapd que maneja un servidor NFS, que no se usa y puede representar vulnerabilidades:
service rpcidmapd stop chkconfig rpcidmapd off
Parar y desinstalar el servicio nfslock que inicia los procesos RPC adecuados para permitir que clientes NFS bloqueen archivos en el servidor, que no se usa y puede representar vulnerabilidades:
service nfslock stop chkconfig nfslock off
Parar y desinstalar el servicio cups que es un servidor de impresión, que no se usa y puede representar vulnerabilidades:
service cups stop chkconfig cups off
Parar y desinstalar el servicio xfs que es un servidor de fonts para X Windows, que no se usa y puede representar vulnerabilidades:
service xfs stop chkconfig xsf off
Parar y desinstalar el servicio atd que es un servidor que ejecuta comandos planificados por el programa at en los momentos configurados, que no se usa y puede representar vulnerabilidades:
service atd stop chkconfig atd off
Se deben deshabilitar los commandos LOAD DATA LOCAL en MySQL agregando la línea siguiente línea en la sección [mysqld] del archivo /etc/my.cnf y luego debemos rearrancar mysql, con:
nano /etc/my.cnf
Agregar bajo la sección [mysqld] la línea:
local-infile=0
Guardar el archivo
Reiniciar mysql con:
service mysql restart
Se deben marcar todos los ítems de procesos maliciosos indicados en:
WHM > Background Process Killer
(BitchX, bnc, eggdrop, generic-sniffers, guardservices, ircd, psyBNC, ptlink, services) y luego guardar.
Se debe marcar la casilla siguiente:
WHM > Tweak Settings > Always redirect users to the ssl/tls ports when visiting /cpanel, /webmail, etc.
Debido a que puede ser un vector de ataque de hackers, debemos impedir que existan cargas de archivos por anónimos, a través de:
WHM > FTP Server Configuration > Allow Anonymous Uploads > No
Se deben colocar en automatico las actualizaciones de paquetes y seguridad asociados a cPanel en:
Se deben marcar varias casillas relacionadas con la seguridad en cuanto a la conexión del navegador del usuario, referidores, tokens de seguridad y cokies, estas casillas son:
WHM > Tweak Settings > Only permit cpanel/whm/webmail to execute functions when the browser provides a referrer
WHM > Tweak Settings > Only permit cpanel/whm/webmail to execute functions when the browser provided referrer (Domain/IP and Port) exactly matches the destination URL
WHM > Tweak Settings > Require security tokens for all interfaces
CSF Firewall es un popular cortafuegos basado en iptables para sistemas Gnu/Linux, nació para integrarse con el popular panel cPanel/WHM, pero fue tan grande su éxito que el desarrollador añadió una versión generica que corre hoy en día en las distros más populares.
CSF/LFD soporta los siguientes sistemas operativos:
RedHat v7.3, v8.0, v9.0
*openSUSE v10, v11
RedHat Enterprise v3, v4, v5 (32/64 bit)
*Debian v3.1, v4.0, v5.0
CentOS v3, v4, v5 (32/64 bit)
*Ubuntu v6.06 LTS, v8.10, v9.10, v10.04 LTS
Fedora Core v1 to v12(32/64 bit)
*Mandriva 2009, 2010
*Gentoo
*Slackware v12.2
(* pueden requerir patrones regex personalizados para algunas funciones)
A su vez, soporta los siguientes Servidores Virtuales:
** Virtuozzo
**OpenVZ
VMware
UML
Xen
MS Virtual Server
VirtualBox
(** require la configuración correcta de iptables en el servidor)
Las características de CSF/LFD son:
Script de firewall basado en iptables SPI directas
Proceso tipo demonio que verifica fallas en la autenticación por login para:
Courier imap, Dovecot, uw-imap, Kerio
openSSH
cPanel, WHM, Webmail (sólo servidores cPanel)
Pure-pftd, vsftpd, Proftpd
Páginas web protegidas por contraseña (htpasswd)
Fallas de Mod_security (v1 y v2)
Fallas Suhosin
Exim SMTP AUTH
Fallas de login personalizados con archivos log separados y coincidencia de expresiones regulares.
Seguimiento de login POP3/IMAP para reforzar los login por hora
Notificación de login por SSH
Notificación de login SU
Bloqueo de conexión excesiva
Integración con la interfaz Web para cPanel, DirectAdmin y Webmin
Actualizaciones sencillas entre versiones dentro de cPanel/WHM, DirectAdmin ó Webmin
Actualizaciones sencillas entre versiones por SSH
Pre-configurado para trabajar con cPanel con todos los puertos de cPanel abiertos
Pre-configurado para trabajar con DirectAdmin con todos los puertos de DirectAdmin abiertos
Auto-configuración del puerto SSH si se esta utilizando un puerto no estándar
Bloqueo del tráfico en las direcciones IPs no utilizadas en el servidor para disminuir riesgos
Alerta cuando scripts de usuarios envian emails excesivos po hora para identificar spam
Reporte de procesos sospechosos indicando exploits potenciales ejecutándose en el servidor
Reporte de procesos de usuario excesivos
Reporte de procesos de usuario de uso excesivo y terminación opcional
Reporte de archives sospechosos para indicar archives poteciales de exploit en /tmp y directorios similares.
Vigilancia de directories y archivos, reportando cuando un directorio o archivo vigilado cambia
Bloquea el tráfico que este registrado en las listas de DShield Block y Spamhaus DROP
Protección de paquetes BOGON
Parámetros pre-configurados para seguridad Baja, Media o Alta (sólo para servidores cPanel)
Trabaja con multiples dispositivos ethernet
Verificación de la seguridad del servidor. Verifica aspectos básicos de seguridad y parámetros del servidor (a través de la interfaz web de cPanel/DirectAdmin/Webmin)
Permite direcciones IP con DNS Dinámicos, permitiendo el acceso desde su IP siempre aún cuando su IP cambie cuando se conecta a la Internet.
Envío de Alerta si el promedio de carga permanence alto por un determinado período de tiempo
Reporte del log de mod_security (si está instalado)
Seguimiento de Email relay (verifica todos los emails enviados a través del servidor y emite alertas por uso escesivo ” sólo para servidores con cPanel)
Sistema de Detección de Intrusiones IDS (la última línea de detección alerta acerca de cambios del sistema y archivos binarios de aplicaciones
Protección de SYN Flood
Protección de Ping of death
Bloqueo y seguimiento de rastreo de puertos
Bloqueo permanente y temporal de Ips (con TTL)
Verificación de Exploits
Seguimiento de modificaciones de cuentas (envía alertas si un registro de cuenta es modificado. Ejm: si se cambia la contraseña o el acceso por SSH)
Toma en cuenta el syslog compartido
Servicio de Messenger. Le permite redireccionar solicitudes de conexiones desde IPs bloqueadas hacia páginas de texto o html preconfiguradas para informar al visitante que ha sido bloqueado por el firewall. Esto puede ser muy útil para aquellos con una gran base de usuarios y ayuda en el proceso de solicitudes de soporte en forma más eficiente.
Bloqueo por código de país. Le permite denegar o permitir el acceso desde códigos de país ISO
Detección y mitigación de Port Flooding (por IP y Puerto, para evitar ataques DoS)
Notificación de acceso al WHM root (solo para servidores con cPanel)
Clustering en LFD. Permite que los bloques de IPs se propaguen automáticamente alrededor de un grupo de servidores ejecutando LFD. Esto permite el manejo de LFD en clusters.
Arranque Rápido CSF. Arranque diferido por LFD para servidores con listas de permitidos y bloques muy largos
Detección de Ataques de Fallas de Login Distribuido
IPs Permitidas temporales (con TTL)
Soporte IPv6 con ip6tables (BETA)
Demonio de Fallas de Logins (LFD)
Para complementar el CSF, se utiliza el demonio LFD que se ejecuta como un proceso continuo que se ejecuta cada ciertos segundos y rastrea las entradas a los archivos log buscando intentos de accesos con logins fallidos en forma contínua en un corto período de tiempo. Dichos intentos se denominan “Ataques por Fuerza Bruta” y el proceso del demonio responde muy rápidamente a tales patrones bloqueando las IP’s.
Instalación:
Para realizar la instalación debemos:
Ejecutar:
cd /usr/local/src wget http://www.configserver.com/free/csf.tgz tar -zxvf csf.tgz cd csf
Antes de instalarlo debemos saber que CSF/LFD no debe coexistir con APF/BFD ya que traerá múltiples inconvenientes. Si estamos instalado CSF/LFD en un servidor donde previamente se había instalado APF/BFD entonces debemos ejecutar una aplicación que permite eliminar el APF/BFD con el siguiente comando:
sh /etc/csf/remove_apf_bfd.sh
Ahora podemos instalarlo con:
sh install.sh
Al culminar mostrará:
*** SSH port XXXXX added to the TCP_IN port list TCP ports currently listening for incoming connections: 21,25,53,80,110,143,443,465,765,993,995,2077,2078,2082,2083,2086,2087,2095,2096,3306,8009,8080,XXXXX UDP ports currently listening for incoming connections: 53,631,759,762,5353,53491,57363 Note: The port details above are for information only, csf hasn't been auto-configured. Don't forget to: 1. Configure the TCP_IN, TCP_OUT, UDP_IN and UDP_OUT options in the csf configuration to suite your server 2. Restart csf and lfd 3. Set TESTING to 0 once you're happy with the firewall Adding current SSH session IP address to the csf whitelist in csf.allow: Adding 190.205.209.35 to csf.allow only while in TESTING mode (not iptables ACCEPT) *WARNING* TESTING mode is enabled - do not forget to disable it in the configuration
Luego de instalado debemos ejecutar el siguiente commando para realizar la prueba:
perl /etc/csf/csftest.pl
Si todo esta OK entonces el firewall ha sido instalado y si refrescamos la pantalla del WHM lo veremos al final del menú en el área de Plugins.
Debemos ir a:
WHM > Plugins > ConfigServer Security&Firewall y hacer clic en el botón Firewall Configuration
Buscar los siguientes campos y colocar los valores indicados:
TESTING colocarlo en 0 SMTP_BLOCK colocarlo en 1 LF_SCRIPT_ALERT colocarlo en 1 PT_ALL_USERS colocarlo en 1 SAFECHAINUPDATE colocarlo en 1 IPV6 colocarlo en 1 LT_POP3D colocarlo en 120 PT_DELETED colocarlo en 0 TCP_IN = 20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2089,2095,2096,XXXXX,1433,3306,8080 TCP_OUT = 20,21,22,25,37,43,53,80,110,113,443,587,873,2087,2089,2703,1433 UDP_IN = 20,21,53 UDP_OUT = 20,21,53,113,123,873,6277
Clic en el botón Change y Luego clic en el botón Restart.
LISTO
Adicionalmente, para evitar que el LFD envíe emails constantes en referencia a procesos asocidados al spamd, awstats y tomcat, se debe ingresar al CSF vía Web y editar el archivo “csf.pignore”, agregando al final:
A su vez, podemos editarlos directamente por el WHM con:
WHM > Plugins > ConfigServer Security & Firewall
Al final esta una caja de selección con los nombres de las plantillas de email comenzando con alert.txt y a su lado tiene el botón Edit con el cual se pueden editar.
En el caso de que estemos utilizando Webmin podemos instalar el módulo de CSF para este panel, siguiento estos pasos:
Webmin > Configuración de Webmin > Módulos de Webmin > install from: Desde archivo local > /etc/csf/csfwebmin.tgz > instalar módulo.
Después en:
Webmin > Sistema
Se mostrará ConfigServer Security & Firewall con su logo.
Por otro lado, es importante conocer los comandos del CSF que pueden ser ejecutados por consola (SSH) que listamos a continuación:
Comando Descripción csf -d [IP] Comentario Bloquear/Denegar el acceso a una IP permanentemente y agregarla al archivo /etc/csf/csf.deny csf -td [IP] Bloqueo Temporal csf -dr [IP] Desbloquear una IP y sacarla del archivo /etc/csf/csf.deny csf -g [IP] Verificar si una IP está bloqueada csf -s Inicar las reglas del firewall csf -f Hacer Flush/Parar las reglas del firewall (nota: lfd puede reiniciar csf) csf -r Reiniciar las reglas del firewall csf -a [IP] Permitir acceso a una IP y agregarla al archivo /etc/csf/csf.allow csf -tr [IP] Sacar una IP de la lista de bloqueos temporales o de la lista de permitidos csf -tf Hacer Flush de todas las IPs de la lista de IPs bloqueadas temporalmente csf -df Sacar y desbloquear todas las IPs que están en el archivo /etc/csf/csf.deny csf -t Mostrar la lista de las IP permitidas temporalmente y denegar las IP’s con su TTL y comentario
El sistema BFD va llenando el archivo de IPs bloqueadas del APF constantemente por lo que el mantenimiento del mismo se puede volver muy engorroso. Para que este archivo se limpie cada 4 horas (específicamente al minuto 50 cada 4 horas) debemos ejecutar:
cd /etc/apf nano limpiaips.sh
Colocar en el archivo el siguiente contenido:
MAILTO= #!/bin/sh #Limpiar las IP Bloqueadas en el APF cada 4 horas echo > /etc/apf/deny_hosts.rules >/dev/null 2>&1 /usr/local/sbin/apf -r >/dev/null 2>&1
Guardar el archivo y salir del editor.
Ahora debemos darle permisos de ejecución con:
chmod 700 limpiaips.sh
Luego debemos crear el cron que se ejecute en el minuto 50 cada 4 horas, para ello debemos ejecutar:
crontab -e
Colocar al final del archivo el siguiente contenido:
50 */4 * * * /etc/apf/limpiaips.sh
Guardar el archivo y salir del editor.
Ahora debemos reiniciar el servicio del cron con:
service crond restart (ó con /etc/rc.d/init.d/crond restart)
LISTO.
NOTA: Si el editor que maneja el crontab es el editor “vi” entonces debemos ir al final del archivo, presionar la tecla ” i ” para pasar al modo de inserción, pegar el contenido en una nueva línea, luego presionar la tecla ESC para salir del modo de inserción y finalmente ejecutar el comando para guardar y salir con ” :wq “.
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:
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:
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:
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:
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
Lynx es un navegador de internet en formato de texto que podría ser usado para realizar hackeos, por ello es conveniente cambiar el permiso de ejecución de lynx ubicado en:
/usr/bin/lynx y pasarlo a 600 ó cambiarlo a 750 y cambiarle el grupo a Wheel de tal forma que sólo pueda ser ejecutado por los usuarios en dicho grupo, los comandos son:
Para conocer el contenido del archivo de registro de eventos (log) de los emails manejados por exim ejecutamos:
tail -f /var/log/exim_mainlog
Este archivo nos muestra el directorio desde el cual se emiten los emails. Ahora bien, para mejorar la información reportada podemos modificar el archivo de configuración del exim. Esto lo podemos hacer por SSH ó por WHM según lo que se prefiera:
Por SSH:
nano /etc/exim.conf
Debemos buscar el parámetro log_selector y colocar:
PHP y Apache no hacen seguimiento de los usuarios que envían correos a través del usuario nobody (usuario estándar de PHP), causando debilidades en el uso de formmail y la posibilidad de no poder detectar usuarios malintencionados que envían spam.
Revisar el exim_mainlog no es de gran ayuda, se ve la salida del correo electrónico, pero no se puede hacer seguimiento de qué usuario o secuencia de comandos lo envió.
Si se analiza el archivo php.ini notamos que el programa de correo electrónico está establecido en: /usr/sbin/sendmail y el 99,99 % de los scripts PHP sólo utilizarán la función mail () por lo que todo irá a través de la /usr/sbin/sendmail.
Para poder disponer de un registro de eventos de emails enviados usando nobody debemos realizar el siguiente procedimiento:
Ingresar en la consola con el usuario root y apagar el servicio exim mientras se completa este procedimiento:
/etc/init.d/exim stop
Respaldar el archivo original /usr/sbin/sendmail :
mv /usr/sbin/sendmail /usr/sbin/sendmail.hidden
Crear el script de monitoreo de SPAM para el nuevo sendmail:
nano /usr/sbin/sendmail
Colocar en el archivo lo siguiente:
#!/usr/local/bin/perl # use strict; use Env; my $date = `date`; chomp $date; open (INFO, ">>/var/log/spam_log") || die "Failed to open file ::$!"; my $uid = $>; my @info = getpwuid($uid); if($REMOTE_ADDR) { print INFO "$date - $REMOTE_ADDR ran $SCRIPT_NAME at $SERVER_NAME n"; } else { print INFO "$date - $PWD - @infon"; } my $mailprog = '/usr/sbin/sendmail.hidden'; foreach (@ARGV) { $arg="$arg" . " $_"; } open (MAIL,"|$mailprog $arg") || die "cannot open $mailprog: $!n"; while (<stdin> ) { print MAIL; } close (INFO); close (MAIL);</stdin>
Salir y Guardar.
Debemos cambiar los permisos de ejecución de sendmail
chmod +x /usr/sbin/sendmail
Creamos un nuevo archivo log para guardar el histórico de todos los correos emitidos desde el servidor utilizando programas web:
Podemos entonces monitorear el archivo spam_log para ubicar el spam. Es posible usar cualquier aplicación de formmail o un script que use la función mail() de php.
El archivo spam_log no se ha inicializado para ser rotado por lo que podría llegar a ser muy grande rápidamente. Debe entonces ser agregado logrotation, para ello debemos editar el archivo de configuración del mismo:
nano /etc/logrotate.conf
Buscar:
# no packages own wtmp -- we'll rotate them here /var/log/wtmp { monthly create 0664 root utmp rotate 1 }
