“Seguridad y optimización, el camino del guerrero hacia la paz interior del GLAMP”

David Hernández (Dabo) | @daboblog | www.daboblog.com

2013

Info y herramientas usadas en mi demo de ConectaCon.

Escenario

Para la demo de Jaén, usé conectando vía SSH, 4 servidores bajo Debian 6 GNU/Linux propios en producción, dentro un entorno de pruebas y alcance controlado. La siguiente información es válida también para Ubuntu, en otras distros, parcialmente.

El objetivo era dar otro enfoque, no sólo desde el punto de la seguridad, hablamos también de optimizar recursos. No olvidemos que “la disponibilidad es seguridad”.

Se basaba en un escenario “clásico”. Servidor GLAMP (GNU/Linux, Apache, MySQL y PHP) configurado por defecto (con un Kernel compilado con el parche de grsecurity).

Revisando temas relativos a cuestiones de seguridad y optimización, realizando diversos ataques y ver cómo se podían mitigar, además de monitorizarlos en el lado del servidor viendo trazas de los mismos y logs, mientras iba haciendo cambios.

Iré insertando en el PDF enlaces a material de apoyo y varias de las herramientas que usé, junto a otras que os pueden resultar útiles en vuestro día a día con los Sistemas.

Sobre estas cuestiones, hay gran material publicado por otros (que incluyo aquí) el mío, tomadlo como un punto de partida más y aplicad los cambios con precaución -;).

Sobre Apache, MySQL, Nginx, DB, Amazon EC2

SysAdmin - Amazon

Podcast "Especial SysAdmin” con Ricardo Galli (UIB – Menéame)

(Además del audio, os recomiendo leer el texto inferior que le acompaña)

Podcast “Especial Amazon EC2” con Ricardo Galli y Raúl Naveiras.

Bases de datos

Bases de datos web : estrategias, escalado, tipos, etc. Por Ricardo Galli.

Optimizar MySQL | MySQLTuner | MySQl performance | otros scripts.

Sobre Apache (recuerda...)

Nota (En el Podcast “Especial SysAdmin”, diapositiva anterior, hablamos a fondo de estas configuraciones).

Apache 2 y Multiproceso (MPM). “Control dinámico de los procesos según la carga bajo demanda”.

Prefork (default) Procesos hijo, mod_php. En teoría más estable y compatible con más módulos o soft. Mayor capacidad de aislamiento si hay un problema con una petición respecto al resto de procesos “hijo”.

Worker lanza procesos hijos e hilos (hebras o subprocesos) por hijo,PHP va como fastCGI. Menor consumo de memoria que Prefork, más rendimiento. Si un hilo falla, afectará al resto..

TimeOut segundos antes de que se cancele un conexión por falta de respuesta. (Entre 20 y 30 seg ok).

Keepalive (conexiones persistentes) recomendable (salvo excepciones) activo = “On”. Permite múltiples peticiones sobre la misma conexión TCP. Útil para sesiones HTTP de larga duración (por ej foros).

MaxKeepAliveRequests limita el número de peticiones permitidas por conexión cuando KeepAlive está activado. Por defecto 0 (ilimitadas). Se recomienda un valor alto, veréis ejemplos con 100, 1.000, etc.

KeepAliveTimeout  Segundos que Apache esperará peticiones subsiguientes antes de cerrar una conexión persistente. Si ya ha sido recibida una petición, se aplica directiva Timeout para cerrar la conexión. Cuanto mayor sea el valor de timeout, más procesos del servidor ocupados esperando en conexiones con clientes no activos. Recomendable entre 2 y 5 segundos.

Después veremos cómo monitorizar Apache y más servicios, pero en mi demo también mostré “Server Status”, desde el terminal “apachectl fullstatus”, o accediendo vía web. Tutorial de configuración e info.

(Recordad lo que dije de Apache 2.4. I/O asíncrona, proxy inverso tipo Nginx, menos memoria, caching, etc).

Sobre Apache (Caching)

