| Artículos | 01 JUL 2007

No nos podemos fiar de nadie

Tags: Histórico
Daniel Matey.
Puede parecer un tanto paranoico, pero sin duda nuestras redes están expuestas a un buen número de amenazas, tanto externas como internas. Usamos herramientas como cortafuegos, encriptaciones, políticas, auditorias de vulnerabilidades, sistemas de actualizaciones de parches o software antimalware para minimizar estos riesgos de seguridad dentro y fuera de las redes, pero el uso de éstas y otras medidas, aunque nos protege, no aporta una seguridad absoluta de que nuestra red no pueda verse comprometida, o de lo que es peor, que no lo haya sido ya.

Aunque no hay que escatimar esfuerzos en intentarlo, es prácticamente imposible diseñar un sistema invulnerable, pero, sin embargo, en caso de que queramos saber si nuestro sistema ha sido atacado y el atacante tubo algún éxito, tendremos que implementar sistemas de auditoría y de informática forense que nos permitan analizar los eventos de seguridad que se producen en nuestra red, con la certeza de que no han sido alterados. Este tipo de sistemas nos ayudarán también en uno de los retos más difíciles a los que se puede enfrentar todo responsable de seguridad: protegerse de los propios administradores.
En todas las empresas hay administradores que disponen de los privilegios suficientes como para alterar las medidas de protección instauradas, con el fin de acceder a datos que la empresa prohíbe. La única forma final de protegernos de este riesgo es contar con sistemas que auditen los eventos de seguridad, garanticen que serán almacenados sin haber sido modificados, y además lo hagan en el plazo de tiempo más cercano posible al momento en el que fueron disparados. Indudablemente, todos los datos procedentes de la auditoria han de ser almacenados en un repositorio con un acceso lo más restringido posible, tratando de separar el rol del administrador del rol del auditor.

Microsoft Auditory Collection System
MSACS es un producto que ha tardado mucho tiempo en ver la luz. De hecho, hace ya años que vimos las primeras betas. Inicialmente pretendía ser distribuido gratuitamente como un Feature Pack para Windows Server 2003, pero posteriormente, durante pruebas tanto en clientes como en la propia Microsoft, se vio que los retos a los que se enfrentaba el producto eran tan grandes que era necesario más tiempo para su desarrollarlo.
Pensemos, por ejemplo, en los controladores de dominio de cualquier empresa. Cada usuario que accede al dominio, cada intento de contraseña fallida o intento de abrir objetos auditados, provocará al igual que una gran cantidad de situaciones, eventos de seguridad. De esta forma, un sistema que recolecte estos eventos puede acabar lidiando con varios TB de información en el plazo de un mes. Si además queremos que esta información se almacene centralizadamente, el sistema habrá de enfrentarse a una cantidad increíble de inserciones en la base de datos, con una concurrencia realmente alta.
Por todas estas razones, Microsoft tardo más en sacar el producto al mercado, pero ahora, MSACS está disponible dentro de Microsoft System Center Operations Manager 2007 (SCOM, del que hablamos el recientemente en esta misma sección de PC World).

La Arquitectura y el dimensionamiento de ACS
ACS tiene tres componentes, MSACS Forwarder, MSACS Collector y la base de datos de MSACS.
Forwarder es un servicio de Windows (ACSFwdr) que corre en los puestos y servidores en los que se quieren recolectar los eventos, y forma parte del agente de SCOM. El agente puede correr sobre Windows 2000, Windows Server 2003, XP o Windows Vista. Aunque Forwarder está incluido en el agente SCOM, por defecto no está habilitado, así que, en caso de querer usarlo, tendremos que activarlo de forma manual.
Forwarder puede estar instalado en máquinas localizadas en oficinas remotas, dado que todo el tráfico está comprimido. En situaciones normales no se requiere mucho ancho de banda, y su único requisito es que la conexión sea continua, ya que MSACS no puede programar los envíos.
Collector recibe, procesa y filtra los eventos de los forwarders, y los manda a la base de datos. El colector tiene que ser miembro del dominio y, dado que recibirá mucha información, conviene que sea una máquina potente (recomendamos máquinas con procesadores duales, en la ayuda de SCOM hay una fórmula que nos ayuda a calcular la cantidad de RAM necesaria para cada entorno).
Base de datos es el repositorio donde se centralizan todos los eventos, y del que saldrá la información para los informes. En redes grandes, estaremos hablando de servidores con 4 microprocesadores y 4 GB de memoria RAM, aunque no estaría mal disponer de 8 GB extra, en caso de que necesitemos obtener informes interactivamente.
La base de datos puede ser SQL Server 2005 Estandar o Enterprise. Hay una gran diferencia entre usar una versión o la otra, ya que MSACS realiza un proceso de mantenimiento que incluye la re indexación de los datos todos los días a una hora concreta. Si usamos la versión Estándar, durante este proceso los Forwarders y el Collector tendrán que almacenar los eventos recopilados en buffers locales, y posteriormente enviarlos a la base de datos cuando ya se haya terminado con el proceso de mantenimiento.
Si optamos por Enterprise, será posible introducir eventos en la base de datos mientras se ejecuta este proceso, ya que esta modalidad sí permite la escritura en la base de datos durante este tipo de operaciones.
El dimensionamiento de los discos dependerá del número de días que se quieran almacenar en línea. Nosotros recomendamos no mantener en línea más de 15 días, y disponer, eso sí, de copias de la información anterior, por si fueran necesarias para alguna investigación posterior. A la hora de diseñar los RAID y escoger un sistema de almacenamiento, conviene valorar que el patrón será mayoritariamente de escrituras, cortas pero muy continuadas.
Hay que tener en cuenta que, según declara Microsoft, monitorizar 15.000 máquinas puede producir unos 8 TB de datos en tan sólo 30 días.

Los Eventos
Tal y como se puede ver en la imagen 2, los eventos tienen tres partes. En primer lugar, nos encontramos con la cabecera, en la que se pueden ver datos como el identificador del evento, la fuente, la hora, la categoría y el ordenador en el que se produjo el evento.
Posteriormente tenemos la plantilla, que rige los campos que podemos encontrar dentro de los datos. Por esta razón, a la hora de almacenar un evento, no es necesario guardar todo su contenido, dado que los títulos de los campos están en la plantilla, y puede ser guardada una única vez. Estas plantillas pueden estar en varios idiomas y pueden cambiar para el mismo evento de unos sistemas operativos a otros. MSACS se encarga de unificar todas las plantillas al formato de Windows Server 2003.
La última parte de un evento son los datos. Aquí es donde se almacenan los datos reales del evento, y donde podremos ver qué es lo que realmente sucedió.
Si analizamos los eventos de un sistema Windows, nos encontraremos con dos tipos diferenciados, por un lado tendremos los eventos del propio sistema operativo (o los servicios y aplicaciones que corran sobre él), y por otro los eventos de seguridad y auditoría. En el primer tipo lo importante será el evento en sí, la cabecera, mientras que en los eventos de seguridad lo más importante son los datos. Así, SCOM, que se encarga de monitorizar sistemas en general, hace un buen trabajo recolectando todo el evento, pero esta forma de trabajar no sería la m

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información