Seguridad en Windows Server 2019

A finales del pasado mes de diciembre, Microsoft publicó un documento titulado What’s new in Windows Server 2019 sobre las nuevas características y funcionalidades renovadas que aportará esta nueva versión de Windows Server. Esta entrada, como no podría ser de otra manera, se centrará en aquellas funcionalidades relacionadas con las mejoras en seguridad que aporta Windows Defender ATP y que ya se habían visto en Windows 10 a través de Windows Defender Exploit Guard, EMET (Enhanced Mitigation Experience Toolkit) que dejó de tener soporte el pasado 31 de julio de 2018, así como WDAC (Windows Defender Application Control).

Conforme se estaba desarrollando la entrada, se fue ahondando en la investigación y esto llevó a un documento mucho más completo sobre ATP, en concreto Windows Defender Advanced Threat Protection. Este post pretende ser un breve resumen ordenado de todo aquello que recogen los múltiples enlaces del documento anteriormente citado.
[Read more…]

Sistemas Windows: Caídas e inicios de servidor

Los administradores de sistemas necesitamos tener constancia en todo momento de: los períodos de tiempo entre caídas de servidor, así como determinar cuando se ha producido una caída o un apagado ordenado de un sistema. En los sistemas Windows, toda esta información se almacena en el Visor de Sucesos, lo cual supone de gran ayuda para entornos no monitorizados. El problema que surge es la escasa “manejabilidad” de este registros de eventos y su extracción de información, por lo que con objeto de facilitar su tratamiento voy a dar información muy básica sobre este sistema, y cómo extraer información de una manera sencilla.

Cada tipo determinado de información viene marcada por un número de Identificador de evento, que indica un tipo distinto de acción en el servidor. Por ejemplo, respecto a las caídas e inicios de servidor podemos observar tres eventos tipo:

Evento 6006, que refleja que se detiene el Registro de sucesos. Esto indica por regla general un cierre ordenado del sistema, aunque evidentemente podría detenerse únicamente el servicio de registro de sucesos:

c:\> net stop eventlog

Tipo de suceso: Información
Origen del suceso: EventLog
Categoría del suceso: Ninguno
Id. suceso: 6006
Fecha: dd/mm/aaaa
Hora: hh:mm:ss
Usuario: No disponible
Equipo: MISERVIDOR
Descripción:
Se ha detenido el servicio de Registro de sucesos.

Evento 6009, que refleja que el servidor ha sido iniciado.

Tipo de suceso: Información
Origen del suceso: EventLog
Categoría del suceso: Ninguno
Id. suceso: 6009
Fecha: dd/mm/aaaa
Hora: hh:mm:ss
Usuario: No disponible
Equipo: MISERVIDOR
Descripción:
Microsoft (R) Windows (R) 5.02. 3790 Service Pack 2 Multiprocessor Free.

Evento 6008. Este evento nos avisa de cuando se produjo una caída inesperada de sistema, lo cual nos proporciona información para poder determinar que otros sucesos ocurrieron entorno a ese hora/día y determinar las causas de la caída del sistema.

Tipo de suceso: Error
Origen del suceso: EventLog
Categoría del suceso: Ninguno
Id. suceso: 6008
Fecha: dd/mm/aaaa
Hora: hh:mm:ss
Usuario: No disponible
Equipo: MISERVIDOR
Descripción:
El cierre anterior del sistema a las hh:mm:ss del dd/mm/aaaa resultó inesperado.

Una vez sabemos dónde tenemos que buscar la información, queda la cuestión de cómo estructurarla. Aunque se pueden aplicar filtros en el Visor de sucesos para la búsqueda de información, a continuación planteo una forma más automatizada para la obtención de dicha información, y a través de la que podremos exportar la información. Para ello utilizaremos lenguaje VBS.

El siguiente script (que obviamente, y como disclaimer previo, deberán utilizar bajo su propia responsabilidad y de cuyos posibles efectos perjudiciales no asumimos responsabilidad alguna) se encarga de realizar un volcado de la información a un fichero .txt. Si bien es cierto que la información volcada al fichero es pequeña, en esta entrada simplemente trato de abrir la puerta a las posibilidades que nos ofrece el hecho de automatizar procesos de obtención de información. El resto se deja como ejercicio para el lector interesado (o necesitado).

REM Definimos la máquina (en este caso local)
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
  & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

REM Creamos fichero para añadir texto
Const ForAppending = 8
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile ("c:\informe.txt", ForAppending, True)

REM Recolectamos los eventos de Sistema con EventID: 6009)
Set colLoggedEvents = objWMIService.ExecQuery _
  ("Select * from Win32_NTLogEvent Where Logfile = 'System' and " _
    & "EventCode = '6009'")

REM Introducimos en el fichero cada una de las lineas obtenidas
For Each objEvent in colLoggedEvents
  objTextFile.WriteLine(objEvent.EventCode & vbTab _
    & objEvent.TimeWritten & vbTab & _
      objEvent.Message)
