Pruebas de conceptoRedes

GNS3: Montando el laboratorio con Sophos UTM Home y Cumulus Linux

¡Buenas, conejetes! Hoy vengo a traeros algo un poquito diferente, pero que hace tiempo ya tocamos en el blog (aquí y aquí). Se trata del uso de la herramienta GNS3 para crear nuestros propios laboratorios de prueba de infraestructuras de redes.

Sobra decir que para nuestras pruebas de seguridad y blue team esta herramienta puede servirnos de muchísimo, asi como para probar nuestras herramientas y técnicas sobre máquinas que simulan casi a la perfección a las reales (de hecho, la gran mayoría son directamente los appliances virtuales oficiales de las mismas).

Sin más dilación vamos a ponernos a ello!!

Planificación del laboratorio e instalación de máquinas

Lo primero será instalar GNS3 si no lo habéis hecho ya (revisar las entradas de los links más arriba). Os valdrá tanto en un host Windows, Linux o lo que prefiráis. De todas formas, ante cualquier duda (no quiero entretenerme más de la cuenta en la instalación de la herramienta en sí) podéis consultar los docs.

En mi caso, utilizo GNS3 principalmente sobre Windows y VMware Workstation, pero como os digo, sed libres de escoger lo que mejor se adapte a vuestros equipos 🙂

En este punto vamos a definir un poco nuestro laboratorio de pruebas. En mi caso, para empezar, quiero montar un pequeño laboratorio base compuesto por un Firewall, un Switch y varios equipos de usuario. Podríamos elegir cualquiera de las muchas opciones tanto para el Firewall como para el Switch. En el caso que nos ocupa, utilizaremos como Firewall un appliance virtual de Sophos UTM Home, que nos permite un uso ilimitado como usuario doméstico. Para el Switch, he elegido montar una instancia de Cumulus Linux VX, una distribución especializada en funciones de Switching que me resulta de lo más interesante, en este caso en formato de máquina virtual 🙂

Podéis encontrar los ficheros necesarios para importarlos a nuestro GNS3 en los siguientes enlaces:

No quiero entretenerme mucho tampoco (ocuparía más espacio del que me gustaría) en describir el proceso de importación a GNS3 de los appliances, además de que en la página oficial lo explican muchísimo mejor de lo que puedo deciros yo 🙂 Os lo dejo aquí: https://docs.gns3.com/1_3RdgLWgfk4ylRr99htYZrGMoFlJcmKAAaUAc8x9Ph8/index.html. Fijaos bien en descargar las máquinas en formato .qcow2!

Vamos a definir exactamente cómo queremos que sea nuestro laboratorio con el siguiente esquema:

Algunos comentarios de la arquitectura:

  • El Sophos UTM Home será el encargado de realizar las funciones de enrutado de la red (por simplicidad, al menos de momento). En el futuro podríamos añadir un Router salida a Internet y tener una infraestructura más realista 🙂
  • Creamos dos zonas de usuarios separadas en dos VLAN (10 y 20) que llamaremos zonas USR1 y USR2 en adelante por ahorrar tecla. Podrán acceder tanto a la DMZ como a servicios limitados en el exterior.
  • Creamos además una zona DMZ en la VLAN 16 que haremos accesible desde el exterior y desde las redes de usuarios.

Como véis, instalaremos de momento en la infraestructura cuatro máquinas Windows como clientes; dos máquinas Windows 7 y dos Windows 10. Así tenemos variadito. Elijo equipos finales Windows por dos razones principales: la primera es que estadísticamente la mayoría de ataques o implementaciones que se suelen probar es sobre ellos; la segunda es que en el futuro podríamos rematar el laboratorio montando un directorio activo o similar, muy útil para orquestar pruebas en escenarios empresariales. Podemos descargar imágenes de prueba para desarrollador, por ejemplo, en este enlace: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Instalaremos estas máquinas virtuales directamente sobre VMWare (o el software de virtualización que hayamos elegido), simplemente importando los ficheros .vmx de las máquinas comprimidas descargadas. Hecho esto con ambos modelos (W7 y W10), podemos simplemente realizar un clonado completo de las mismas para tener dos pares. Ni que decir que las dejaremos con el hardware “bare minimum”, es decir, un core y 1GB de RAM. Que queremos seguir pudiendo usar el PC teniendo unas cuantas máquinas encendidas 😛

