proyecto fin de grado grado en ingeniería de las...

+++

Proyecto Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación

Monitorización de tráfico con recolector de estadísticas basado en iptables e interfaz en Rails

Autor: Mercedes Castaño Torres Tutor: Juan Manuel Vozmediano Torres

Departamento de Telemática Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2014

Proyecto Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación

Monitorización de tráfico con recolector de estadísticas basado en iptables e interfaz en Rails

Autor:

Mercedes Castaño Torres

Tutor:

Juan Manuel Vozmediano Torres Profesor titular

Departamento de Telemática Escuela Técnica Superior de Ingeniería

Universidad de Sevilla Sevilla, 2014

Proyecto Fin de Carrera: Monitorización de tráfico con recolector de estadísticas basado en iptables e interfaz en Rails

Autor: Mercedes Castaño Torres

Tutor: Juan Manuel Vozmediano Torres

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2014

El Secretario del Tribunal

A mi familia y amigos

A mis profesores

i

Agradecimientos

Con este proyecto cierro una de las etapas más importantes y bonitas de mi vida: el final de mi carrera. Por ello, quiero dedicar este trabajo y dar mis agradecimientos:

- A mis padres, por haberme dado la posibilidad de estudiar, por su apoyo y fuerza durante estos cinco años que llevo en Sevilla.

- A mis profesores, gracias por todo lo que he aprendido con vosotros. Especialmente al departamento de Telemática, por haber hecho que cada día me alegre más de la especialidad que escogí. Evidentemente, en especial a Juan Manuel Vozmediano, mi tutor de proyecto. Gracias por enseñarme a aclarar mis ideas en la cabeza antes de sacarlas al exterior, gracias por tus clases y por hacer conmigo de “Pepito Grillo”.

- A todos los amigos que he hecho a lo largo de la carrera, que me han ayudado a que los días se pasaran volando, incluso en los momentos de agobio. Especialmente a Carlota Borjabad, que lleva a mi lado desde el segundo día de carrera, compartiendo conmigo risas y llantos: GRACIAS.

- A Andrés Gómez, por ser un libro abierto a mi lado cada día y por darme su apoyo y tranquilizarme cuando yo sola no podía. Y, por supuesto, a Ángel Miguel de Meana, por sus tutoriales express de Ruby on Rails.

iii

Resumen

En este proyecto se desarrollará un sistema de monitorización de tráfico basado en iptables. Se probará para el caso concreto de una subred interna. La información recolectada podrá ser consultada por los clientes desde Internet. Para ello se creará un servidor web que mostrará gráficas intuitivas, facilitando el estudio de la información monitorizada. Las pruebas concretas para el proyecto se realizarán simulando una LAN con varios equipos (entre dos y seis), generando tráfico que utilicen los protocolos UDP y TCP. Para una IP determinada se monitorizarán, de forma particular, los flujos de tráfico de los puertos 80 (http) y 25 (smtp). Como resultado final podrá concluirse la validez del sistema en pequeñas subredes, siendo una solución simple, económica y sencilla de usar por usuarios inexpertos en monitorización de redes.

v

Abstract

The present project aims to develop a traffic monitoring system based on iptables. It will be tested specifically for an internal subnet. Clients will be able to access the collected data via Internet. In order to facilitate the study of the gathered information, a web server that shows intuitive graphics will be created. The particular tests required for this project shall be carried out by a simulation of a LAN with multiple computers (two to six). This will generate traffic that uses the UDP and TCP protocols. For a given IP, the traffic flows of the 80 (http) and 25 (smtp) ports will be monitored. In conclusion the validity of this system will be proven by the tests done in small subnets. Lastly this is a simple, affordable and easy to use solution, accessible to all types of users, even those without experience in monitoring networks.

Índice

Agradecimientos i

Resumen iii

Abstract v

Índice vi

Índice de Tablas ix

Índice de Figuras xi

Notación xiii

1 Introducción 1 1.1 Motivación 1 1.2 Objetivo 1 1.3 Estructura de la memoria 2

2 Herramientas 3 2.1 Debian 3 2.2 Netfilter e Iptables 3 2.3 Shell Script 5 2.4 Cron 5 2.5 Lenguajes de Programación Web 5 2.5.1 Ruby on Rails 5 2.5.2 HTML5 y CSS 8

2.6 Librería Chart.js 8 2.6.1 Comparativa con otras librerías 8

2.7 Java Script Object Notation 9 2.8 Elementos Secundarios 9 2.8.1 OmniGraffle y Gliffy 9 2.8.2 VMware Fusion 9 2.8.3 Microsoft Word 10

3 Arquitectura 11 3.1 Router 12 3.1.1 Instalación 12 3.1.2 Implementación de reglas de contabilización 12

3.2 Servidor Web 13 3.2.1 Instalación 13 3.2.2 Servidor Ruby on Rails 13 3.2.3 Estilo 18

3.3 Cliente 19

4 Funcionamiento del escenario 21 4.1 Recolección de información 21 4.2 Consulta de información 24 4.2.1 Información global 24

vii

4.2.2 Información concreta 24 4.3 Edición de gráficas 25

5 Pruebas Realizadas 27 5.1 Recolección de estadísticas en estado periódico 27 5.1.1 Consultas del último intervalo de tiempo 27 5.1.2 Consulta global 29

5.2 Recolección de estadísticas en estado forzado 30 5.2.1 Consultas del último intervalo de tiempo 30 5.2.2 Consulta global 31

6 Conclusiones 33 6.1 Líneas futuras 34

Referencias 35

Anexo A: Sistema Operativo Debian 37

Anexo B: Servidor en Ruby on Rails 45

ix

Índice de Tablas

Tabla 1: Comparativa de lenguajes interpretados en servidor web

Tabla 2: Comparativa de librerías JS para generar gráficas

7

8

xi

Índice de Figuras

Figura 1: Estructura de funcionamiento de Iptables

Figura 2: Diagrama de Modelo Vista Controlador

Figura 3: Escenario simulado

Figura 4: Diagrama de despliegue del escenario real

Figura 5: Estructura de Directorios de Ruby on Rails

Figura 6: Estructura Inicial RoR

Figura 7: Lista de rutas del proyecto

Figura 8: Modelo Vista Controlador en RoR

Figura 9: Página web principal (diseño)

Figura 10: Diagrama de Casos de Uso del Escenario

Figura 11: Diagramas de flujo de script “daemon.sh”

Figura 12: Diagrama de flujo general de los controladores

Figura 13: Tipos de gráficas utilizadas

Figura 14: Resultados de tráfico TCP

Figura 15: Resultados de tráfico UDP

Figura 16: Tráfico monitorizado por IP

Figura 17: Resumen trajano (gráfica tipo “Pie”)

Figura 18: Tráfico entrante en octetos en gráfica global (una hora)

Figura 19: Tráfico entrante en octetos en gráfica global (seis horas)

Figura 20: Gráfica global en caso forzado (resultado para seis horas)

Figura 21: Diagrama de Componentes del proyecto

4

6

10

11

13

14

15

16

18

19

22

23

24

27

27

28

28

29

29

30

32

xiii

Notación

RoR MVC HTML CSS JSON HTTP UDP TCP SMTP IP .js .rb .erb .sh

Ruby on Rails Modelo - Vista – Controlador (patrón) HyperText Markup Language Cascading Style Sheets JavaScript Object Notation HyperText Transfer Protocol User Datagram Protocol Transmission Control Protocol Simple Mail Transfer Protocol Internet Protocol Java Script (extensión) Ruby (extensión) Embedded Ruby (extensión) Shell Script (extensión)

1

1 INTRODUCCIÓN

1.1 Motivación La RAE define el verbo monitorizar como “observar mediante aparatos especiales el curso de uno o varios parámetros fisiológicos o de otra naturaleza para detectar posibles anomalías”. Actualmente, las redes son monitorizadas ya sea por simple gestión o para recabar alguna información de interés. Además, esta acción puede ayudar a solventar errores e incluso a prevenir ataques. Existen programas como wwstats [1] e isoqlog [2] encargados de monitorizar tráfico web y de correo electrónico, respectivamente. Las novedades que este proyecto aporta respecto a los programas anteriores son: - Información recolectada a partir de reglas de iptables: muy liviano. Es una herramienta inherente en Unix. No requiere ninguna instalación previa basando la funcionalidad del proyecto en el propio núcleo del equipo. - Como consecuencia de la característica anterior, las estadísticas que se obtienen en la web de este proyecto no se limitan a un sólo tipo de tráfico. Se podrán visualizar los flujos que atraviesan los puertos 80 (http), 21 (FTP), 22 (SSH), 25 (SMTP)… - Empleo de lenguaje Ruby para dotar de funcionalidad al proyecto, en lugar de C como es el caso de isoqlog. Además, el proyecto cuenta con dos características fundamentales de interés: - Empleo de Ruby on Rails (RoR): una gema de ruby para programación web que, como ya se explicará más adelante, aporta una gran variedad de prestaciones eficaces y escalables. Además el servidor que levanta es mucho menos pesado (16MB) que otros como Apache (100MB). - SO Debian: mientras que los anteriores sólo están diseñados para utilizarlos en Windows.

1.2 Objetivo El objetivo del proyecto es mostrar, de forma simple y visual mediante gráficas, estadísticas de

tráfico de una serie de direcciones IP, basándose en información recolectada con iptables. Las gráficas se servirán en una web en la cuál se podrá elegir entre diversas opciones: visualizar tráfico TCP, UDP, sólo puertos 25 o 80 ó, por último, un resumen general del mismo.

“Nunca consideres el estudio como una obligación, sino como una oportunidad para penetrar en el bello y

maravilloso mundo del saber.”

- Albert Einstein -

Introducción

2

Para ello, un equipo central con sistema operativo Debian ejercerá como router. Éste hará de interfaz entre una subred interna e Internet. Además tendrá configuradas distintas reglas de iptables, (para realizar un conteo de tráfico), y a la vez ejercerá de servidor web. El servidor escogido se establece con Ruby on Rails. Cuando un cliente de la subred interna consulte a dicho servidor, se recolectará la información que se haya almacenado con iptables hasta el momento, y se generarán las gráficas que se le presentarán al cliente.

1.3 Estructura de la memoria En el siguiente punto de la memoria se detallan las características de las herramientas y lenguajes

empleados en el proyecto, solo se da una visión teórica. En el punto 3, se explicará como interviene cada elemento en el proyecto. Seguido de ello se detallará la funcionalidad exacta del proyecto, cómo se llega al resultado final. Por último, se hablará de las pruebas que se han realizado para comprobar su funcionamiento. El proyecto se cierra con unas conclusiones generales a cerca del mismo seguidas de las referencias y los anexos de instalación necesarios.

3

2 HERRAMIENTAS

ntes de comenzar con el desarrollo del proyecto en sí, resulta necesario presentar las herramientas y lenguajes utilizados. En este apartado se describirán sus características, sin entrar en el papel que desempeña cada uno en el proyecto.

2.1 Debian Debian [3] es un sistema operativo libre. Usa el núcleo de Linux o de FreeBSD. Cuenta con más de

37500 paquetes que pueden ser incorporados al sistema en cualquier momento de forma simple. Este sistema operativo es producido por casi un millón de desarrolladores, que contribuyen en el proyecto de forma activa y se encuentran repartidos por todo el mundo. El proyecto Debian es organizado y cualquiera puede informarse sobre su funcionamiento a través de su “rincón del desarrollador”. Para el proyecto se ha utilizado un Debian versión 7 de 64 bits. A la máquina virtual se le ha cedido 1 núcleo de procesador y 2GB de memoria.

2.2 Netfilter e Iptables Netfilter [4] es un módulo que poseen los núcleos de Linux, (desde la versión 2.4.x en adelante),

que permite realizar un filtrado de paquetes. Proporciona al núcleo la posibilidad de ejercer como cortafuegos del equipo. La herramienta que hace posible su uso es iptables [4]. Gracias a esta herramienta podemos definir reglas que permiten el filtrado de paquetes atendiendo a direcciones IP o puertos, la realización de traducciones nat y otra serie de manipulaciones como conteo de tráfico. En iptables, las reglas se aplican en orden descendente, por lo que deben establecerse de forma más específica a menos. En la figura 1 podemos observar la organización de iptables: las reglas se agrupan en cadenas (recuadros) y éstas en tablas (coloreadas por tipo). Las acciones a realizar sobre un paquete pueden ser ACCEPT, DROP, MASQUERADE, REDIRECT…

A

Herramientas

4

Figura 1: Estructura de funcionamiento de Iptables

Para establecer una regla se utiliza la siguiente sintaxis general:

iptables -t tabla -A CADENA condiciones -j ACCIÓN

En caso de no establecer ninguna acción, (no se especifica la opción -j), simplemente se contabilizarán los paquetes que cumplan las condiciones especificadas en la regla. El único detalle a tener en cuenta al contabilizar tráfico con iptables, es utilizar las reglas de conteo antes de la de filtrado. Tal y como iptables aplica sus reglas, si no se siguiese el orden correcto de inserción podrían generarse resultados falsos de contabilización. Es en esta posibilidad que ofrece la herramienta en la que se basa el proyecto.

Un elemento importante que da a iptables un nivel extra de funcionalidad son las “cadenas de usuario”. Básicamente son un conjunto de regla que el propio usuario define bajo un alias. Aportan comodidad a la hora de tener que aplicar un conjunto de reglas concretas que siempre se utilizan en bloque de la misma forma. Además pueden utilizarse en cualquiera de las cuatro tablas anteriores. Como ventaja extra permiten realizar la operación lógica “AND” en iptables, que de otra forma no sería posible. Para trabajar con cadenas de usuario se emplean los comandos inferiores:

iptables -N cadenaUsuario (para crear la cadena)

iptables -A cadenaUsuario condiciones (para introducir las reglas)

5 Monitorización de tráfico con recolector de estadísticas basado en iptables e interfaz en Rails

