Auditando tu política de actualizaciones con terceras partes. Nessus Home
En este artículo vamos a hablar de la auditoría de las actualizaciones de productos administrados bajo WSUS con una herramienta, Nessus.
La idea es sencilla. Si administras una infraestructura en la que dispones de sistemas operativos Windows, y algún que otro servidor... tendrás instalado WSUS, el servicio de actualizaciones para los productos Microsoft, como puedan ser el propio sistema operativo, Office, Sql Server, Sharepoint etc etc.
Constantemente hablamos de la necesidad de controlar los sistemas en profundidad Como halábamos en otra entrada, debemos considerar implementar una política de escaneo de vulnerabilidades continua, que nos permita tener una visión global del estado de nuestros sistemas, en lo que a nivel de parcheo, configuraciones por defecto y obtención de información se refiere, que es lo que considero que aporta un test de vulnerabilidades.
Vamos a usar Nessus en versión home para auditar un equipo, en cuanto a nivel de parcheo se refiere. No vamos a escanear el equipo en cuestión, sino que vamos a consultar al servidor WSUS el estado del equipo.
Si realizamos una auditoría autorizada a un equipo, y le pasamos las credenciales válidas para conectarse, Nessus trata de obtener la versión de la librería implicada en la actualización que trata de comprobar. Esta acción es directa contra el equipo, y puede que no sea 100% efectiva.
El por qué realizar una auditoría de este tipo? Se me ocurren muchas razones. Imaginemos el caso de una empresa en la que la administración de los servidores la lleva a cabo una empresa contratada. Imaginemos el caso de que tienen un acuerdo de nivel de servicio. Imaginemos que fallan las actualizaciones en un segmento de equipos y que por este motivo se produce una infección y se acaba el mundo... Contar con unos informes en los que se almacene el estado de las actualizaciones puede sernos útil.
Una razón sería usar esta información en un proceso de post-explotación en un test de intrusión en el que tenemos acceso a una cuenta local, en un servidor corriendo WSUS, y en el que sin duda obtendremos mucha información útil del estado de los equipos sin tener que actuar directamente contra ellos.
Otra razón simplemente sería la de tener un indicador más de rendimiento del servicio.
Lo primero que debemos hacer es configurar una Política o Policies. Como el propósito de este test no es saber los puertos abiertos, vulnerabilidades, etc desmarco todas esta opciones. En preferencias seleccionamos Patch Management: WSUS Server Settings y configuramos los datos del servidor WSUS. En Plugins, los que muestro. Un consejo, desmarcar todos los plugins, y mediante un filtro, buscar por "contiene la palabra Wsus".
Podemos incorporar el Plugin Bulletins. Este Plugin identifica el KB concreto de la actualización con toda su descripción. Sería el que usaríamos en un test normal, contra el equipo directamente, y proporcionándole credenciales. No es el caso. La única diferencia entre activarlo o no sería que en el resultado del Report, si lo incluimos, nos aparecerá una vulnerabilidad por cada actualización que no se encuentre aprobada pero no instalada, mientras que si no usamos el Plugin Bulletins, en el Report nos aparecerá solo una "vulnerabilidad" del tipo Info. con el resumen de actualizaciones no instaladas.
Es decir, veríamos esto con Bulletins:
La idea es sencilla. Si administras una infraestructura en la que dispones de sistemas operativos Windows, y algún que otro servidor... tendrás instalado WSUS, el servicio de actualizaciones para los productos Microsoft, como puedan ser el propio sistema operativo, Office, Sql Server, Sharepoint etc etc.
Constantemente hablamos de la necesidad de controlar los sistemas en profundidad Como halábamos en otra entrada, debemos considerar implementar una política de escaneo de vulnerabilidades continua, que nos permita tener una visión global del estado de nuestros sistemas, en lo que a nivel de parcheo, configuraciones por defecto y obtención de información se refiere, que es lo que considero que aporta un test de vulnerabilidades.
Vamos a usar Nessus en versión home para auditar un equipo, en cuanto a nivel de parcheo se refiere. No vamos a escanear el equipo en cuestión, sino que vamos a consultar al servidor WSUS el estado del equipo.
Si realizamos una auditoría autorizada a un equipo, y le pasamos las credenciales válidas para conectarse, Nessus trata de obtener la versión de la librería implicada en la actualización que trata de comprobar. Esta acción es directa contra el equipo, y puede que no sea 100% efectiva.
El por qué realizar una auditoría de este tipo? Se me ocurren muchas razones. Imaginemos el caso de una empresa en la que la administración de los servidores la lleva a cabo una empresa contratada. Imaginemos el caso de que tienen un acuerdo de nivel de servicio. Imaginemos que fallan las actualizaciones en un segmento de equipos y que por este motivo se produce una infección y se acaba el mundo... Contar con unos informes en los que se almacene el estado de las actualizaciones puede sernos útil.
Una razón sería usar esta información en un proceso de post-explotación en un test de intrusión en el que tenemos acceso a una cuenta local, en un servidor corriendo WSUS, y en el que sin duda obtendremos mucha información útil del estado de los equipos sin tener que actuar directamente contra ellos.
Otra razón simplemente sería la de tener un indicador más de rendimiento del servicio.
Lo primero que debemos hacer es configurar una Política o Policies. Como el propósito de este test no es saber los puertos abiertos, vulnerabilidades, etc desmarco todas esta opciones. En preferencias seleccionamos Patch Management: WSUS Server Settings y configuramos los datos del servidor WSUS. En Plugins, los que muestro. Un consejo, desmarcar todos los plugins, y mediante un filtro, buscar por "contiene la palabra Wsus".
Podemos incorporar el Plugin Bulletins. Este Plugin identifica el KB concreto de la actualización con toda su descripción. Sería el que usaríamos en un test normal, contra el equipo directamente, y proporcionándole credenciales. No es el caso. La única diferencia entre activarlo o no sería que en el resultado del Report, si lo incluimos, nos aparecerá una vulnerabilidad por cada actualización que no se encuentre aprobada pero no instalada, mientras que si no usamos el Plugin Bulletins, en el Report nos aparecerá solo una "vulnerabilidad" del tipo Info. con el resumen de actualizaciones no instaladas.
Es decir, veríamos esto con Bulletins:
Y esto como resumen si no añadimos ese plugin.
Como podéis ver, muestra en el resumen para ese equipo 58 Parches no instalados. Lo mismo que me dice WSUS.
Si está acostumbrado a usar WSUS sabrás que su fuerte no es el Reporting. Puede que en determinadas ocasiones saber si un grupo de equipos tiene instalada una actualización concreta puede ser ardua tarea.
A eso le sumamos la facilidad de usar Nessus para almacenar el estado de actualizaciones para un determinado momento.
Lo que no he podido hacer es configurar una programación para este escaneo, paralela a la política de Microsoft de segundos martes del mes...
Sin duda me parece necesario el control de parches de nuestros sistemas, y de esta manera, podemos controlar si lo estamos haciendo bien o tenemos algún problema con el servicio.
Como siempre, gracias por leerme y espero que te guste el artículo.