Por último, montaremos una máquina Debian 9 con un servicio Apache2 levantado, a la que podrán acceder los equipos de ambas redes de usuarios exclusivamente al puerto HTTP, pero no a la inversa. Es decir, una zona desmilitarizada o DMZ que no podrá realizar conexiones al exterior. Podéis encontrar la imagen de instalación de Debian y las guías de instalación en los siguientes enlaces:

Fijaos que en el proceso de instalación se os da la opción de instalar un servidor web. Decid que sí, y además el SSH 🙂

Montaje inicial

Vamos ahora a montar las primeras máquinas sobre GNS3. Primeramente vamos a simplificar la infraestructura. Crearemos solamente un esqueleto muy básico con el Firewall Sophos UTM Home, el Switch Cumulus Linux VX y dos máquinas Windows 7 y Windows 10 como representantes de la primera red de usuarios.

Abrimos GNS3 y se nos pedirá que abramos o creemos un proyecto. Veremos además cómo se inicia la máquina virtual de GNS3 en nuestro software de virtualización. Vamos a crear en la ventana principal un nuevo proyecto llamado MADRIGUERA, nombre con el que a partir de ahora nos referiremos a nuestra infraestructura. Creo que sobra dar razones para el nombre.

Si realizamos antes correctamente la importación de las máquinas, podremos encontrar Cumulus Linux VX clicando en el botón Browse Switches del panel izquierdo (más facil si en el desplegable seleccionamos Installed appliances). Clicaremos en él y arrastraremos al lienzo del proyecto. Acto seguido haremos doble click en el texto que flota sobre el icono del dispositivo para cambiar su hostname. Lo llamaremos CumulusCore, nombre por el que le llamaremos a partir de ahora.

Dejaremos la instancia CumulusCore con las preferencias predeterminadas en GNS3. Podemos si queremos hacer click derecho en ella y clicar Configure para ver los parámetros generales que pueden configurarse, como la memoria RAM y las vCPUs o número de núcleos de procesador, el orden de arranque y el tipo de consola (telnet de forma predeterminada). En la pestaña Network podemos ver el número de adaptadores que tendrá el dispositivo virtual (7 de forma predeterminada) y su dirección MAC base. Como digo, por simplificar y al menos de momento, dejaremos estos valores predeterminados.

Antes de agregar siquiera el Firewall a la infraestructura, vamos a añadir al proyecto las dos máquinas de la red USR1, configurarles una IP estática y conectarlos al Switch para ver que pueden comunicarse entre ellos. Para agregar nuestras dos máquinas ya creadas en VMware, debemos ir a Edit -> Preferences -> VMware VMs y hacer click en el botón New. Se abrirá una ventana para poder importar la máquina de la lista de las instaladas actualmente en VMware. Agregaremos dos máquinas Windows 7 y Windows 10.

Podemos encontrarlas ahora en el menú lateral clicando en el botón de Browse End Devices. Clicaremos en ellas y las arrastraremos a la MADRIGUERA, cambiando además sus nombres por USR1_WIN7_10 y USR1_WIN10_11. El nombre corresponderá al nombre de su red, su sistema operativo, y la parte host de sus direcciones IP. Así no nos liamos 🙂

Notas: Tal vez tengamos que reiniciar GNS3 tras importar las máquinas para que las máquinas aparezcan en el menú. Debemos además asegurarnos de que las máquinas no tienen ninguna interfaz de red en sus preferencias en VMware, eliminándolas de no ser así (click derecho en la máquina -> Settings…, seleccionar la interfaz de red y hacer click en el botón Remove). GNS3 gestionará las interfaces.

Hora de conectar las máquinas de usuarios a CumulusCore. Es tan simple como hacer click en el icono Add a Link del panel lateral izquierdo para usar la herramienta de conexión. Haremos click en cada una de las máquinas seleccionando la única interfaz de red disponible y después en CumulusCore. Las conectaremos a las bocas swp5 y swp6.

Ahora debemos realizar un pequeño paso para permitir que GNS3 gestione las interfaces de red virtuales de VMware. Debemos ir a Edit -> Preferences -> VMware -> Advanced local Settings y hacer click en el botón Configure. Tras unos en los que podermos ver cómo se instalan las nuevas interfaces en una consola, tendremos hecho esto.

En este punto podemos encender nuestras máquinas virtuales, haciendo click derecho en sus iconos y pulsando Start. Veremos cómo las máquinas Windows se inician dentro de VMware. CumulusCore, por otra parte, se estará ejecutando dentro de la propia máquina virtual de GNS3. Si todo ha ido bien hasta ahora, veremos por todas partes ese color verde que tanto nos gusta.

