Módulo de Generación de Reportes Gráficos de una Honeynet a partir de los logs tcpdumps



Descargar 292,64 Kb.
Página5/5
Fecha de conversión05.08.2017
Tamaño292,64 Kb.
1   2   3   4   5

Figura 5.1.2.3 Formato de salida del Mapper de Tráfico por IP




  • Por cada paquete que se parsea en el mapper, se forma un registro con el formato que se presenta en la Figura 5.1.2-3, la cual detalla como está formado el modelo clave/valor. Dentro de la clave, se encuentran la IP de origen y la fecha de captura, mientras que en el valor se encuentran un contador y el tamaño en bytes del paquete.



  • Y por último, para los reportes de cantidad de bytes por día de la semana y hora específica, se requieren del día de envío del paquete, la hora de captura y el tamaño del mismo.








    Figura 5.1.2.4 Formato de salida del Mapper de Cantidad de bytes por día de la semana y hora del día




  • Por cada paquete que se parsea en el mapper, se forma un registro con el formato que se presenta en la Figura 5.1.2-4, la cual detalla como está formado el modelo clave/valor. Dentro de la clave, se encuentran el día de la semana y la hora de captura, mientras que en el valor se encuentran un contador y el tamaño en bytes del paquete.



  • El proceso de parsear cada archivo de entrada se lo realiza gracias a la librería JNetStream, la misma que está orientada a la interpretación de paquetes de red de manera primitiva. Esta librería no posee métodos definidos para la extracción de datos, razón por la cual se implementó una clase PacketAnalyzer capaz de satisfacer las necesidades con respecto a la información requerida para la correcta generación de cada reporte.



  • A medida que el modelo clave/valor se va generando a partir de cada mapper, para cada tipo de reporte se va ejecutando el correspondiente reducer, cada uno de ellos tiene la finalidad de agrupar de manera correcta cada valor con su respectiva clave.



  • Una vez que todos los mappers han entregado sus correspondientes porciones de datos, el reducer procesa dichos datos y los agrupa en un solo resultado final.



      1. Archivos de salida



  • El resultado del reducer (para nuestro caso) debe de almacenarse en un archivo XML. Para poder realizar el correspondiente almacenamiento, se debió de crear una clase que extienda de FileOutputFormat y que sobrescriba los métodos necesarios para que el resultado final se almacene como archivo XML en Amazon S3.



    1. Diseño del Front-End






    Figura 5.2.1 Diseño Arquitectónico del Front-End




      1. Adobe FLEX



  • La interacción entre los reportes y el usuario debía ser muy práctica, por lo que el nivel de presentación se optó por desarrollarlo con Adobe FLEX, el cual trabaja usando lenguaje XML.



  • Mediante Gráficos Estadísticos como Barras, Pastel y Burbujas se puede visualizar, interpretar y analizar el comportamiento de la red, pudiendo detectar posibles ataques por parte de hackers. Cada uno de estos gráficos es el resultado del procesamiento de datos masivos almacenados en archivos tcpdumps.



  • Evaluación

    1. Pruebas de eficacia



  • Para realizar estas pruebas fue necesario contrastar el trabajo realizado por el módulo de parseo de archivos *.pcap con otros programas de lectura existentes, sin embargo esto sólo fue posible con archivos en el orden de los MB, para archivos de mayor tamaño se encontraron errores en los programas probados por las limitantes que tienen al depender de las características de memoria y velocidad de procesamiento de una sola máquina.








    Figura 7.1.1 Error tomado al abrir archivo de tamaño 1,25GB con Wireshark V




  • La Figura 7.1.1 muestra el mensaje correspondiente a “Fuera de Memoria” del programa Wireshark, al tratar de analizar la información contenida en el archivo de 1GB del mes de Septiembre de 2008.



  • Otros programas de distribución gratuita como JpcapDumper, simplemente se cerraron al tratar de analizar el mismo archivo.



    1. Pruebas de eficiencia



  • Estas pruebas fueron realizadas en el Amazon EC2 y se han usado diferentes números de nodos para medir el tiempo que se requiere para completar la tarea.



  • Los resultados los describimos a continuación:






    Figura 7.2.1 Reporte Gráfico por IP




  • Como se muestra en la Figura 7.2.1 se realizaron tres pruebas de procesamiento masivo para el Reporte de IP, teniendo una diferencia de tiempo dentro de un intervalo de +/- 10 seg. Con tres nodos se obtuvo un tiempo de procesamiento de 12,67 seg., en cambio con cinco nodos se obtuvo un tiempo de procesamiento de 10,82 seg., mientras que con diez nodos se obtuvo un tiempo de procesamiento de 10,45 seg.






    Figura 7.2.2 Reporte Gráfico por País




  • Como se puede observar en la Figura 7.2.2, en el caso del Reporte por País, se realizaron tres pruebas de procesamiento masivo, obteniendo una diferencia dentro de un intervalo de +/- 10 seg. Con tres nodos se obtuvo un tiempo de procesamiento de 13,29 seg., en cambio con cinco nodos se obtuvo un tiempo de procesamiento de 12,20 seg., mientras que con diez nodos se obtuvo un tiempo de procesamiento de 12,11 seg.






    Figura 7.2.3 Reporte Gráfico por Hora y Día




  • Como se muestra en la Figura 7.2.3, en el caso del Reporte por Hora/Día, se realizaron tres pruebas de procesamiento masivo, obteniendo un intervalo de diferencias de +/- 10 seg. Con tres nodos se obtuvo un tiempo de procesamiento de 12,23 seg., en cambio con cinco nodos se obtuvo un tiempo de procesamiento de 10,91 seg., mientras que con diez nodos se obtuvo un tiempo de procesamiento de 10,65 seg.






    Figura 7.2.4 Reporte por Protocolo




  • Como se muestra en la Figura 7.2.4, se realizaron tres pruebas de procesamiento masivo para el Reporte por Protocolo, teniendo una diferencia de tiempo dentro de un intervalo de +/- 10 seg. Con tres nodos se obtuvo un tiempo de procesamiento de 12,67 seg., en cambio con cinco nodos se obtuvo un tiempo de procesamiento de 10,82 seg., mientras que con diez nodos se obtuvo un tiempo de procesamiento de 10,45 seg.



  • En cada gráfico se puede observar el comportamiento del rendimiento del módulo bajo tres condiciones de recursos. De manera general, se observa que a mayor número de nodos, se tiene un menor tiempo de procesamiento. Sin embargo, el correcto aprovechamiento del número de nodos depende del tamaño total de información a procesar, del número de mappers a utilizar y del tamaño configurado para cada chunk.



  • Conclusiones



  • 1. Los reportes gráficos fueron generados bajo un ambiente altamente usable, pues se ha explotado varias características visuales que provee el lenguaje utilizado para la implementacion del front end (MXML, Action Script).



  • 2. A través de cada uno de los reportes, se puede demostrar el resultado del parseo, procesamiento y filtrado de los correspondientes logs. Pudiendo visualizar bajo varias perspectivas, diferentes enfoques de análisis, apoyando el monitoreo de las redes y controlando las debilidades y fortalezas de las mismas, dando soporte a la toma de decisiones y el mejoramiento continuo a la administración de la red.



  • 3. Proveemos una alternativa diferente a las herramientas existentes, debido a que las actuales no brindan soporte para archivos de mayor tamaño (1GB) y mucho menos generar reportes a partir de varios archivos, si estos superan el tamaño soportado por la herramienta.



  • 4. Se desarrolló un módulo que puede ser adaptable a las necesidades de los administradores de red para el procesamiento de los logs en formato pcap.



  • Recomendaciones



  • 1. Los reportes presentados son una muestra de lo que se puede realizar a partir de los archivos de salida generados por map/reduce. Sin embargo, se pueden generar reportes mas complejos, exportarlos a otros tipos de formato e inclusive visualizarlos de una forma diferente utilizando las herramientas adecuadas (muchas herramientas soportan la generación de graficos a partir de un archivo XML).



  • 2. El analisis de archivos pcap en el ambiente Hadoop ya ha sido discutido en foros de Internet , donde no han encontrado una solución viable. Nosotros hemos compartido nuestra propuesta y esperamos una pronta retroalimentacion con el objetivo de mantener el mejoramiento continuo del módulo.



  • 3. Los administradores de red podrían adaptar la propuesta que hemos detallado para generar reportes personalizados a sus necesidades, sin embargo, tendrían que familiarizarse con el ambiente distribuido que utiliza Hadoop para el procesamiento de datos.



  • Referencias



  • [1] Lance Spitzner, “Honeypots: Tracking Hackers”, Addison Wesley professional, 2002.



  • [2] Apache. Hadoop. http://lucene.apache.org/hadoop/, 2008



  • [3] Apache. Pig. http://incubator.apache.org/pig/, 2008



  • [4] Chu, L., Tang, H., Yang, T., and Shen, K. 2003. Optimizing data aggregation for cluster-based internet services. In Pro-ceedings of the Ninth ACM SIGPLAN Symposium on Prin-ciples and Practice of Parallel Programming, 2003.



  • [5] Jeffrey Dean, Sanjay Ghemawat: MapReduce: simplified data processing on large clusters. OSDI 2004: 137-149.



  • [6] Michael Isard, Mihai Budiu, Yuan Yu, Andrew Birrell, Den-nis Fetterly: Dryad: distributed data-parallel programs from sequential building blocks. EuroSys 2007: 59-72.



  • [7] Fay Chang et al, Bigtable: a distributed storage system for structured data, OSDI 2006, 205-218



  • [8] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung: The Google file system. SOSP 2003: 29-43.



  • [9] OpenSolaris. Hadoop. http://opensolaris.org/os/project/livehadoop/, 2008



  • [10] Herringshaw C., "Detecting attacks on networks", Diciembre 1997.



  • [11] Jeffrey Dean, Sanjay Ghemawat, "Simplified Data Processing on Large Clusters", Diciembre 2004.
  • 1   2   3   4   5


    La base de datos está protegida por derechos de autor ©absta.info 2016
    enviar mensaje

        Página principal