jun 27 2012
Servidores web y respuesta rápida a incidentes. Teoría Vs práctica. (Publicado en INTECO)
Disclaimer: Publicado originalmente en el blog de INTECO.
Existen muchos mitos sobre un concepto tan utilizado en el mundo IT como el de “respuesta rápida a incidentes“. Podemos incluso, realizar todo tipo de planes de contingencia, continuidad de negocio, previsiones y pruebas de concepto, pero en base a las experiencias vividas en mi día a día con los servidores web, a título personal, o junto a mis compañeros de APACHEctl, a pesar de intentar marcar unas pautas comunes de actuación, en la hoja de ruta a seguir cuando todo lo que puede ir mal sucede, en cada caso tienes que añadir una nueva variable.
Es como un teorema en permanente estado de revisión, cuestionamiento y actualización. Obviamente, cuando has preparado un entorno web desde cero, juegas con la ventaja de saber en que terreno te mueves (sabes cómo puede funcionar el proveedor de hosting, la gestión del incidente, tiempos de recuperación, backups, la gestión de la comunicación y posible respuesta del cliente, medios de los que dispones, etc).
Pero en mi opinión, la complejidad reside en un caso muy común y muchas veces olvidado, donde cuando estableces una conexión SSH, tienes la sensación de estar “en tierra de nadie”. En un panorama como el siguiente, no sirven de mucho las teorías, lo que cuenta es crearlas sobre la marcha con la experiencia adquirida en el desarrollo de ese teorema anterior y ponerlas en práctica en el mínimo tiempo posible. Me refiero al caso tipo de:
“Hola, el motivo de mi consulta es porque mi servidor web no va bien y creo que puede estar comprometido”.
Hablamos de escenarios hostiles, las frases hechas como “lo más seguro es quitar el cable de red” son sólo eso, coletillas con un efecto placebo para el usuario. En momentos así, el único mecanismo de defensa frente al pánico del responsable del entorno de producción de turno, es pensar que quizás pueda librarse de verlo parado con las consecuencias que ese hecho pueda tener, tanto para la empresa, como para los usuarios finales.
Y allí estás, frente a una línea de comandos en un sistema GNU/Linux conocido por su arquitectura, pero totalmente desconocido en cuanto a su estado, en el que ya sabes desde antes de empezar que ese día, tu lista de variables aumentará, esperando también que alguna de las almacenadas en memoria funcionen. En medio del fuego cruzado TCP/IP que está entrando y saliendo por el cable de esa máquina, donde tú sólo eres una pieza más del puzzle (olvídate de protagonismos heredados de Hollywood) y los daños colaterales pueden ser grandes.
Siendo consciente, de que eres posiblemente el paso previo a un posterior análisis forense que de hecho, ya lo estás haciendo, aunque sea a un nivel no tan bajo del sistema. Revisando conexiones, logs y alguna vez, compartiendo sesión con quien ha provocado que estés allí.
Y sí, tienes que manejar de la mejor forma posible tanto la gestión del incidente, la comunicación, plan de continuidad, impacto sobre el sistema, grado de intrusión y todo lo que está en la teoría, ya que una decisión errónea, puede ser el desencadenante de una serie de hechos totalmente desafortunados para todas las partes implicadas, el ligero problema, es que debes hacerlo en minutos, o segundos…
Ahí radica la diferencia con “el escenario ideal”, otra frase hecha, pero en esta ocasión para quien se ha esforzado en implementar todos los planes necesarios que comienzan por ISO, el cliente que ha pagado por ello, o para el sufrido “SysAdmin” que también tiene derecho a irse a dormir algún día tranquilo. Cuando ves la (IN) Seguridad como algo natural y estás familiarizado con ella, sabes que todo es susceptible de pasar de “ideal” a “infernal” en cualquier momento y tienes que estar preparado.
Quizás, por ejemplos como este, uno de tantos, si después lees algo acerca de los intentos de criminalización de nuestra profesión, queriendo limitar el uso de herramientas para realizar auditorías de seguridad o tests de intrusión, es cuando piensas que mucha gente vive en universos paralelos, que más bien podrían denominarse, “para lelos”. Hoy, ese teorema, tan inquietante como abstracto, seguirá evolucionando.
Por cierto, no sé cómo acabará, pero empieza con un “Hacking is not a Crime”.
en los casos que comento. Ante las (lógicas) posibles dudas, vamos a apelar a aquello de “pásate por ejemplo” por 
Y de mi actividad principal quería hablaros, servidores, seguridad, clientes, SysAdmins y algún ISP que en lugar de “Internet Service Provider“, bien podría ser un acrónimo de “Internet Sopla Pollas“. Sí, de varios hechos que he podido comprobar con mis propios ojos, algunos adelantados en medio de sensaciones entre el cabreo o la falta de comprensión por mi parte y…ciertamente hacen falta más de 140 caracteres para expresarlo. Eso sí, 140 caracteres son pocos, pero aunque tampoco quiero abusar de vuestro limitado tiempo en medio de una multitarea cada vez más acuciante, reconoceréis que a casi un post por mes, tengo que exprimir un poco el teclado ;)
Este post está dedicado sin mala leche y con cariño, a esos maqueros que tenéis a bien seguirme, a pesar de que sobre Mac apenas publico o comento nada (salvo 
[1] Recuerdo q