Nota: Para que las máquinas se comuniquen, el servidor local y la máquina GNS3 deben estar en el mismo rango IP. Esto se seleccionaba en la configuración inicial tras instalar GNS3. Si no, no va a funcionar (creedme que lo he comprobado en mis carnes). En este post podéis ver cómo solucionarlo en caso de que en el apartado Topology Summary (ver imagen abajo) veáis rangos IP diferentes.

Podemos acceder a la máquina CumulusLinux mediante Telnet. Recordad que en un entorno real esto es inseguro no, lo siguiente, pero GNS3 nos lo configura así al inicio. Lo suyo en la “vida real” es realizar esta configuración directamente o bien mediante cable serial si es un dispositivo físico, o bien mediante la misma consola de VMware (que no tenemos accesible ahora mismo al correr sobre la máquina GNS3) o el software de virtualización que tuviésemos en producción, o bien por la interfaz dedicada de management… dependerá del caso y del dispositivo.

Hablando del acceso por Telnet, podemos utilizar cualquier programa de consola que tengamos, como bien puede ser Putty, Bitvise… En mi caso utilizo Mobaxterm. Tenéis la dirección y el puerto en el panel de la derecha como véis en la imagen de arriba. Además, podemos acceder al Telnet haciendo click con el botón derecho en el icono de la máquina en la MADRIGUERA y clicando en Console. De forma predeterminada intentará abrir el Putty de Solarwinds, pero si no lo tenéis instalado o simplemente no queréis usarlo, podéis seleccionar la herramienta de consola a utilizar en Edit -> Preferences -> General -> Console Applications.

Instalación y configuración básica de Cumulus Linux VX

Empezaremos accediendo mediante Telnet mediante la herramienta que elijamos a CumulusCore. Los credenciales predeterminados son:

  • cumulus / CumulusLinux!

Como vemos, Cumulus Linux es, sorpresa… un Linux. Concretamente si leemos el banner de bienvenida veremos que está basado en un Debian 8 con núcleo 4.1.0-cl-7-amd64.

Lo primero que haremos siempre por seguridad es cambiar la contraseña del usuario cumulus para el acceso:

sudo passwd cumulus

Lo segundo que haremos es configurarle un hostname, en este caso CumulusCore, y activar las interfaces swp5 y swp6, que como recordaréis son las que tienen conectados los dos equipos de usuario en USR1. Para esto ejecutaremos estos comandos en la interfaz de consola (incluyo un comentario con el significado de cada comando):

net add hostname CumulusCore # Establecerá el hostname
net add interface swp5-6 # Activará las interfaces swp5 y swp6
net pending # Mostrará los cambios realizados en la configuración. 
net commit # Guardará y aplicará los cambios. Mostrará además lo mismo que el anterior.

Podemos, tras escribir los cambios, comprobar el estado de las interfaces con el siguiente comando:

net show interface all

¡Vamos bien! A continuación activaremos los puertos swp5 y swp6 como miembros de un bridge. Esto quiere decir que los configuraremos como puertos de Switch de capa 2. Además, crearemos la VLAN 10 con la IP 192.168.10.101 y la asignaremos a bridge. Nos aseguramos de que los puertos quedan en modo acceso. Finalmente aplicaremos de nuevo los cambios.

net add bridge bridge ports swp5-6
net add vlan 10 ip address 192.168.10.101
net add bridge bridge vids 10
net add interface swp5 bridge access 10
net add interface swp6 bridge access 10
net commit

Podemos ver ahora en el listado de interfaces que aparece una interfaz bridge y que swp5 y swp6 aparecen asignadas a ella en modo Access.

Hecho esto, los equipos deberían poder comunicarse entre sí si les configurarmos una dirección IP estática del rango correspondiente a USR1, que es el 192.168.10.0/24. ¡Vamos a ello! Configuramos las máquinas USR1_WIN7_10 y USR1_WIN10_11 con sus direcciones IP correspondientes para poder comprobar la conectividad entre ellos mediante ping.

Nota: Tendremos que haber marcado la red como doméstica o de trabajo en el centro de redes de Windows para que la máquina responda a ping, o bien marcar Turn on network discovery Turn on file and printer sharing en Control Panel -> Network and Internet -> Network and Sharing Center -> Advanced sharing settings -> Guest or Public, para que las máquinas respondan a ping, o bien directamente desactivar el Firewall de Windows temporalmente.

Como podemos ver en las imágenes, el ping llega, así que las máquinas están conectadas correctamente 🙂 De momento todo va bien.

Instalación y configuración básica de Sophos UTM Home

