Orquestación de sistemas Linux. Ejemplo con Nmap.
Seguimos con la orquestación de sistemas, como empezamos a ver en el primer artículo de la serie.
Vamos a realizar una pequeña prueba de concepto para configurar sistemas Linux de la misma manera que lo hacemos con sistemas Windows.
Pongamos un ejemplo. Administras la infraestructura virtual de una empresa que se encarga de realizar auditorías de seguridad. Tienes un pool de becarios :-) de 30 personas. Cuando una persona se incorpora al departamento, se le asigna una máquina virtual con una distribución de Linux, a la cual hay que añadirle la colección de herramientas necesarias para su trabajo. Una de las herramientas que necesita es Nmap, siempre usando la última versión, como pueda ser el caso de Nmap 6.40. El proceso de instalación de Nmap lo podemos hacer en el disco duro virtual plantilla que usamos para distribuir las VM, pero en este caso queremos tener la posibilidad de que sea el trabajador el que demande la instalación del aplicativo, con el fin de trazar mediante gestión de servicio el tiempo que ha empleado en ello, o si lo hubiera, documentar problemas conocidos para esa versión de Nmap en su distro...
Para este ejemplo de Nmap, no tiene mucho sentido, ya que la instalación consume no más de 2 minutos, y se supone que cualquier operario de sistemas Linux puede hacerlo. Y si pensamos en que ese becario deba instalar una instancia de Oracle de pruebas en su sistema para realizar pruebas y demás? No tiene sentido que un auditor de sistemas invierta su tiempo en instalar Oracle en su máquina, ni que el sysadmin lo haga, mejor que se haga automáticamente, bajo petición del usuario.
Vamos a crear un Runbook con System Center Orchestrator que va a descargar e instalar Nmap en el equipo que indiquemos.
El fichero que voy a probar para lanzar el script es este.
wget http://nmap.org/dist/nmap-6.40.tar.bz2
bzip2 -cd nmap-6.40.tar.bz2 | tar xvf -
cd nmap-6.40
./configure
make
su root
make install
cd ..
rm nmap-6.40.tar.bz2
exit
Añadimos una notificación por E-Mail, como hicimos en post de iniciación de Orchestrator.
Mientras creamos y preparamos el Runbook, metemos a un recipiente de horno:
Google +
Vamos a realizar una pequeña prueba de concepto para configurar sistemas Linux de la misma manera que lo hacemos con sistemas Windows.
Pongamos un ejemplo. Administras la infraestructura virtual de una empresa que se encarga de realizar auditorías de seguridad. Tienes un pool de becarios :-) de 30 personas. Cuando una persona se incorpora al departamento, se le asigna una máquina virtual con una distribución de Linux, a la cual hay que añadirle la colección de herramientas necesarias para su trabajo. Una de las herramientas que necesita es Nmap, siempre usando la última versión, como pueda ser el caso de Nmap 6.40. El proceso de instalación de Nmap lo podemos hacer en el disco duro virtual plantilla que usamos para distribuir las VM, pero en este caso queremos tener la posibilidad de que sea el trabajador el que demande la instalación del aplicativo, con el fin de trazar mediante gestión de servicio el tiempo que ha empleado en ello, o si lo hubiera, documentar problemas conocidos para esa versión de Nmap en su distro...
Para este ejemplo de Nmap, no tiene mucho sentido, ya que la instalación consume no más de 2 minutos, y se supone que cualquier operario de sistemas Linux puede hacerlo. Y si pensamos en que ese becario deba instalar una instancia de Oracle de pruebas en su sistema para realizar pruebas y demás? No tiene sentido que un auditor de sistemas invierta su tiempo en instalar Oracle en su máquina, ni que el sysadmin lo haga, mejor que se haga automáticamente, bajo petición del usuario.
Vamos a crear un Runbook con System Center Orchestrator que va a descargar e instalar Nmap en el equipo que indiquemos.
El fichero que voy a probar para lanzar el script es este.
wget http://nmap.org/dist/nmap-6.40.tar.bz2
bzip2 -cd nmap-6.40.tar.bz2 | tar xvf -
cd nmap-6.40
./configure
make
su root
make install
cd ..
rm nmap-6.40.tar.bz2
exit
Añadimos una notificación por E-Mail, como hicimos en post de iniciación de Orchestrator.
Probamos el test del Runbook y si todo ha ido bien...
Habría que tener en cuenta varios aspectos de control del proceso, que seguro los lectores de perfil programación detectarán al instante. Uno de ellos es los TimeOut de la conexion SSH.
Para procesos complejos, deberíamos modular el Runbook realizando un conjunto de operaciones de manera controlada, es decir, con transacciones y posibilidad de hacer rollback. Hasta que el proceso RunSSH no acaba, no nos va a enviar ningún código de estado, por lo que en el primer fallo en una secuencia de comandos, provocaría la ejecución eterna del paquete.
Intentaremos en próximos artículos hablar del conjunto de buenas prácticas en el diseño de Runbooks. Ahora mismo con que funcionen las cosas es suficiente :-)
Vamos a modificar un poco el paquete. Vamos a cambiar la variable de entrada, siendo esta la ip de un equipo al que vamos a realizar un port scan. Dejamos la ip del equipo SSH fija, este sería el equipo atacante. En el apartado de Run SSH command, metemos la variable que hemos iniciado, y en cuerpo del mensaje, configuramos que muestre el resultado de la ejecución.
Las posibilidades son muchas. Ahora mismo, con la ejecución de este Runbook no ganamos nada. Pero imaginemos un entorno de pentesting, en el que no está permitido el uso de Nmap directamente contra un destino, o se requiere de una autorización previa. Podemos usar las características de Orchestrator con Services Manager para crear el flujo de petición/aprobación/ejecución para cumplir con las políticas del Services Desk...Podemos integrar el Runbook con Operations Manager para realizar reporting, y saber el tiempo que se invierte en esta tarea...Conectaremos el Runbook el entorno de SelfServices que vimos en el anterior post para publicar el servicio, etc.
Imaginemos que exportamos ese resultado a un fichero en red. Podemos anidar varios Runbooks... Intentaremos crear en Inseguros un Runbook denominado "PenTest, the final solution"para parametrizar al máximo los procesos de un PenTest, usando herramientas de varios sistemas, para conseguir parametrizar al máximo el trabajo, al menos el de adquisición de información.
Como siempre, gracias por leerme, y espero que os gusten esta serie de artículos sobre automatización.
Mientras creamos y preparamos el Runbook, metemos a un recipiente de horno:
- 5 huevos.
- 200 ml nata líquida.
- 5 rebanadas de pan de molde sin corteza.
- un poco de sal.
- 200 gr de tu queso favorito (dados, rayado).
Y con el horno caliente a 200 º, metemos el invento y lo dejemos unos 30 minutos, hasta que veamos que tenemos el pastel. Enjoy !!!
