Alejandro sierra munera pontificia universidad javeriana facultad de ingenieria



Descargar 296.24 Kb.
Página4/5
Fecha de conversión11.01.2017
Tamaño296.24 Kb.
1   2   3   4   5

DC. Domain Controller

Un DC es responsable de controlar y mantener las actividades del dominio. Más específicamente responde a solicitudes de autenticación, y de chequeo de permisos.


En un DC están [30]:

  • Una copia física de la base de datos Active Directoty

Un Active Directory esta compuesto por

    • LDAP

    • X.500

    • DNS

    • Kerberos

  • Servicios de Registros

    • Kerberos

    • LAN Manager Authentication

  • Adicionalmente sirve como servidor DHCP.


Servidor de Archivos
Servidor de Impresión.
Exchange:

Servidor de correo electrónico basado en PC.


SQL Server

Servidor de base de datos basado en PC


IIS

Servidor Web basado en PC


Servidor de Seguridad/VPN (ISA Server)
Punto de Acceso Inalámbrico

        1. Servicios de la red típica de una PyME y sus principales implementaciones

Con base en los componentes definidos en [29], una red típica de una PyME tendría los siguientes servicios:

  • Servidor de Autenticación

  • DNS

  • DHCP

  • Servidor de Archivos

  • Servidor de Impresión

  • Servidor de correo electrónico

Según estadísticas de [33] los 3 servidores de correo más usados son:

    • Microsoft ESMTP MAIL Service

    • Sendmail

    • Imail

  • Servidor o manejador de bases de datos

  • Servidor Web

De acuerdo con [31] los tres servidores Web más usados en Agosto de 2006 son:

    • Apache.

    • Microsoft IIS.

    • Zeus Web Server.

Cubriendo entre los 3 un 93,21% de los encuestados.

  • Servidor VPN + Firewall

Según [32] la industria de los Firewalls con VPN integrados ha crecido notablemente; “es el tercer segmento más grande dentro del software de seguridad”. También aseguran que según un estudio de Infonetics Research, Cisco System es la empresa líder en este mercado seguida por Check Point Software Technologies. Sumando entre ambas un 59,2% del mercado.

  • Access Point inalámbrico

  • Enrutador hacia Internet



  1. REQUERIMIENTOS PARA LA GESTION CENTRALIZADA DE LOS REGISTROS DE EVENTOS DE SEGURIDAD

De acuerdo con los requisitos definidos anteriormente (sección 2.2) para realizar el proceso de correlación, y para mantener el carácter de evidencia digital de los registros de eventos, se definen los requerimientos propios para la gestión centralizada de éstos.


Estos requerimientos se clasifican en requerimientos funcionales y requerimientos no funcionales. Los funcionales son aquellos que se definen la interacción entre el sistema y sus usuarios u otros sistemas, independiente a su implementación. Mientras que los no funcionales, son aquellos que describen aspectos del sistema visibles por el usuario pero que no se relacionan en forma directa al comportamiento funcional del sistema. [35]

      1. Requerimientos funcionales

  • Los registros de eventos deben quedar en un punto central.

  • Es necesario garantizar que los registros de eventos queden todos en un solo formato polimórfico para su correlación.

El formato por lo menos debe tener

    • Identificación del sistema que generó el evento

    • Estampilla de tiempo

    • Detalle del evento

  • Debe existir un proceso de reducción de datos para el proceso de correlación.
    Con esto se busca la eficiencia en la correlación y se puede hacer mediante:

    • Compresión de datos

    • Borrado de duplicados

    • Filtrar datos combinando varios eventos relacionados en uno solo.

  • Las estampillas de tiempo de los registros de eventos deben estar sincronizadas y deben incluir por lo menos la fecha y hora en la que se generó.

  • Los registros de eventos deben tener algún mecanismo de identificación del sistema o tecnología de información que los generó para efectos de su utilización como evidencia digital.

      1. Requerimientos no funcionales

  • Se debe utilizar un método de transporte confiable.

    • El método de trasporte debe ser orientado a conexión

    • Debe garantizar la integridad de los datos.

    • Debe mantener algún mecanismo de autenticación

    • Los datos deben estar cifrados durante el transporte.

  • Se debe utilizar algún mecanismo de autenticación con respecto al sistema que los generó.

  • Se debe asegurar que no se perdió, ni cambó ningún dato en los registros de eventos para su uso como evidencia digital.

  • Se debe verificar que el sistema esté en correcto funcionamiento en el momento en que se generan o modifican los registros.

  • Los registros de eventos de seguridad, debe poder ser utilizados en tiempo presente y futuro.

    • Esto se refiere a que la forma de almacenamiento debe poder ser consultada en el futuro y en el presente.




      1. Diagrama de Red típica de una Pyme.