Vamos a agregar ahora a nuestra infraestructura el Firewall Sophos UTM Home. Igual que con el resto de dispositivos, podemos hacerlo buscando en el panel lateral (en este caso pulsando en el botón Browse Security Devices) y pinchando y arrastrando en el dispositivo deseado. También le pondremos de nombre SophosUTM haciendo doble click en su nombre.

Acto seguido, utilizaremos de nuevo la herramienta Add a link para conectar el SophosUTM a CumulusCore. Realizaremos la conexión en la interfaz eth0 del SophosUTM (típicamente es la que se utiliza para el segmento LAN en el caso de este dispositivo) y en la interfaz swp1 del CumulusCore.

Por último encenderemos el SophosUTM haciendo click derecho en el mismo y selecionando Start.

Nota: Podría aparecer un aviso en GNS3 pidiendo más RAM. Sois libres de “tunear” la máquina de GNS3 para que vaya todo más fluido, pero dependerá de vuestro equipo. Yo, por ejemplo, en este punto le subí a 4GB de RAM y 2 cores.

Antes de nada tendremos que habilitar la boca del CumulusCore para permitir el tráfico en el enlace con el SophoUTM. Vamos para ello a ejecutar los siguientes comandos en la consola del mismo para configurarle un enlace de tipo trunk permitiendo la VLAN 10 de usuarios y además la VLAN 20que utilizaremos en el futuro. Tendremos además que agregar esta VLAN al Switch para ello, y de paso la VLAN 16 que usará la DMZ. Sin embargo, no queremos que en el trunk de segmentos LAN pase ésta última, sino solamente la 10 y la 20, así que tendremos que decir que solamente éstas puedan pasar por swp1.

net add vlan 20 ip address 192.168.20.101/24
net add vlan 16 ip address 172.16.0.101/24
net add interface swp1
net add bridge bridge ports swp1
net add interface swp1 bridge trunk vlans 10,20
net pending # Recuerda mirar siempre antes de guardar ;)
net commit

Con esto tendremos configurado el Switch para admitir el resto de las VLAN de cara a futuro, y con un trunk conectado al SophosUTM. Podemos comprobarlo con net show interface all:

Además, podemos verificar el trunk y sus VLAN permitidas si ejecutamos el comando net show interface swp1 detail:

Se admite de forma predeterminada siempre la VLAN 1 que, a no ser que queramos cambiarlo de forma explícita, es la VLAN nativa. Todos los paquetes que se envíen sin etiqueta de VLAN se considerarán por tanto de la VLAN 1.

Vamos ahora a empezar a configurar el SophosUTM en sí. Para acceder a él haremos click derecho en su icono en GNS3 y abriremos la consola, que en este caso abre una sesión VNC. Se nos presenta un precioso diálogo de instalación del aplicativo.

Pulsaremos intro con Start seleccionado y procederemos a la instalación. Primero detectará el Hardware, importante fijarse en los cuatro interfaces que se muestran, eth0-3, y que ha detectado que corre de forma virtual. Los primeros pasos de la instalación es sencilla, seleccionando nuestra distribución de teclado (española, pero podéis elegir otra si queréis), nuestro área (Europe/Madrid) la fecha y hora actual.

Se nos preguntará entonces a través de qué interfaz accederemos a la consola web de administración o WebAdmin. Seleccionaremos eth0, la cual tenemos conectada a CumulusCore y que será la utilizada para conectar a nuestro segmento LAN.

En el siguiente diálogo se nos pide la dirección IP mediante la cual acceder al servicio anterior. Estableceremos la dirección 192.168.10.1 y máscara 255.255.255.0, haciéndolo accesible desde el segmento USR1. No configuraremos un Gateway, dado que el mismo SophosUTM va a ser el Gateway de la red.

Si tenemos un equipo de 64 bits se nos preguntará si queremos un kernel de 64 bits, a lo que diremos que sí. Se nos preguntará después si queremos realizar una instalación completa del dispositivo o solamente los paquetes libres, a lo que diremos que queremos intalarlo todito. Confirmaremos por último que queremos proceder con el borrado de datos en el disco para la instalación y veremos como empieza el formateo y la instalación de paquetes.

Se nos avisará al cabo de un rato de que se ha terminado la instalación y que se puede reiniciar el aplicativo, y que podremos acceder al WebAdmin desde la dirección https://192.168.10.1:4444.

Tras aceptar el reinicio, se nos presentará en el VNC una pantalla de carga, pudiendo pulsar F2 para ver los detalles del arranque (veremos que es un Linux, como suele pasar). Finalmente se nos mostrará la pantalla de login de consola del aplicativo. No podremos hacer login por consola, sin embargo, hasta que accedamos al WebAdmin y completemos la configuración inicial.

