Proyecto Fin de Carrera
2. 2.1.
Departamento de Ingenier´ıa Telem´atica
Creando las condiciones de desarrollo Virtualizaci´ on en VMware ESXi
Para la etapa de desarrollo se ha utilizado un servidor de pruebas sobre el que se realiza todo el trabajo. La m´aquina para albergar la tarea de desarrollo est´a dotada con el ”hypervisor” VMware ESXi 5.1.0 sobre el que virtualizaremos la distribuci´on CentOS 6.5(Community ENTerprise Operating System) [23]. CentOS es una distribuci´on que naci´o a partir de la distribuci´on Linux Red Hat Enterprise Linux RHEL que no tiene relaci´on legal con ella, aunque son distribuciones casi iguales, y que puede usarse libremente sin el soporte t´ecnico de Red Hat [24]. En Enero de 2014 [25], Red Hat a´ una esfuerzos con los desarrolladores de CentOS de forma que CentOS pasa a ser un proyecto m´as de Red Hat. La estabilidad de CentOS y su posterior incorporaci´on en Red Hat hacen de esta distribuci´on una buena opci´on para implementar nuestro firewall de aplicaci´on. La versatilidad que da utilizar un esquema de virtualizaci´on para la etapa de desarrollo as´ı como el ahorro en costes que supone disponer de un m´aquina que es capaz de simular distintos equipos y de simular distintas topolog´ıas de red hacen del servidor VMware ESXi id´oneo para el desarrollo. Lo primero que nos encontramos al utilizar VMware ESXi es que es un sistema operativo gestionable, bien por consola en el emplazamiento f´ısico del equipo, o a trav´es del software de gesti´on VMware vSphere Client.
Figura 16: VMware vSphere Client
Una vez dentro del sistema, las opciones de men´ u son relativamente simples e intuitivas para una r´apida instalaci´on y configuraci´on de las m´aquinas virtuales: Summary: Permite monitorizar el estado de las m´aquinas virtuales, conocer las caracter´ısticas del servidor de virtualizaci´on y realizar operaciones b´ asicas sobre las m´aquinas virtuales (creado, reinicio, encendido, apagado...).
29
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Virtual Machines: Se puede visualizar informaci´on m´as espec´ıfica y detallada de las m´aquinas virtuales. Resource Allocantion: Nos permite conocer la ubicaci´on f´ısica dentro del servidor ESXi donde se almacenan las m´aquinas virtuales. Performance: Recopila estad´ısticas de uso, funcionamiento y consumo de recursos de las m´aquinas virtuales. Configuration: Es el men´ u m´as amplio puesto que se encarga de la configuraci´on del servidor y de las m´aquinas virtuales a todos los niveles. Cuenta con m´odulos b´asicos de configuraci´on, uno a nivel hardware y otro a nivel software. A nivel hardware de configuraci´on encontramos opciones configuraci´on de memoria, procesadores, adaptadores de red, redes virtuales y consumo de energ´ıa. En el lado software disponemos de capacidad de configuraci´on del servidor de tiempos, DNS, routing, autenticaci´on de servicios, operaciones b´asicas de gesti´on de las m´aquinas virtuales, perfiles de seguridad y configuraci´on avanzada de las m´aquinas virtuales. Local Users & Groups: Gestiona los usuarios y grupos del servidor ESXi. Events: Permite acceder al log de errores y de eventos del servidor ESXi. Permissions: Recopila un resumen de los permisos de los que disponen los usuarios dados de alta en el sistema.
Figura 17: Pantalla principal ESXi
30
Proyecto Fin de Carrera
2.2.
Departamento de Ingenier´ıa Telem´atica
Escenario de trabajo
Con el objetivo de reproducir las condiciones reales lo m´as fielmente posible, nos disponemos a crear un laboratorio de pruebas en el servidor ESXi que nos permita simular una situaci´on t´ıpica en la que se pueda encontrar un firewall de aplicaci´on. En particular, vamos a crear un entorno virtual de desarrollo en el que el firewall va a ser una m´aquina virtual que va a estar entre la Intranet de la organizaci´on e Internet, que simular´ıa la implementaci´on de un equipo espec´ıficamente dise˜ nado para actuar de firewall en el per´ımetro de la red, es decir, a continuaci´on del router que da salida a internet a la organizaci´on. No es obligatorio, pero el firewall tambi´en puede hacer NAT.
Figura 18: Escenario de prueba
Los equipos User1 y User2 van a ser m´aquinas virtuales que van a simular subredes IP de la Intranet. Como puede verse, queremos que todo el tr´afico, incluido el tr´afico interno, pase por el firewall. La gran ventaja de disponer de un firewall de aplicaci´on es la capacidad de bloquear a nivel de aplicaci´on flujos no solo exteriores sino tambi´en de la propia organizaci´on. De esta manera se puede evitar el uso inapropiado de diversos servicios dentro de la organizaci´on acorde a la pol´ıtica de seguridad y de uso corporativo establecida. Respecto a la m´aquina virtual que emula las capacidades del firewall, vamos a disponer de 3 instancias diferentes: Firewall (SDK): Es la m´aquina virtual en la que se van a realizar los desarrollos y las modificaciones oportunas para convertir el core de Netfilter de CentOS 6.5 en un verdadero stateful firewall a nivel de aplicaci´on. Firewall (SDK Backup): Puesto que la m´aquina Firewall SDK es la m´as sensible a la corrupci´on del sistema, por el propio car´acter intrusivo de las modificaciones, disponemos de una m´aquina virtual de respaldo con el u ´ltimo punto de control estable de la m´aquina SDK. Firewall (Production): Es la m´aquina sobre la que se prueban los cambios una vez probados y depurados en los entornos de desarrollo. 31
Proyecto Fin de Carrera
2.3.
Departamento de Ingenier´ıa Telem´atica
Configuraci´ on de las VM
Para obtener el esquema mostrado en la Figura 18, es preciso crear las m´aquinas virtuales y configurar la red virtual conforme a la topolog´ıa de red deseada. Para crear una m´aquina virtual, nos vamos a la pesta˜ na Summary y seleccionamos ”New Virtual Machine” y nos aparecer´a el asistente de creaci´on de m´aquinas virtuales. A continuaci´on se nos da la opci´on de elegir el modo de instalaci´on, t´ıpico o personalizado.
Figura 19: Configuraci´on de las VM: Paso 1
32
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Puesto que la red a implementar es sencilla y para las m´aquinas virtuales nos basta con instalar un sistema operativo seleccionamos la opci´on ”Typical”. Lo siguiente que nos piden es el nombre que va a tener la m´aquina virtual. En el caso que nos ocupa, las m´aquinas virtuales se habr´ıan de llamar: CentOS 6.5 redBorder-Stronghold SDK CentOS 6.5 redBorder-Stronghold SDK Backup User1 User2 Server Client La importancia de la m´aquina Server Client se explicar´a con detalle en la secci´on 7.1 Inyecci´on de tr´afico con tcpreplay. Por el momento, creamos simplemente la m´aquina virtual y no le damos configuraci´on de red. A continuaci´on seleccionamos la ubicaci´on f´ısica donde queremos alojar las m´aquinas virtuales. Para tal prop´osito, hemos habilitado en el servidor un disco duro de pruebas donde se guardar´an las m´aquinas virtuales. Seleccionamos por tanto ”Disco de pruebas”.
Figura 20: Configuraci´on de las VM: Paso 2
33
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
En siguiente lugar especificamos el sistema operativo que se va a instalar en las m´aquinas virtuales. Una vez que se han especificado las caracter´ısticas generales de la m´aquina virtual se pide configurar las conexiones de red. Para ello, seleccionamos crear en la pesta˜ na NIC 3 interfaces de red con los siguientes prop´ositos: Interfaz conectada al switch de gesti´on: Se utilizar para alcanzar la m´ aquina desde la red real a la que estamos conectados. Interfaz conectada al VS1: Es un Virtual Switch que hemos creado para conectar a ´el las interfaces con presencia en la subred IP a la que pertenece User1 Interfaz conectada al VS2: Es un Virtual Switch que hemos creado para conectar a ´el las interfaces con presencia en la subred IP a la que pertenece User2
Figura 21: Configuraci´on de las VM: Paso 3
La gu´ıa de c´omo se crea un Virtual Switch y como se conectan a ´este las m´aquinas virtuales se puede ver en la secci´on 12.2 Configuraci´on de un Virtual Switch en VMware ESXi.
34
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Acto seguido, hay que especificar la cuota de disco que deseamos tener en cada la m´aquina virtual.
Figura 22: Configuraci´on de las VM: Paso 4
35
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Por u ´ltimo se finaliza el proceso y se comprueba que la m´aquina virtual se ha a˜ nadido al panel de la izquierda de la pantalla.
Figura 23: Configuraci´on de las VM: Paso 5
Figura 24: Configuraci´on de las VM: Paso 6
36
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Para editar la configuraci´on de las m´aquinas virtuales se selecciona la que deseemos, pulsamos bot´on derecho y pinchamos en ”Edit Settings...”
Figura 25: Configuraci´on de las VM: Paso 7
Figura 26: Configuraci´on de las VM: Paso 8
37
Proyecto Fin de Carrera
2.4.
Departamento de Ingenier´ıa Telem´atica
Instalaci´ on de CentOS 6.4 minimal
De todas las posibles opciones de CentOS vamos a utilizar la ISO minimal [26], que instala el conjunto de paquetes m´ınimo para el correcto funcionamiento del servidor. Este tipo de im´agenes son verdaderamente u ´tiles para la instalaci´on de servidores, o de equipos espec´ıficos en nuestro caso, puesto que no sobrecargan la m´aquina con paquetes que no se utilizan. Adem´as, la instalaci´on m´ınima no trae entorno gr´afico, ya que el entorno gr´afico consume una gran cantidad de recursos y queremos que nuestro equipo se dedique u ´nica y exclusivamente a una tarea. Por consiguiente, el acceso al equipo es a trav´es de una interfaz de comandos. Dado que ya disponemos de la m´ aquina virtual, ahora solamente es preciso especificar la ruta a la imagen ISO a partir de la cual vamos a instalar el sistema operativo y comenzar con la instalaci´ on. Para ello nos vamos al panel izquierdo de la aplicaci´on y seleccionamos nuestra m´aquina virtual. Pinchamos en ella, hacemos click derecho en el rat´on y seleccionamos ”Edit Settings...”
Figura 27: Instalaci´on de CentOS minimal: Paso 1
38
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Buscamos el dispositivo de lectura de CD/DVD y marcamos la opci´on ”Datastore ISO File”. Pinchamos en el bot´on ”Browse”, buscamos la ISO en el equipo y la seleccionamos.
Figura 28: Instalaci´on de CentOS minimal: Paso 2
Introducimos la contrase˜ na del super usuario y creamos el usuario por defecto.
Figura 29: Instalaci´on de CentOS minimal: Paso 3
39
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
A continuaci´on arrancamos la m´aquina virtual y se nos mostrar´a el asistente de instalaci´on de CentOS minimal. Este asistente es r´ apido, sencillo y no requiere de m´as configuraci´on (debido a que ya hemos facilitado al hypervisor gran parte de lo que la instalaci´ on requiere).
Figura 30: Instalaci´on de CentOS minimal: Paso 4
Una vez finalizado el proceso de instalaci´on la m´aquina se reiniciar´a y comenzar´a a cargar el sistema operativo.
Figura 31: Arranque de CentOS minimal
40
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
La carga finaliza con la aparici´on del terminal de CentOS. Tras loguearnos en el sistema ya estamos en disposici´on de utilizar el sistema operativo y de empezar con el desarrollo.
Figura 32: Pantalla de login de CentOS minimal
Pese a que estamos en plenas condiciones de empezar a explicar el proceso de desarrollo, previamente se va a explicar en el siguiente apartado como se gestiona un proyecto dentro de un equipo de trabajo utilizando control de versiones. La herramienta para conseguirlo se denomina Git y es quiz´as uno de los software de control de versiones m´as utilizados en el mundo del software libre.
41
Proyecto Fin de Carrera
2.5.
Departamento de Ingenier´ıa Telem´atica
Control de versiones: Git
Para la gesti´on de las fuentes del proyecto, se ha empleado un sistema de control de versiones distribuido llamado Git [27]. Un sistema de control de versiones guarda constancia de los cambios producidos en los ficheros a lo largo del tiempo de forma que puedan ser recuperadas las versiones anteriores a posteriori. Cabe destacar que aunque se emplea Git para el control de versiones del c´odigo fuente generado en este proyecto, es posible utilizar git para un fichero de forma gen´erica sin importar lo que contenga. Existen varias formas de mantener el control de versiones: [28] [29] Control de versiones en local: Consiste en una peque˜ na base de datos que almacena los cambios de versiones de los ficheros pertenecientes al directorio bajo control. Este sistema simplemente guarda copia de las modificaciones de cada fichero generando un fichero por cada modificaci´on guardada.
Figura 33: Control de versiones en local [30]
Control de versiones de forma centralizada: Surge a partir de la necesidad de colaborar y compartir ficheros con personas que est´an en un sistema diferente. Consiste en un servidor que contiene todos los ficheros bajo el control de versiones y del cual los usuarios bloquean las fuentes, realizan las modificaciones y actualizan la versi´on del fichero. Debido a la arquitectura centralizada, si el servidor cae se deja inaccesible el contenido que est´a bajo el control de versiones.
42
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Figura 34: Control de versiones de forma centralizada [31]
Control de versiones de forma distribuida: En esta arquitectura, no se comprueba la versi´on de un u ´nico fichero sino que se sincroniza el repositorio distribuido de manera completa. En caso de caer el servidor, el uso de este sistema distribuido permite tener siempre una copia de seguridad del repositorio original que puede ser restaurada en cualquier momento.
Figura 35: Control de versiones de forma distribuida [32]
43
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Git en particular tiene algunas caracter´ısticas que lo diferencian de otros sistemas de control de versiones. Esos sistemas, tales como Subversion, almacenan la informaci´on como cambios temporales asociados a un fichero de manera que lo que realmente existe es el fichero y sus trazas de modificaciones. Sin embargo, git trata los datos de una manera muy distinta. Git almacena una foto de cada modificaci´ on de un fichero con lo que en vez de un fichero y sus trazas de modificaciones lo que tenemos es el fichero en su versi´on original y otro fichero con las modificaciones por cada versi´on que exista del mismo.[33]
Figura 36: Checkin en git [34]
Git tiene tres estados fundamentales para determinar la situaci´on de un fichero. Dichos estados son:[33] Commited: Indica que un fichero est´a correctamente almacenado en el sistema. Modified: Indica que un fichero ha sufrido cambios pero que no han sido ”comitted” en el sistema. Staged: Indica que un fichero modificado ha sido marcado en su actual versi´on para poder proceder con el siguiente ”commit”.
44
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
Por consiguiente, y a la vista de los tres estados fundamentales, el flujo b´asico para el control de versiones en Git sigue el siguiente patr´on: [33] Se produce una modificaci´on en un fichero del directorio de trabajo bajo control de versiones. Se marcan los ficheros modificados y se depositan en la ”staging area”. Los ficheros de la ”staging area” son almacenados en el repositorio al hacer ”Commit”
Figura 37: Checkin en git [35]
45
Proyecto Fin de Carrera
Departamento de Ingenier´ıa Telem´atica
A continuaci´on se van a exponer los comandos b´asicos para gestionar el proyecto con git. Lo primero que debemos hacer es crearnos un directorio de trabajo. En nuestro caso, el directorio de trabajo se va a llamar ”project”, y las fuentes del proyecto se van a guardar en un directorio llamado ”redBorder-ndpi” [ root@redBorder−S t r o n g h o l d ]# mkdir −p p r o j e c t / redBorder−ndpi Entramos en el directorio en el que vamos a alojar el proyecto y hacemos un clone del servidor remoto: [ root@redBorder−S t r o n g h o l d ]# cd p r o y e c t / redBorder−ndpi [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# g i t c l o n e s e r m i l r o d @ m o r f e o : redBorder−ndpi Para registrar cambios en los ficheros del proyecto, y siguiendo el flujo b´asico, se utiliza el comando ´add´el cual deposita el fichero en la ”staging area” [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# g i t add n f c o n n t r a c k p r o t o t c p . c Para a˜ nadir los cambios a la copia local se utiliza el comando ”commit”. Con la opci´on -m se puede a˜ nadir un comentario al commit anterior [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# g i t commit −m ” Conntrack con e s t a d o s de n i v e l 7” Y por u ´ltimo para subir los cambios al repositorio remoto se utiliza el comando ”push” [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# g i t push Si en vez de provocar cambios, lo que estamos es interesados en actualizar el directorio de trabajo porque otro integrante del equipo ha realizado cambios, o porque deseamos actualizar el proyecto en otra m´aquina, se utiliza el comando ”pull” [ root@redBorder−S t r o n g h o l d redBorder−ndpi ]# g i t p u l l
46
