Alejandro sierra munera pontificia universidad javeriana facultad de ingenieria



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

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

El protocolo SSH garantiza la integridad de los datos por medio del uso de algoritmos HASH garantizando así la integridad de los datos.


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

Para asegurar que el sistema esté en correcto funcionamiento en el momento en que se crean o modifican los datos, se sugiere realizar auditorias, que evalúen el comportamiento de los sistemas.


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

Para permitir que los registros de eventos de seguridad se encuentren disponibles en tiempo presente y futuro se recomienda que la pyme tenga políticas de procedimientos documentados en los cuales se describa el proceso de elaboración de copias de respaldo.


Debe existir un proceso de reducción de datos para el proceso de correlación, mediante compresión de datos, borrado de duplicados o filtrado de datos combinando varios eventos relacionados en uno solo.

Al analizar éste requerimiento se observa que se contradice con el requerimiento que sugiere “asegurar que no se perdió, ni cambó ningún dato en los registros de eventos para su uso como evidencia digital”. Por tal motivo este requerimiento no será tenido en cuenta.




  1. ESTRUCTURA DE LA GUÍA METODOLÓGICA

La guía metodológica para la gestión centralizada de registros de eventos de seguridad definida pretende llevar al administrador de la red de una pyme a una manera más sencilla y más ágil de analizar y monitorear los registros de eventos generados en la red.
La guía procura cumplir con los requerimientos necesarios para realizar una futura correlación de registros de eventos, así como mantener el carácter de evidencia digital de los logs.

      1. Diagrama de flujo de la guía metodológica.

La estructura de la guía metodológica se basa en el siguiente diagrama de flujo de datos, en el cual se exponen cada uno de los pasos que hacen parte de la guía metodológica.

Figura 11. Diagrama de flujo de la guía metodológica.




        1. Sincronización de los relojes de tiempo.

El paso inicial para lograr la centralización de registros de eventos de seguridad, es realizar la sincronización de los relojes de tiempo de todos los dispositivos presentes en la red de la pyme. Para esto, se debe seleccionar un servidor de NTP con sistema operativo UNIX LIKE. Este servidor puede ser el mismo servidor de logs, aunque no es requerido.


A continuación, se realiza la instalación y configuración de NTPd en el servidor y se configuran los clientes de acuerdo a su tipo (UNIX LIKE, Windows o dispositivo de red), con el fin de que todos los equipos de la red hagan uso del protocolo NTP.

        1. Creación del Túnel SSH.

Tras asegurar que todos los dispositivos de la red tienen sus relojes de tiempo sincronizados, se procede a realizar la creación del túnel SSH.
Para ello es necesario elegir el equipo con sistema operativo RED HAT LINUX, el cual actuará como servidor de SSH. Éste será el mismo equipo que prestará el servicio de recibir los logs enviados por todos los clientes y de almacenarlos.
Una vez configurado el servidor de SSH, como se muestra en el ANEXO 1, se crea el túnel desde los clientes. El proceso de creación del túnel depende del tipo de cliente que se vaya a configurar (LINUX, WINDOWS).
Para la creación del túnel SSH se debe tener algún mecanismo de autenticación, el mecanismo recomendado por la guía metodológica es por medio de llaves públicas y privadas. Esto con el fin de que el establecimiento del túnel pueda hacerse como un servicio del sistema operativo, y adicionalmente para que la creación del túnel y su proceso de autenticación sea transparente para los usuarios finales.
En los sistemas Operativos Windows, para establecer el túnel como un servicio del sistema, es necesaria la creación de una cuenta de usuario en el sistema operativo. Esta cuenta requiere contar con privilegios administrativos. El objetivo de la creación de la cuenta, es poder establecer el servicio en Windows, ya que los servicios deben quedar ligados a una cuenta de usuario.

        1. Instalación y creación del repositorio de datos.