Nos vemos ahora con un problema. ¿Por qué no podemos acceder desde los equipos de usuario? La respuesta es sencilla: al estar colocados en la VLAN 10 y llegar a un trunk, los paquetes llegan al SophosUTM con cabeceras 802.1Q con la etiqueta de dicha VLAN. Sin embargo, el SophosUTM de forma predeterminada no es consciente de que está conectado a un trunk y espera paquetes sin etiquetar.

¿Cual es la solución? Muchas veces estos aplicativos, cuando son físicos, se configuran previamente en una red aislada y luego se colocan en su destino. Otra solución es haberle configurado una interfaz diferente de gestión y haber complicado un poco la arquitectura colocando un puerto extra en el Switch en modo acceso. Haremos algo más sencillo ya que tenemos la libertad de estar haciéndolo todo en virtual: configuraremos termpoalmente  la boca swp5 del switch como acceso en la VLAN 1. ¿Qué solución aporta esto? Recordad que la VLAN 1, que es la nativa, se enviará por el trunk sin etiquetar. Por tanto, el SophosUTM podrá interpretar la comunicación y podremos acceder al WebAdmin.

Ejecutaremos estos comandos en el CumulusCore para ello:

net add interface swp5 bridge access 1
net pending # ;)
net commit

Podemos ejecutar el comando net show interface swp5 detail para comprobar que está en modo acceso y en la VLAN 1.

Podemos comprobar tras esto que desde la máquina USR1_WIN7_10 tenemos ping hacia 192.168.10.1, la dirección del SophosUTM, y que además desde un explorador podemos acceder a la interfaz WebAdmin. Por cuestiones de salud, instalé Firefox en la máquina para ésto (aquí los instaladores offline).

Accederemos a la página del WebAdmin y tras crear excepción de seguridad (el certificado del SophosUTM es, como es habitual, autofirmado; Advanced -> Add Exception -> Confirm Security Exception) se nos presenta el setup inicial.

En la primera pantalla podremos elegir el hostname del aplicativo como SophosUTM. Nuestra organización será MADRIGUERA, en Madrid (Spain). Elegiremos además nuestra contraseña de acceso como admin al mismo WebAdmin. Como no lo vamos a utilizar al menos de momento, dejamos cualquier cosa en el apartado de correo electrónico. Aceptamos los términos de licencia y clicamos en Perform basic system setup.

Tras 40 segundos de espera, como nos indicará un mensaje abajo, acabará el setup inicial y se nos volverá a presentar la pantalla para crear la excepción de seguridad. Tras crearla, podremos introducir los credenciales que elegimos para entrar en el WebAdmin y comenzar con la configuración básica del propio UTM.

Aprovecho ahora y os dejo el link de las guías de administración de Sophos UTM por si queréis consultar alguna duda sobre el proceso que seguiremos 🙂 https://community.sophos.com/kb/en-us/119209

En el primer diálogo se nos preguntará simplemente si queremos ejecutar el wizard o restaurar alguna copia de seguridad. Dejaremos seleccionado Continue y haremos click en Next.

En el siguiente diálogo se nos pide una clave de licencia. Si no queremos introducirla o al menos no de momento, se nos activará una evaluación de 30 días. Si queréis conseguir una clave de licencia Home, podéis crearos una cuenta en https://myutm.sophos.com/ y solicitarla en el apartado License Management -> Home Use License, tras lo cual podrás clicar en ella y descargar el fichero de licencia.

Llevaremos el fichero de licencia (es un simple .txt) a la máquina virtual y clicaremos en el icono de License File para subirlo al aplicativo. Se nos presentará una emergente y confirmaremos los datos y la subida de la licencia. Por último haremos click en Next.

El siguiente diálogo nos pide que especifiquemos la IP de cara al segmento LAN, que dejaremos como 192.168.10.1 y máscara 255.255.255.0. No activaremos el servicio DHCP; al menos de momento las IPs de los equipos finales serán estáticas.

Se nos pedirá ahora que configuremos la interfaz WAN, pero marcaremos la opción Setup Internet connection later, dado que de momento no hemos configurado la MADRIGUERA para proporcionar acceso a Internet ni tampoco nos hace falta. Por ahora con que nos funcione todo en las redes internas nos vale como estructura básica.

En el siguiente paso se nos preguntará si queremos permitir de primeras el acceso a algunos servicios a los segmentos de la LAN. Marcaremos los servicios Web, Email y DNS. Además, permitiremos que el UTM responda a los pings de momento para facilitar el troubleshooting, pero no dejaremos que les haga forward. Es decir, no permitirá el ping desde fuera hacia dentro.

En el siguiente paso, activaremos los servicios Intrusion Prevention Engine y Command & Control/Botnet Detection Engine, que realizan tareas de detección de ataques y también previene la comunicación por parte de máquinas detectadas como infectadas en base a la inspección del tráfico de red que pasa por el SophosUTM. Más tarde, como se indica, podremos afinar estos servicios con diversos parámetros de configuración.

En el siguiente paso podremos configurar la protección web o Web Protection. Primero activaremos el escaneo de sitios web en busca de amenazas y/o virus. Además, podemos bloquear el acceso a diversos tipos de sitios web en base a su temática. Vamos a bloquear los sitios web con temáticas Criminal Activities, Extremistic Sites, Suspicious y Weapons. Les dejamos los juegos, no vamos a ser tan mala gente.

Activaremos la inspección de correos electrónicos obtenidos mediante POP3 por pura prevención (aunque no podrá inspeccionar POP3S), pero no configuraremos un servidor de correo interno de la organización. Básicamente porque no lo tenemos.

Finalmente se nos presenta un resumen de lo que hemos configurado. Si todo está bien, haremos click en Finish para terminar la configuración inicial y se nos enviará al Dashboard, que por cierto me parece to bonico. Si queréis podéis entreteneros un rato ahora inspeccionado los diferentes apartados y lo que ofrecen 🙂

¿Recordáis el lío con las VLAN? Vamos a solucionarlo rápidamente. Iremos al menú lateral y seleccionaremos Interfaces & Routing -> Interfaces. Veremos que únicamente está configurada la interfaz eth0, que es la que configuramos para el acceso a los segmentos LAN.

Haremos click en el botón Edit para editar los parámetros de la interfaz. Vamos a cambiar su tipo de Ethernet a Ethernet VLAN, rellenando el campo VLAN Tag con el valor 10. ¿Qué quiere decir esto? Que en vez de recibir tráfico sin etiquetar por la VLAN nativa 1 como estamos haciendo ahora, podremos recibirlo con la etiqueta de la VLAN 10, haciendo uso de la interfaz trunk a la que estamos conectados y el protocolo 802.1Q. Colocaremos además un comentario aclaratorio sustituyendo al que hay y nombraremos a la interfaz Internal-USR1. Dejaremos la misma dirección IP. Hecho esto, haremos click en Save.

Veremos que desde nuestra máquina USR1_WIN7_10 hemos perdido el acceso, dado que ahora mismo no está colocada en la VLAN 10. Podemos comprobar sin embargo que en la USR1_WIN10_11, que sí que lo está, sí que lo tenemos 🙂 Para poder seguir configurando desde la primera, ejecutaremos en el CumulusCore los siguientes comandos para mandar de vuelta la interfaz swp5 a la VLAN 10:

net add interface swp5 bridge access 10
net pending
net commit

Y podremos comprobar que tenemos acceso de nuevo. Por último, configuraremos los dos equipos de la red USR1 para utilizar SophosUTM como gateway de la red.

Creación de la segunda red de usuarios

Vamos a necesitar en el futuro acceso también a la VLAN 20 por esa boca, vamos a ir de nuevo a Interfaces & Routing -> Interfaces y hacer click en New Interface… para agregar otra nueva interfaz de tipo Ethernet VLAN. La configuraremos de forma exactamente igual que la anterior, solo que para la red USR2 en la VLAN 20, y con la dirección IP del rango correspondiente (192.168.20.1). Fijaos bien en utilizar eth0 en el selector de Hardware para indicar que se usa la misma interfaz física que la anterior.

Importante notar que tras clicar en Save y volver a la pantalla de configuración de interfaces, hace falta hacer click en el botón deslizante de la interfaz para activarla. Debería quedanos algo así (si se queda un aviso rojo de DOWN, actualizad la página):

Ahora ya somos capaces de recibir por esa entrada tráfico de ambas redes de usuarios. Contando con esto y que ya teníamos agregada la segunda VLAN en el CumulusCore, podremos añadir a GNS3 nuestra segunda serie de equipos de usuario de forma exactamente igual que como hicimos en en la primera (ahora vamos mas rápido, ¿eh?).

