Seguridad WSUS de Microsoft a futuro inmediato Rberny 2021
En ambientes informáticos predominantes con Microsoft Server, Windows 10 y Office principalmente y que el volumen de sistemas operativos de esta marca es considerable, muchos de los administradores o gerentes de TI utilizamos su herramienta para las actualizaciones masivas controladas, si bien es cierto es una gran facilidad y a su vez seguro, ya que controlas que descargara y que se distribuirá a los equipos, por supuesto hay muchas otras ventajas que por el momento no mencionaré, ya que en esta ocasión me centraré en que no todos saben que dichas actualizaciones lanzadas se ofrecen a clientes que no cuentan con HTTPS en sus dominios, es decir certificados de seguridad.
En el ciclo de actualizaciones que se avecina en el mes de septiembre de este 2020, la propuesta de la empresa Microsoft, es que propiciaran el descarte de utilización de HTTP con WSUS para futuras operaciones de parcheo, con este artículo pretendo que los profesionales de TI procuren asegurarse y tomen las acciones correspondientes de cambio para que antes de que llegue el próximo día del parcheo masivo que se prevé para el martes 13 de octubre del 2020.
Entonces la idea central, es que Microsoft exige HTTPS para organizaciones que utilizan Windows Server Update Services, por lo que anunció que la instalación de sus actualizaciones de seguridad de septiembre podría evitar que lleguen futuras actualizaciones de software, si las organizaciones que utilizan su solución Windows Server Update Services (WSUS) para la gestión de parches se conectan utilizando el protocolo HTTP en lugar de HTTPS.
Un poco de tecnicismos
Es de conocimiento general que HTTPS agrega el cifrado de seguridad de la capa de transporte a las conexiones del cliente y del servidor web, recuerden que esto se considera un bloqueo contra los llamados ataques de “man-in-the-middle” o manipulación, por lo que la recomendación es que las organizaciones no deberían usar HTTP para conectarse con la red de entrega de contenido de Microsoft para obtener parches y a mi parecer es bastante lógico, no obstante, ¿qué pasa con las organizaciones que pueden tener algunos servidores internos que utilizan HTTP que no se conectan a Internet?, ¿un dilema?, claro que sí y si además están involucrados en la entrega de actualizaciones de software a los dispositivos de los clientes, ahí ya no me siento tan entusiasmado, porque se rompe la cadena de confianza.
De igual manera Microsoft también ha demostrado desconfianza en el uso del proxy de los clientes para obtener contenido de parches para servidores internos que usan HTTP, recomiendo que en su lugar estas organizaciones deberían utilizar el proxy del sistema, ¿Cuál es la razón?, pues que los servidores proxy del cliente están potencialmente sujetos a manipulación, cuando se usa un proxy basado en el usuario, un usuario, incluso uno sin privilegios elevados, podría interceptar y manipular los datos que se intercambian entre el cliente y el servidor de actualización.
Mucho cuidado con esto, se nos está vendiendo una idea un tanto errónea, pues consideran que únicamente con firmar binarios es suficiente y no es así, pienso que es una protección a medias, recordemos que los metadatos de actualización también deben estar firmados por Microsoft, entonces, la protección SSL / TLS puede ser fácilmente ignorada por cualquier WSU intermedio mal configurado que utilice certificados SSL / TLS legítimos, por ejemplo, de StartSSL y es como está ahora, cualquier cliente de Windows puede ser engañado para que ejecute archivos binarios legítimos firmados por Microsoft con parámetros de línea de comandos falsos, de esta manera el propio, WSUS se convierte en un caballo de Troya y puede usarse para secuestrar de manera masiva a todos sus clientes a través de su canal de actualización, no se alarmen, ¿Qué se puede Hacer?
Acciones
La primera acción protege tu entorno WSUS con el protocolo TLS / SSL y configura servidores con HTTPS, segunda configura un proxy basado en el sistema para detectar actualizaciones si es necesario, tercera debemos habilitar la política “Permitir que el proxy de usuario se utilice como respaldo si falla la detección mediante el proxy del sistema”.
¿Cuál será el efecto?, si no se realiza ninguna de estas acciones, los dispositivos de la red con sistema o aplicaciones de Microsoft dejarán de escanear correctamente en busca de actualizaciones de software después de la actualización de seguridad de septiembre de 2020.
En el monitoreo de mis servidores WSUS, no encontré ningún parche hasta el día de hoy 14 de septiembre del 2020, que en particular que activara esta nueva política contra el uso de HTTP con WSUS, el rastro proviene del mes pasado, cuando Microsoft simplemente recomendó el uso de HTTPS con WSUS como un enfoque de seguridad de mejores prácticas, esa si se las creó, sin embargo, el mes de septiembre aún no concluye y tenemos la posibilidad que esta política se cargue en las actualizaciones, y también estoy seguro de que: si Microsoft ya inicio a marcar el camino próximamente solo se permitirá HTTPS para utilizarlo con WSUS como un requisito para seguir recibiendo parches de seguridad.
Leyendo del tema en Microsoft, se menciona que los archivos de políticas del grupo local se actualizarán una vez que tome el parche de septiembre sea implementado, pregunte a algunos colegas que pensaban al respecto y me indican que esta situación crea un gran problema, para los que en gran parte tienen un dominio.local y más si consideran que eso no va a cambiar pronto, entonces sabemos que para configurar HTTPS para WSUS se necesita un certificado, no obstante, recuerdo que no se puede crear un certificado para un dominio.local, de igual manera el certificado debe coincidir con el FQDN del host, que es un nombre de host “wsusVM.midominio.local”, para el que no puede crear un certificado, ¿Qué alternativas hay?, bueno se puede utilizar un certificado interno para https, en su caso, crear una CA interna para los clientes.local, por decir alguna.
Las instrucciones para agregar HTTPS a WSUS pueden resultar bastante complicadas y también requieren obtener un certificado de una autoridad de certificación (Si quieres comprarlo), lo que puede tener un costo adicional y en las notas de Microsoft encontré que también proteger su servidor con TLS puede resultar en una ligera pérdida de rendimiento.
Los que llevamos tiempo trabajando con Microsoft, sabemos de sobra que muchos de los cambios propuestos a manera de mejora, muchas veces o todas obedecen a intereses económicos de sus productos de licenciamiento y no es únicamente lógico, sino que son sus productos, lo cual resulta muy obvio, en el transcurso de los años sé que Microsoft no ha puesto mucho esfuerzo en el desarrollo de WSUS en su versión gratuita, aun cuando no es un producto obsoleto, la postura y recomendación de la marca es que los profesionales de TI deberíamos cambiar a Windows Update for Business, el servicio de Microsoft para administrar las actualizaciones de Windows 10, en lugar de usar WSUS, así como, también recomiendan utilizar Delivery Optimization, un esquema de igual a igual para abordar los impactos de ancho de banda de la función de Windows 10 y las actualizaciones críticas de seguridad.
En esta nota hay muchos términos técnicos que con gusto platicaré contigo si tienes dudas, para lo cual puedes escribirme a mi correo electrónico: [email protected].
Saludos,
Views: 69