Para el almacenamiento de los logs en el servidor de logs, se tienen dos opciones: almacenamiento en bases de datos o almacenamiento de logs en archivos. También existe la posibilidad de almacenarlos de forma duplicada en Bases de datos y archivos planos.
Por lo anterior, este paso de la guía metodológica, es opcional, y depende de lo que se requiera en cuanto al almacenamiento.
Inicialmente, para el almacenamiento en Base de Datos, se debe realizar la instalación de MySQL en el servidor de logs. Luego, se debe realizar la creación de la base de Datos de logs y finalmente se debe configurar el pipe, el cual se encargará de realizar la comunicación entre syslog-ng y mysql.


        1. Instalación y Configuración de herramientas de envío de eventos.

En el servidor, para la recepción de los registros de eventos de seguridad, antes de la instalación de syslog-ng, es necesario realizar la instalación de la librería Eventlog. Después de esta instalación se procede a instalar y configurar la herramienta syslog-ng, de acuerdo como se muestra en la guía metodológica. [ANEXO 1]


A continuación, se debe establecer syslog-ng como un servicio en el servidor, con el fin de que al iniciar el sistema operativo, inicie también el servicio de syslog-ng, sin necesidad de intervención humana.
Adicionalmente, en el servidor se debe crear el archivo de configuración de syslog-ng. En él se especifica la forma de almacenamiento de los registros de eventos en el servidor que se requiera. Es decir, si se decide que el almacenamiento debe ser en Bases de datos, se debe especificar en este archivo, de igual forma, si se decide en archivos, o en forma duplicada. Esta configuración se especifica en el ANEXO 1.
En Los clientes se debe configurar la herramienta de envío de acuerdo con su sistema operativo. De igual manera, para todos los clientes, se debe establecer el transporte de los registros de eventos como un servicio.

        1. Procedimiento de copias de respaldo.

Una vez configurado y probado el transporte y almacenamiento centralizado de los registros de eventos de seguridad, es necesario realizar una revisión de los procedimientos de elaboración de copias de respaldo en la pyme.
Para esto, se debe evaluar si se tiene un procedimiento que permita periódicamente almacenar una copia de los registros de eventos centralizados, sea en la base de datos o en archivos planos. Adicionalmente, se debe revisar que estas copias de respaldo puedan ser consultadas en tiempo presente y en tiempo futuro.
En caso, en que no se tenga dicho procedimiento o no cumpla con las especificaciones anteriores, se hace necesario la creación o modificación de una política documentada que describa el procedimiento, y se aplique a la pyme.
Esto se realiza con el fin de que los registros de eventos de seguridad, se encuentren disponibles y se puedan consultar en tiempo presente y futuro. Por tal motivo, vale la pena recalcar que las copias de seguridad deben ir perfectamente rotuladas, indicando como mínimo la fecha a la que pertenecen, y un identificador.

        1. Establecer Auditoria.

Para garantizar que los registros de eventos fueron generados o modificados por un sistema que se encontraba en correcto funcionamiento la guía metodológica sugiere realizar auditorias periódicas, en las cuales se evalúe el funcionamiento del sistema.



      1. Orden secuencial de pasos para la configuración de la centralización.

La configuración de cada equipo para la centralización de registros de eventos debe cumplir con una secuencia de pasos, los cuales deben ser seguidos estrictamente en el orden descrito a continuación para cada equipo.

        1. Secuencia de pasos en la configuración del servidor de logs.

La Figura 11 muestra el diagrama de flujo que describe la secuencia de pasos a seguir para la configuración del servidor.

Figura 12. Diagrama de Flujo para la configuración del servidor



        1. Secuencia de pasos en la configuración de los clientes UNIX LIKE

La Figura 12 muestra el diagrama de flujo que describe la secuencia de pasos a seguir para la configuración de los clientes con sistema operativo UNIX LIKE.

Figura 13. Diagrama de Flujo para la configuración de los clientes UNIX LIKE





        1. Secuencia de pasos en la configuración de los clientes WINDOWS

La Figura 13 muestra el diagrama de flujo que describe la secuencia de pasos a seguir para la configuración de los clientes WINDOWS.