De acuerdo al análisis realizado de la red de una pyme, se determina que el esquema de red que define apropiadamente la red típica de una pyme es como se muestra en la figura 8.

Figura 9. Diagrama de una Red típica de una pyme



        1. Logs de Seguridad en una Pyme

De acuerdo con la clasificación de NIST [34] podríamos encontrar los siguientes logs de seguridad en una Pyme:
Logs de Aplicaciones de Seguridad

  • Logs de Servidor de Autenticación

  • Logs de VPN+Firewall

  • Logs de Antivirus/Antimalware


Logs de Sistemas Operativos (estaciones de trabajo, servidores y equipos de red)

  • Logs de Sistema

  • Logs de Auditabilidad


Logs de Aplicaciones

  • Logs del servidor de correo

  • Logs del servidor Web

  • Logs del servidor de archivos

  • Logs del servidor de DBMS(base de datos)




  1. DEFINICIÓN DE INFRAESTRUCTURA

Tras haber definido los requerimientos que debe satisfacer la guía metodológica, se procede a realizar la definición de los procedimientos que deben estar comprendidos en la guía metodológica, para la satisfacción de la totalidad de los requerimientos.


      1. Definición del método de sincronización de relojes de tiempo.

Al detectar la necesidad de que todos los relojes de tiempo de los dispositivos presentes en la red se encuentren sincronizados, para que a su vez, las estampillas de tiempo de los logs generados por estos dispositivos se encuentren sincronizadas, se establece el uso del protocolo de tiempo de red (NTP).
Aunque se tiene conocimiento de otro protocolo de sincronización de tiempo más simple (SNTP), se determina el uso de NTP debido a que un servidor NTP puede prestar servicios a un cliente SNTP, lo cual provee mayor cobertura.
Para la instalación y configuración de NTP es necesario determinar un servidor de NTP, el cual debe ser un equipo con sistema operativo UNIX Like1, y debe contar con el software NTPd [48].
De igual forma, los clientes con sistema operativo UNIX LIKE, deben contar con el mismo software del servidor para su configuración .
En cuanto a los clientes con sistema operativo Windows 2000, este sistema operativo tiene incorporado el protocolo SNTP v2.

Los sistemas operativos Windows XP, tienen incluido su propio cliente de NTP para la sincronización de relojes, la cual se describe en la guía metodológica. [ANEXO 1].


Los dispositivos de red (routers, access point, etc), deben también ser sincronizados. Estos tienen soporte desde la fábrica, para correr el protocolo NTP, o SNTP.

      1. Definición del método de transporte

Para cubrir el requerimiento que hace referencia a tener todos los registros de eventos en un punto central de la red, se consideran los protocolos que pueden proveer transporte de logs (SNMP, Syslog y sus versiones mejoradas).
Sin embargo, hay que tener en cuenta que no basta con transportar los registros de eventos a un punto central. Este transporte debe realizarse cumpliendo con los requerimientos que obligan a tener un mecanismo que garantice autenticación, integridad, y confidencialidad. Adicionalmente, este transporte debe ser orientado a conexión.
Para establecer el método más apropiado para realizar el transporte, se busca el método que cumpla con la mayor cantidad de requerimientos posibles. Para esto, se realiza una comparación entre los métodos contemplados teniendo en cuenta los requerimientos con los que cumplen.


Método de transporte

Integridad

Autenticación

Confidencialidad

Orientado a conexión

Syslog-ng












RFC 3195

/Secure Syslog











Nsyslog










Modular Syslog(msyslog)












Stealthful Logging













SNMP Traps v1.













SNMP Traps v3.










Tabla 3. Característica de los Métodos de transporte
Como se observa en la Tabla 3 ninguno de los métodos contemplados cumple con todos los requisitos necesarios para realizar el transporte. Por lo que se contempla la idea de establecer un túnel SSH, por medio del cual se encapsule algún servicio basado en TCP en una sesión de SSH. Esto garantiza satisfacer los requerimientos de proveer autenticación, integridad, confidencialidad y transporte orientado a conexión.
Para la elección del servicio utilizado para ser encapsulado en SSH, se observa en la tabla 3 que syslog-ng, secure syslog (rfc 3195) y Nsyslog y SNMP v.3 son basados en TCP, por lo que cualquiera de éstos podría ser utilizado.
Sin embargo, se encuentra que secure syslog (rfc 3195) no tiene implementación para sistemas operativos Windows, lo cual restringe su uso en la guía metodológica, considerando que este sistema operativo es usualmente utilizado en pequeñas y medianas empresas.
Finalmente, se decide el uso de syslog-ng, ya que además de soportar los requerimientos necesarios, provee el beneficio de almacenar los registros de eventos en una base de datos, lo cual, aunque no es requerido, facilita la gestión centralizada de los logs, y hace más sencilla su correlación.
Con la implementación de syslog-ng, se garantiza también el cumplimiento del requerimiento que exige que los registros de eventos queden todos en un solo formato polimórfico para su correlación, ya que el formato utilizado es el propio de syslog.


      1. Definición de herramientas de uso en la guía metodológica.

