PDF de programación - Seguridad y optimización GLAMP. ConectaCon 2013

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

2013

Info y herramientas usadas en mi demo de ConectaCon.



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



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 in