Figura 14. Diagrama de Flujo para la configuración de los clientes WINDOWS



        1. Secuencia de pasos en la configuración de clientes dispositivos de red.

Las Figuras 14 y 15 muestran los diagramas de flujo que describen la secuencia de pasos a seguir para la configuración de los clientes dispositivos de red, así como del cliente UNIX LIKE que recibe sus registros de eventos y los envía al servidor de logs.

Figura 15. Diagrama de Flujo para la configuración de los clientes dispositivos de red.



Figura 16. Diagrama de Flujo para la configuración de los clientes UNIX LIKE, receptores de logs de los dispositivos de red.
La configuración del equipo encargado de recibir los registros de eventos enviados por los dispositivos de red, por medio de syslog y de enviarlos al servidor de logs, se realiza de manera similar a la configuración de un cliente UNIX LIKE. Sin embrago en la configuración se Syslog-ng existe una variación, la cual puede ser detallada en la guía metodológica. [ANEXO 1]


      1. Centralización de registros de eventos de herramientas utilizadas en pymes.

Los registros de eventos de las herramientas de seguridad utilizadas en la pyme para la protección informática, tales como Antivirus, AntiSpyware, Firewalls, etc. Deben ser tenidos en cuenta dentro del esquema de centralización.
Se sugiere al administrador, elegir herramientas de seguridad que permitan reportar sus logs por medio del protocolo syslog. Tambien existe la posibilidad, si la herramienta es software, de utilizar algún mecanismo que permita reportar los registros de eventos al sistema operativo, ya sea Windows o Unix Like. De esta manera, la herramienta utilizada en el sistema operativo para capturar los registros de eventos y transportarlos a un receptor syslog-ng, será quien se encargue de su centralización.

      1. Dependencia de los servicios.

Como se ha mencionado anteriormente, una de las características de la centralización de registros de eventos propuesta por la guía metodológica, es precisamente la transparencia del proceso para el usuario final.
Para ello, cada actividad que se realice en el proceso de la centralización debe ser instaurada como un servicio en el sistema se presenta. Es importante, tener presente que estos servicios tienen una dependencia que se debe respetar para el correcto funcionamiento del sistema.

Figura 17. Diagrama de Dependencias de los Servicios



En los clientes con sistema operativo Windows tanto LASSO como PLINK, deben configurarse como un servicio del sistema operativo. En este caso el servicio LASSO depende del servicio tunelssh.
En los cliente UNIX/UNIX, es importante tener en cuenta que se debe configurar como servicios syslog-ng, ntpd y ssh. En donde syslog-ng depende de ntpd y de ssh.
De forma similar sucede en el servidor de logs, en donde los servicios a configurar son syslog-ng, mysql, sshd y ntpd. En este caso, syslog-ng depende de los otros servicios.
La configuración de los servicios y las dependencias en cada sistema operativo, se detalla en la guía metodológica. [ANEXO 1].

  1. VALIDACIÓN DE LA GUÍA METODOLÓGICA

En el presente capítulo se describe el caso de prueba sobre el cual se realizo la validación de la guía metodológica definida como resultado del trabajo realizado.


  1. CARACTERÍSTICAS DEL CASO DE PRUEBA.

Para la validación de la guía metodológica se implementa una red que cumpla con las características de una red típica de una pyme en un ambiente controlado.
Para este procedimiento se contó con un conjunto de equipos del laboratorio de redes del departamento de Ingeniería de Sistemas de la Pontifica Universidad Javeriana. Los equipos que se disponen para la elaboración de la red son: 4 equipos con sistema operativo RED HAT LINUX, 2 equipos con sistema operativo Windows XP y un router Cisco 1800.
La tabla 4 describe las características técnicas de los equipos y su función en la red y en el modelo de centralización.


Características técnicas

Sistema Operativo

Función en la red

Elemento del modelo de centralización

Compaq EVO

Red Hat Linux

Servidor de logs

Servidor de logs

Dell Optiplex Gx 260

Windows XP

Host