Importaremos las máquinas correspondientes y las conectaremos en el lienzo de la MADRIGUERA las dos nuevas máquinas, conectándolas a las interfaces swp3 y swp4 de CumulusCore y nombrándolas con la misma nomenclatura. Finalmente las encenderemos y les configuraremos manualmente las direcciones IP 192.168.20.10 y 192.168.20.11 y con el SophosUTM como gateway de la red, utilizando su dirección IP 192.168.20.1.

¿Qué nos falta para que funcione? Efectivamente, tendremos que ejecutar algunos comandos en CumulusCore para habilitar las interfaces a las que conectan los equipos de USR2:

net add interface swp3-4 bridge access 20
net pending
net commit

Hecho esto, podemos comprobar en las máquinas que tienen conectividad con el SophosUTM y entre ellas (recordad igual que antes que podríais tener que activar el descubrimiento de red). Ya tenemos creada correctamente nuestra red USR2 🙂

Nota: en los equipos de usuario de ambas redes podemos hacer ping al gateway de la otra. Esto es debido a que marcamos en el setup inicial que se podía hacer ping al SophosUTM, y éste lo interpreta con que lo permite (y crea reglas internamente para ello) a todas sus interfaces. Lo mismo ocurre con el acceso a WebAdmin, dado que podemos acceder a través de eth0, interfaz física a la que están conectadas ambas redes de usuario. En próximas entregas lo solucionaremos 😉 Quedaos de momento con que los segmentos de las VLAN sí que están aislados entre sí.

Creación de la DMZ

Nos acercamos al fin de nuestro “esqueleto” inicial del laboratorio, y es que solamente nos falta montar una zona DMZ. Teniendo una máquina Debian creada en VMware, vamos igual que las máquinas Windows de las redes de usuarios a importarla dentro de GNS3 y agregarla al lienzo de la MADRIGUERA. Le pondremos de nombre DEBIAN_WEB en un alarde de imaginación. Recordad eliminar de la máquina desde VMware los interfaces de red.

Lo que vamos a hacer es conectar la máquina de la DMZ a una interfaz del switch CumulusCore como siempre, pero no vamos a hacer que ésta vaya por la interfaz swp1 configurada como trunk hasta la eth0 de SophosUTM. En su lugar realizaremos otra conexión desde CumulusCore hasta la interfaz eth2 de SophosUTM, que típicamente es la que se marca como DMZ en los aplicativos físicos.

Realmente podríamos hacerlo agregando la VLAN 16 al trunk y configurar el enrutado y las políticas de acceso para que sea como una interfaz totalmente separada. ésto el inconveniente de que cargaremos más el mismo enlace y dejaremos desaprovechados más interfaces del SophosUTM. Además, la configuración es más sencilla y mucho menos liosa si conectamos el segmento DMZ a una interfaz física separada. Por tanto, vamos a ello.

Nos encontramos un pequeño problema, y es que necesitamos 2 interfaces libres en el CumulusCore pero solamente hay una. Tendremos que hacer click derecho en el aplicativo en GNS3 y seleccionar Stop para detenerlo, además de detener el resto de máquinas Windows. Eliminaremos los links creados hasta ahora (GNS3 nos obliga a hacerlo antes de cambiar el número de adaptadores). Volveremos a hacer click derecho y seleccionaremos Configure y la pestaña Network. Allí podremos editar el número de adaptadores o interfaces. De cara a futuro, cambiaremos el número de bocas de 7 a 20 y haremos click en OK para guardar los cambios.

Nota: Si GNS3 a la hora de borrar los links os da error de que no existe, reiniciad la aplicación y debería solucionarse.

Hecho esto, volveremos a crear todos los links como estaban antes, además de agregar uno entre DEBIAN_WEB y la interfaz swp10 de CumulusCore y otro entre la interfaz eth2 de SophosUTM y swp9 de CumulusCore.

Volveremos a arrancar CumulusCore y al menos una máquina de cada VLAN de usuarios (y evidentemente el SophosUTM) si tuvimos que reiniciar la aplicación o los detuvimos en algún descanso 😛 Podremos ahora activar las bocas swp9-10 del CumulusCore en modo acceso para la VLAN 16 y permitir así la comunicación entre DEBIAN_WEB y el Firewall:

net add interface swp9-10 bridge access 16
net pending
net commit

Ya tenemos las interfaces activadas y configuradas en el switch. Configuraremos ahora en SophosUTM la nueva interfaz yendo a Interfaces & Routing -> Interfaces -> New Interface. Llamaremos a la nueva interfaz DMZ, de tipo Ethernet al no necesitar gestionar VLAN (al ser de tipo access el link no se realiza etiquetado), y con la interfaz hardware eth2. Le añadiremos asimismo la dirección IP 172.16.0.1/24 y un pequeño comentario aclaratorio.