Una vez definido el método de transporte para los registros de eventos de seguridad, se determinan las herramientas que ayuden a realizar el transporte con base en los protocolos ya establecidos.
Al considerar que el protocolo SSH actúa bajo una arquitectura cliente servidor, se considera necesaria la determinación de las herramientas para el servidor, así como para cada uno de los clientes a utilizar, teniendo en cuenta los dispositivos utilizados en una red típica de una pyme.
Es importante aclarar que todas las herramientas utilizadas para la centralización de registros de eventos son de libre distribución lo que permite a todas las pymes seguir la guía metodológica sin limitaciones económicas de software.
Con este documento se adjuntan versiones adquiridas durante el segundo semestre de 2006 de todas las herramientas utilizadas.


        1. Herramientas para el servidor.

Para la creación del túnel SSH, se debe buscar una herramienta que permita establecer el túnel en una máquina con sistema operativo UNIX LIKE y actúe como servidor de SSH. Se recomienda el uso de la herramienta Open SSH [44], ya que ésta es una herramienta libre que permite establecer el túnel, y soporta todas las versiones del protocolo SSH. Ésta herramienta es desarrollada por “the OpenBSD Project”.
Luego, se debe obtener la herramienta syslog-ng, la cual se encuentra disponible en la página principal de syslog-ng [45]. Esta herramienta se debe configurar para responder a los servicios solicitados por los clientes, de acuerdo como se muestra en la guía metodológica. [ANEXO 1]


        1. Herramientas para clientes con sistema operativo UNIX LIKE.

En los clientes con sistema operativo UNIX LIKE, para establecer el túnel SSH, se sugiere el uso de la herramienta SSH client [44]. Aunque cualquier otra que permita establecer un túnel SSH con el servidor podría ser útil.
En cuanto a syslog-ng, se utiliza la misma herramienta nombrada para el servidor, y su configuración es tal como se muestra en la guía metodológica. [ANEXO 1]



        1. Herramientas para clientes con sistema operativo WINDOWS.

En los equipos con sistema operativo Windows, para establecer el túnel se debe usar una herramienta que permita su creación, la cual debe permitir su administración por medio de línea de comandos, así como su ejecución de fondo (en background), de éste modo el proceso de establecer el túnel será transparente para el usuario final. Para este proceso se recomienda el uso de la herramienta PLINK [46], la cual hace parte del paquete PUTTY y permite la conexión por medio de línea de comandos.
Existe una herramienta llamada LASSO [47], la cual es un software de código abierto, diseñado para recoger registros de eventos en Windows, pasarlos a formato syslog y transportarlos vía TCP a cualquier receptor de logs compatible con syslog-ng.


        1. Herramientas para otros clientes.

Los dispositivos de red presentes en la red de la pyme, como requerimiento de la guía deben soportar syslog. De éste modo, será posible realizar el transporte de los logs. Sin embargo, como syslog no provee mecanismos de seguridad, es necesario establecer una red alterna entre el dispositivo y un equipo con sistema operativo UNIX Like, al cual se envíen los logs. Y este deberá estar configurado como cliente, para enviar sus logs y los del dispositivo al servidor.
En el caso de los access point, y en caso de no tener un computador disponible para la red alterna de los demás dispositivos de red, es posible realizar la centralización por medio de syslog con UDP sin embargo no se cumpliría en su totalidad con los requerimientos de la guía. Por no proveer integridad, confidenciabilidad, ni autenticación.
Actualmente, no se tiene implementado syslog seguro en los dispositivos de red, sin embargo, probablemente en un futuro los dispositivos lo tengan integrado.


      1. Modelo de la infraestructura para la centralización de registros de eventos de seguridad.

Con base en las definiciones de los métodos para satisfacer los requerimientos que debe satisfacer la guía y de las herramientas tecnológicas que ayudan a cumplir con los métodos definidos, se modela la infraestructura de la guía metodológica de acuerdo al esquema de centralización mostrado en la figura 9.

Figura 10. Esquema de centralización de logs.