Cliente Windows

Compaq Deskpro

Red Hat Linux

Equipo de gestión de logs

Receptor de logs de dispositivo de red.

Dell Optiplex Gx 270

Windows XP

Host

Cliente Windows

Dell Optiplex Gx 270

Red Hat Linux

Host

Cliente UNIX Like

Dell Optiplex Gx 270

Red Hat Linux

Firewall

Cliente UNIX Like

Router Cisco 1800

Cisco IOS Software 1841 v.12,4

Enrutador

Cliente dispositivo de red

Tabla 4. Equipos de la red del caso de prueba


      1. Diagrama De Red Del Caso De Prueba

El diagrama de red de la figura 18, describe el montaje de red realizado para la ejecución de la validación.

Figura 18. Esquema de Red del caso de prueba


  1. Definición de los resultados esperados.

Tras realizar el seguimiento de la guía metodológica se espera obtener los registros de eventos de los equipos presentes en la red, en un punto central.
Para lograr llegar a la centralización deseada se espera que la lista de validación mostrada en la tabla 5 se encuentre con todos los puntos seleccionando la casilla “si” o “N/A”.
La casilla N/A se debe llenar únicamente para la validación del proceso de MySQL en caso, en que no se requiera el almacenamiento en Base de Datos sino en archivos secuenciales.


Punto para verificar

Equipo

Prueba

si

no

N/A

Sincronización de los relojes de tiempo.

Clientes Windows XP

Rectifique que la hora mostrada a la derecha de la barra de herramientas corresponda con la hora que muestra el servidor de NTP










Clientes Unix Like

Rectifique que la hora mostrada en a la derecha de la barra de herramientas corresponda con la hora que muestra el servidor de NTP










Clientes Dispositivo de red

Verifique que la hora configurada en el sistema corresponda con la hora mostrada por el servidor de NTP










Establecimiento del túnel SSH

Servidor de logs

Ejecute el netstat siguiente comando:

na | grep tcp



De esta manera verifique cuantas conexiones hacía el puerto 22 existen. El número existente debe ser igual a la cantidad de clientes que se encuentren en funcionamiento en el momento.










Syslog-ng

Servidor de logs

Verifique que el proceso de syslog-ng se encuentra corriendo en el sistema.










Cliente Windows XP

Verifique que el proceso de LASSO se encuentra corriendo en el sistema.










Cliente Unix Like

Verifique que el proceso de syslog-ng se encuentra corriendo en el sistema.










Base de datos

Servidor de logs

Valide que el proceso de Mysql se encuentre corriendo en el servidor.










Servicios y dependencias

Servidor de logs

Rectifique que al apagar y volver a iniciar la máquina los servicios de NTP, SSH, Mysql y de syslog-ng se inicien automáticamente










Cliente Windows XP

Rectifique que al apagar y volver a iniciar la máquina los servicios de LASSO y PLink se inicien automáticamente










Cliente Unix Like

Rectifique que al apagar y volver a iniciar la máquina los servicios de NTP, SSH, y de syslog-ng se inicien automáticamente










Centralización de registros de eventos

Todos los equipos de la red

Rectifique que en el repositorio de registros de eventos haya logs de todos los clientes.










tabla 5. Lista de validación para la guia metodológica

  1. observaciones Y RESULTADOS OBTENIDOS.

Una vez concluido el seguimiento de cada paso de la guía metodológica aplicándolo a la red que simula una red típica de una pyme, se encontraron los siguientes resultados.


  • Toda la lista de validación se encontraba con la casilla “si” seleccionada para todos los puntos a verificar. Lo que indica que la guía se siguió correctamente, logrando los resultados esperados.

  • La guía metodológica se logró seguir paso a paso de manera secuencial sin tener que retroceder a pasos anteriores, lo que da a entender, que la guía se encuentra correctamente estructurada y entendible.

  • Se encontró que la instalación del software requerido para los sistemas UNIX Like se encuentra ligada en lo máximo posible al proceso de instalación estándar del software libre.

  • Mediante una captura en un analizador de tráfico, se logró observar que los mensajes que viajan por la red se encuentran cifrados, lo que permite garantizar un nivel de seguridad considerable en el transporte de los registros de eventos.

  • La guía metodológica permite centralizar los registros de eventos en una organización de forma transparente para los usuarios finales, pues los servicios inician automáticamente una vez inicie el sistema operativo.

  • Se observa, que después de seguir la guía metodológica, se logra centralizar los registros de eventos de seguridad de los dispositivos presentes en la red. Siendo la guía metodológica útil para el proceso de gestión de registros de eventos.



  1. CONCLUsIONES

Durante el tiempo de desarrollo del trabajo se logró definir y validar una guía metodológica para la gestión centralizada de registros de eventos de seguridad de red, la cual puede ser utilizada en organizaciones de pequeña y mediana escala.
La definición de la guía metodológica se consiguió por medio de la apropiación de la teoría asociada a la gestión y centralización de eventos de seguridad, de donde se obtuvieron los requerimientos que debía satisfacer la guía. Con base a estos requerimientos, se definió la infraestructura para la gestión centralizada que los satisficiera. Finalmente, se llegó a la implantación de la infraestructura, definiendo así la guía metodológica, la cual fue validada en un ambiente de pruebas.
Durante el desarrollo del trabajo, se obtuvieron las conclusiones y resultados que se describen a continuación:


  • La centralización de registros de eventos de seguridad es un tema actualmente muy inquietante en el ámbito de la seguridad informática y de la auditoria, pues facilita la gestión de los registros de eventos de seguridad en las compañías, ahorrando costos de tiempo y esfuerzo de los administradores de la red.

  • Aunque se tiene conocimiento de guías o procedimientos para la centralización de registros de eventos, no se conoce ninguna que cumpla con las características de seguridad requeridas para conservar el carácter de evidencia digital de los registros de eventos de seguridad y que contemple al tiempo sistemas operativos diferentes.

  • Existen herramientas tecnológicas que permiten la centralización de registros de eventos de seguridad, sin embargo son de precios demasiado elevados, y generalmente no se encuentran al alcance de una compañía de pequeña o mediana escala, por lo que la guía metodológica desarrollada es de un aporte altamente valioso para las pymes.

  • El conocimiento en cuanto a la tecnología obtenida en las pymes y al nivel de seguridad informática que se tiene en las compañías de escala pequeña y mediana en Colombia, es demasiado limitado. Las entidades que tienen como objetivo estudiar y apoyar a las pymes, no tienen estudios públicos en el tema.

  • En la definición de los requerimientos que debería satisfacer la guía metodológica, se encuentra que dos de ellos se contradicen entre sí. Al tratar de reducir los registros de eventos por medio de la compresión, borrado o filtrado no se estaría cumpliendo con el principio de suficiencia o completitud de los datos para la evidencia digital.

  • Durante la etapa de estructuración de la guía metodológica, se encontró la dificultad recolectar los registros de eventos generados por herramientas diseñadas en Windows, ya que no se rigen ningún estándar tal como lo hacen las herramientas para UNIX con syslog.

  • Al realizar el análisis de la información de la seguridad informática en las pequeñas y mediana empresas, se encontró que es un tipo de información muy resguardado lo cual es considerado correcto, pues de esta manera se evitan ataques de ingeniería social

  • Con el proceso de validación de la guía se encontró que la guía metodológica es una herramienta que lleva al administrador de la red a realizar de forma segura la centralización de los registros de eventos de seguridad, cumpliendo con los requerimientos definidos.


  1. TRABAJOS FUTUROS

A partir del trabajo realizado se deduce que estándares como syslog necesitan ser actualizados agregándoles aspectos de seguridad directamente en el estandar. Asi como definir estándares en necesario que los dispositivos y las herramientas incluyan en su diseño la implementación de estos estándares, para su integración en infraestructuras como esta.
Un trabajo futuro propuesto es el desarrollo de una guía que implemente también con herramientas de software libre como OSSIM el proceso de analisis y correlación de los eventos centralizados.
También se sugiere la implementación de la guía en un ambiente real y asi concretar las utilidades de la misma.
Para complementar el software utilizado en este trabajo, se pueden desarrollar agentes que permitan reportar los eventos de herramientas que por defecto no soportan el envio de mensajes, para que se integren a la infraestructura.


  1. BIBLIOGRAFIA

  1. TORRES, Juan Carlos. RONDÓN, Richard García. “Control, Administración E Integridad De Logs”. http://www.criptored.upm.es/guiateoria/gt_m248h.htm




  1. LONVICK, C., The BSD Syslog Protocol, RFC 3164, August 2001. http://www.ietf.org/rfc/rfc3164.txt




  1. MOCKAPETRIS, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987




  1. PITT DONALD,Log Consolidation with syslog. December 23, 2000 http://www.giac.org/practical/gsec/Donald_Pitts_GSEC.pdf




  1. NAWYN, Kenneth E. “A Security Analysis of System Event Logging with Syslog”. SANS Institute 2003. www.sans.org/rr/whitepapers/logging/1101.php




  1. IETF RFC 3080, http://www.ietf.org/rfc/rfc3080.txt.




  1. BOTERO, Nicolás. “Modelo de Gestión de Seguridad con Soportes a SNMP”. Pontificia Universidad Javeriana, Junio de 2005.




  1. FLOREZ, Diego Andrés – Londoño, Leonardo Eduardo. “Monitoreo y Control de Componentes de Red, Sobre Protocolo SNMP”. Pontificia Universidad Javeriana, Octubre de 2005.




  1. CRESPO, Joaquin, “Correlación de eventos de seguridad”, 2004. www.germinus.com/sala_prensa/articulos/Correlacion%20Eventos%20Seguridad.pdf




  1. CALDWELL, Matthew. “The Importance of Event Correlation for Effective Security Management”, ISACA, 2002. http://www.isaca.org/




  1. TIFFANY, Michael “A Survey of Event Correlation Techniques”, 2002. http://www.tiffman.com/netman/netman.pdf




  1. CHUVAKYN, Anton “Event Correlation in Security”, 2004. http://www.securitydocs.com/library/2270




  1. LIU, G - Mok,A.K.- Yang, E.J. “Composite Events for Network Event Correlation”, The University of Texas at Austin, 1999.




  1. NOBLETT, Michael G. POLLITT, Mark M. PRESLEY, Lawrence A. “Recovering and Examining Computer Forensic Evidence”. OCTOBER 2000. http://www.fbi.gov/hq/lab/fsc/backissu/oct2000/computer.htm

  2. CARRIER, Brian. “Defining Digital Forensic Examination and analysis Tools”. Agosto 7 de 2002. http://www.dfrws.org/2002/papers/Papers/Brian_carrier.p




  1. CASEY, Eoghan. “Digital Evidence and Computer Crime: Forensic Science, Computers, and the Internet”. 2004




  1. FARNER, Dan. “Forensic Discovery”. 2006.




  1. Cano Jeimy, Mosquera González José Alejandro, Certain Jaramillo Andrés Felipe. Evidencia Digital: contexto, situación e implicaciones nacionales. Abril de 2005. http://derecho.uniandes.edu.co/derecho1/export/derecho/descargas/texto/NasTecnologias6.pdf




  1. Cano Martines Jeimy José. Admisibilidad de la Evidencia Digital: Algunos Elementos de Revisión y Análisis. Agosto de 2003. http://www.alfa-redi.org/rdi-articulo.shtml?x=1304




  1. Ley 446 de Julio de 1998, http://www.sic.gov.co/Normatividad/Leyes/Ley%20446-98.php




  1. CANO, Jeimmy J. “Buenas Prácticas en la Administración de la evidencia digital”. 2006




  1. SERRANO G, Maria Isabel. “Fundamentos de Criptografía”. http://ainsuca.javeriana.edu.co/seginfor/. Consultado Abril de 2006.




  1. GÓMEZ, Nelson. “Soluciones de seguridad”. http://ainsuca.javeriana.edu.co/seginfor/. Septiembre de 2005. Consultado Abril de 2006.




  1. Noel, “Clasificación y tipos de ataques contra sistemas de información”, http://ww.delitosinformaticos.com




  1. GARZÓN, Daniel. RATKOVICH, Juan Carlos. VERGARA, Alejandro. “Metodología de análisis y vulnerabilidades para empresas de media y pequeña escala en la ciudad de Bogotá”. Febrero de 2005.




  1. McDowell, Mindi. “Understanding Denial-of-Service Attacks”. http://www.us-cert.gov/cas/tips/ST04-015.html




  1. RAFAIL, Jason. “Cross-Site Scripting Vulnerabilities”. http://www.cert.org/archive/pdf/cross_site_scripting.pdf




  1. SERRANO, Maria Isabel. “Seguridad en redes y Técnicas Hacking”. 2005.




  1. “Seguridad en la red: identificación de perímetros de red SMB”, Centro de Información y Recursos para PyMEs, Microsoft Colombia. http://www.microsoft.com/colombia/pymes/issues/sgc/articles/sec_net_smb_per_dev.mspx. Consultado: julio 27 de 2006.




  1. “Microsoft Active Directory, An Overview”. Presentación en Power Point. Windows Experts. www.windows-expert.net . Consultado Julio 31 de 2006




  1. ”Netcarft. Web Server Survey Archives”. Netcraft. http://news.netcraft.com/archives/web_server_survey.html. Consultado Agosto 8 de 2006




  1. ”Firewall/VPN, una solución a muchos problemas”. iWorld – IDG España. http://www.idg.es/iworld/articulo.asp?id=145203. Enero 1 de 2003. Consultado: Agosto 9 de 2006




  1. ”Mail Server Survey April 2004”. FalkoTimme.com. http://www.falkotimme.com/projects/survey_smtp.php?id=170 . Consultado Agosto 14 de 2006.




  1. “Guide to Computer Security Log Management (Borrador)”. NIST (Nacional Institute of Standards and Technology). Abril de 2006.




  1. Bruegge, Bernd. Dutoit, Alen H. “Ingeniería de Software orientado a Objetos”. 2002. Pirson Education.




  1. BABBIN, Jacob. “Security Log Management. Identifying Pattenrs In The Chaos”. Syngress Publishing, Inc. 2006




  1. ArCert. “Instalación y configuración de NTP”. http://www.arcert.gov.ar. Agosto de 2006




  1. AKIN Thomas. “Hardening Cisco Routers”. Febrero de 2002. http://www.oreilly.com/catalog/hardcisco/chapter/ch10.html




  1. IETF RFC 1305, http://www.ietf.org/rfc/rfc1305.txt.




  1. IETF RFC 2030, http://www.ietf.org/rfc/rfc2030.txt.




  1. SSH Communications Security. http://www.ssh.com/




  1. BARRELT, Daniel J. SILVERMAN, Richard. BYRNES, Robret G. “SSH. The Secure Shell – The Definitive Guide”. O’Reily. 2005.




  1. IETF RFC 739, http://www.free.lp.se/fish/rfc.txt




  1. Open SSH. Noviembre de 2006. http://www.openssh.com/




  1. Balabit IT Security. 2006. http://www.balabit.com/products/syslog_ng/




  1. http://www.chiark.greenend.org.uk/~sgtatham/putty




  1. Source Fore .net. 2007. http://sourceforge.net/projects/lassolog




  1. The Network Time Protocol project. http://www.ntp.org/



  1. ANEXOS

ANEXO 1: Remítase al documento “Guía Metodológica para la Gestión Centralizada de registros de eventos de seguridad en Pymes”

1 Entiéndase como Unix Like todo sistema operativo que se comporte de manera similar a un sistema UNIX, como Linux.

1   2   3   4   5


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

    Página principal