Next

Al ejecutar el anterior script, en el fichero “informe.txt” tendremos los eventos registrados en el Visor de Sucesos para el evento 6009, Inicio de servidor. Modificando los valores del EventID, dependiendo del tipo de evento que deseemos buscar, o el nombre de la máquina (ya que con un usuario privilegiado en el dominio podriamos acceder a máquinas remotas) obtendremos informes completos sobre las caídas y reinicios de los sistemas de nuestra red, que podremos exportar y tratar de manera más automatizada que visualizando el visor de sucesos.

El resto de aplicaciones y posibilidades se dejan como ejercicio.

Falsos positivos

Esta mañana he tenido que realizar la visita a un cliente. El problema que me comunicó ayer por la tarde es que su navegador web no le mostraba ninguna de las páginas que solicitaba, pero en cambio el cliente de correo funcionaba sin problemas. Curioso, comprobé que no era problema de DNS, ya que el nivel de seguridad estaba configurado igual que en el resto de navegadores que su red local. La única pista que tenía era que suponía que todo se había producido tras una actualización del sistema operativo.

Así que acudo a la cita para solucionar el problema, puesto que se trataba de una persona de cierta responsabilidad y no debía realizar gestiones a través de internet desde otro equipo que no fuera el suyo. Tras darle un par de pensadas y comprobar que efectivamente la configuración de red era la correcta, recordé un caso que me había pasado hace tiempo.

Me dirijo a la configuración del software antivirus (que incorpora funcionalidad de firewall personal) y ahí estaba el problema. Este programa había detectado la actualización del navegador como un cambio en un software que solicita salida a internet, como un si se tratara de un troyano; mi cliente había confiado plenamente en el corttafuegos personal y éste había tomado la decisión por sí mismo de bloquear el ejecutable.

Es necesario recordar algo que se menciona en numerosas ocasiones; este tipo de herramientas, así como las de detección de intrusos y similares, se mueven por patrones de comportamiento, pero es un entrenamiento adecuado de dicho software el que puede conseguir, que por sí solo, se comporte con la inteligencia y la capacidad de decisión que esperamos de él. Mientras esto no sea así, no dejemos de lado al operador humano y echemos un vistazo por si las moscas.

(N.d.E.: Nos van a disculpar si la frecuencia de actualización disminuye —quizá de manera sensible— durante estos días, pero entre el turrón, los Reyes Magos, unas cosas y otras, no sabe uno de dónde sacar el tiempo para todo…)

El justiciero que llevamos dentro

A finales del pasado mes leí un artículo de Raúl Morales titulado “Proponen nodos suicidas para proteger las redes de los hackers”. En él se comentaba la propuesta de la Universidad de Cambridge para la protección de redes descentralizadas o distribuidas: permitir a cualquier nodo de una red terminar con un nodo considerado malo con la contrapartida de que el nodo “ejecutor” se vea obligado a “suicidarse” (desconectarse) como justificación al acto de “eliminación” de ese nodo malo (en pocas palabras, doy mi vida por el bien común).

Hay que remarcar que se trata de una propuesta, y claro, para eso estamos los “chicos” de Security Art Work, para sacarle punta a (casi) todo. Teniendo eso muy en cuenta, ¿qué soporte tiene esta propuesta? ¿No nos lleva a sacar al justiciero que llevamos dentro?

Puesto que los investigadores de Cambridge se basan en la naturaleza para establecer este mecanismo de autodefensa (las abejas atacan con su aguijón perdiendo con ello la vida), se puede establecer como hipótesis de trabajo el argumento contrario basado en la naturaleza humana, por ejemplo, los terroristas suicidas. Al otorgarse total derecho a eliminar nodos malignos sin otro fundamento legal que la obligación de desconectar nuestro propio nodo, esta medida podría utilizarse por parte de grupos criminales con gran capacidad para establecer nodos “nacidos para el suicidio”, de manera que, al amparo de esta propuesta, se dediquen a destruir con carta blanca nodos que realmente no tienen actividad sospechosa o delictiva.

Por otro lado, de sobra es conocida la existencia de mecanismos reguladores para la obtención de licencias de armas, en los que se deben pasar exámenes médicos y psicológicos que ratifiquen nuestra capacitación. Si la libertad de agredir a otro nodo está al alcance de la mano de cualquiera, por muy loable que sea el fin de esta acción, podremos llegar al caso de nodos de “gatillo fácil”, es decir, nodos que no estén lo suficientemente preparados o entrenados para distinguir patrones de ataques que en algunos casos puedan tratarse de falsos positivos (mi nodo pensó que el tuyo era maligno).