Como se observa en el esquema, el modelo se encuentra compuesto de un único servidor de logs, y una cantidad de clientes. La comunicación entre los clientes y el servidor es orientada a conexión y basada en el protocolo TCP.
Esta comunicación tiene la característica de garantizar la integridad de los datos, confidencialidad y autenticación. Estos principios de seguridad son garantizados por medio del túnel SSH.
En cuanto a la instauración del túnel SSH, en el servidor de logs se tiene un servidor de SSH (sshd), este se obtiene con la herramienta Open SSH. El servido de SSH se encarga de aceptar o denegar las conexiones con los clientes, dependiendo de la satisfacción o falla del proceso de autenticación.
El servidor SSH (sshd) se comunica por TCP con la herramienta syslog-ng, quien se encarga se recibir los registros de eventos transportados por el túnel y enviarlos para su almacenamiento a una base de datos (mysql) y/o a archivos planos.
Para el envío de los registros de eventos de los clientes con sistema operativo UNIX LIKE, se tiene la herramienta syslog-ng. Syslog-ng se comunica vía TCP con un cliente SSH (ssh) de la herramienta Open SSH, y éste cliente SSH se encarga de establecer el túnel con el servidor. De éste modo se realiza el transporte de los registros de eventos desde el cliente hasta el servidor.
De forma similar, se realiza el transporte de los registros de eventos de los clientes con sistema operativo Windows, en donde la herramienta LASSO actúa recogiendo los logs. Ésta herramienta se comunica vía TCP con el cliente SSH (plink) para Windows y transporta los registros de eventos por medio del túnel SSH hasta el servidor.
Los clientes con sistema operativo diferente a Windows o UNIX LIKE, como los dispositivos de red, envían sus registros de eventos por medio de syslog, a un cliente UNIX LIKE. Este transporte se realiza vía UDP y sin ningún mecanismo de integridad, confidencialidad, ni autenticación, por lo cual se debe tener una red alterna, que se utilice únicamente para este transporte y debe ser físicamente altamente protegida.


      1. Métodos utilizados para la satisfacción de los requerimientos de la guía metodológica.

A continuación se muestra la manera en que se abarca cada uno de los requerimientos definidos para la guía metodológica, con la infraestructura definida.

        1. Requerimientos funcionales

Los registros de eventos deben quedar en un punto central.

Como se observa en la estructura de la metodología, el elemento principal de la guía metodológica es el transporte de los registros de eventos desde su lugar de origen hasta un repositorio central ubicado en el servidor de logs. De éste modo todo los registros de eventos quedan ubicados en un punto central.


Es necesario garantizar que los registros de eventos queden todos en un solo formato polimórfico para su correlación. Este formato debe contener Identificación del sistema que generó el evento, Estampilla de tiempo y Detalle del evento.

Por medio del uso del protocolo syslog en la estructura de la guía metodológica, se garantiza que todos los registros de eventos enviados al servidor de logs tengan un único formato, el cual está compuesto de tres campos: PRI (prioridad del evento), HEADER (en donde se encuentra la estampilla de tiempo y el identificador del origen del evento) y MSG (contiene el nombre de programa o proceso que genero el evento y el detalle del evento).


Las estampillas de tiempo de los registros de eventos deben estar sincronizadas y deben incluir por lo menos la fecha y hora en la que se generó.

Al sincronizar todos los relojes de tiempo de los dispositivos presentes en la red se garantiza que las estampillas de tiempos de los registros de eventos se encuentren sincronizados. Adicionalmente, con el protocolo syslog, se garantiza que las estampillas de tiempo se encuentren en formato “Mmm dd hh:mm:ss”, incluyendo así la fecha y hora del evento.


Los registros de eventos deben tener algún mecanismo de identificación del sistema o tecnología de información que los generó para efectos de su utilización como evidencia digital.

A través del protocolo syslog se garantiza que todos los registros de eventos enviados al servidor de logs tengan la información del sistema o tecnología que los generó. Esta información se encuentra contenida en el campo MSG (contiene el nombre de programa o proceso que genero el evento y el detalle del evento) de los mensajes de syslog.




        1. Requerimientos no funcionales

Se debe utilizar un método de transporte confiable: el método de trasporte debe ser orientado a conexión, debe garantizar la integridad de los datos, debe mantener algún mecanismo de autenticación y los datos deben estar cifrados durante el transporte.

Este requerimiento es satisfecho por medio de la creación del túnel SSH, a través del cual, viajan los registros de eventos. El protocolo SSH es orientado a conexión. Suministra la privacidad de los datos utilizando algoritmos de cifrado para los datos. Utiliza métodos de autenticación, en éste caso el proceso de autenticación se realizará por medio de llaves públicas y privadas. Y garantiza que los datos que llegan al servidor de logs son los mismos que salieron del origen, por medio de la utilización de algoritmos Hash para la integridad de los datos.


Se debe utilizar algún mecanismo de autenticación con respecto al sistema que los generó.

El protocolo SSH permite la autenticación del cliente con el servidor. El método definido para realizar la autenticación es por medio de llaves públicas y privadas.

1   2   3   4   5


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal