2. Creando las condiciones de desarrollo

Transcripción

1 2. Creando las condiciones de desarrollo 2.1. Virtualización 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áquina para albergar la tarea de desarrollo está dotada con el hypervisor VMware ESXi sobre el que virtualizaremos la distribución CentOS 6.5(Community ENTerprise Operating System) [23]. CentOS es una distribución que nació a partir de la distribución Linux Red Hat Enterprise Linux RHEL que no tiene relación legal con ella, aunque son distribuciones casi iguales, y que puede usarse libremente sin el soporte técnico de Red Hat [24]. En Enero de 2014 [25], Red Hat aúna esfuerzos con los desarrolladores de CentOS de forma que CentOS pasa a ser un proyecto más de Red Hat. La estabilidad de CentOS y su posterior incorporación en Red Hat hacen de esta distribución una buena opción para implementar nuestro firewall de aplicación. La versatilidad que da utilizar un esquema de virtualización para la etapa de desarrollo así como el ahorro en costes que supone disponer de un máquina que es capaz de simular distintos equipos y de simular distintas topologías de red hacen del servidor VMware ESXi idóneo 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és del software de gestión VMware vsphere Client. Figura 16: VMware vsphere Client Una vez dentro del sistema, las opciones de menú son relativamente simples e intuitivas para una rápida instalación y configuración de las máquinas virtuales: Summary: Permite monitorizar el estado de las máquinas virtuales, conocer las características del servidor de virtualización y realizar operaciones básicas sobre las máquinas virtuales (creado, reinicio, encendido, apagado...). 29

2 Virtual Machines: Se puede visualizar información más específica y detallada de las máquinas virtuales. Resource Allocantion: Nos permite conocer la ubicación física dentro del servidor ESXi donde se almacenan las máquinas virtuales. Performance: Recopila estadísticas de uso, funcionamiento y consumo de recursos de las máquinas virtuales. Configuration: Es el menú más amplio puesto que se encarga de la configuración del servidor y de las máquinas virtuales a todos los niveles. Cuenta con módulos básicos de configuración, uno a nivel hardware y otro a nivel software. A nivel hardware de configuración encontramos opciones configuración de memoria, procesadores, adaptadores de red, redes virtuales y consumo de energía. En el lado software disponemos de capacidad de configuración del servidor de tiempos, DNS, routing, autenticación de servicios, operaciones básicas de gestión de las máquinas virtuales, perfiles de seguridad y configuración avanzada de las máquinas 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

3 2.2. Escenario de trabajo Con el objetivo de reproducir las condiciones reales lo más fielmente posible, nos disponemos a crear un laboratorio de pruebas en el servidor ESXi que nos permita simular una situación típica en la que se pueda encontrar un firewall de aplicación. En particular, vamos a crear un entorno virtual de desarrollo en el que el firewall va a ser una máquina virtual que va a estar entre la Intranet de la organización e Internet, que simularía la implementación de un equipo específicamente diseñado para actuar de firewall en el perímetro de la red, es decir, a continuación del router que da salida a internet a la organización. No es obligatorio, pero el firewall también puede hacer NAT. Figura 18: Escenario de prueba Los equipos User1 y User2 van a ser máquinas virtuales que van a simular subredes IP de la Intranet. Como puede verse, queremos que todo el tráfico, incluido el tráfico interno, pase por el firewall. La gran ventaja de disponer de un firewall de aplicación es la capacidad de bloquear a nivel de aplicación flujos no solo exteriores sino también de la propia organización. De esta manera se puede evitar el uso inapropiado de diversos servicios dentro de la organización acorde a la política de seguridad y de uso corporativo establecida. Respecto a la máquina virtual que emula las capacidades del firewall, vamos a disponer de 3 instancias diferentes: Firewall (SDK): Es la máquina 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ón. Firewall (SDK Backup): Puesto que la máquina Firewall SDK es la más sensible a la corrupción del sistema, por el propio carácter intrusivo de las modificaciones, disponemos de una máquina virtual de respaldo con el último punto de control estable de la máquina SDK. Firewall(Production): Es la máquina sobre la que se prueban los cambios una vez probados y depurados en los entornos de desarrollo. 31

4 2.3. Configuración de las VM Para obtener el esquema mostrado en la Figura 18, es preciso crear las máquinas virtuales y configurar la red virtual conforme a la topología de red deseada. Para crear una máquina virtual, nos vamos a la pestaña Summary y seleccionamos New Virtual Machine y nos aparecerá el asistente de creación de máquinas virtuales. A continuación se nos da la opción de elegir el modo de instalación, típico o personalizado. Figura 19: Configuración de las VM: Paso 1 32

5 Puesto que la red a implementar es sencilla y para las máquinas virtuales nos basta con instalar un sistema operativo seleccionamos la opción Typical. Lo siguiente que nos piden es el nombre que va a tener la máquina virtual. En el caso que nos ocupa, las máquinas 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áquina Server Client se explicará con detalle en la sección 7.1 Inyección de tráfico con tcpreplay. Por el momento, creamos simplemente la máquina virtual y no le damos configuración de red. A continuación seleccionamos la ubicación física donde queremos alojar las máquinas virtuales. Para tal propósito, hemos habilitado en el servidor un disco duro de pruebas donde se guardarán las máquinas virtuales. Seleccionamos por tanto Disco de pruebas. Figura 20: Configuración de las VM: Paso 2 33

6 En siguiente lugar especificamos el sistema operativo que se va a instalar en las máquinas virtuales. Una vez que se han especificado las características generales de la máquina virtual se pide configurar las conexiones de red. Para ello, seleccionamos crear en la pestaña NIC 3 interfaces de red con los siguientes propósitos: Interfaz conectada al switch de gestión: Se utilizar para alcanzar la máquina desde la red real a la que estamos conectados. Interfaz conectada al VS1: Es un Virtual Switch que hemos creado para conectar a él 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 él las interfaces con presencia en la subred IP a la que pertenece User2 Figura 21: Configuración de las VM: Paso 3 La guía de cómo se crea un Virtual Switch y como se conectan a éste las máquinas virtuales se puede ver en la sección 12.2 Configuración de un Virtual Switch en VMware ESXi. 34

7 Acto seguido, hay que especificar la cuota de disco que deseamos tener en cada la máquina virtual. Figura 22: Configuración de las VM: Paso 4 35

8 Por último se finaliza el proceso y se comprueba que la máquina virtual se ha añadido al panel de la izquierda de la pantalla. Figura 23: Configuración de las VM: Paso 5 Figura 24: Configuración de las VM: Paso 6 36

9 Para editar la configuración de las máquinas virtuales se selecciona la que deseemos, pulsamos botón derecho y pinchamos en Edit Settings... Figura 25: Configuración de las VM: Paso 7 Figura 26: Configuración de las VM: Paso 8 37

10 2.4. Instalación 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ágenes son verdaderamente útiles para la instalación de servidores, o de equipos específicos en nuestro caso, puesto que no sobrecargan la máquina con paquetes que no se utilizan. Además, la instalación mínima no trae entorno gráfico, ya que el entorno gráfico consume una gran cantidad de recursos y queremos que nuestro equipo se dedique única y exclusivamente a una tarea. Por consiguiente, el acceso al equipo es a través de una interfaz de comandos. Dado que ya disponemos de la máquina 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ón. Para ello nos vamos al panel izquierdo de la aplicación y seleccionamos nuestra máquina virtual. Pinchamos en ella, hacemos click derecho en el ratón y seleccionamos Edit Settings... Figura 27: Instalación de CentOS minimal: Paso 1 38

11 Buscamos el dispositivo de lectura de CD/DVD y marcamos la opción Datastore ISO File. Pinchamos en el botón Browse, buscamos la ISO en el equipo y la seleccionamos. Figura 28: Instalación de CentOS minimal: Paso 2 Introducimos la contraseña del super usuario y creamos el usuario por defecto. Figura 29: Instalación de CentOS minimal: Paso 3 39

12 A continuación arrancamos la máquina virtual y se nos mostrará el asistente de instalación de CentOS minimal. Este asistente es rápido, sencillo y no requiere de más configuración (debido a que ya hemos facilitado al hypervisor gran parte de lo que la instalación requiere). Figura 30: Instalación de CentOS minimal: Paso 4 Una vez finalizado el proceso de instalación la máquina se reiniciará y comenzará a cargar el sistema operativo. Figura 31: Arranque de CentOS minimal 40

13 La carga finaliza con la aparición del terminal de CentOS. Tras loguearnos en el sistema ya estamos en disposición 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ás uno de los software de control de versiones más utilizados en el mundo del software libre. 41

14 2.5. Control de versiones: Git Para la gestión 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ódigo fuente generado en este proyecto, es posible utilizar git para un fichero de forma genérica 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ña 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ón 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án 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ón del fichero. Debido a la arquitectura centralizada, si el servidor cae se deja inaccesible el contenido que está bajo el control de versiones. 42

15 Figura 34: Control de versiones de forma centralizada [31] Control de versiones de forma distribuida: En esta arquitectura, no se comprueba la versión de un ú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

16 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ón 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ón 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ón original y otro fichero con las modificaciones por cada versión que exista del mismo.[33] Figura 36: Checkin en git [34] Git tiene tres estados fundamentales para determinar la situación de un fichero. Dichos estados son:[33] Commited: Indica que un fichero está 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ón para poder proceder con el siguiente commit. 44

17 Por consiguiente, y a la vista de los tres estados fundamentales, el flujo básico para el control de versiones en Git sigue el siguiente patrón: [33] Se produce una modificación 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

18 A continuación se van a exponer los comandos básicos 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 Stronghold]# mkdir p project/redborder ndpi Entramoseneldirectorioenelquevamosaalojarelproyectoyhacemosunclonedelservidor remoto: [ root@redborder Stronghold ]# cd proyect/redborder ndpi [ root@redborder Stronghold redborder ndpi]# git clone sermilrod@morfeo : redborder ndpi Para registrar cambios en los ficheros del proyecto, y siguiendo el flujo básico, se utiliza el comando áddél cual deposita el fichero en la staging area [ root@redborder Stronghold redborder ndpi]# git add nf conntrack proto tcp.c Para añadir los cambios a la copia local se utiliza el comando commit. Con la opción -m se puede añadir un comentario al commit anterior [ root@redborder Stronghold redborder ndpi]# git commit m Conntrack con estados de nivel 7 Y por último para subir los cambios al repositorio remoto se utiliza el comando push [ root@redborder Stronghold redborder ndpi]# git 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áquina, se utiliza el comando pull [ root@redborder Stronghold redborder ndpi]# git pull 46