2.3 Shell Script El shell es la interfaz de línea de comandos del core Unix. Puede definirse como un programa que interpreta y ejecuta comandos. Éstos pueden ser leídos directamente de teclado o de un fichero escrito previamente. Un shell script [5] es un programa formado por un conjunto de instrucciones escritos en lenguaje shell y alojado en un fichero de texto plano. Se escriben exactamente igual que se haría por línea de comandos. Estos programas no necesitan una compilación previa, son programas interpretados. Los shell script incluyen desde variables y comandos simples hasta complejas funciones formadas con estructuras de control. Incluso pueden crearse scripts que a la vez generen nuevos scripts. Permite agilizar así el uso básico del terminal.

2.4 Cron El término cron viene del griego “chronos” (tiempo). Es un “demonio” que utilizan los sistemas operativos Unix para administrar procesos que deben ejecutarse cada cierto tiempo o en un momento concreto. Se inicia desde /etc/tc.d o /etct/init.d (dependiendo de la distribución).

Tanto los procesos a ejecutar como la hora en la que deben hacerlo, se almacenan en el fichero crontab siguiendo el formato inferior. Es la manera más sencilla de administrar tareas con cron. Escritos en texto plano, posee la lista de comandos que se ejecutarán en un momento especificado por el usuario.

Teniendo en cuenta esos dos conceptos, el funcionamiento del cron es el siguiente: cron se ejecuta en el background, y va comprobando cada minuto la tabla de tareas crontab en búsqueda de tareas que se deban cumplir.

2.5 Lenguajes de Programación Web Este apartado se divide en dos puntos: en el primero se habla de Ruby y Ruby on Rails, lenguajes de

programación web en el servidor; en el segundo se pasa a los lenguajes que serán interpretados en el cliente (HTML5 y CSS3).

2.5.1 Ruby on Rails

El árbol de directorios que conforman la página web será desarrollado en Ruby on Rails. A continuación se indican algunas de sus características y organización.

Minuto (0 – 59)

Hora (0 – 23)

Día del mes (1 – 31)

Mes (1 – 12 ó jan, feb…)

Día de la semana (0 – 6, Domingo = 0)

* * * * * comando_a_ejecutar

Herramientas

6

2.5.1.1 Ruby

Ruby [6] es un lenguaje creado por Yukihiro Matsumoto y que nació de la mezcla de partes de sus lenguajes favoritos (Perl, Smalltalk, Eiffel, Ada, y Lisp). Fue liberado en 1995 y su utilización ha aumentado progresivamente. Actualmente ocupa el puesto 13 del ranking mundial en el índice TIOBE (escala que mide el crecimiento de los lenguajes de programación). Es un lenguaje totalmente libre: es gratuito y puede ser usado, copiado, modificado y distribuido a placer por el usuario. Además, es un lenguaje bastante flexible. ·Entre sus funcionalidades destacan el manejo de excepciones, facilidad de extensiones en C, manejo de hilos…Y, quizás uno de los más importantes, el uso de gemas entre las que destaca Rails.

2.5.1.2 Rails

Ruby on Rails (RoR) [7] [8] es un entorno para desarrollo de aplicaciones web de código abierto. Ofrece una gran facilidad para trabajar con bases de datos. Permite realizar códigos fáciles de mantener, extensibles, con menos errores que otros lenguajes y, además, sugiriéndote “la mejor forma de hacer las cosas”. Esto es consecuencia de sus dos grandes pilares: “Don’t Repeat Yourself (DRY)” y “Convention Over Configuration”. Como ya se verá más adelante, con pocos comandos podremos levantar nuestro propio servidor en RoR, escuchando en el puerto 3000 de nuestro equipo. El patrón que sigue es el de Modelo Vista Controlador.

2.5.1.3 Modelo Vista Controlador

El Modelo Vista Controlador (MVC) [9] es un patrón arquitectónico que propone descomponer el sistema en tres componentes mostrados en el diagrama de la figura 2:

Figura 2: Diagrama de Modelo Vista Controlador

- Modelo (M): incluye la implementación de las funcionalidades y los datos del sistema

(app/models/). Proporciona al controlador los servicios para satisfacer las peticiones del usuario.


Implementa un mecanismo de coordinación con las vistas y los controladores asociados, para la notificación sobre cambios de estado.

- Vista (V): muestra la información al usuario final (app/views/vista.html.erb). Un mismo modelo

puede tener más de una vista. A veces, debe cambiar la información que muestra si hay cambios en el modelo. Por ello, tiene asociado un controlador que gestione estos eventos de modificación.

- Controlador (C): recibe la petición del navegador y gestiona la interacción con el usuario

(app/controllers/). Realiza invocaciones a los servicios que proporciona el modelo y peticiones de funcionalidad de las vistas.

2.5.1.4 Comparativa con otros lenguajes

La elección de un lenguaje de programación sobre otro se basa en el objetivo final del programador. Para este proyecto concreto se buscaba un lenguaje de desarrollo web flexible, escalable (para futuras mejoras en la página) y con el que se pudiese levantar un servidor web liviano. Se ha elegido Ruby on Rails porque cumple en general las características esperadas. Además, es un lenguaje que está alcanzando popularidad entre los programadores y resulta de interés aprenderlo. A continuación, en la tabla 1, se expone una comparativa entre Ruby, PHP y Python.

Ruby PHP Python

Propósito

Su objetivo básico es hacer la programación divertida y flexixble para el programador

Fue diseñado para desarrollar páginas webs dinámicas

Fue desarrollado para realizar códigos productivos y legibles facilmente

Influenciado por ADA, C++, CLU, DYLAN, EIFFEL, LISP, PERL y PYTHON

C, PERL, TCL, JAVA Y C++

ABC, ALGOL 68, C, C++, ICON, JAVA, LISP Y PERL

Usados actualmente por Twitter, Hulu y Groupon Wikipedia, Udemy y Facebook

Youtube y Google

Utilidad

Usualmente descrito como: elegante, poderoso y expresivo. Su mayor ventaja es la capacidad para minimizar los errores del propio programador.

Permite un enfoque clásico de programación y cuenta con una amplia documentación para posibles consultas.

Es un lenguaje muy estructurado, y probablemente sea el más legible de los existentes por el momento.

Facilidad de aprendizaje

Es conveniente tener soltura programando antes de aprender Ruby.

Resulta fácil de aprender para personas que sólo saben C.

Es perfecto para usuarios que comienzan con la programación.

Tabla 1: Comparativa de lenguajes interpretados en servidor web

Ruby puede combinarse con distintos servidores dependiendo de las características esperadas de la págia web: número de visitas simultáneas, cantidad de contenido dinámico… Entre ellos pueden destacarse:

- Webrick: servidor por defecto para diseños en Ruby on Rails.

- Nginx

Herramientas

8

- Unicorn

- Passenger

2.5.2 HTML5 y CSS

HTML5 [10] (HyperText Markup Langugage versió 5) es el último estándar de HTML. Este último nació en 1999. Las páginas web han evolucionado mucho en los últimos años, por lo que ha sido necesario actualizar la versión del lenguaje empleado. HTML5 es un lenguaje multiplataforma y que prentede minimizar el uso de plugin externos en una web. La sintaxis no difiere del HTML tradicional, simplemente se distingue de éste en un aumento del número de etiquetas disponibles.

CSS [10] (Cascading Style Sheets) define la forma de mostrar elementos HTML. Se diseñan hojas de

estilo con extensión css que son externas al código HTML, organizando el trabajo del programador.

2.6 Librería Chart.js Chart.js [11] es una librería [11] de java scripts que permite dibujar gráficas a partir de una serie

de datos de entrada. Pueden elegirse distintos resultados visuales: gráficas de líneas, de barras, circulares, polares… La decisión de usar esta librería recae en su comodidad para obtener datos de archivos JSON, su estética, su sencillez y su amplia documentación.

2.6.1 Comparativa con otras librerías

Tipos de gráficas soportadas Interactividad Tecnologías

Line Area Donut Radar Gantt onClick mouseOver HTML5 VML

Chart.js ✓ ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✗

xCharts ✓ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗

canvasXpress ✓ ✓ ✗ ✗ ✗ ✓ ✓ ✓ ✓

Flot Charts ✓ ✓ ✓ ✗ ✗ ✓ ✓ ✓ ✗

FusionCharts ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Tabla 2: Comparativa de librerías JS para generar gráficas

Como se observa en la comparativa de la tabla 2, Chart.js no es la que más ventajas tiene. Es evidente que FusionCharts es mucho más completa. Pero la primera cumple con los requisitos que se necesitaban, así que se ha optado por ella. Existen una multitud de librerías además de las comparadas en este apartado. Si se necesitasen unas prestaciones distintas en el futuro podría cambiarse fácilmente de librería, ya que el código correspondiente a Chart.js está perfectamente aislado del resto de la web.


2.7 Java Script Object Notation

Se define Java Script Object Notation, más conocido por JSON, como “un formato ligero de intercambio de datos” [12], un formato de texto independiente del lenguaje que lo utiliza. Es útil porque mientras que, cara a los usuarios es fácil de escribir y leer, cara a las máquinas es sencillo generarlo e interpretarlo. JSON tiene un formato claro y organizado, formado por dos estructuras básicas que son soportadas por todos los lenguajes de programación, como se indica al final del apartado:

- Un conjunto desordenado de objetos: una serie de pares nombre-valor. Los objetos se indican entre llaves. El nombre se separa del valor mediante “:” (dos puntos). Para separar un objeto de otro se utiliza “,” (una coma).

- Una lista ordenada de valores object_json { “nombre1”: valor1, “nombre2”: valor2, . . . “nombreN”: valorN }

2.8 Elementos Secundarios En los siguientes apartados se incluirán las herramientas que han ayudado al desarrollo del proyecto en

un segundo plano. Para ello se describirán brevemente los programas utilizados para la creación de diagramas, el montaje de máquinas virtuales y la realización de la memoria.

2.8.1 OmniGraffle y Gliffy

Es una aplicación para Mac OS que permite la realización de diagramas de todo tipo. Pueden utilizarse imágenes externas, formas predeterminadas, líneas…En concreto, en el proyecto, ha sido utilizada para el diseño de los diagramas UML que apoyan las explicaciones. La versión utilizada es la 6.0.5. Gliffy es un producto online que permite crear diagramas profesionales de manera rápida e intuitiva. Lo cómodo de su uso es la posibilidad de realizar los diagramas directamente sobre el navegador.

2.8.2 VMware Fusion

Tanto el router como los clientes, han sido desarrollados sobre máquinas virtuales como ya se ha mentado a lo largo de la memoria (a excepción de un cliente extra que será el propio equipo de desarrollo, como ya se explicará más adelante). La versión de Debian utilizada se indicó en la sección 2.1. Sin embargo, para el montaje de máquinas virtuales ha sido necesaria una herramienta extra. En este caso se ha utilizado la versión profesional de VMware Fusion© 6.0.0.

Herramientas

10

2.8.3 Microsoft Word

La memoria del proyecto se ha realizado sobre Microsoft Word© 2007. Se ha utilizado la plantilla que se ha proporcionado en la página web oficial de la Escuela de Ingenieros de Sevilla, para respetar el formato acordado por la Universidad.

11

3 ARQUITECTURA

na vez se conocen las herramientas y lenguajes de programación que se utilizarán, pasemos a ver como colaboran en cada componente del proyecto para conseguir una funcionalidad general. El escenario que se simulará se muestra en la figura 3.

Imagen 3: Escenario simulado

Básicamente, una visión general del mismo sería la siguiente: un servidor web Ruby on Rails, conectado a un router con sistema operativo Debian e iptables implementadas, muestra una serie de estadísticas de tráfico de su subred interna. Los clientes, también conectados a ese router, podrán solicitar información al servidor web, el cuál mostrará sus datos en forma de gráficas (generadas con Chart.js).

A continuación, sobre el modelo real del proyecto, mostrado en la figura 4, se irá explicando el objetivo de cada elemento, así como su instalación y funcionamiento.

U

Arquitectura

12

Figura 4: Diagrama de despliegue del escenario real

3.1 Router

“Encaminar: dirigir algo hacia un punto determinado” - RAE -

3.1.1 Instalación

El papel de router será desarrollado por el equipo central. El Sistema Operativo sobre el que se implementa el proyecto es Debian. Como se explicará más adelante, en este mismo elemento se encontrará el servidor web al que le haremos las consultas. El equipo central, (de aquí en adelante será referido como router), hace de intermediario entre una subred interna e Internet. Por tanto, todo tráfico entrante o saliente a dicha subred deberá pasar por él antes de salir al exterior.

En Debian, para la configuración del router hay que editar el fichero:

/etc/network/interfaces El resultado final del fichero “interfaces” se encuentra en el anexo A. El router se configurará con dos interfaces diferentes: - eth0: configurada mediante DHCP, será la que se comunique directamente con el router real que da salida a internet. - eth1: con IP 193.147.162.1 ejercerá de gateway de la subred interna. La elección de esta IP concreta se justificará cuando se hable de los clientes. Para que funcione el escenario es necesario que el router realice NAT para que sea posible la comunicación de la subred interna con Internet. Por tanto, hay que añadir una primera regla de iptables: iptables -t nat -A POSTROUTING -o eth_salida_internet -j MASQUERADE

3.1.2 Implementación de reglas de contabilización

Una vez tenemos el router activo hay que introducir las reglas que lo dotarán como firewall. Las reglas de iptables se instancian ejecutando el script account.sh (detallado en el anexo A). En este script se


crea una cadena de usuario TRAF, que a su vez actuará en la cadena FORWARD, (se aplicará a todos los paquetes que tenga que ser reenviados por el router). El conjunto de reglas que contiene TRAF, en general, contabiliza el tráfico con fuente o destino en el rango de IPs 193.147.162.129-193.147.162.187, con protocolo TCP/UDP.

Ahora que están introducidas todas las reglas se tiene un equipo que ejerce de router de una subred, y que además contabilizará el tráfico que conmute.

3.2 Servidor Web

“Servidor: Inform. Unidad informática que proporciona diversos servicios a computadoras conectadas con ella a través de una red” - RAE -

3.2.1 Instalación

Como ya se indicó en la introducción, el servidor del proyecto se desarrolla en Ruby on Rails. Hay dos opciones para realizar la instalación: rvm [12] o mediante compilación de código fuente. La opción elegida en este proyecto es la primera, lo que ofrece una instalación rápida y simple.

1. Instalar ruby mediante rvm:

curl -sSL https://get.rvm.io | bash -s stable --ruby

2. Instalar tantas gemas como se desee, incluida Rails:

gem install rails

3. Resta por crear el servidor web en sí. Para ello, utilizamos el comando:

rails new pfg Con estos tres pasos se consigue el árbol de directorios necesario para configurar un servidor en Ruby on Rails. En una máquina con un sistema operativo Debian que trabaja con 2 gigas de memoria RAM y un núcleo, estos tres pasos solo llevarán unos cinco minutos aproximadamente.

3.2.2 Servidor Ruby on Rails

En la figura 5 se muestra la estructura de directorios que se genera con los pasos anteriores. Ésta es una de sus grandes ventajas: produce un orden inherente para almacenar los ficheros. Por ejemplo, como se observa en la figura 5, en la última carpeta (“vendor”) se genera automáticamente un subdirectorio llamado “javascript”. Éste sirve para incluir las librerías js que puedan ser necesarias en la página web. Al incluir código de esas librerías en cualquier fichero, Ruby on Rails lo detectará y buscará directamente en dicha ubicación.

Arquitectura

14

Figura 5: Estructura de Directorios de Ruby on Rails

Bien es cierto, que no todas las carpetas han sido necesarias para la realización del proyecto. Por ello, a continuación se irán describiendo de forma fraccionada partes de este gran árbol de directorios, dando información de cada uno. En el anexo B, se encuentra el contenido adicional a las explicaciones del apartado: ficheros que han sido necesarios y directorios añadidos. Se comenzará con el conjunto de carpetas que nos encontramos justo al entrar en la aplicación. Su estructura se muestra en la figura 6:


Figura 6: Estructura Inicial RoR

- Directorio “app”: es el directorio central de la aplicación web. Contiene los controladores, modelos,

vistas, helpers… Aunque después se volverá a esta carpeta, en esta ocasión sólo hablaremos del directorio assets:

- Directorio “assets”: contiene distintas carpetas para organizar el estilo de nuestra aplicación.

Cuando en una vista, (explicadas más adelante), se insertan imágenes, ficheros de estilo css… La aplicación acude directamente a este directorio, no hay que indicárselo. Las tres carpetas que posee por defecto son:

- “Images”: contendrá las imágenes utilizadas en las vistas, en cualquier formato (png, gif, jpeg…). En la aplicación, cuando necesite insertarse alguna, no habrá que poner la ruta entera hasta este fichero. Sólo hay que utilizar el nombre con el que se haya guardado la imagen.

- “Stylesheets”: los ficheros que se alojan aquí poseerán el formato .css.scss. Son ficheros

de estilo habituales, exactamente como los css que se integran con html en otro tipo de servidores. El nombre debe ser el mismo que el de la vista con la que se tiene que asociar, para que RoR sepa cuándo aplicarlo.

- “Javascripts”: los ficheros que se guardan en este directorio tienen un formato un poco

especial, son “.js.coffee”. Coffee [13] es un pequeño lenguaje que se compila dentro de javascript, y que difiere un poco de la sintaxis habitual. Se genera, por defecto, un fichero .js.coffee por cada vista. Puesto que en este proyecto, el uso de javascript se limita a la inserción de gráficas en la web (comandos simples y mecánicos), no se ha considerado necesario utilizar este componente.

Un fichero relevante de este directorio es application.js. Contiene la lista de ficheros que deben ser compilados para usarlos en la aplicación. Las librerías que se utilicen deben añadirse instancias utilizando la notación:

Arquitectura

16

//= require librería

Para este proyecto solo ha sido necesario insertar la librería Chart.js, para lo cuál se han añadido la lineas adicionales:

//= require Chart //= require excanvas

- Directorio “vendor”: aquí se ubican todo tipo de código “externo” a la aplicación, las librerías

necesarias que quieran insertarse, incluyendo las propias gemas de Ruby. Es una aplicación típica de Rails. Dentro de este directorio, de nuevo se encuentra dos carpetas por defecto: javascripts y stylesheets. Se utilizan con fines similares a las explicadas anteriormente. Sin embargo, el directorio javascripts de vendor sirve para almacenar las librerías externas que van a utilizarse en la aplicación.

En este proyecto, se encontrará alojada la librería “Chart.js”, utilizada para generar las gráficas de

la web. - Directorio “db”: contiene la base de datos, en caso de utilizarse en la aplicacion, así como las

migraciones necesarias. - Directorio “config”: Ruby on Rails cuenta con una serie de alias para utilizar las rutas del árbol de

directorios de la aplicación. Para configurarlas utilizamos los ficheros alojados en este directorio. En concreto, cabe destacar el fichero routes.rb. En él puede indicarse quién será la página principal de la aplicación o indicar hacia qué método concreto del controlador nos gustaría tener un alias.

Para consultar qué alias tenemos creadas en nuestra aplicación basta con ejecutar en la consola el

comando:

rake routes En concreto para este proyecto, el resultado de ese comando sería el mostrado en la figura 7:

Figura 7: Lista de rutas del proyecto

En el apartado 2, ya se explicó el patrón seguido por Ruby on Rails (MVC). Ahora se explicará el patrón sobre el propio sistema de directorios que componen el servidor, así como los distintos ficheros que deben incluirse en cada uno. La figura 8 muestra la estructura dentro del árbol de directorio de rails. La carpeta que contiene el patrón es app:


Figura 8. Modelo Vista Controlador en RoR

- Directorio “controllers”: contiene ficheros escritos en ruby. Habrá un fichero por clase de la aplicación. El formato a seguir en todos ellos es el siguiente:

class nombre_controladorController < ApplicationController def nombreMetodo end end

Cada controlador hereda de ApplicationController y el nombre debe comenzar con una letra minúscula. Los métodos se definen como se especifica en el código anterior. Para crear un controlador se puede incluir el fichero en sí, con un editor de texto o ejecutar en el terminal el comando:

rails generate controller nombre_controlador nombreMetodo - Directorio “views”: incluye ficheros de ruby embebido que contienen html (.html.erb). Será la interfaz que se vea en la página web. Habrá un fichero por vista. Dentro de este directorio se crea una carpeta por controlador, con el mismo nombre del mismo. En su interior se alojarán los ficheros que se necesitarán para generar su vista. Los ficheros tendrán el nombre del método del controlador que los cargue. De nuevo, pueden crearse estos subdirectorios de dos formas: si el controlador ha sido generado mediante un comando en la consola se crean automáticamente; si no, habrá que hacerlo de forma manual. Los ficheros del directorio “views” no siguen el patrón clásico de html, en ellos solo se incluye el código correspondiente al <body> de un documento html. Además pueden introducirse script en

Arquitectura

18

javascript, jquery… o cualquier otro lenguaje que se combine con html en el lado cliente. Como ya se explicó, RoR sabe dónde buscar las librerías necesarias para comprender el script correspondiente. - Directorio “models”: los ficheros de este directorio tienen un nombre en singular, y la base de datos que lleva asociada adquiere el mismo pero en plural. Una vez más, se puede crear el modelo de forma manual o mediante el siguiente comando:

rails generate model Nombre_modelo La ventaja de utilizar este segundo modo de creación es que generaríamos directamente el modelo y la base de datos correspondiente, (se generarían los ficheros app/models/nombre_modelo.rb y db/migrate/20140261191729_create_nombre_modelos.rb Entre otras funciones, los modelos sirven para validar variables e interaccionar con la base de datos de la aplicación. No se entrará en más detalles sobre el formato de los ficheros correspondientes al modelo, ya que no han sido necesarios en la realización del proyecto.

3.2.2.1 Estructura final

Para la realización del proyecto ha sido necesario añadir subdirectorios dentro del patrón básico de MVC. Se explicará la función de cada controlador. No se entrará en más detalle acerca de todos los ficheros añadidos, ya que, cada uno cumple las funciones expuestas en el apartado anterior: - “main_controller.rb”: carga la vista principal. Simplemente se muestra un resumen con la funcionalidad de la web. Los siguientes controladores constan de un único método, “getinfo”. En esencia, la función que realiza es recolectar información de un fichero de texto en formato JSON. Lo que diferencia a unos controladores de otros son los campos que toman del json. - “global_controller.rb”: muestra gráficas con resúmenes de estadísticas: UDP entrante y saliente, TCP entrante y saliente, uso del puerto 80… pero a lo largo de varias horas. Existirá un punto en la gráfica por cada intervalo. - “ips_controller.rb”: las gráficas que genera filtran el tráfico por IP. Para un intervalo concreto de tiempo muestran qué IPs de las monitorizadas han generado tráfico, qué cantidad (en octetos y paquetes) y de qué protocolo (UDP o TCP). - “ports_controller.rb”: su resultado son tres gráficas de barras y una circular. En las primeras, se muestra tráfico de los puertos 80 y 25 en un intervalo de tiempo concreto. En la circular, se compara en octetos el tráfico http y smtp generado en dicho intervalo. - “tcps_controller.rb” y “udps_controller.rb”: muestran, para los protocolos TCP y UDP respectivamente, tráfico entrante y saliente en paquetes y en octetos.

3.2.3 Estilo

Puesto que la aplicación tiene como finalidad recolectar estadísticas sobre el tráfico del departamento de telemática, he considerado adecuado seguir el modelo del servidor (trajano.us.es). Por tanto, la web presentará una interfaz como la mostrada en la figura 9. En concreto, esa es la página principal de la aplicación. Cada uno de los enlaces cargará una nueva vista con una estructura similar. La única diferencia será el cuerpo de la pantalla, en el que se mostrará la gráfica correspondiente precedida de su título.


Figura 9: Página web principal (diseño)

Acerca del estilo se puede concretar: - Colores utilizados: mostaza (#FFCC66) y burdeos (#660000) - Encabezado de las vistas: imagen red.jpg situada, evidentemente, en app/assets/images/ y un índice con las distintas opciones - Pie de página: datos sobre el proyecto en caso de la vista inicial, y enlace a la misma desde las otras. - Cuerpo de cada vista: información de la pestaña correspondiente. En caso de la página principal, se muestra una descripción de la funcionalidad de la web. Los ficheros .css.scss se encuentran en el anexo C. Como se observará, existe uno por cada controlador.

3.3 Cliente “Cliente: Inform. Programa o dispositivo que solicita determinados servicios a un servidor del que depende.” - RAE - Para la realización del proyecto se han elegido dos clientes sobre sistema operativo Debian, por uniformidad. No requieren una configuración especial. Sólo se ha tenido en cuenta el detalle de darle direcciones IPs del rango de las monitorizadas, y de establecer como su gateway el router simulado. De esta forma, el tráfico que generen quedará monitorizado. Es por ello, que la IP elegida para el router haya sido la primera de la subred interna a monitorizar. El proyecto se ha realizado en un equipo con sistema nativo Mac OS. Éste también desempeñará el rol de cliente por la otra subred a la que está conectado el router. En el diagrama de casos de uso de la figura 10 se esquematiza el resultado final.

Arquitectura

20

Figura 10: Diagrama de Casos de Uso del Escenario

21

4 FUNCIONAMIENTO DEL ESCENARIO

n este capítulo se estudiará la interconexión general de los componentes, pero centrándonos en la función que desempeñada cada uno para llegar al objetivo final. Se irán describiendo los distintos mecanismos que suceden desde que se genera tráfico hasta que el servidor acaba mostrando una

gráfica con los resultados. La situación de partida es con las reglas de iptables implementadas en el router y los clientes, conectados ya a él, generando tráfico que será recogido. Cabe recordar que el servidor web se encuentra en el equipo que realiza de router, por lo que la información no debe ser transmitida entre componentes. Se dejará para el siguiente apartado las pruebas concretas que se han realizado en el proyecto. Por ahora se supondrán que el cliente genera un tráfico general y que, posteriormente, consulta la web para observar las estadísticas.

4.1 Recolección de información

En esta sección se explicará cómo se obtienen los datos de iptables en el formato que interesa para dar el siguiente paso, en concreto JSON. Como ya se comentó, el proyecto hace uso del cron de Debian. Se ha configurado de modo que se ejecute el script daemon.sh, detallado en el anexo A, cada quince minutos. Para ello, hay que añadir al fichero /etc/crontab la línea:

*/15 * * * * /home/servidor/webServer/daemon.sh Este script básicamente se limita a generar un fichero de logs en /var/log/daemonMark.log, y a

invocar al script en ruby daemonGlobal.rb. Este fichero también se expone en el anexo A, junto a todos los que se utilizan en esta sección, pero se explicará su funcionamiento general sobre el diagrama de flujo de la figura 12. Antes de comenzar se presentarán los ficheros participantes: - “markGlobal.txt”: fichero que almacena una marca de tiempo para saber cuándo hay que resetear el fichero “global.txt” - “global.txt”: fichero que almacena eventos en json. Éstos serán representados en la gráfica que realiza un resumen de tráfico a lo largo de varias horas. Cada evento json contendrá los siguientes campos: {:time=> “Hora en que se genera el evento”, :inUdp=> “Resumen de tráfico UDP entrante”, :outUdp=> “Resumen de tráfico UDP saliente”, :inTcp=> “Resumen de tráfico TCP entrante”, :outTcp=> “Resumen de tráfico TCP saliente”, :http=> “Resumen de tráfico http”, :inSmtp=> “Resumen de tráfico SMTP entrante”, :outSmtp=> “Resumen de tráfico SMTP saliente”}

E

Funcionamiento del escenario

22

En la gráfica habrá veinticuatro puntos, por lo que el fichero tendrá que ser reseteado al llegar a los veinticuatro eventos. Como se verá en el diagrama de flujo, esto implica resetear el script cada seis horas. Se ha elegido este límite por fijar un final. Podría configurarse para cualquier otro. - “fileAux.txt”: almacena la salida de iptables estructurada por columnas en las que se representan: origen, destino, flujo de paquetes, flujo de octetos y protocolo utilizado. - “iptablesJson.txt”: almacena, en formato JSON, la salida de iptables en un instante concreto. Se crea a partir de fileAux.txt. No es necesario por tanto que contenga ninguna marca de tiempo. - “trafico.sh”: este script es el encargado de generar “fileAux.txt”. Simplemente ejecuta iptables -L y trabaja sobre la salida que proporciona el propio comando. - “reset.sh”: resetea iptables. - “account.sh”: introduce las reglas de iptables.

A continuación se enumeran los distintos pasos que se siguen en el script, los cuales se señalan en la figura 11: 1. Se incluye una marca de tiempo en el fichero “mark.txt”. Si no existe se crea, y en caso contrario se comprueba si ha llegado el momento de resetear el fichero “global.txt”. 2. Se borran los ficheros “iptablesJson.txt” y “fileAux.txt” porque habrá que crearlos de nuevo en esta ejecución. 3. Ejecutamos el script “trafico.sh” y hacemos la conversión del fichero auxiliar al fichero “iptablesJson.txt”. 4. Se va mapeando el nuevo fichero json para obtener los campos de información que interesan, generando así un resumen de tráfico. 5. El resultado del punto 4 es un nuevo evento JSON que se incorparará a “global.txt”. 6. Por último, se ejecutan “reset.sh” y “account.sh” para dejar las reglas de iptables listas para empezar un nuevo conteo.


Figura 11: Diagrama de flujo del scrip “daemon.sh”


24

Por tanto, al finalizar el script ¿qué ficheros de interés se han generado?

- global.txt: una línea nueva cada quince minutos.

- iptablesJson.txt: información detallada recolectada por iptables en el último cuarto de hora.

4.2 Consulta de información

Esta sección se dividirá en función del fichero que se quiera consultar, ya que cada uno tiene un trato distinto por el tipo de información almacenada.

4.2.1 Información global

El fichero leído es “global.txt”. El controlador “global_controller.rb” guarda el fichero en una cadena, declarada como variable global del sistema, que posteriormente es utilizada por la librería Chart.js.

4.2.2 Información concreta

Para el caso del fichero iptablesJson, la consulta de información es algo más compleja. Ya no interesa el fichero entero, por lo que cada controlador debe seleccionar qué campos enviarle a la librería Chart.js mediante variables globales. Para ello, el mecanismo es siempre el mismo y se presenta en el diagrama de la figura 12:

Figura 12: Diagrama de flujo general de los controladores


4.3 Edición de gráficas

Como resulta evidente, las gráficas se crean en las vistas. Para insertar el código en Java Script se utilizan las etiquetas de HTML <script>, al final del fichero correspondiente.

En este punto del proceso se tiene la información relevante guardada en variables globales, por lo que cada script tomará la que necesite. Para ello es necesario insertar código ruby en el script:

var myVarJS = <%= @var_Ruby %>

Para generar y situar una gráfica se utilizan los dos comandos inferiores. Las gráficas se emplazan en el elemento <canvas> de HTML5. Para ello, en el primer comando se toma el identificador del mismo, y en la segunda se genera la gráfica correspondiente. “type_graph” debe ser sustituido por el modelo que queramos usar. Los tipos de gráficas utilizados en este proyecto junto con sus nombres se muestran en la figura 13.

var ctx = $(“#id_canvas”).get(0).getContext(“2d”);

var myChart = new Chart(ctx).type_graph(chartData);

Figura 13: Tipos de gráficas utilizados

El parámetro que recibe la gráfica es un mapa formado por los datos del eje X (labels) y del eje Y (datasets). Es aquí donde donde se mapean las variables globales leídas en el script. Labels y dataset reciben arrays formado por los valores que se mostrarán en la gráfica. Para ello se ha utilizado un nuevo método llamado “mapProperty” [14], que mapea un array y devuelve uno nuevo con los valores leídos. Tomando uno de los casos utilizados en el proyecto, la dinámica sería la siguiente:

tcps_controller.rb

@graph_octetos_tcp = [{:data => 20, :type => ”Entrantes”},

{:data => 30, :type => ”Salientes”}].to_json.to_s


26

/tcps/getinfo.html.erb

Por tanto, el proceso de edición de gráficas es simple y puede resumirse en los siguientes puntos:

1. Se toma la variable global generada en los controladores.

2. Se mapean los campos deseados y se le asignan a los elementos “labels” y “dataset”.

3. Se lanza la gráfica.

var myOctetos = <%= @grap_octetos_tcp.html_safe %>

/* myOctetos = [{:data => 20, :type => ”Entrantes”},

{data => 30, :type => ”Salientes”}] */

octetosChartData = {

labels : myOctetos.mapProperty(‘type’),

// labels = [“Entrantes”, “Salientes”]

datasets : myOctetos.mapProperty(‘data’)

// datasets = [20, 30]

}

27

5 PRUEBAS REALIZADAS

n este capítulo se describen las pruebas de funcionamiento realizadas al proyecto. Se mostrarán imágenes en cada apartado con los resultados obtenidos. A gran escala, las pruebas se limitan a generar distintos tipos de tráfico entre equipos simulados de la subred de trajano. Se estudiarán

distintas situaciones que pueden presentarse.

5.1 Recolección de estadísticas en estado periódico

Cuando se habla de estado periódico se está suponiendo que el cron está programado para que ejecute el script daemon.sh cada quince minutos, y que la gráfica que muestra resultados globales será reseteada cada seis horas.

5.1.1 Consultas del último intervalo de tiempo

En este apartado se harán dos configuraciones distintas en las máquinas virtuales:

A) Visualizar un tipo de tráfico concreto

Se configurarán dos máquinas virtuales con una IP cada una del rango 193.147.163.120 – 193.147.163.187. Ambas interfaces tendrán como gateway la dirección 193.147.163.1.

B) Visualizar tráfico por IPs

Se configurarán dos máquinas virtuales con varias IPs cada una del rango 193.147.163.120 – 193.147.163.187. Todas las interfaces tendrán como gateway la dirección 193.147.163.1. La forma de generar tráfico en este caso requiere un cuidado especial: debe realizarse siempre una comunicación cruzada. Es decir, aunque una máquina virtual posea varias IPs no debe generarse tráfico entre ellas. En esta simulación, el tráfico se enviaría por la interfaz “lo” de la máquina, por lo que no pasaría por el router para ser contaiblizado.

Las opciones posibles para visualizar tráfico en un intervalo de tiempo concreto son:

• TCP (escenario A)

Se consultarán web externas, como por ejemplo cuentas de correo electrónico, para generar tráfico que viaje sobre TCP. Con ellos se obtienen resultados como los mostrados en la figura 14.

• UDP (escenario A)

Se realizarán pings a distintas IPs externas desde los dos equipos simulados, así como entre ellos mismos. Como consecuencia, la monitorización da lugar a una gráfica como la de la figura 15.

• Tráfico por IP (escenario B)

Surge como consecuencia de las pruebas anteriores. Pero como lo interesante en estas gráficas es que resume el tráfico cursado desde/hacia cada IP, realizaremos pruebas como las anteriores en el escenario B. En la figura 16 se distinguen las IPs utilizadas y el tipo de tráfico generado.

• SMTP y HTTP para la IP 193.147.163.130 (servidor trajano)

Trajano es un servidor real, y la monitorización de su tráfico se basa en los puertos 80 y 25. Para conseguir este resultado tendría que simularse un escenario con un servidor real, o bien hacer las pruebas sobre el propio departamento. Puesto que el mecanismo de recolección de datos es el mismo que en los casos anteriores, no se ha considerado necesaria una simulación real para trajano. En este

E

Pruebas Realizadas

28

caso, el tráfico se ha introducido manualmente en el fichero JSON correspondiente. Con ello, han podido generarse las gráficas de tráfico correspondientes en la pestaña “Uso Trajano” de la web. Se crearán gráficas de barras como en los otros casos, pero además, solo para trajano, se genera la gráfica mostrada en la figura 17.




Figura 16: Tráfico monitorizado por IP

Figura 17: Resumen trajano (gráfica tipo “Pie”)

5.1.2 Consulta global

Por último, el funcionamiento de la gráfica global no es más interesante en un escenario que en el otro. Basta con estar generando tráfico que se encamine por el router. Cada quince minutos aparecerá un nuevo punto en la gráfica hasta llegar a veinticuatro, (seis horas de monitorización), donde se comenzará la cuenta de nuevo.

En las figuras 18 y 19 se muestran los resultados tanto de la primera hora de monitorización, como del último punto previo al reseteo de la gráfica, respectivamente. En marrón se muestra el tráfico UDP y en azul el TCP.

Pruebas Realizadas

30

Figura 18: Tráfico entrante en octetos en gráfica global (una hora)

Figura 19: Tráfico entrante en octetos en gráfica global (seis horas)

5.2 Recolección de estadísticas en estado forzado En esta sección lo que se pretende es simular un estado forzado del sistema. Para ello se supone que

hay un intervalo concreto de tiempo que quiere analizarse. Se parte de la base de que el tráfico mostrado, ya sea en detalle o de forma global, mide estadísticas cada quince minutos. La prueba siguiente consiste en ejecutar manualmente el script daemon.sh en mitad de uno de los intervalos.

La configuración en esta sección será la básica: dos máquinas virtuales con una IP cada una del rango 193.147.163.120 – 193.147.163.187. Ambas interfaces tendrán como gateway la dirección 193.147.163.1. No se distinguirán los dos casos de la sección anterior porque el resultado va a ser el mismo, sólo que en un intervalo de tiempo más pequeño.

5.2.1 Consultas del último intervalo de tiempo

En este apartado no se incluyen imágenes porque no van a apreciarse diferencias respecto de las gráficas anteriores. Simplemente el intervalo de tiempo monitorizado es menor.


5.2.2 Consulta global

En este caso la gráfica sufre una modificación respecto la de la sección anterior: se añade un punto extra. La gráfica se reseteará a las seis horas como hasta el momento, sólo que ahora tendrá un punto una hora diferente a su rutina: la hora a la que se ha ejecutado el script. El resultado sería similar al mostrado en la figura

20, donde se señala el punto extra.


33

6 CONCLUSIONES

• Como herramientas de recolección de información se ha optado por una combinación de “iptables” con un “cron”. Es decir, dos herramientas intrísecas a Debian. Ha sido una buena elección ya que se ahorran instalaciones adicionales, poseen una sintaxis clara y hay una amplia documentación al respecto.

• El uso de Ruby on Rails como lenguaje para la parte de desarrollo web ha sido muy positivo. Su instalación es simple y rápida. Ofrece un sinfín de posibilidades para añadir nuevas funcionalidades. Puede combinarse, como ya se indicó en el documento, con una multitud de servidores distintos, (atendiendo a las prestaciones que se preetndran ofrecer). Además, su organización estructurada con patrón MVC facilita la comprensión del sistema para programadores exteriores.

• La librería “Chart.js” ha cumplido el objetivo deseado. Las gráficas son totalmente personalizables, y existen más tipos aparte de los usados en el proyecto. Además su uso ha sido sencillo. Al permitir la lectura de archivos JSON, facilita el paso de datos infinitamente. Así, pueden añadirse gráficas sin más que repetir el código cambiando el campo que interesa leer del JSON.

• En general, el proyecto muestra una forma nueva e interesante de analizar tráfico en una subred. Por los elementos que utiliza para cumplir su objetivo, ocupa poco espacio en el equipo en el que se instale. Al haberse realizado “a base” de Shell Scripts sobre Debian, unifica su exportación a otros equipos con sistema operativo Unix. Es sencillo añadir nuevas IPs a monitorizar, ya que no habría que alterar en absoluto el servidor Rails. Bastaría con crear nuevas reglas de iptables en el script correspondiente. Con ello puede observarse que los componentes del proyecto son independientes unos de otros, como se muestra en la figura 21, facilitando futuras modificaciones.


“Lo importante es no dejar de hacerse preguntas.”

- Albert Einstein -

Conclusiones

34

6.1 Líneas futuras En este apartado se proponen futuras mejoras que podrían realizarse sobre el proyecto, aumentado sus

funcionalidades o seguridad. Antes de ello, sólo decir que el proyecto ha sido probado en el departamento, monitorizando tráfico real con resultados positivos:

• Podría realizarse una pestaña extra en la web para facilitar las tareas del usuario en caso de ejecución forzada: en esa pestaña, sin más que pulsar un botón, se ejecutaría un script muy similar a daemon.sh y se mostrarían las gráficas desde el último reseteo hasta ese momento. La utilidad de realizar un nuevo script para esta función es que así podrían mantenerse intactas las otras gráficas. Con esta pequeña modificación no se perdería en absoluto la periodicidad de la web y además, el usuario tendría control total de ejecución de los script desde su navegador web.

• Actualmente, la web creada sólo es accesible desde las subredes a las que se encuentra conectado el router. En el caso concreto del proyecto son: 193.147.162.x y la subred propia del wifi. Sería interesante que la página web pudiese consultarse desde cualquier IP, es decir, el montaje de un servidor real. En la memoria se proponen distintos servidores con los que Ruby on Rails se combina fácilmente. También existiría otra opción, bien es cierto que es mucho más insegura, que sería configurar una nueva regla de iptables. Con ello, podría montarse un servidor habitual escuchando en el puerto 80 del equipo y, todo lo que llegase a este puerto, sería redirigido al 3000, (puerto donde escucha Rails).

• También podría ser útil guardar información global durante más de seis horas. Podrían almacenarse incluso información de días, y combinando RoR y Chart.js añadir opciones de zoom y filtrado en la gráfica global.

• Como medio de seguridad, resultaría conveniente que no todos los usuarios pudiesen visualizar el tráfico de esta subred interna. Para ello la solución podría ser un registro previo en la página web. Ruby on Rails facilita la tarea, ya que cuenta con su propio sistema de base de datos. En ella se almacenarían una serie de usuarios que tendrían que autenticarse para realizar consultas a la web.

• A la hora de ampliar las funcionalidades es conveniente tener claros los límites de iptables, ya que es el filtro que se aplica a los flujos de información. Evidentemente, cualquier aumento de rango de monitorización se resume en añadir nuevas reglas de iptables. Esta herramienta no pasa del nivel 4 del modelo OSI, es decir, ve tráfico en función de IP y puerto. No traduce alias. Sin embargo, cuenta con módulo como conntrack que permiten un estudio más profundo del tráfico: permite el seguimiento de conexiones. No se han empleado módulos en este proyecto, por tanto aún podría exprimirse más la monitorización de la red.

o Una mejora de “otro nivel” sería cambiar al uso del protocolo NetFlow.

35

REFERENCIAS

[1] «Wstats: stats on the move» [En línea] [Web] Disponible: wstats.net

[2] «Enderunix - Isoqlog: Multi Functional Mail Server Log Analyzer» [En línea] [Web]

Disponible: www.enderunix.org/isoqlog/ [3] «Debian: The Universal Operating System» [En línea] [Web]

Disponible: www.debian.org [4] «Netfilter: firewalling, NAT and packet mangling for linux» [En línea] [Web]

Disponible: www.netfilter.org

[5] Peter Seebach, « Beginning Portable Shell Scripting», 2008 ISBN: 978-1-4302-1043-6 [6] «Lenguaje de Programación Ruby» [En línea] [Web]

Disponible: www.ruby-lang.org [7] «Rails Guides» [En línea] [Web]

Disponible: guides.rubyonrails.org [8] Jarkko Laine, Christian Hellsten «Beginning Ruby on Rails E-Commerce», 2006 ISBN: 978-1-59059-736-1 [9] Ernest Teniente López, Antoni Olivé Ramon, Enric Mayol Sarroca, Cristina Gómez Seone

« Diseño de sistemas software en UML », 2003 ISBN: 84–8301–724–5 [10] «Online Web Tutorials» [En línea] [Web]

Disponible: www.w3schools.com [11] «Open source HTML5 Charts» [En línea] [Web]

Disponible: www.chartjs.org [12] «Ruby Version Manager» [En línea] [Web]

Disponible: rvm.io [13] «Coffee Script Language» [En línea] [Web] Disponible: coffeescript.org [14] «Lectura de JSON para Chart.js» [En línea] [Web]

Disponible: kushagragour.in

37

ANEXO A: SISTEMA OPERATIVO DEBIAN

En este anexo se incluyen los ficheros con los que se trabaja directamente sobre el sistema operativo.

Esto es, los ficheros de configuración del router, fichero crontab y scripts.

o CONFIGURACIÓN DEL ROUTER

Hay que editar el fichero /etc/network/interfaces. En él se le asignan nombres y direcciones IP a las distintas interfaces del equipo. Evidentemente la configuración es distinta dependiendo de si el equipo ejerce de router o cliente.

• Router1

• Cliente

1 Para que un equipo encamine paquetes hay que ejecutar además: echo 1 > /proc/sys/net/ipv4/ip_forward

# The loopback network interface auto lo iface lo inet loopback # Salida hacia internet auto eth0 iface eth0 inet dhcp # Gateway de la subred interna auto eth1 iface eth1 inet static address 193.147.162.1

# The loopback network interface auto lo iface lo inet loopback # Interfaz de la subred auto eth0 iface eth0 inet static address 193.147.162.140 gateway 193.147.162.1 # Tantas como quieran simularse… auto eth1 iface eth1 inet static address 193.147.162.141 gateway 193.147.162.1

Anexo A: Sistema Operativo Debian

38

CONFIGURACIÓN DEL CRON

Como ya se explicó en la memoria, el fichero que hay que editar para que el corn funcione es el fichero /etc/crontab. La modificación añadida se señala en negrita en el código inferior:

# /etc/crontab: system-wide crontab # Unlike any other crontab you don't have to run the `crontab' # command to install the new version when you edit this file # and files in /etc/cron.d. These files also have username fields, # that none of the other crontabs do. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) */15 * * * * root /etc/webServer/daemon.sh #

#!/bin/bash mkdir /etc/webServer mkdir /tmp/webServer cp *.sh /etc/webServer cp *.rb /etc/webServer

SCRIPT DE PRECONFIGURACIÓN

configure.sh

Este script es usado para crear ciertos directorios que serán necesarios para los siguientes scripts de configuración. Simplemente “prepara” el sistema para la inserción del recolector.


o SCRIPTS DE CONFIGURACIÓN En este apartado hay que distinguir entre los scripts generales (daemon.sh y daemonGlobal.rb) y los pequeños scripts que los anteriores van invocando. Todos han sido ya explicados en la memoria, con lo cuál simplemente se expondrá el código de los mismos. daemon.sh daemonGlobal.rb

#!/bin/bash

# Varia para cada equipo

source /home/servidor/.rvm/scripts/rvm

ruby /etc/webServer/daemonGlobal.rb &> /dev/null

echo -e "Ultima actualizacion: $(date)" &>> /var/log/daemonMark.log

echo –e "---------------------" &>> /var/log/daemonMark.log

#!/usr/bin/env ruby # -*- coding: utf-8 -*- require 'json' require 'date' # Variables script _inUdp = 0 _outUdp = 0 _inTcp = 0 _outTcp = 0 _http = 0 _inSmtp = 0 _outSmtp = 0 file = "" markNow = 0 resetMark = 6 # Creo el fichero mark.txt if File.exists?('/tmp/webServer/markGlobal.txt') # Incluye una marca para saber si tengo que resetear la grafica global File.open('/tmp/webServer/markGlobal.txt', 'r') do |fmark| system('cat /tmp/webServer/markGlobal.txt') markNow = fmark.gets end # Han pasado resetMark horas? File.open('/tmp/webServer/markGlobal.txt', 'w') do |fmark| if (DateTime.now-(Rational(resetMark,24))).hour.to_i == markNow.to_i File.delete('/tmp/webServer/global.txt') fmark.puts Time.now.hour else fmark.puts markNow end end # continua…


40

else File.open('/tmp/webServer/markGlobal.txt', 'w') do |fmark| fmark.puts Time.now.hour end end # Elimino los ficheros de gráficas if File.exists?('tmp/webServer/iptablesJson.txt') File.delete('/tmp/webServer/iptablesJson.txt') end if File.exists?('/tmp/webServer/fileAux.txt') File.delete('/tmp/webServer/fileAux.txt') end # Tengo que ejecutar el script ./traffic.sh # Toma los valores de iptables actuales # Ordena la informacion # Genera un JSON ---> iptablesJson.txt system(". /etc/webServer/trafico.sh") # Realizo el resumen ---> trabajo con el fichero # Guardo el fichero en variable file File.open '/tmp/webServer/iptablesJson.txt', 'r' do |f1| while line = f1.gets file = file+line end end # Recolecto informacion necesaria jsonArray = JSON.parse(file) jsonArray.each do |json| if json['proto'] == "udp" # Trafico entrante UDP if json['src'] == "anywhere" _inUdp = json['bytes'] + _inUdp # Trafico saliente UDP else _outUdp = json['bytes'] + _outUdp end elsif json['proto'] == "tcp" #Trafico entrante TCP

if json['src'] == "anywhere" _inTcp = json['bytes'] + _inTcp # Trafico saliente TCP else _outTcp = json['bytes'] + _outTcp end


elsif json['port'] == "dpt:_http" # Solo existe trafico entrante _http = json['bytes'] + _http elsif json['port'] == "dpt:smtp" # Trafico entrante SMTP if json['src'] == "anywhere" _inSmtp = json['bytes'] + _inSmtp # Trafico saliente SMTP else _outSmtp = json['bytes'] + _outSmtp end end end # Genero un nuevo JSON: global.txt event = {:time=>DateTime.parse(Time.now.to_s).strftime("%H").to_s+ ":"+DateTime.parse(Time.now.to_s).strftime("%M").to_s, :inUdp=>_inUdp, :outUdp=>_outUdp, :inTcp=>_inTcp, :outTcp=>_outTcp, :http=>_http, :inSmtp=>_inSmtp, :outSmtp=>_outSmtp} file1 = "" jsonArrayGlobal = [] if File.exists?('/tmp/webServer/global.txt') File.open '/tmp/webServer/global.txt', 'r' do |f4| while line1 = f4.gets file1 = file1+line1 end end # Recolecto informacion necesaria jsonArrayGlobal = JSON.parse(file1) end jsonArrayGlobal.push(event) File.open('/tmp/webServer/global.txt', 'w') do |f2| f2.puts jsonArrayGlobal.to_json end # Reset de iptables para renovar valores system(". /etc /webServer/reset.sh") # Introduzco las reglas de nuevo para iptables system(". /etc/webServer/account.sh")


42

• Scripts específicos

account.sh

trafico.sh

# Creacion de cadena de usuario TRAF iptables -N TRAF iptables -I FORWARD -j TRAF iptables -F TRAF iptables -L TRAF -v -x iptables -I TRAF -d any/0 # Rango de IPs monitorizadas for i in `seq 129 187` do for proto in tcp udp do iptables -I TRAF -s 193.147.162.$i/32 -p $proto iptables -I TRAF -d 193.147.162.$i/32 -p $proto done done # Para trajano análisis especial… iptables -I TRAF -d 193.147.162.130/32 -p tcp --dport 25 iptables -I TRAF -s 193.147.162.130/32 -p tcp --dport 25 iptables -I TRAF -d 193.147.162.130/32 -p tcp --dport 80 iptables -I TRAF -s 172.16.16.0/24

# Vuelco salida de iptables con un formato concreo en fileAux.txt iptables -L TRAF -x -v > /tmp/webServer/fileAux.txt | egrep -v ' *0 *0 *all'> /tmp/webServer/fileAux.txt | sed -e 's/target.*out//g'> /tmp/webServer/fileAux.txt | sed -e 's/... *-- *any *any *//g' > /tmp/webServer/fileAux.txt| sort -n > /tmp/webServer/fileAux.txt # Convierto a JSON # La ultima fila se trata aparte porque no debe incluir la coma final # Guardo formato en iptablesJson.txt DATA=`cat /tmp/webServer/fileAux.txt | gawk '{ printf("{\"src\":\"%s\", \"dst\":\"%s\", \"pkts\":%d, \"bytes\":%d, \"proto\":\"%s\", \"port\":\"%s\"}, \n",$7, $8, $1, $2, $3, $10) } ' | sed '1,2d'`; echo "[${DATA}DEL" |sed 's/,DEL/]/g' > /tmp/webServer/iptablesJson.txt


reset.sh

• Ejemplos de ficheros generados (proceso por el que pasa la información)2

fileAux.txt

2 Se muestran sólo fragmentos de cada fichero, para visualizar el cambio de formato.

# Borra cadena de usuario iptables -Z TRAF

Chain TRAF (85 references)

pkts bytes target prot opt in out source destination

0 0 all -- any any 172.16.16.0/24 anywhere

0 0 tcp -- any any anywhere trajano.us.es tcp dpt:http

0 0 tcp -- any any trajano.us.es anywhere tcp dpt:smtp

0 0 tcp -- any any anywhere trajano.us.es tcp dpt:smtp

0 0 udp -- any any anywhere ait26.us.es

0 0 udp -- any any ait26.us.es anywhere

0 0 tcp -- any any anywhere ait26.us.es

0 0 tcp -- any any ait26.us.es anywhere










44

iptablesJson.txt global.txt /var/log/daemonMark.log

[{"src":"172.16.16.0/24", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"all", "port":""},

{"src":"anywhere", "dst":"trajano.us.es", "pkts":0, "bytes":0, "proto":"tcp", "port":"dpt:http"},

{"src":"trajano.us.es", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"tcp", "port":"dpt:smtp"},

{"src":"anywhere", "dst":"trajano.us.es", "pkts":0, "bytes":0, "proto":"tcp", "port":"dpt:smtp"},

{"src":"anywhere", "dst":"ait26.us.es", "pkts":0, "bytes":0, "proto":"udp", "port":""},

{"src":"ait26.us.es", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"udp", "port":""},

{"src":"anywhere", "dst":"ait26.us.es", "pkts":0, "bytes":0, "proto":"tcp", "port":""},

{"src":"ait26.us.es", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"tcp", "port":""},


{"src":"ait25.us.es", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"udp", "port":""},

{"src":"anywhere", "dst":"ait25.us.es", "pkts":0, "bytes":0, "proto":"tcp", "port":""},

{"src":"ait25.us.es", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"tcp", "port":""},


{"src":"ait24.us.es", "dst":"anywhere", "pkts":0, "bytes":0, "proto":"udp", "port":""}]

[{"time":"10:00","inUdp":0,"outUdp":0,"inTcp":0,"outTcp":0,"http":0,"inSmtp":0,"outSmtp":0},{"time":"10:15","inUdp":0,"outUdp":0,"inTcp":0,"outTcp":0,"http":0,"inSmtp":0,"outSmtp":0},{"time":"10:30","inUdp":0,"outUdp":0,"inTcp":0,"outTcp":0,"http":0,"inSmtp":0,"outSmtp":0},{"time":"10:45","inUdp":0,"outUdp":0,"inTcp":0,"outTcp":0,"http":0,"inSmtp":0,"outSmtp":0},{"time":"11:00","inUdp":0,"outUdp":0,"inTcp":0,"outTcp":0,"http":0,"inSmtp":0,"outSmtp":0},{"time":"11:15","inUdp":0,"outUdp":0,"inTcp":0,"outTcp":0,"http":0,"inSmtp":0,"outSmtp":0}]

--------------------- Ultima actualizacion: mar ago 26 14:27:43 CEST 2014 --------------------- Ultima actualizacion: mar ago 26 14:30:11 CEST 2014 --------------------- Ultima actualizacion: mar ago 26 14:45:17 CEST 2014 ---------------------


ANEXO B: SERVIDOR EN RUBY ON RAILS En este anexo se expondrán todos los ficheros relacionados con la programación del servidor web. El orden seguido va de acuerdo con estructura dentro de la carpeta del proyecto. El título de cada sección del anexo se corresponde con el nombre de una carpeta del árbol del directorios de Ruby on Rails. Los subdirectorios y ficheros que contenga serán los incluídos en dicha sección. De esta forma, se traspasa al anexo el servidor web completo, conservando su estructura. Se parte de una carpeta general llamada pfg, creada mediante el comando:

rails new pfg

• Directorio App (pfg/app/) o /assets

§ /images Sólo contiene las imágenes esi.gif y red.jpg (utilizadas en la web).

§ /javascripts Contiene ficheros vacíos con extensión .js.coffee. Todos se han creado por defecto al crear los controladores mediante comandos de terminal. El único fichero relleno es application.js. Su función y sintaxis ya se explicó en la memoria, así que simplemente se mostrará su contenido:

- global.js.coffee (vacío)

- ips.js.coffee (vacío)

- main.js.coffee (vacío)

- ports.js.coffee (vacío)

- tcps.js.coffee (vacío)

- udps.js.coffee

application.js

// This is a manifest file that'll be compiled into application.js, which will // include all the files listed below. // // Any JavaScript/Coffee file within this directory, lib/assets/javascripts, // vendor/assets/javascripts,or vendor/assets/javascripts of plugins, if any, // can be referenced here using a relative path. // // It's not advisable to add code directly here, but if you do, it'll appear at // the bottom of the compiled file. // // Read Sprockets README (https://github.com/sstephenson/sprockets#sprockets-//directives) for details about supported directives. // //= require jquery //= require jquery_ujs //= require turbolinks //= require_tree . //= require Chart //= require excanvas

Anexo B: Servidor en Ruby on Rails

46

§ /stylesheets global.css.scss

h2 { color: #660000; text-align: center; } canvas { border-style: solid; border-style: dashed; border-width: 1px; border-color: rgba(102, 0, 0, 0.3); background-color: rgba(255, 240, 209, 0.2); margin-bottom: 1em; } #legend { margin-right: 100px; margin-left: 100px; } #return { width: 50%; background: none; color: #660000; float: left; } #mainGlobal { padding-right: 5%; padding-left:5%; padding-top: 2em; width: 1100px; } #subtit { color: #660000; float: right; width: 50%; text-align: right; } .link_end { color: #660000; } .legend { list-style: none; } .legend li { float: left; margin-right: 10px; }


.legend span { border: 1px solid #fff; float: left; width: 12px; height: 12px; margin: 2px; } .legend .UDP { background-color: rgba(204,102,0,1); } .legend .TCP { background-color: rgba(151,187,205,1); } .legend .HTTP { background-color: rgba(255,0,0,1); } .legend .SMTPin { background-color: rgba(0,153,0,1); } .legend .SMTPout { background-color: rgba(102,0,102,1); }

body { background-color: #FFCC66; padding: 1em; } h1 { float: left; position: static; color: #660000; font-family: arial; font-weight: bold; } td { text-align: center; padding-left: 3em; padding-right: 3em; background-color: #660000; }

main.css.scss


48

body { background-color: #FFCC66; padding: 1em; } h1 { float: left; position: static; color: #660000; font-family: arial; font-weight: bold; } td { text-align: center; padding-left: 3em; padding-right: 3em; background-color: #660000; } table { margin: 0 auto; text-align: center; } strong { color: #660000; text-align : justify; } strong { text-align: center; } .link { font-family: arial; color: #FFCC66 } #title { width: 500px; } #index { margin: 0 auto; text-align: center; width: 1000px; }


#mainBody { position: static; padding: 4em; border-top-style: solid; border-width: 1px; border-color: #660000 } #icon { float: left; padding: 1em; } #endPage { clear: both; border-top-style: solid; color: #660000; font-family: arial; font-weight: bold; border-width: 1px; border-color: #660000; }

#http { color: #660000; text-align: left; margin-top: 3em; width: 50%; float: left; position: relative; } #ports { margin-top: 3em; float: right; position: relative; } #subsec { margin-bottom: 500px; } #trajano { text-align: right; float: right; }

ports.css.scss


50

Además de estos ficheros, evidentemente, de forma automática se han generado también los siguientes:

- ips.css.scss - udps.css.scss

En este proyecto esos ficheros se encuentran vacíos. Esto puede hacerse en Ruby on Rails por su

método de lectura de estilos. Para cada elemento html, rails busca primero en su fichero asociado, (el que tiene el nombre de la vista correspondiente). En caso de no encontrar un estilo definido para ese elemento en el fichero consultado, va leyendo uno por uno todos los estilos existentes. Por tanto, el hecho de que esos dos ficheros estén vacíos y la web tenga su estilo intacto, indica que todos los elementos utilizados en las vistas “ips” y “udps” ya tienen su estilo prestablecido en los css anteriores.

Aclaraciones:

§ @variable: representa una variable global del proyecto.

§ Métodos: deben encuadrarse entre def nombreMetodo y end

§ Patrón de búsqueda: para saber si un evento es entrante o saliente se mirará la IP origen (campo src). Si su valor es “anywhere” significará que el tráfico es entrante en la subred, en otro caso será saliente.

§ Insercción de vistas auxiliares: se utiliza la instrucción <%= render 'mainIndex' %>. Permite separar código que se repita en varias vistas, programándolo en un fichero distinto e insertando el mismo cuando sea necesario.

§ Vistas: se separá el código htmldel que genera las gráficas en java script. Ambos bloques, en la realidad, se encuentran en el mismo fichero (en el indicado en la cima del código html).En caso de generarse varias gráficas dentro del mismo script, se expondrá el código de cada una en un bloque independiente. Es simplemente una cuestión visual.

o /controllers

#chartPacks { float: right; }

tcps.css.scss

class MainController < ApplicationController

def index end

end

main_controller.rb


class GlobalController < ApplicationController def getinfo file = "" totalPkts = 0 totalBytes = 0 inPkts = 0 outPkts = 0 inBytes = 0 outBytes = 0 File.open '/tmp/webServer/global.txt', 'r' do |f1| while line = f1.gets file = file+line end end @graph_global = file.to_s end end

global_controller.rb


52

class IpsController < ApplicationController def getinfo file= "" i = 0 j = 0 @ipsOut = [] @bytesOut = [] @packsOut = [] @ipsIn = [] @bytesIn = [] @packsIn = [] File.open '/tmp/webServer/iptablesJson.txt', 'r' do |f1| while line = f1.gets file = file+line end end jsonArray = JSON.parse(file) jsonArray.each do |json| if json['pkts'] > 0 # In traffic if json['src'] == "anywhere"

@ipsIn[i] = json['dst'] + " : " + json['proto'].upcase @bytesIn[i] = json['bytes'] @packsIn[i] = json['pkts'] #Update the index for the next candidate IP address

i+=1 # Out traffic else @ipsOut[j] = json['src'] + " : " + json['proto'].upcase @bytesOut[j] = json['bytes'] @packsOut[j] = json['pkts'] #Update the index for the next candidate IP address j+=1 end end end @[email protected]_s @[email protected]_s @[email protected]_s @[email protected]_s @[email protected]_s @[email protected]_s end end

ips_controller.rb


class PortsController < ApplicationController def getinfo file = "" http = {:in80_B=>0, :in80_P=>0, :type=>"Bytes/Paquetes entrantes"} smtp = {:in25_B=>0, :out25_B=>0, :total25_B=>0, :in25_P=>0,:out25_P=>0, :total25_P=>0} # Lectura del fichero File.open '/tmp/webServer/iptablesJson.txt', 'r' do |f1| # Traslado el fichero para poder pasarlo a js while line = f1.gets file = file+line end end jsonArray = JSON.parse(file) jsonArray.each do |json| if json['port'] == "dpt:smtp" smtp[:total25_B] = json['bytes'] + smtp[:total25_B] smtp[:total25_P] = json['pkts'] + smtp[:total25_P] # Trafico entrante if json['src'] == "anywhere" smtp[:in25_P] = json['pkts'] + smtp[:in25_P] smtp[:in25_B] = json['bytes'] + smtp[:in25_B] # Trafico saliente (viene de una IP conocida) else smtp[:out25_P] = json['pkts'] + smtp[:out25_P] smtp[:out25_B] = json['bytes'] + smtp[:out25_B] end else if json['port'] == "dpt:http" http[:in80_P] = json['pkts'] + http[:in80_P] http[:in80_B] = json['bytes'] + http[:in80_B] end end end bytes25 = [{:data=>smtp[:total25_B], :type=>"Bytes Totales"}, {:data=>smtp[:in25_B], :type=>"Bytes entrantes"}, {:data=>smtp[:out25_B],:type=>"Bytes salientes"}].to_json packs25 = [{:data=>smtp[:total25_P], :type=>"Paquetes Totales"}, {:data=>smtp[:in25_P], :type=>"Paquetes entrantes"}, {:data=>smtp[:out25_P],:type=>"Paquetes salientes"}].to_json global = [{:in25_Bytes=>smtp[:in25_B], :out25_Bytes=>smtp[:out25_B]}].to_json @graph_bytes_25 = bytes25.to_s @graph_packs_25 = packs25.to_s @graph_global = global.to_s @graph_http = [http].to_json.to_s end end

ports_controller.rb


54

class TcpsController < ApplicationController def getinfo file = "" totalPkts = 0 totalBytes = 0 inPkts = 0 outPkts = 0 inBytes = 0 outBytes = 0 File.open '/tmp/webServer/iptablesJson.txt', 'r' do |f1| while line = f1.gets file = file+line end end jsonArray = JSON.parse(file) jsonArray.each do |json| if json['proto'] == "tcp" totalPkts = json['pkts'] + totalPkts totalBytes = json['bytes'] + totalBytes if json['src'] == "anywhere" inPkts = json['pkts'] + inPkts inBytes = json['bytes'] + inBytes else outPkts = json['pkts'] + outPkts outBytes = json['bytes'] + outBytes end end end bytes = [{:data=>totalBytes, :type=>"Bytes Totales"}, {:data=>inBytes, :type=>"Bytes entrantes"}, {:data=>outBytes, :type=>"Bytes salientes"}].to_json packs = [{:data=>totalPkts, :type=>"Paquetes Totales"}, {:data=>inPkts, :type=>"Paquetes entrantes"}, {:data=>outPkts, :type=>"Paquetes salientes"}].to_json @graph_bytes_tcp = bytes.to_s @graph_packs_tcp = packs.to_s end end

tcps_controller.rb


class UdpsController < ApplicationController def getinfo file = "" totalPkts = 0 totalBytes = 0 inPkts = 0 outPkts = 0 inBytes = 0 outBytes = 0 File.open '/tmp/webServer/iptablesJson.txt', 'r' do |f1| while line = f1.gets file = file+line end end jsonArray = JSON.parse(file) jsonArray.each do |json| if json['proto'] == "udp" totalPkts = json['pkts'] + totalPkts totalBytes = json['bytes'] + totalBytes if json['src'] == "anywhere" inPkts = json['pkts'] + inPkts inBytes = json['bytes'] + inBytes else outPkts = json['pkts'] + outPkts outBytes = json['bytes'] + outBytes end end end bytes = [{:data=>totalBytes, :type=>"Bytes Totales"}, {:data=>inBytes, :type=>"Bytes entrantes"}, {:data=>outBytes, :type=>"Bytes salientes"}].to_json packs = [{:data=>totalPkts, :type=>"Paquetes Totales"}, {:data=>inPkts, :type=>"Paquetes entrantes"}, {:data=>outPkts, :type=>"Paquetes salientes"}].to_json @graph_bytes_udp = bytes.to_s @graph_packs_udp = packs.to_s end end

udps_controller.rb


56

o /helpers Los ficheros de esta carpeta no han sido modificados. Por ello, simplemente se enumerarán y se expondrá el contenido por defecto de uno de ellos. Es similar en el resto.

§ application_helper.rb

§ global_helper.rb

§ ips_helper.rb

§ main_helper.rb

§ ports_helper.rb

§ tcps_helper.rb

§ udps_helper.rb

application_helper.rb

o /mailers Sirve para crear clases encargadas de gestión de emails en una aplicación web. No procede en el proyecto.

o /models Como ya se indicó, no es necesario el uso de este componente del patrón MVC en el proyecto.

o /views § /main

_mainIndex.html.erb

module ApplicationHelper

end

<div id="index"> <%= image_tag "red.jpg", :alt => "US" %> <table> <tr> <td class="link"> <%= link_to 'Resumen Global', global_getinfo_path,{:class => 'link'}%> </td> <td> <%= link_to 'Uso UDP', udps_getinfo_path, {:class => 'link'} %> </td> <td> <%= link_to 'Uso TCP', tcps_getinfo_path, {:class => 'link'} %> </td> <td> <%= link_to 'Uso Trajano', ports_getinfo_path, {:class => 'link'} %> </td> <td> <%= link_to 'Tráfico por IP', ips_getinfo_path, {:class => 'link'} %> </td> </tr> </table> </div>


El fichero anterior tiene un nombre que comienza en guión bajo. Usualmente, y en este proyecto concreto, los ficheros con esa nomenclatura se utilizar para guardar extructuras que se repiten a lo largo de cada vista. En esta en particular, se guarda el índice superior que aparece siempre en pantalla, junto con la imagen de encabezado de la web.

index.html.erb

<%= render 'mainIndex' %> <div id="title"> <div id="icon"> <%= image_tag "esi.gif", :alt => "ESI" %> </div> <h1> Recolector de Estadísticas </h1> </div> <div id="mainBody"> </br></br> <strong> En esta web podrá visualizar estadísticas de tráfico UDP y TCP del rango de direcciones: 193.147.162.129 - 192.147.162.187 </strong></br></br> <strong> En concreto, la IP 193.147.162.130 ("trajano.us.es") cuenta con gráficas propias. En ellas, se mostrará el uso de los puertos 25 y 80 para esta dirección. </strong> </br> </br> <strong> En la pestaña "global" obtendrá un resumen de tráfico de hasta seis horas (dividido en intervalos de quince minutos)</strong> </div> <div id="endPage"> <small class="proyecto"> Proyecto Fin de Grado de Telecomunicaciones (Telemática) </small></br> <small> Realizado por Mercedes Castaño Torres </small></br> <small> Dirigido por Juan Manuel Vozmediano Torres </small> </div>


58

§ /ips

getinfo.html.erb

<%= render 'main/mainIndex' %> <div id="mainBody"> <h2> Tráfico Entrante (Bytes/Paquetes) </h2> <canvas id="inBytes" width="1100" height="500"> </canvas> <h2> Tráfico Saliente (Bytes/Paquetes) </h2> <canvas id="outBytes" width="1100" height="500"> </canvas> </div> <%= render 'global/endpage' %> <script> $(document).ready(function(){ Graph 1 Graph 2 }); </script>


Graph 1

/* Reading of arrays */ var myX = <%= @ipsIn.html_safe %>; var myYbytes = <%= @bytesIn.html_safe %>; var myYpacks = <%= @packsIn.html_safe %>; /* Values of the first graph */ inChartData = { /* X-axis: Array of ips */ labels : myX, /* Y-axis: Array of packets and bytes */ datasets : [ { label : "bytes", fillColor : "rgba(219,148,77,0.4)", strokeColor : "rgba(102,0,0,1)", highlightFill: "rgba(151,187,205,0.75)", highlightStroke: "rgba(151,187,205,1)", data : myYbytes }, { label : "packets", fillColor: "rgba(102,0,0,0.4)", strokeColor : "rgba(102,0,0,1)", highlightFill: "rgba(128,230,178,0.5)", highlightStroke: "rgba(128,230,178,0.2)", data : myYpacks } ] }; /* These lines create and place the graph */ var ctx = $("#inBytes").get(0).getContext("2d"); var myLine = new Chart(ctx).Bar(inChartData);


60

/* Reading of values */ var myX = <%= @ipsOut.html_safe %>; var myYbytes = <%= @bytesOut.html_safe %>; var myYpacks = <%= @packsOut.html_safe %>; /* Values of the second graph */ outChartData = { /* X-axis: Array of ips */ labels : myX, /* Y-axis: Array of packets and bytes */ datasets : [ { label : "bytes", fillColor : "rgba(219,148,77,0.4)", strokeColor : "rgba(102,0,0,1)", highlightFill: "rgba(151,187,205,0.75)", highlightStroke: "rgba(151,187,205,1)", data : myYbytes }, { label : "packets", fillColor: "rgba(102,0,0,0.4)", strokeColor : "rgba(102,0,0,1)", highlightFill: "rgba(128,230,178,0.5)", highlightStroke: "rgba(128,230,178,0.2)", data : myYpacks } ] }; /* These lines create and place the graph */ var ctx = $("#outBytes").get(0).getContext("2d"); var myLine = new Chart(ctx).Bar(outChartData);

Graph 2


§ /global

_endpage.html.erb

<div id="endPage"> <div id="return"> <%= link_to 'Volver al inicio', root_path, {:class => 'link_end'} %> </div> <div id="subtit"> <small> Recolector de estadísticas <br> basado en iptables </small> </div> </div>

<%= render 'main/mainIndex' %> <ul class="legend"> <li><span class="UDP"></span><strong> UDP </strong></li> <li><span class="TCP"></span><strong> TCP </strong></li> <li><span class="HTTP"></span><strong> HTTP </strong></li> <li><span class="SMTPin"></span><strong> SMTP entrante </strong></li> <li><span class="SMTPout"></span><strong> SMTP saliente </strong></li> </ul> <div id="mainGlobal"> <h2> Tráfico Entrante (bytes) </h2> <canvas id="inGlobal" width="1100" height="400"> </canvas> <h2> Tráfico Saliente (bytes) </h2> <canvas id="outGlobal" width="1100" height="400"> </canvas> <h2> Resumen Trajano (bytes) </h2> <canvas id="trajano" width="1100" height="400"> </canvas> </div> <%= render 'global/endpage' %> <script> $(document).ready(function(){ /* This function maps the array with only the passed property values */ Array.prototype.mapProperty = function(property) { return this.map(function (obj) { return obj[property]; }); }; Grap 1 Graph 2 Graph 3 }); </script>

getinfo.html.erb


62

Graph 1

/* Reading of arrays */

var myDataGlobal = <%= @graph_global.html_safe %>;

/* First graph */

var globalChartData = {

labels : myDataGlobal.mapProperty('time'),

datasets : [

{

label: "UDP in",

fillColor : "rgba(219,148,77,0.2)",

strokeColor : "rgba(204,102,0,1)",

pointColor: "rgba(204,102,0,1)",

pointStrokeColor: "#fff",

pointHighlightFill: "#fff",

pointHighlightStroke: "rgba(204,102,0,1)",

data: myDataGlobal.mapProperty('inUdp')

},

{

label: "TCP in",

fillColor: "rgba(151,187,205,0.2)",

strokeColor: "rgba(151,187,205,1)",





data: myDataGlobal.mapProperty('inTcp')

}

]

};

var ctx = $("#inGlobal").get(0).getContext("2d");

var myGlobal = new Chart(ctx).Line(globalChartData,

{bezierCurve: false});


Graph 2

/* Second graph */

var globalChartData = {

labels : myDataGlobal.mapProperty('time'),

datasets : [

{

label: "UDP out",

fillColor : "rgba(219,148,77,0.2)",






data: myDataGlobal.mapProperty('outUdp')

},

{

label: "TCP out",

fillColor: "rgba(151,187,205,0.2)",

strokeColor: "rgba(151,187,205,1)",





data: myDataGlobal.mapProperty('outTcp')

}

]

};

// Indico posicion de la grafica en la web

var ctx = $("#outGlobal").get(0).getContext("2d");

// Disparo la grafica




64

Graph 3

/* Third graph */ var globalChartData = { labels : myDataGlobal.mapProperty('time'), datasets : [ { label: "Http", fillColor : "rgba(255,0,0,0.2)", strokeColor : "rgba(255,0,0,1)", pointColor: "rgba(255,0,0,1)", pointStrokeColor: "#fff", pointHighlightFill: "#fff", pointHighlightStroke: "rgba(255,0,0,1)", data: myDataGlobal.mapProperty('http') }, { label: "Smtp in", fillColor: "rgba(0,153,0,0.2)", strokeColor: "rgba(0,153,0,1)", pointColor: "rgba(0,153,0,1)", pointStrokeColor: "#fff", pointHighlightFill: "#fff", pointHighlightStroke: "rgba(0,153,0,1)", data: myDataGlobal.mapProperty('inSmtp') }, { label: "Smtp out", fillColor: "rgba(102,0,102,0.2)", strokeColor: "rgba(102,0,102,1)", pointColor: "rgba(102,0,102,1)", pointStrokeColor: "#fff", pointHighlightFill: "#fff", pointHighlightStroke: "rgba(102,0,102,1)", data: myDataGlobal.mapProperty('outSmtp') } ] }; // Indico posicion de la grafica en la web var ctx = $("#trajano").get(0).getContext("2d"); // Disparo la grafica




§ /ports

getinfo.html.erb

<%= render 'main/mainIndex' %> <div id="mainBody"> <h2> Uso del puerto 25 (smtp)</h2> <canvas id="chartBytes" width="500" height="400"></canvas> <canvas id="chartPacks" width="500" height="400"></canvas> <div id="subsec"> <div id="http"> <h2> Uso del puerto 80 (http) </h2> <canvas id="chart80" width="500" height="400"></canvas> </div> <div id="ports"> <h2> Resumen Trajano (Bytes) </h2> <canvas id="trajano" width="500" height="400"></canvas> </div> </div> </div> <%= render 'global/endpage' %> <script> $(document).ready(function(){ /* This function maps the array with only the passed property values */ Array.prototype.mapProperty = function(property) { return this.map(function (obj) { return obj[property]; });

};

Graph 1 Graph 2 Graph 3 Graph 4 }); </script>


66


var myDataBytes = <%= @graph_bytes_25.html_safe %>;

var myDataPacks = <%= @graph_packs_25.html_safe %>;

/* Values of the first graph (bytes) */

smtpBytesChart = {

/* X-axis */

labels : myDataBytes.mapProperty('type'),

/* Y-axis */

datasets : [

{

fillColor : "rgba(102,0,0,0.4)",


highlightFill: "rgba(102,0,0,0.5)",

highlightStroke: "rgba(102,0,0,0.2)",

data : myDataBytes.mapProperty('data')

}

]

};

/* These lines create and place the graph */

var ctx = $("#chartBytes").get(0).getContext("2d");

var myLine = new Chart(ctx).Bar(smtpBytesChart);

Graph 1


/* Values of the second graph (packets) */

linePacksChart = {

/* X-axis */

labels : myDataPacks.mapProperty('type'),

/* Y-axis */

datasets : [

{





data : myDataPacks.mapProperty('data')

}

]

};


var ctx = $("#chartPacks").get(0).getContext("2d");

var myLine = new Chart(ctx).Bar(linePacksChart);

Graph 2


68

/* Reading of values */

var myDataHtml = <%= @graph_http.html_safe %>;

/* Values of the third graph (http) */

httpChartData = {

/* X-axis */

labels : myDataHtml.mapProperty('type'),

/* Y-axis */

datasets : [

{

label: "Port 80 (bytes)",

fillColor : "rgba(219,148,77,0.4)",



highlightStroke: "rgba(151,187,205,1)",

data : myDataHtml.mapProperty('in80_B')

},

{

label: "Port 80 (packets)",

fillColor: "rgba(102,0,0,0.4)",




data : myDataHtml.mapProperty('in80_P')

}

]

};

var ctx = $("#chart80").get(0).getContext("2d");

var myLine = new Chart(ctx).Bar(httpChartData);

Graph 3


/* Reading of values */

var myDataGlobal = <%= @graph_global.html_safe %>;

/* Values of the fourth graph */

trajanoData = [

{

value: parseInt(myDataHtml.mapProperty('in80_B')),

color:"#F7464A",

highlight: "#FF5A5E",

label: "HTTP entrante"

},

{

value: parseInt(myDataGlobal.mapProperty('in25_Bytes')),

color: "#46BFBD",

highlight: "#5AD3D1",

label: "SMTP entrante"

},

{

value: parseInt(myDataGlobal.mapProperty('out25_Bytes')),

color: "#FDB45C",

highlight: "#FFC870",

label: "SMTP saliente"

}

];

var ctx = $("#trajano").get(0).getContext("2d");

var myTrajano = new Chart(ctx).Pie(trajanoData);

Graph 4


70

§ /tcps

getinfo.html.erb

<%= render 'main/mainIndex' %>

<div id="mainBody">

<h2> Uso de TCP </h2>

<canvas id="chartBytes" width="500" height="400"></canvas>

<canvas id="chartPacks" width="500" height="400"></canvas>

</div>

<%= render 'global/endpage' %>

<script>

$(document).ready(function(){

/* This function maps the array with only the passed property values */

Array.prototype.mapProperty = function(property) {

return this.map(function (obj) {

return obj[property];

});

};

Graph 1

Graph 2

});

</script>


Graph 1


var myDataBytes = <%= @graph_bytes_tcp.html_safe %>;

var myDataPacks = <%= @graph_packs_tcp.html_safe %>;


bytesChartData = {

/* X-axis */


/* Y-axis */

datasets : [

{






}

]

};



var myLine = new Chart(ctx).Bar(bytesChartData);


72

Graph 2


packsChartData = {

/* X-axis */

labels : myDataPacks.mapProperty('type'),

/* Y-axis */

datasets : [

{





data : myDataPacks.mapProperty('data')

}

]

};



var myLine = new Chart(ctx).Bar(packsChartData);


§ /udps

getinfo.html.erb

<%= render 'main/mainIndex' %>

<div id="mainBody">

<h2> Uso de UDP </h2>

<canvas id="chartBytes" width="500" height="400"></canvas>

<canvas id="chartPacks" width="500" height="400"></canvas>

</div>

<%= render 'global/endpage' %>

<script>

$(document).ready(function(){

/* This function maps the array with only the passed property values */

Array.prototype.mapProperty = function(property) {

return this.map(function (obj) {

return obj[property];

});

};

Graph 1

Graph 2

});

</script>


74

graph 1


var myDataBytes = <%= @graph_bytes_udp.html_safe %>;

var myDataPackets = <%= @graph_packs_udp.html_safe %>;


bytesChartData = {

/* Eje x:

Mapeo el valor de JSON */


/* Eje y:

Mapeo el valor de JSON

.....

*/

datasets : [

{






}

]

};



var myLine = new Chart(ctx).Bar(bytesChartData);


Graph 3


packsChartData = {

/* X-axis*/

labels : myDataPackets.mapProperty('type'),

/* Y-axis */

datasets : [

{





data : myDataPackets.mapProperty('data')

}

]

};



var myLine = new Chart(ctx).Bar(packsChartData);


76

§ /layouts

application.html.erb

<!DOCTYPE html>

<html>

<head>

<title>Pfg</title>

<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => true %>

<%= javascript_include_tag 'application', 'data-turbolinks-track' => true %>

<%= csrf_meta_tags %>

</head>

<body>

<%= yield %>

</body>

</html>


• /pfg/bin/

#!/usr/bin/env ruby

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

load Gem.bin_path('bundler', 'bundle')

bundle

#!/usr/bin/env ruby

begin

load File.expand_path("../spring", __FILE__)

rescue LoadError

end

APP_PATH = File.expand_path('../../config/application', __FILE__)

require_relative '../config/boot'

require 'rails/commands'

rails

#!/usr/bin/env ruby

begin

load File.expand_path("../spring", __FILE__)

rescue LoadError

end

require_relative '../config/boot'

require 'rake'

Rake.application.run

rake


78

spring

#!/usr/bin/env ruby

# This file loads spring without using Bundler, in order to be fast

# It gets overwritten when you run the `spring binstub` command

unless defined?(Spring)

require "rubygems"

require "bundler"

if match = Bundler.default_lockfile.read.match(/^GEM$.*?^ spring $(.*?)$$.*?^$/m)

ENV["GEM_PATH"] = ([Bundler.bundle_path.to_s] + Gem.path).join(File::PATH_SEPARATOR)

ENV["GEM_HOME"] = ""

Gem.paths = ENV

gem "spring", match[1]

require "spring/binstub"

end

end


• /pfg/config/

§ database.yml

§ secrets.yml

o /enviroments § development.rb

§ production.rb

§ test.rb

o /initializers § assets.rb § backtrace_silencers.rb § cookies_serializer.rb § filter_parameter_logging.rb § inflections.rb § mime_types.rb § sesión_store.rb § wrap_parameters.rb

o /locales § en.yml

No se indica el contenido de los ficheros anteriores porque se crean junto con el proyecto, con el comando inicial. No han sufrido modificaciones desde su creación y no tienen un contenido relevante en la realización del proyecto. Son simplemente ficheros de configuración internos de rails. Los ficheros mostrados a continuación siguen perteneciendo al directorio /pfg/config, sin enmarbgo tienen un contenido más interesante de visualizar.

boot.rb

# Set up gems listed in the Gemfile.

ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exist?(ENV['BUNDLE_GEMFILE'])


80

application.rb

require File.expand_path('../boot', __FILE__)

require 'rails/all'

require 'json'

# Require the gems listed in Gemfile, including any gems

# you've limited to :test, :development, or :production.

Bundler.require(*Rails.groups)

module Pfg

class Application < Rails::Application

# Settings in config/environments/* take precedence over those specified here.

# Application configuration should go into files in config/initializers

# -- all .rb files in that directory are automatically loaded.

# Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.

# Run "rake -D time" for a list of tasks for finding time zone names. Default is UTC.

# config.time_zone = 'Central Time (US & Canada)'

# The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded.

# config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]

# config.i18n.default_locale = :de

end

end])

# Load the Rails application.

require File.expand_path('../application', __FILE__)

# Initialize the Rails application.

Rails.application.initialize!

environment.rb


A continuación, en varios fragmentos, se muestra el contenido del fichero routes.rb. ya se ha hablado de él a lo largo de la memoria. En negrita se destacan los datos de interés: declaración de métodos o establecimiento de una vista como página principal de la web.

routes.rb

Pfg::Application.routes.draw do

get 'ips/getinfo'

get 'global/getinfo'

get 'ips/getinfo'

get 'global/getinfo'

get 'udps/getinfo'

get 'tcps/getinfo'

get 'ports/getinfo'

#get 'main/index'

# The priority is based upon order of creation: first created -> highest priority.

# See how all your routes lay out with "rake routes".

# You can have the root of your site routed with "root"

root 'main#index'


82

# Example of regular route: # get 'products/:id' => 'catalog#view' # Example of named route that can be invoked with purchase_url(id: product.id) # get 'products/:id/purchase' => 'catalog#purchase', as: :purchase # Example resource route (maps HTTP verbs to controller actions automatically): # resources :products # Example resource route with options: # resources :products do # member do # get 'short' # post 'toggle' # end # # collection do # get 'sold' # end # end # Example resource route with sub-resources: # resources :products do # resources :comments, :sales # resource :seller # end # Example resource route with more complex sub-resources: # resources :products do # resources :comments # resources :sales do # get 'recent', on: :collection # end # end # Example resource route with concerns: # concern :toggleable do # post 'toggle' # end # resources :posts, concerns: :toggleable # resources :photos, concerns: :toggleable # Example resource route within a namespace: # namespace :admin do # # Directs /admin/products/* to Admin::ProductsController # # (app/controllers/admin/products_controller.rb) # resources :products # end end


• pfg/db/

No aplica en este proyecto. Sólo contiene ficheros creados por defecto.

• pfg/lib/

Contiene ficheros exteriores y subdirectorios, mostrados en este orden en la sección.Los primeros, han sido insertados para hacer posible el uso de la librería Chatrt.js

chartjs.rb

o /assets

o /chartjs

Incluye ficheros de configuración relacionados con las librerías java script, NO la librería en sí. Su contenido no tiene mayor interés.

§ axis_helpers.rb

§ chart_helpers.rb

§ engine.rb

§ versión.rb

o /tasks

• pfg/log/

Contiene un único fichero, development.log, en el que se almacenan los logs del sistema. Pueden borrarse mediante el comando:

rake log:clear

require 'chartjs/engine'

require "chartjs/version"

module Chartjs

end

# Internally use the chartjs namespace, not chartjs-ror.

require 'chartjs'

chartjs-ror.rb


84

A continuación se muestra un fragmento del archivo actual del proyecto:

development.log

• pfg/public/

En este directorio se incluyen ficheros que se harán públicos al usuario final en momentos determinados. Por ejemplo, como se observa en los ficheros inferiores, la interfaz que se mostrará en caso de error en la web. Se han respetado los creados por defecto. En el subdirectorio assets, se encuentran elementos propios de la aplicación que también se hacen públicos en la navegación. Las imágenes son un ejemplo de ello. El nombre adquirido en este subdirectorio ha sido creado por rails, el programador sólo debe incluir la imagen en el directorio pfg/app/assets/images/.

404.html

Started GET "/" for 127.0.0.1 at 2014-07-31 10:14:11 +0200

ActionController::RoutingError (uninitialized constant WelcomeController):

activesupport (4.1.4) lib/active_support/inflector/methods.rb:238:in `const_get'

activesupport (4.1.4) lib/active_support/inflector/methods.rb:238:in `block in constantize'

activesupport (4.1.4) lib/active_support/inflector/methods.rb:236:in `each'

activesupport (4.1.4) lib/active_support/inflector/methods.rb:236:in `inject'

activesupport (4.1.4) lib/active_support/inflector/methods.rb:236:in `constantize'

actionpack (4.1.4) lib/action_dispatch/routing/route_set.rb:78:in `controller_reference'

actionpack (4.1.4) lib/action_dispatch/routing/route_set.rb:68:in `controller'

<!DOCTYPE html> <html> <head> <title>The page you were looking for doesn't exist (404)</title> <meta name="viewport" content="width=device-width,initial-scale=1"> <style> body { background-color: #EFEFEF; color: #2E2F30; text-align: center; font-family: arial, sans-serif; margin: 0; }

div.dialog > div { border: 1px solid #CCC; border-right-color: #999; border-left-color: #999; border-bottom-color: #BBB; border-top: #B00100 solid 4px; border-top-left-radius: 9px; border-top-right-radius: 9px; background-color: white; padding: 7px 12% 0; box-shadow: 0 3px 8px rgba(50, 50, 50, 0.17); } h1 { font-size: 100%; color: #730E15; line-height: 1.5em; } div.dialog > p { margin: 0 0 1em; padding: 1em; background-color: #F7F7F7; border: 1px solid #CCC; border-right-color: #999; border-left-color: #999; border-bottom-color: #999; border-bottom-left-radius: 4px; border-bottom-right-radius: 4px; border-top-color: #DADADA; color: #666; box-shadow: 0 3px 8px rgba(50, 50, 50, 0.17); } </style> </head> <body>  <div class="dialog"> <div> <h1>The page you were looking for doesn't exist.</h1> <p>You may have mistyped the address or the page may have moved.</p> </div> <p>If you are the application owner check the logs for more information.</p> </div> </body> </html>


86

422.html

<!DOCTYPE html>

<html>

<head>

<title>The change you wanted was rejected (422)</title>

<meta name="viewport" content="width=device-width,initial-scale=1">

<style>

body {

background-color: #EFEFEF;

color: #2E2F30;

text-align: center;

font-family: arial, sans-serif;

margin: 0;

}

div.dialog {

width: 95%;

max-width: 33em;

margin: 4em auto 0;

}

div.dialog > div {

border: 1px solid #CCC;

border-right-color: #999;

border-left-color: #999;

border-bottom-color: #BBB;

border-top: #B00100 solid 4px;

border-top-left-radius: 9px;

border-top-right-radius: 9px;

background-color: white;

padding: 7px 12% 0;

box-shadow: 0 3px 8px rgba(50, 50, 50, 0.17);

}

h1 {

font-size: 100%;

color: #730E15;

line-height: 1.5em;

}

div.dialog > p {

margin: 0 0 1em;

padding: 1em;

background-color: #F7F7F7;




border-bottom-color: #999;

border-bottom-left-radius: 4px;

border-bottom-right-radius: 4px;

border-top-color: #DADADA;

color: #666;


}

</style>

</head>

<body>



<div class="dialog">

<div>

<h1>The change you wanted was rejected.</h1>

<p>Maybe you tried to change something you didn't have access to.</p>

</div>

<p>If you are the application owner check the logs for more information.</p>

</div>

</body>

</html>


88

500.html

<!DOCTYPE html>

<html>

<head>

<title>We're sorry, but something went wrong (500)</title>

<meta name="viewport" content="width=device-width,initial-scale=1">

<style>

body {

background-color: #EFEFEF;

color: #2E2F30;

text-align: center;

font-family: arial, sans-serif;

margin: 0;

}

div.dialog {

width: 95%;

max-width: 33em;

margin: 4em auto 0;

}

div.dialog > div {




border-bottom-color: #BBB;

border-top: #B00100 solid 4px;

border-top-left-radius: 9px;

border-top-right-radius: 9px;

background-color: white;

padding: 7px 12% 0;


}

h1 {

font-size: 100%;

color: #730E15;

line-height: 1.5em;

}

div.dialog > p {

margin: 0 0 1em;

padding: 1em;

background-color: #F7F7F7;




border-bottom-color: #999;

border-bottom-left-radius: 4px;

border-bottom-right-radius: 4px;

border-top-color: #DADADA;

color: #666;


}

</style>

</head>

<body>



<div class="dialog">

<div>

<h1>We're sorry, but something went wrong.</h1>

</div>

<p>If you are the application owner check the logs for more information.</p>

</div>

</body>

</html>


90

o /assets (Varían para cada proyecto. Creados automáticamente por rails. No se mostrará su contenido en el anexo)

§ application-0cf2fcc9fa639d1b2c56d9159461c98b.css

§ application-0cf2fcc9fa639d1b2c56d9159461c98b.css.gz

§ application-8397dc45c0fa81dfad8f93889d3f588c.js

§ application-8397dc45c0fa81dfad8f93889d3f588c.js.gz

§ esi-066d982dde9bd35c04be825194b1fef8.gif

§ red-03de96fb0f64e9440bf5c19188b22b56.jpg

§ manifest-aa2d97610a5b2872c141da6d41267283.json (mostrado a continuación)

{"files":{"esi-066d982dde9bd35c04be825194b1fef8.gif":{"logical_path":"esi.gif","mtime":"2014-07-31T18:27:49+02:00","size":4891,"digest":"066d982dde9bd35c04be825194b1fef8"},"red-03de96fb0f64e9440bf5c19188b22b56.jpg":{"logical_path":"red.jpg","mtime":"2014-07-31T14:59:26+02:00","size":150079,"digest":"03de96fb0f64e9440bf5c19188b22b56"},"application-8397dc45c0fa81dfad8f93889d3f588c.js":{"logical_path":"application.js","mtime":"2014-08-05T12:26:01+02:00","size":466251,"digest":"8397dc45c0fa81dfad8f93889d3f588c"},"application-0cf2fcc9fa639d1b2c56d9159461c98b.css":{"logical_path":"application.css","mtime":"2014-08-04T20:19:47+02:00","size":2543,"digest":"0cf2fcc9fa639d1b2c56d9159461c98b"}},"assets":{"esi.gif":"esi-066d982dde9bd35c04be825194b1fef8.gif","red.jpg":"red-03de96fb0f64e9440bf5c19188b22b56.jpg","application.js":"application-8397dc45c0fa81dfad8f93889d3f588c.js","application.css":"application-0cf2fcc9fa639d1b2c56d9159461c98b.css"}}


• pfg/test/

text_helper.rb

Los test son generados automáticamente por rails cuando se crea un controlador, o un modelo o cualquier otro componente del proyecto. Solamente se indicarán los existentes en el proyecto, pero no su contenido.

o Controllers

§ global_controller_test.rb

§ ips_controller_test.rb

§ main_controller_test.rb

§ ports_controller_test.rb

§ tcps_controller_test.rb

§ udps_controller_test.rb

o fixtures

o helpers

§ axis_helpers_test.rb

§ global_helper_test.rb

§ ips_helper_test.rb

§ main_helper_test.rb

§ ports_helper_test.rb

§ tcps_helper_test.rb

§ udps_helper_test.rb

ENV['RAILS_ENV'] ||= 'test'

require File.expand_path('../../config/environment', __FILE__)

require 'rails/test_help'

class ActiveSupport::TestCase

# Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.

fixtures :all

# Add more helper methods to be used by all tests here...

end


92

o integration

o mailers

o models

• pfg/tmp/ (mismo significado que en los sitemas operativos: guarda archivos temporales)

o /cache

§ /assets/developments/

- /sass (los ficheros que se generan son automáticos y no relevantes)

- /sprockets (los ficheros que se generan son automáticos y no relevantes)

o /pids

§ server.pid

o /sessions

o /sockets

• pfg/vendor/

o /assets

§ /javascripts (no se muestra el contenido de los ficheros porque son las propias librerías java script)

- Chart.js

- Chart.min.js

- excanvas.js

§ /stylesheets

proyecto fin de grado grado en ingeniería de las...

Documents