Hola amigos, alguno me pidió que publicase enlaces y algún texto sobre la parte que me tocó a mi (Servidores web y seguridad) en el pasado ESET Foro Internet Meeting Point que se celebró en Gijón.
Foto cortesía de mi gran amigo Fernando (SInLaVeniA), su crónica.
En su momento, hablé más o menos aquí de lo que iba a hablar en esos 30 min que me tocaban a mi en el EFIMP, después, os comenté en esta otra entrada que tendría el placer de compartir mesa con Fernando De La Cuadra (ESET), muchas gracias por todo, además de con un gran amigo Oscar Reixa (Oreixa) que ya ha publicado su parte de la charla (Seguridad en WP y optimización), alguien que no dudo en estar conmigo allí cuando le comenté la posibilidad de hacer algo juntos para la ocasión.
No voy a intentar referenciar o enlazar a todos los amigos que estuvieron allí además de los que conocí “in situ”, porque seguro que me olvido de alguno así que sólo puedo decir que gracias, por todo.
Lo cierto es que el tiempo era justo y después estaba el partido de Paraguay, (que no lo pude ver entero ya que Oreixa tuvo que llevar a Julia a casa por un asunto familiar y me quedé encerrado en su coche 20 min, con radio, eso sí -;) pero quizás contra lo que más tuve que luchar fue contra mi mismo, el Sábado por la mañana andaba todavía con fiebre del gripazo que me pillé unos días antes.
Pude estar ahí gracias a los antibióticos, el Bisolgrip, la excelente organización con su máximo exponente en Ana Fernández Ordíz, tutelada por un gran profesional como Carlos Urioste y a esos grandes amigos que tengo -;).
El Viernes no pude estar por razones obvias, pero desde las 9,30 del Sábado, estuve asistiendo a las interesantes charlas que nos precedían y conseguí “desquitarme” un poco el Sábado por la noche cuando acabó todo y compartí unos cuantos buenos momentos con varios de los participantes del EFIMP.
Me precedieron como os decía Fernando De La Cuadra (ESET) que habló de seguridad local con algunos conceptos fundamentales y Oscar Reixa (Oreixa) que tomó el testigo hablando de seguridad a nivel de WordPress (El CMS más usado de los que estábamos allí) y cuestiones de optimización como podéis ver en el enlace de superior de su parte).
Luego seguí yo hablando de seguridad web a nivel del servidor (cuando publiquen el vídeo lo enlazaré desde aquí), cada ejemplo lo acompañé de una demostración práctica ya que no quería quedarme sólo en la teoría y me basé en experiencias propias usando para ello un par de servidores web dedicados en producción bajo Debian, el mismo S.O que corría en mi MacBook (con KDE 4x). Todo ello dentro de mis limitados conocimientos adquiridos a base de muchas noches intentando “comprender”.
Algún participante comentó que quizás mi parte era muy técnica pero en el programa y donde iba mi ficha de participante ya puse esto “Todo ello apoyado con escenarios reales de ataques web de diversos tipos” y vaya, Internet es tan real como lo que se pudo ver(me quedé corto, os lo aseguro).
Conocer los riesgos o amenazas antes de montar tu flamante negocio online (que se habló mucho de ello) por citar un ejemplo y saber a qué te enfrentas y cómo hacerlo o qué deberías contratar caso de que no quieras pasarte media vida frente un terminal, creo que es fundamental. Ya hablé en esta entrada de la situación inicial en la que te encuentras contratando un servidor virtual/dedicado administrado sólo con un Plesk, DA o Cpanel. Mucha responsabilidad y más riesgo.
Todo ello partiendo de la base de que como dije allí, hablamos de ataques automatizados en la mayor parte de los casos, si esos ataques se realizan de un modo directo por alquien que tenga los motivos, conocimientos o dinero suficiente para llevarlos a cabo, tienes un buen problema ya que de un modo u otro, acabaría por conseguir su objetivo…
Parte 1; Seguridad por oscuridad.
Como complemento a lo que comentó Oreixa a nivel de WordPress, di algún repaso a cuestiones de Apache y PHP frente a posibles ataques automatizados buscando versiones obsoletas como pueden ser las siguientes;
Ocultar la versión de Apache y PHP (con ello también la del sistema operativo a veces y PHP, SSL, etc)
Primero vimos cómo con una simple extensión de Firefox se podía conseguir una valiosa información acerca del servidor web que está ejecutándose en una web, se trata de Server Spy.
En apache2.conf (normalmente estaría en /etc/apache2/apache2.conf) cambiamos los siguientes valores; ServerTokens por defecto está en “Full”, lo cambiamos a “Prod”.
ServerSignature por defecto está en “On”, lo cambiamos a “Off”.
Luego vimos como con esto no es suficiente ya que el “flag” de PHP por defecto revela información acerca de estas cuestiones tal y como se comprobó con una simple petición con curl;
curl -i aqui-la-web.com y mediante la herramienta whatweb con un ./whatweb aqui-la-web.com
Para ello, editamos el fichero de configuración de PHP, php.ini (normalmente en /etc/php/apache2/php.ini)
El valor expose_php por defecto está en “On”, hay que ponerlo en “Off”, esto, además de revelar que está ejecutándose de facto PHP, algo que no es un riesgo para la seguridad realmente, revela la versión de PHP como se pudo ver también mediante una petición con curl, el mismo whatweb o vía un escaneo con nmap del tipo nmap -sS -sV -P0 aquí-la-web.com.
Para que todos estos cambios se hagan efectivos, es necesario recargar la configuración de apache, por ejemplo con /etc/init.d/apache2 reload.
Para testar cómo es nuestra configuración de PHP a nivel de seguridad, aconsejé el uso de phpsecinfo, sólo tenéis que descargarlo y descomprimirlo dentro de la raíz de vuestro site y acceder vía el navegador.
Parte 2; Rootkits, puertos, servicios ejecutándose en la máquina.
Aquí primero hice un par de demos con dos herramientas para buscar Rootkits-Troyanos además de cambios (al estilo Tripwire) en comandos esenciales en el sistema, configuración de algunos servicios y versiones, en este caso rkhunter, además de otra aplicación muy potente como chkrootkit.
También puse algún ejemplo de cómo controlar el estado de las conexiones viendo tanto puertos abiertos como qué servicios se ejecutan en dichos puertos con herramientas como;
iptraf, lsof o netstat o nmap pudiéndose añadir alguno más, varios ejemplos;
netstat -an
lsof -i
ps ax | grep apache | wc -l (Procesos que origina Apache)
netstat -n -p | grep SYN_REC | awk ‘{print $5}’ | awk -F: ‘{print $1}’ | sort | uniq -c | sort -n (Tráfico SYN).
También hablé de la importancia de controlar el tráfico que enviamos o recibimos y además del uso de Munin (que se vio en la parte de Oreixa), puede ser una buena opción el comando vnstat, ejemplos;
vnstat -m (mes)
vnstat -d (dia)
vnstat -h (hora)
Parte 3, diferenciando el tráfico legítimo del no deseado y bloqueo con Mod Evasive.
En esta parte además de hablar de algún ejemplo de picos de tráfico supuestamente legítimos que al final no lo eran tanto (Robots de Yahoo, algún ataque de una Botnet, etc), recomendé para monitorizar en tiempo real el tráfico que llega a nuestras webs, el uso del módulo para Apache Server Status (ahí se puede ver en el sitio web de Apache a Mod Status en acción).
Luego, para los casos en los que sea necesario bloquear picos de tráfico puntuales (más que parar un ataque DoS como se lee mucho por ahí), otro módulo para Apache como Mod Evasive puede ayudarnos, hice una demo del script en Perl que viene con él, (test.pl) para ver cómo bloqueaba un intento masivo de 200 conexiónes a la vez.
Parte 4, acceso al servidor vía SSH, FTP, riesgos y medidas de seguridad.
Hablé de algún consejo para usar con mayor seguridad estos servicios, realizando una demo con Medusa de un ataque de fuerza bruta contra una cuenta FTP y el mejor consejo que pude dar es que no se use como nombre de usuario del FTP, el mismo que tiene la web, para que un ataque de fuerza bruta no sea tan fácil de realizar.
Recalqué lo importante también que es además de cambiar el puerto por defecto del SSH (el 22) y de no usar la cuenta de “root” para conectar vía SSH, revisar los logs del sistema con regularidad ya que este tipo de ataques dejan un rastro fácil de seguir a poco que se observen con atención esos logs (authlog, secure.log, etc).
Para proteger los intentos no deseados de conexión vía SSH, recomendé el uso de DenyHosts (también puede servir Fail2ban) que bloquea tras el número de intentos que definamos una conexión añadiendo la IP a “hosts.dey” y enviando un mail con la IP del bloqueo. También BFD os puede ayudar hablando de ataques de fuerza bruta.
Parte 5, APF Firewall trabajando junto a Iptables.
Para usuarios que no estén familiarizados con el uso de iptables, el firewall por excelencia en sistemas GNU/Linux, recomendé el uso de APF Firewall, puede trabajar junto a paneles como Plesk, CPanel, DA, etc, contando con un fichero de configuración (/etc/apf/conf.apf) muy faćil de interpretar, pudiendo cambiar valores del sistema a nivel de Kernel para paliar ataques DoS (sysctl, etc), descargar listas de IPs maliciosas de lugares como Dshield, etc, recargar la configuración pasado un tiempo (muy válido para DNS dinámicas) o al estilo de “Porsentry” detectar y bloquear un escaneo u otros ataques definiendo los valores deseados TOS o proteger ciertos rangos de puertos previamente definidos.
Hice una demo de ataque (DoS Flood Syn) y detección-bloqueo con una gran herramienta como es Pentbox creada por Alberto Ortega, por cierto, esa demo fue sólo una parte de lo mucho que puede hacer Pentbox.
Parte 6, Mod Security para Apache.
Aquí expliqué algo acerca de las bondades del módulo para Apache Mod Security, potente firewall de aplicaciones y del por qué de su uso en hostings compartidos donde el admin no puede controlar todo lo que instalan o no actualizan sus “inquilinos”. Pero ojo con matar moscas a cañonazos…
Repasé a grosso modo las opciones de detección y bloqueo que se pueden definir en sus extensas reglas (CRS) de ataques XSS, inyección SQL, robots maliciosos, peticiones malformadas HTTP, etc.
Hice una demo de un ataque XSS con bloqueo incluido con la “Hackbar” para Firefox.
Parte 7, control del tráfico y servicios con Logcheck y Monit.
Aquí ya el tiempo apremiaba, como os digo esto fue en 30 min aprox y hablé de Logcheck para estar al tanto cada hora en tu e-mail de todos los avisos relevantes del sistema que rastrea buscando en los logs de un modo tan efectivo Logcheck.
Para monitorizar servicios como SSH, FTP, MySQL, etc, recomendé el uso de Monit que avisa caso de que algún servicio esencial caiga, pudiendo levantarlo o ejecutar un comando previamente definido.
Espero que os pueda ser de utilidad, se podría hablar mucho más sobre todo esto y seguro que mucho mejor, pero creo que puede ser un punto de partida para quienes estén interesados en estos temas.
Tags: Apache, Ataques, CMS, Debian, FIMP, Firewall, GNU/Linux, iptables, iptraf, ModSecurity, nmap, Server Status, Servidor Web, SSH
El concepto de “seguridad por oscuridad” viene ya de lejos. Imagino que, si hablamos de servidores web, nace de la necesidad de protegerse tanto de muchos ataques automatizados que pueden llegar a nuestro servidor web, buscando versiones de software vulnerables, como de la imposibilidad de realizar esas actualizaciones o frente a ataques “0 day”, para los que no hay ningún parche disponible.
Esta entrada no tendría mucha lógica si unos cuantos colegas que usan WordPress, no me he hubiesen hecho llegar la pregunta sobre cómo activar el modo “pantalla completa” en WordPress 3.2.
Como muchos sabéis, 
Bueno, esta vez me tocaba a mi pasar al otro lado del micro y mi amigo Daniel, de 
Hola amigos, iba a currarme una mini-traducción de lo que solventa esta nueva versión 2.8.6 de WordPress, pero 
Vengo de darme una vuelta por 