Si recordáis las herramientas que instalé en la demo, usé tanto Memcached a nivel de Server, como el módulo para Apache memcache y X-Cache como sistema de caching para scripts de PHP. Si está instalado Memcached, hay muchos CMS que pueden usarlo bien de forma “nativa” (Foros SMF) o vía un plugin como en el caso de WordPress (Memcached Object Cache Plugin).

Estas soluciones, están disponibles desde los sources de Debian (o Ubuntu) y con un aptitude install memcached php5-xcache php5-memcache quedarían instaladas. Después podéis comprobar si están cargados los módulos tanto con un php info, como tecleando en la línea de comandos php - - ri (y detrás iría el módulo, por ejemplo memcache o xcache).

Podéis seguir este tutorial de Falko para instalar Memcached y el módulo de Apache y este otro (con más opciones) de José María en el que incluye el soporte para WordPress.

De todos modos, no olvidéis cambiar las configuraciones por defecto de los módulos ya que no son las adecuadas tal y como se instalan. Hay otras soluciones tipo APC (las repasamos en el podcast) pero con PHP 5.5 ha llegado Opscode y a falta de probarlo, lo veo interesante.

Recordad que para ver si todo está ok cuando se carga algún módulo en Apache, se cambia la configuración (o del fichero php.ini), con un tail -f /var/log/apache2/error.log, veréis si es correcto, también después de ejecutar un apachectl restart o /etc/init.d/apache2 reload.

Para ver si la sintaxis de Apache está ok: apachectl configtest, las opciones de compilación: apachectl -V, módulos cargados: en /etc/apache2/mods-enabled/ otros comandos de Apache.

“Seguridad por Oscuridad”

En la demo, hice varias pruebas con Nmap, Curl, Server Spy o xprobe2 para identificar puertos abiertos o servicios activos en el server, detectar la versión del S.O o módulos de Apache.

Ataques automatizados buscando versiones de software vulnerables, un posible “0 day”, o cuando no siempre se puede parchear, hacen necesario cambiar las configuraciones por defecto.

Apache > En /etc/apache2/conf.d/security: ServerTokens Prod y ServerSignature Off.

Para evitar listados de directorios, usé “Options – Indexes”, también se puede via .htaccess. No olvidéis cargar la nueva conf de Apache con /etc/init.d/apache2 reload o apachectl restart).

PHP > Tras el cambio, vimos que con un curl -i laweb.com | less, seguíamos viendo versiones de SSL o PHP. En /etc/php5/apache2/php.ini dejamos en “Off” el valor de expose_php. Como en el caso anterior, para cargar una nueva configuración de PHP, hay que relanzar la de Apache.

SSH > También vimos como aún con un firewall activo, seguía saliendo la versión y S.O por el banner de SSH. En este caso (Debian Based), la versión de SSH se oculta como una opción de compilación.

Editando /etc/ssh/sshd_config e incluyendo “DebianBanner no” (y /etc/init.d/sshd restart para actualizar cambios) no revela tanta información, sólo la versión. Más sobre seguridad en SSH.

MySQL > Recordad que para que sólo admita conexiones desde el localhost, hay que insertar en my.cnf la siguiente línea: bind-address = 127.0.0.1 (y después, un /etc/init.d/mysql restart).

Otros > (BIND, Postfix, etc) Os recomiendo leer esta entrada de Infosec Institute sobre el tema.

“Seguridad en PHP”

Dimos un repaso a las directivas más importantes de cara a la seguridad en PHP: límites de memoria, errores, Suhosin Patch (a 19/06/2013 fuera de Debian 7 por un bug) funciones, etc.

Como punto de partida, recomendé el uso de PhpSecInfo. Se descomprime en la raíz del sitio el fichero y se accede vía web para comprobar el estado por defecto de vuestra instalación.

Junto a cada sección, tenéis un enlace al motivo por el cual algún valor puede estar marcado como un problemático (según colores, dependiendo del impacto). Resumen y explicación.

También con un ejemplo de un “info.php” que no debía estar activo, incluí en php.ini algunos valores deshabilitando funciones para evitar posibles brechas de seguridad:

disable_functions = system, exec, passthru, shell, shell_exec, popen, pclose, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, phpinfo, proc_open, show_source, passthru

Otras lecturas recomendadas:

eBook Pro PHP Security 2ª edición (actualizado a la versión 5.3) | PHP Insecurity Notes.

25 PHP Security Best Practices | Inserting Vulnerabilities in Web Applications | PHP IDS.

Evitar ataques XSS con PHP Input Filter | Seguridad en PHP | Manual online de PHP, seguridad.

“IDS / IPS - iptables”

Una vez ocultadas las versiones, utilicé Portsentry como IDS / IPS y vimos su funcionamiento tanto en modo IDS (sistema de detección de intrusos) como IPS (prevención / bloqueo).

Para ello, lancé un portscan con Nmap 6.25 intentando identificar puertos, servicios y S.O. Después de ver el resultado, ya con menos información que al principio, instalé Portsentry

Recordad que durante la instalación, (aptitude install portsentry) nos informaba que por defecto actúa en modo IDS y para que realice un bloqueo de la IP atacante, había que poner en “1” en “etc/portsentry/portsentry.conf” los valores “BLOCK_UDP” y “BLOCK_TCP” (por defecto en 0).

Otro valor a tener en cuenta es el “SCAN_TRIGGER”, en una de las pruebas que realicé, Nmap pasó la barrera de Porsentry, después bajé el valor a 0 y el siguiente ataque ya fue bloqueado. No olvidéis una vez realizados los cambios ejecutar un /etc/init.d/porsentry restart. Con un lsof -i veréis cómo está a la escucha en sus correspondientes puertos tanto en modo IDS como IPS.

Es muy importante en cualquier herramienta de este tipo, usar las listas blancas para evitar bloqueos indeseados a la propia IP del server, balanceador, “failover”, etc (“portsentry.ignore”).

Después, levanté y revisé la configuración de APF Firewall, un interface para interactuar con iptables (tuto) de una forma más “amigable” para los que empiezan, con interesantes funciones.

Realicé un ataque con Nmap y vimos como APF ralentizaba y bloqueaba el escaneo de puertos según el timming de Nmap, consiguiendo este último una escasa información del sistema.

Insisto en la necesidad de documentarse bien antes de poner en producción estas medidas.

“Fuerza Bruta - DoS - WAF”

Para ataques SSH / fuerza bruta usé Denyhosts y Fail2ban que vigila más servicios como FTP, mail o por ej Apache (ambos vía aptitude). Mirad la documentación y listas blancas / exclusiones.

También BFD desde el cron bloqueando con APF Firewall. Otra opción puede ser SSHGuard.

Como dije en Jaén, un DoS o DDoS bien realizado, no lo vais a mitigar con estas herramientas, pero ayudarán en muchas ocasiones a bloquear picos de tráfico indeseado, o ataques desde una o varias direcciones IP. Pero es importante volver de nuevo a la sección de “Caching” y Apache porque está todo muy relacionado hablando de peticiones masivas.

Os resultará interesante leer este post en SbD sobre “Ataques DoS basados en mitigación”.

Sobre Mod Security, junto al libro de Ivan Ristic, os recomiendo leer esta gran saga de Adastra. Recomendable tutorial de sobre Mod Security y Mod Evasive (ojo con el “mail bug” de Evasive).

También su entrada sobre otro clásico para los DoS, Mod Evasive (en el post menciona un viejo bug que tiene del que os hablé allí). Como antes, un ifconfig y detectar las IP para las exclusiones.

Instalé DoS Deflate y vimos la protección “Anti DoS” de APF. Atacando desde 3 servers con PenTBox (Net DoS Tester) y Apache Benchmark, simulando cientos de peticiones / conexiones.

Pudiéndose ver el incremento de tráfico, logs y bloqueos con aplicaciones a bajo nivel de sistema como iptraf (lo puse en modo Sniffer), vnstat -l, comandos de netstat y otros útiles como pueden ser: lsof, iostat, iotop, iftop, Arpwatch, Monitorix (encontraréis otros más en el enlace) etc.

“Logs - Monitorización”

Logcheck (aptitude install logcheck), aplicación que analiza los logs de la máquina y muestra o envía por email un informe (por defecto cada hora) sobre sucesos relevantes del sistema.