Tanto por el hecho de dejar una puerta a la impunidad, como por la capacidad de no estar lo suficientemente preparados para tomar la decisión correcta, considero que debe dejarse en manos de los profesionales la investigación y análisis de las actividades que puedan considerarse delictivas en el entorno de la red, y no delegarla en mecanismos semiautomáticos que pueden fallar o ser utilizados con fines poco dudusos. Porque para ello ya existen las Brigadas de Delitos Informáticos de los distintos Cuerpos de Seguridad del Estado.

En seguridad informática o en cualquier otro aspecto de la vida, más vale prevenir que curar.

¿Es Windows Vista un XP tuneado?

Hace unos días, ví en Computing (nº 514, 9 de mayo) una viñeta en la que un tipo pensaba: “¿Pero el Windows Vista es totalmente nuevo, o han tuneado el XP?”. Eso me recordó la primera impresión que me produjo ver (hace ya algunos meses) el nuevo sistema operativo de Microsoft cuando instalé la beta en el PC de casa. Desde luego parece un XP tuneado, empezando por el diseño más llamativo y el hecho de incluir características de la versión Windows XP Media Center (era la versión Ultimate).

Sin embargo, desde el punto de vista de la seguridad, ¿qué había de nuevo? Evidentemente, puedes pasarte horas dando palos de ciego tocando aquí y allá. Así es que con la Windows Vista Security Guide en mano me puse a explorar.

Como parte del Centro de Seguridad, Windows Vista incorpora varias herramientas de serie (descargables para XP) que se centran en la lucha contra el malware.

  • Windows Defender: con el objetivo de combatir el spyware.
  • Malicious Software Removal Tool: como respaldo al sistema antivirus.
  • Mejoras de seguridad en IE7: que ayuda a neutralizar actividades como el Phising.

Por otro lado, en el ámbito de la protección de los datos, presenta la herramienta BitLocker Drive Encryption, en las versiones Enterprise y Ultimate (pero no en la Business, una lástima). BitLocker es la forma que nos ofrece Vista de proteger una estación de trabajo mediante un PIN o con una clave en una memoria USB, por lo que parece un mecanismo interesante para los usuarios móviles, más vulnerables a sufrir sustracciones.

Además de lo enumerado anteriormente, existen otras herramientas mejoradas en el ámbito de la seguridad, como el hecho de soporte para IPSEC en el Windows Firewall, etc.

Evidentemente, a efectos estéticos el Vista ha quedado más tuneado que el XP, pero a efectos de seguridad, se ve que el esfuerzo realizado para proteger el sistema es mayor y que hace adquirir una mayor conciencia al usuario y administrador del sistema de la importancia de mantener un sistema protegido y actualizado.

Dude

thedude.jpgHace unos días, buscando información en Internet, me topé con una herramienta llamada The Dude que se ejecuta en plataformas Microsoft Windows. Al verla no pude dejar de pensar en Nagios y en la solución que podría suponer para ciertos administradores de sistemas que no cuentan (o no quieren contar) con sistemas Linux en los entornos que gestionan.

La herramienta proporciona un mapa de red gráfico que nos indica con un código semafórico el estado del hardware, un sistema de notificaciones mediante pop-ups en el equipo donde reside la aplicación o mediante el envío de correo electrónico. Aunque el número de servicios a monitorizar es (hasta donde ví) muy limitado, es posible parametrizar los existentes y crear nuevos.

Actualmente, la versión estable es la Dude v2.2, pero ya existe en beta la versión Dude v3.0 beta 6. ¿Alguien se anima?

Boletín de seguridad Microsoft para Mayo 2007

El pasado 8 de mayo, Microsoft publicó su boletín de seguridad para el mes de Mayo. Las actualizaciones, que pasamos a referir a continuación, corrigen problemas de ejecución de código remoto.

Tres de las actualizaciones publicadas solucionan vulnerabilidades de la suite Office MS07-025 (934873) y de dos de sus aplicaciones, en concreto Word MS07-024 (934232) y Excel MS07-023 (934233). El software afectado es el de la versión 2000 y superior.

En los entornos de servidor tenemos tres vulnerabilidades, nuevamente, de Ejecución de Código, una para la plataforma Exchange MS07-026 (931832), otra para servidores de DNS MS07-029 (935966), y por último para el producto BizTalk MS07-028 (931906).

Por último, y como no podía ser menos, la joya de la corona: Internet Explorer. Actualización que se aplica en todas las plataformas, desde 2000 a Vista, y todas sus versiones, desde la 5.01 hasta la 7, MS07-027 (931768).

Como es habitual, antes de aplicar ningún parche debemos cerciorarnos de tener instalado en nuestro sistema el último Service Pack para el software que vamos a actualizar, y determinar que la actualización es necesaria en nuestro sistema. Una buena forma de comprobación es el uso de Windows Update o la herramienta MBSA.

La aplicación de actualizaciones acompañadas de sistemas de detección de software dañino, junto con unas pocas prácticas seguras, ayudarán a mantener la seguridad de nuestro sistema.