Haremos click en Save e igual que en los casos anteriores haremos click en el botón deslizante de la interfaz para activarla.

Podemos arrancar la máquina DEBIAN_WEB desde GNS3 y comprobar que el servicio Apache2 está corriendo con systemctl status apache2. Debería aparecer como active (running) en el estado del servicio y además poder acceder a localhost desde Firefox y que se nos muestre la pantalla inicial de Apache2.

Configuraremos de forma estática una dirección IP de la interfaz Ethernet, que en este caso aparece en la máquina como ens33. Dependiendo de si hemos instalado entorno de escritorio o no, se hará de diferente manera, porque en el primer caso tendremos a NetworkManager gestionando esto.

En este caso tendremos que hacer click derecho en el icono de red en la barra de tareas, seleccionar Edit Connections, seleccionar Wired connection 1 y pulsar Edit para gestionar la conexión. En el apartado IPv4 Settings encontramos lo necesario, seleccionado el método Manual y pulsando Add para agregar los campos de dirección, máscara y gateway. Por último hacemos click en Save.

En caso de no haber elegido entorno de escritorio, podéis seguir el siguiente enlace para establecer la IP estática: https://linuxconfig.org/how-to-setup-a-static-ip-address-on-debian-linux

Podemos comprobar desde una terminal que ahora tenemos conexión ping con el gateway en la dirección 172.16.0.1, pero no a ninguna dirección IP de cualquiera de las otras subredes (a excepción de las dirección gateway por la razón que decía antes).

Podemos ahora probar a acceder al servicio web de la DMZ desde las máquinas USR1_WIN7_10 y USR2_WIN7_10. Podemos ver que desde la primera podemos, mientras que no desde la segunda. ¿Por qué? Hay dos configuraciones simultáneas que nos están permitiendo acceder desde la primera red de usuarios:

  • Existen tres reglas creadas durante el setup inicial que si recordáis permiten acceder a los servicios DNS, Email y Web Surfing desde eth0, que en su momento transformamos a la que es ahora Internal-USR1. Por tanto, ahora mismo esto permite al segmento USR1 acceder a cualquier servicio web en el exterior. Podemos ver lo en Network Protection -> Firewall.

  • Además, habilitamos el servicio Web Protection en otro paso del mismo setup inicial para poder filtrar contenidos de páginas chungas. Podemos ver esto en Web Protection -> Web Filtering, que muestra la interfaz Internal-USR1 como red permitida. El firewall permitirá el acceso web pasando mediante el filtro, haciendo una suerte de bypass de las reglas de bloqueo del Firewall.

Como queremos que tanto una red de usuarios como otra tenga acceso a la DMZ y además en general a servicios web, pero pasando por el filtro, añadiremos la interfaz Internal-USR2 tanto a las reglas de Firewall como a las redes permitidas del Web Protection.

En las reglas de Firewall, será tan fácil como clicar en Edit en cada una de las reglas y, haciendo click en el icono de carpeta del apartado Sources, dejar que se abra un nuevo panel lateral y clicar y arrastrar el elemento Internal-USR2 (Network), agregando así toda la subred USR2. Haremos click en Save para guardar cada una de las reglas.

Para el Web Protection, en el apartado Web Filtering agregaremos de forma muy similar a Allowed Networks esta misma red y haremos click en Apply.

Desde el mismo momento que agregamos la subred USR2 a las reglas de Firewall podemos ya comprobar que desde la máquina de usuario USR2_WIN7_10 tenemos acceso al servicio web. ¡Ya lo tenemos!

Conclusiones

Dejamos aquí nuestro esqueleto montado para seguir en el futuro extendiéndolo un poco 🙂 Nos queda pendiente, sobre todo, jugar con los diferentes servicios que nos ofrece el Firewall en cuanto a filtrado, detección y prevención de intrusiones, enrutado… Así como poder ir extendiendo la infraestructura con otros elementos tanto de red puros como de seguridad.

Espero de verdad que os haya gustado (la verdad es que me ha quedado un tocho importante) y que os sirva para practicar un poco y montar vuestros propios laboratorios. Un saludo conejetes y como siempre gracias por leernos!!

6 comentarios en “GNS3: Montando el laboratorio con Sophos UTM Home y Cumulus Linux

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Los datos introducidos se guardarán en nuestra base de datos como parte del comentario publicado, como se indica en la política de privacidad.