Logwatch (aptitude install logwatch), similar a logcheck, pero proporcionando más información. Envía un informe diario por email con registros de /var/log (revisad el fichero de configuracion).

Monit, permite monitorizar procesos daemon (sendmail, Apache, MySQL, etc). La ventaja frente a otros sistemas es que puede reaccionar a los eventos, intentando levantar el proceso caído, avisando por email de su intervención. Es interesante también el servicio M/Monit.

Munin es otra herramienta de monitorización con múltiples plugins que permiten hacer un seguimiento detallado y ver de forma gráfica de lo que sucede en el sistema (post de n1mh).

Monit y Munin se instalan vía aptitude. Rec, guía de instalación / configuración en Debian 7.

GoAccess, tutorial de Israel, para analizar logs de Apache y Nginx. Rel, “apachetop”, Afterglow”.

Nagios puede realizar el trabajo de los 4 anteriores. Es muy robusto y fiable, cuenta con múltiples plugins, monitoriza tanto Software como Hardware, permite configurar múltiples alertas, acceso vía web a las gráficas bajo SSL o por SSH, alertas SMS, clientes para móviles, tablets, etc.

Vía aptitude podéis instalar Nagios 3, pero os sugiero leer este completo tutorial (rama 2.x) junto a este otro sobre la versión 3.3.1 y Debian 6.0.1. Recomendable: blog “Nagios en Español”.

Pandora FMS es otra opción similar a Nagios, altamente configurable, muy bien documentado y con un monitor muy potente y alertas para controlar en tiempo real lo que sucede en el server.

“Rootkits – Malware - Otros”

En uno de los servers de la demo, subí un rootkit de los típicos que se ven en un WordPress o Joomla comprometidos. Lo detecté con LMD. Una vez instalado, analiza todos los ficheros buscando cadenas sospechosas y luego vía el cron, lo hace de forma incremental con cada fichero nuevo a diario (sintaxis básica: maldet -a /path). Otra alternativa interesante es Webserver Malware Scanner que puede trabajar perfectamente en conjunción con LMD.

Hablando de WordPress y ataques, en esta entrada recopilo una serie de plugins y medidas a poner en marcha nivel de Apache para mejorar su seguridad, backups, detectar malware, etc.

También mostré varias aplicaciones para detectar rootkits como RKHunter + Unhide (dentro de las opciones, hay una para que mande una alerta por email si detecta alguno) y Chkrootkit. De todas formas, en la página anterior hay comandos útiles para controlar conexiones de Red.

Otra aplicación que puse en funcionamiento es Lynis (sintaxis básica lynis -c). Es práctica para ver de forma rápida el estado general de la seguridad del sistema. Un ejemplo e info.

Siguiendo con Apps de este estilo, cité varias para comprobar la integridad de ficheros o binarios tales como AIDE o Tripwire (Rkhunter también compara los hashes MD5 de ficheros importantes con su firma correcta en una base de datos en línea, aunque puede dar algún “falso positivo).

Otros. Recomendable “JackTheStripper“ por mi compañera en DebianHackers Eugenia Bahit. Es un script para instalar, configurar y asegurar Ubuntu Server. Del gran Forat, su “Project”.

De INTECO CERT su guía en PDF sobre seguridad y Servers (2012). De Tecmint, esta entrada.

Y en DragonJar TV, podéis ver mi demo con varios temas comentados aquí (las diapositivas).

# Disclaimer / Final

David Hernández (Dabo) | @daboblog | www.daboblog.com

“Asume tu grado de exposición y gestiónalo” dije en Jaén. Las soluciones comentadas aquí ayudan, pero un servidor web es inseguro desde la base y como más se aprende, es estando “en ambos lados”. Es el punto de vista que quise compartir en mi Demo, espero que os sea útil.

Muchas gracias a la organización, asistentes, ponentes y patrocinadores de ConectaCon, fue una experiencia para repetir. Debajo, la foto de grupo (el resto), aprendí mucho con vosotros -;)

La entrada original en mi blog, podéis dejar ahí vuestros comentarios. (updated 29/10/2014)

Relacionado: En PDF, “DebianHackers Elementals”, actualizado con alguna explicación más.