Siguiendo con la visita que @Daboblog nos hizo al S3Lab, habíamos hablado de los plugins que utilizamos para empezar a auditar con tan solo navegar. Después de esto, nos mostró herramientas para auditar wordpress o joomla (los sistemas más utilizados para publicar webs). Las herramientas eran wpscan para wordpress y joomscan para joombla. Estas herramientas se utilizan para localizar las versiones de los gestores de contenido, posibles archivos de elementos sensibles y versiones de los plugins instalados.Para otras plataformas, también nos enseñó que existían herramientas, como whatweb, OpenVas, ZAP, W3af o nikto. Estas herramientas son extremadamente minuciosas a la hora de buscar elementos que afectan a la seguridad del servidor, pero tiene el problema que no todas son tan inocuas como la simple navegación web. Aun así, son unas herramientas a tener muy en cuenta para mantener la seguridad del sistema.
Pero claro, una vez que ya hemos obtenido cierta información sobre el sitio web y su servidor, es necesario determinar la gravedad de la vulnerabilidad. Dabo nos mostró el proyecto OWASP y que es una buena metodología la catalogación de las vulnerabilidades en base a este proyecto.Ya que habíamos visto algunas de las herramientas necesarias para hacer auditorías a servidores web y en base a que metodología mostrar los resultados, ahora tocaba la parte de pentesting. Vimos ataques en tiempo real contra sus servidores. Algo temerario, pero muy visual e instructivo. Empezamos con nmap y un parámetro que me gustó mucho debido a la información que nos brinda, -sC. Vimos que el servidor nos daba toda la información sobre los puertos, por lo que, como dijo Dabo, es como no tener firewall. Modifico la configuración del firewall y de los IDS-IPS para que al hacer otro nmap, la información fuera nula. Utilizamos la herramienta hydra para atacar mediante fuerza bruta su servidor mediante el puerto ssh y ftp. También la herramienta hulk para hacer una denegación de servicio. Ninguna de las dos funciono debido a que él tenía bienurado Apache para evitar ataques de fuerza bruta y DDoS. Todo ello, con una simple revisión a fondo de la configuración de Apache.
Todos estos ataques fueron registrados por los sistemas de logs con la IP, la hora y que se atacaba. Los logs, son otro de los grandes pilares de la seguridad en servidores. Los logs que nos enseñó Dabo abarcaban tanto los de tiempo real como los históricos. Esto mostraba una radiografía completa de todo lo que había sucedido con el servidor, algo muy importante para su optimización, para aprender nuevos ataques y para gestionarlo. Por otra parte, algunos ataques podían tumbar algunos servicios críticos como Apache o MySQL, pero la herramienta Monit, mitigaba ese problema volviendo a levantar el servicio. Para evitar muchos de los nuevos ataques o fallos de seguridad en el propio kernel vimos cómo funcionaba grsecurity y las comparativas con otros sistemas como SELinux o AppArmos. Estos ataques controlados nos dejaron una idea clara, un atacante hace lo posible para que no se le pueda detectar o al menos, hacerlo lo más difícil posible su detección. Para anonimizarse, los atacantes suelen utilizar la red TOR. Nosotros vimos Tails, un sistema operativo basado en Debian para navegar de manera anónima en el cual se pueden instalar todas las herramientas que hemos visto.
Para el último día nos reservó una sorpresita. Teníamos una máquina virtual con un Debian y apache montado. No enseño la herramienta maldetect que buscaba malware en páginas web. Instalamos la aplicación y, al poco tiempo de haberla ejecutado, diciéndola la ruta donde se alojaban las webs, nos encontró un elemento sospechoso. A primera vista era un archivo .htaccess, pero como la herramienta maldetect nos lo había marcado como malo, y el comando file nos decía que era un script php, la cambiamos la extensión a php y sin darnos cuenta, Dabo nos había metido un rootkit en nuestro servidor. Además, estaba codificado, lo que hacía un poco más difícil su detección. Al final, a lo tonto, aprendí bastante sobre los servidores, el poco tiempo que se les dedica para ponerlos en condiciones, lo sencillo que es configurarlos, los diferentes tipos de ataques que se realizan contra ellos y los potentes y necesarios que son los sistemas de logs. También aprendí bastante sobre las diferencias entre los tipos de servers, conceptos como escalabilidad o disponibilidad y laconfigimportancia tanto de elegir una buena base para el servidor en el proceso del desarrollo web, como la importancia de saber auditar no sólo de forma externa mediante herramientas Software, sino también configuraciones críticas del server.
Fue genial tener a Dabo compartiendo sus conocimientos y “engorilandose” contra sus propios servidores. Es una experiencia magnifica que te enseñen los mejores lo que hacen, como lo hacen y, que además lo hagan de manera práctica.
Un placer Dabo, esperamos verte pronto de nuevo.
