Descripción de la Implementación de la Nueva Topología de Red de la Empresa KARAS Project (Parte I)

Saludos nuevamente.

El siguiente post describe el estudio previo (y sus posteriores modificaciones) del montaje, implementación y puesta a punto de un PC-router para la Red Telemática de la empresa de un amigo mío. Por razones obvias sustituiré el nombre real de la empresa por el que he estado usando en los ejemplos que he puesto en el blog: Empresa KARAS Project (Castillito, discúlpame otra vez por tomar el nombre :-D), y los rangos de direcciones IP internas utilizados en la nueva topología.

En él se explica al detalle todo lo referente al proceso de estudio desde el equipamiento a escogido hasta la posterior configuración de sus secciones.

NOTA: Aquí es válido aclarar que una de las intenciones de este post es que el administrador de la red de una organización aproveche al máximo el equipamiento de que dispone (claro, en caso de que lo tenga y esté siendo subutilizado) para así implementar una topología medianamente decente que le permita tener un poco más de seguridad en su red.

El post está dividido por epígrafes, los cuales dan una información completa del proceso.

Configuración actual de la Red

Primero que todo, hay que hablar de la red. Inicialmente la empresa KARAS Project cuenta con una red sencilla compuesta por el router de ETECSA, un PC-router con IPCop como sistema operativo el cual tiene un cable de red conectado al elemento antes mencionado y otro a al switch de la LAN. En la imagen siguiente se ve la topología:

Nodo KARAS Project - Topologia Anterior de la Red

El gran problema de esta configuración está en el PC-router, el cual funciona durante un tiempo y luego presenta problemas, además de estar en un hardware antiguo (un P3) y no disponer de actualizaciones ni parches de seguridad.

Nuevo diseño de la Red

Por lo antes descrito, se decidió modificar la topología de la red para ganar más en seguridad y eficiencia. El nuevo modelo propone 8 subredes controladas por un nuevo PC-router conectado a un nuevo switch Allied Telesys AT-GS950/24 con características especiales (switch Capa 2 o L2, el único que tiene hasta el momento), todo ello con un direccionamiento IP diferente. He aquí el diagrama desde la perspectiva física de la red (perdón si alguno no lo entienden, me llevó un buen rato hacerlo de manera tal que reflejara todo lo mejor posible):

Nodo KARAS Project - Topologia de la Red

Subredes y direccionamiento IP

  • VLAN 1: Dispositivos de conectividad, 10.0.1.0/28
  • VLAN 2: Gestión de los Hipervisores Proxmox, 10.0.1.16/28
  • VLAN 10: Administradores de Red de KARAS Project, 10.0.1.32/28
  • VLAN 11: Servidores de Red Internos de KARAS Project, 10.0.1.64/27
  • VLAN 12: Servidores de Red Externos (DMZ) de KARAS Project, 10.0.1.96/29
  • VLAN 13: Red LAN de KARAS Project, 10.0.1.128/25
  • VLAN 14: Red WAN – Internet/Red-CUBA (ETECSA), 190.6.YYY.120/29
  • VLAN 15: Sucursales de KARAS Project (VPN Local IP/MPLS contratada a ETECSA), 10.0.3.0/30

 

Detalles iniciales de las subredes

A continuación se muestran los detalles d elas subredes a utilizar:

  • Subred de dispositivos de Conectividad (Internetworking)

 

Esta subred contiene solamente a los activos de red que intervienen en la infraestructura de conectividad como routers, switches administrables, bridges, etc. Dado que las direcciones IP de los switches se establece en la VLAN de administración pública (la VLAN 1), se decidió que todos los equipos estarán en esta misma VLAN.

Sólo los Administradores de la Red accederán a esta subred.

Elementos que la componen:

  1. n-c-rt-1.red.karas.co.cu: 10.0.1.1 (PC-router Master)
  2. n-c-sw-1.red.karas.co.cu: 10.0.1.2 (Switch Allied Telesys AT-GS950/24)

 

  • Subred de Gestión de Hipervisores Proxmox

En esta subred están ubicados los servidores que fungen como Hipervisores de máquinas virtuales, donde dichas máquinas virtuales no son más que los servidores de red de la empresa. En los mismos está instalado el software de virtualización Proxmox VE 3.3.

Sólo los Administradores de la Red accederán a esta subred.

Elementos que la componen:

  1. prx-c0-1.red.karas.co.cu: 10.0.1.18 (Servidor DELL PowerEdge T420)
  2. prx-c0-2.red.karas.co.cu: 10.0.1.19 (Servidor DELL PowerEdge T420)

 

  • Subred de los Administradores de la Red de KARAS Project

 

En esta subred se ubicarán las estaciones de trabajo del Administrador de Red y del Especialista de Seguridad Informática, a las cuales se les aplicarán políticas de seguridad especiales para prever accesos no autorizados.

Estas estaciones de trabajo accederán a todas las subredes.

  • Subred de los Servidores de Red Internos de KARAS Project

 

En esta subred se ubicarán los Servidores Internos de Red y Servicios de toda la empresa, los cuales interactuarán con otros servidores que están ubicados en la DMZ, los cuales son visibles tanto en Internet como en la Red CUBA.

A esta subred accederán todas las otras subredes.

  • Subred de los Servidores de Red Externos (DMZ) de KARAS Project

 

En esta subred se ubicarán servidores con servicios que serán visibles o desde Internet o desde la Red CUBA. Dichos servicios normalmente son muy específicos: DNS, MX (Servidor de Correo de tráfico entrante), Servidor de Correo de tráfico saliente, etc., todo esto mediante NAT y/o PAT.

A esta subred accederán los Administradores de Red y los servidores de la red interna que estén autorizados a interactuar con los servidores ubicados aquí.

  • Subred de la Red LAN de KARAS Project

 

En esta subred se ubicarán los servidores de dominio y las estaciones de trabajo de la Red LAN de la empresa KARAS Project, las cuales solamente accederán a la subred de los servidores. Inicialmente se conservará el direccionamiento IP actual, pero en un futuro no muy lejano se establecerá el nuevo direccionamiento.

Desde esta subred se accede a los Controladores de Dominio ubicados en ella y a los servidores internos de la empresa.

  • Subred de la Red WAN (Red CUBA – ETECSA)

 

En esta subred se ubicará el router de ETECSA que apunta o hacia Internet o hacia la Red CUBA. Aquí la DMZ de la empresa será vista a través de NAT/PAT.

A ella solamente saldrán los servidores que se definan en la DMZ.

  • Subred de las Sucursales de KARAS Project

 

En esta subred se ubicarán servidores (en caso de ser necesarios) y estaciones de trabajo de las sucursales de la empresa, las cuales solamente accederán a la subred de los servidores internos. Las mismas estarán interconectadas dentro de una VPN local que se contrató con ETECSA y, a su vez, se conectarán al Nodo de la empresa a través de esta subred. En este punto es válido aclarar que los equipos ubicados en esta subred deben tener visibilidad completa desde el Nodo, nada de usar NAT para resolver problemas de conectividad (porque sería, a la larga, un cuchillo en la garganta del administrador).

Desde esta subred se accede a los servidores internos de la empresa.

Más adelante se detallan algunos de los elementos mencionados anteriormente.

Hasta aquí el nuevo diseño del a red. Ahora toca el turno a la descripción del PC-router que se utilizará.

Configuración del switch principal

Para que el PC-router sea capaz de encaminar el tráfico a través de su única tarjeta de red, el puerto del switch al que se conecta debe ser un puerto VLAN-tagged. Afortunadamente disponemos de un switch Allied Telesys AT-GS950/24, el cual permite realizar una configuración Router-on-Stick, o sea, el router, o PC-router, es el elemento central de la infraestructura de la red al cual se conectan los switches principales (tipo Capa 2 o L2) mediante enlaces troncales IEEE 802.1Q (VLAN Tagging) y a estos se conectan en cascada otros switches de las mismas características y de la misma forma. Por tanto, el control del tráfico lo garantiza dicho elemento central.

Entonces, para el caso que nos ocupa, sólo se dispone de un switch, así que la intención es aprovecharlo lo mejor posible.

NOTA: La configuración de este modelo de switch no permite nombres compuestos separados por “-” o “_”. Por lo tanto, en algunos casos se usaron palabras unidas según permite el dispositivo.

Las VLANs en el switch se configuran de la misma forma que se muestra en este post, así que no voy a poner aquí esa cantidad de imágenes. Claro está que también existen otros parámetros a configurar en el equipo, configuración que es relativamente fácil de realizar.

Equipamiento del PC-Router Físico

Al no disponer la empresa de un presupuesto medianamente responsable para la adquisición de un router especializado, como un Cisco por ejemplo, se decidió utilizar una PC de escritorio y adaptarla como PC-router utilizando las bondades del software libre.

El PC escogido tiene las siguientes características:

  • 512 MB RAM
  • 80 GB HDD
  • 1 Ethernet NIC (Onboard Realtek 8111/8169)

 

Sistema Operativo de los PC-Routers

(Oh, una parte muy polémica esta)

Como dije en un post anterior, ahora existe una fuerte tendencia a usar pfSense como IOS (Sistema Operativo de Internetworking – Internetworking Operating System) de PC-Routers, inclusive me han instado a que use pfSense en lugar de VyOS porque está basado en BSD, tiene una interfaz amigable, etc., etc., etc. A mi en lo particular, hasta ahora, no me llama la atención ese cambio, dado que ya estoy habituado a usar VyOS desde hace ya un buen período de tiempo (de hecho, hice mis pequeños engendros que aún hoy funcionan) y por un problema de mantenerme en la línea de GNU/Linux Debian, de la que VyOS se deriva.

Es verdad que pfSense no está mal, tiene una buena cantidad de características buenas, pero la cosa está en que de todos los colegas que me la han pedido ninguno me pregunta por el repositorio. Sí, pfSense tiene un repositorio, y sobre él hay que estar pendiente a la más mínima actualización que publiquen; entonces, el que dispone de acceso a Internet no tiene problema con eso, pero… ¿y el que no dispone de acceso nacional nada más? Demasiado trabajo. En fin, cada cual escoja el que le sea más cómodo.

Bueno, el sistema operativo que se escogió como IOS del PC-router es la distribución de GNU/Linux VyOS 1.1.6 (Helium), la cual es un fork o derivación de otra distribución llamada Vyatta 6.6R1, ya “eliminada” para la comunidad por la compañía que la compró en 2012, Brocade.

Dicho sistema operativo es compatible, hasta cierto punto, con las configuraciones de Vyatta, pero en su sitio WEB sus autores alegan que en futuras versiones el objetivo es alejarse de su origen.

Funciones de los PC-Routers

Este PC-router tendrá las siguientes funciones:

  1. Reenviador DNS
  2. Enrutador
  3. NATeo de la DMZ
  4. Cortafuegos

 

Interfaces de Red

Con respecto a las interfaces de red, el PC-router físico tiene una sola interfaz de tipo on-board Realtek 8111. Este modelo tiene otras características:

  • RFC 894 – Ethernet II encapsulation
  • IEEE 802.1D MAC bridges
  • IEEE 802.1Q Virtual LANs
  • IEEE 802.2 logical link control
  • IEEE 802.3ab 1000T
  • IEEE 802.3ad (LACP) link aggregation
  • IEEE 802.3u 100TX
  • IEEE 802.3x full-duplex operation
  • IEEE 802.3z Gigabit Ethernet

 

Mientras que el PC-Router virtual también tendrá 7 interfaces de red que serán proporcionadas a través de su hipervisor (bridges virtuales), una por cada VLAN establecida.

Teniendo esto en cuenta, a modo de ejemplo se muestra un pequeño segmento del código de la configuración de las interfaces de red del VyOS en el PC-Router físico:

# set interfaces ethernet eth0 vif 1 address 10.0.1.1/28

# set interfaces ethernet eth0 vif 1 description “VLAN de los Equipos de Internetworking”

 

# set interfaces ethernet eth0 vif 2 address 10.0.1.17/28

# set interfaces ethernet eth0 vif 2 description “VLAN de Gestión de los Hipervisores”

 

# set interfaces ethernet eth0 vif 10 address 10.0.1.33/28

# set interfaces ethernet eth0 vif 10 description “VLAN de los Administradores de Red”

 

# set interfaces ethernet eth0 vif 11 address 10.0.1.65/27

# set interfaces ethernet eth0 vif 11 description “VLAN de los Servidores Internos de Red”

 

# set interfaces ethernet eth0 vif 12 address 10.0.1.97/29

# set interfaces ethernet eth0 vif 12 description “VLAN de los Servidores Externos de Red (DMZ)”

 

# set interfaces ethernet eth0 vif 13 address 10.0.1.129/25

# set interfaces ethernet eth0 vif 13 description “VLAN de la Red LAN de KARAS Project”

 

# set interfaces ethernet eth0 vif 14 address 190.6.YYY.122/29

# set interfaces ethernet eth0 vif 14 address 190.6.YYY.123/29

# set interfaces ethernet eth0 vif 14 address 190.6.YYY.124/29

# set interfaces ethernet eth0 vif 14 address 190.6.YYY.125/29

# set interfaces ethernet eth0 vif 14 address 190.6.YYY.126/29

# set interfaces ethernet eth0 vif 14 description “VLAN de la Red WAN – Red CUBA”

 

# set interfaces ethernet eth0 vif 15 address 10.0.3.2/30

# set interfaces ethernet eth0 vif 15 description “VLAN de la VPN Local IP/MPLS donde estan ubicadas las Sucursales Remotas”

NOTA: La dirección IP 190.6.YYY.121 está asignada a la interfaz de red del Router de ETECSA, el cual funge como puerta de enlace a la Internet/Red-CUBA.

Enmascaramiento de la Red, NAT y PAT hacia la Red CUBA

NOTA: Las direcciones IP que se utilizan en la configuración del NAT deben estar previamente definidas, en caso contrario, el sistema lanzará el aviso:

[nat source]

Warning: IP address <Dirección IP de salida> does not exist on the system!

Numeración de reglas

  • 10-29: Reglas SNAT
  • 30-49: Reglas DNAT para los Servidores de Red
  • 50-69: Reglas MASQUERADE

 

Subred de Servidores de Red Externos (DMZ) de KARAS Project

SNAT

  • 10.0.1.97 —> 190.6.YYY.122 (Servidor de Correo Externo de Tráfico Entrante 1 – MX 1)
  • 10.0.1.98 —> 190.6.YYY.123 (Servidor de Correo Externo de Tráfico Entrante 2 – MX 2)
  • 10.0.1.99 —> 190.6.YYY.124 (Servidor de Correo Externo de Tráfico Saliente – SMTP Saliente)
  • 10.0.1.100 —> 190.6.YYY.125 (Servidor WEB Externo)
  • 10.0.1.101 —> 190.6.YYY.126 (Servidor Proxy de internet/Intranet-CUBA Externo)

 

Código:

# set nat source rule 10 description “Enmascaramiento del Servidor de Correo Externo de Trafico Entrante 1 – MX 1  (SNAT)”

# set nat source rule 10 outbound-interface eth0.14

# set nat source rule 10 source address 10.0.1.97

# set nat source rule 10 translation address 190.6.YYY.122

 

# set nat source rule 11 description “Enmascaramiento del Servidor de Correo Externo de Trafico Entrante 2 – MX 2  (SNAT)”

# set nat source rule 11 outbound-interface eth0.14

# set nat source rule 11 source address 10.0.1.98

# set nat source rule 11 translation address 190.6.YYY.123

 

# set nat source rule 12 description “Enmascaramiento del Servidor de Correo Externo de Trafico Saliente – SMTP Saliente (SNAT)”

# set nat source rule 12 outbound-interface eth0.14

# set nat source rule 12 source address 10.0.1.99

# set nat source rule 12 translation address 190.6.YYY.124

 

# set nat source rule 13 description “Enmascaramiento del Servidor WEB Externo (SNAT)”

# set nat source rule 13 outbound-interface eth0.14

# set nat source rule 13 source address 10.0.1.100

# set nat source rule 13 translation address 190.6.YYY.125

 

# set nat source rule 14 description “Enmascaramiento del Servidor Proxy de Internet/Intranet-CUBA (SNAT)”

# set nat source rule 14 outbound-interface eth0.14

# set nat source rule 14 source address 10.0.1.101

# set nat source rule 14 translation address 190.6.YYY.126

DNAT

  • 190.6.YYY.122 (DNS 1, Correo electrónico de tráfico entrante 1) —> 10.0.1.97
  • 190.6.YYY.123 (DNS 2, Correo electrónico de tráfico entrante 2) —> 10.0.1.98
  • 190.6.YYY.124 (WEB [HTTP y HTTPS]) —> 10.0.1.100

 

Código:

# set nat destination rule 30 description “Enmascaramiento del Servidor DNS 1 (DNAT/PAT)”

# set nat destination rule 30 destination address 190.6.YYY.122

# set nat destination rule 30 destination port domain

# set nat destination rule 30 inbound-address eth0.14

# set nat destination rule 30 protocol tcp_udp

# set nat destination rule 30 translation address 10.0.1.97

 

# set nat destination rule 31 description “Enmascaramiento del Servidor DNS 2 (DNAT/PAT)”

# set nat destination rule 31 destination address 190.6.YYY.123

# set nat destination rule 31 destination port domain

# set nat destination rule 31 inbound-address eth0.14

# set nat destination rule 31 protocol tcp_udp

# set nat destination rule 31 translation address 10.0.1.98

 

# set nat destination rule 32 description “Enmascaramiento del Servidor de Correo de trafico entrante 1 – MX 1 (DNAT/PAT)”

# set nat destination rule 32 destination address 190.6.YYY.122

# set nat destination rule 32 destination port smtp

# set nat destination rule 32 inbound-address eth0.14

# set nat destination rule 32 protocol tcp

# set nat destination rule 32 translation address 10.0.1.97

 

# set nat destination rule 33 description “Enmascaramiento del Servidor de Correo de trafico entrante 2 – MX 2 (DNAT/PAT)”

# set nat destination rule 33 destination address 190.6.YYY.123

# set nat destination rule 33 destination port smtp

# set nat destination rule 33 inbound-address eth0.14

# set nat destination rule 33 protocol tcp

# set nat destination rule 33 translation address 10.0.1.98

 

# set nat destination rule 34 description “Enmascaramiento del Servidor WEB Externo (DNAT/PAT)”

# set nat destination rule 34 destination address 190.6.YYY.125

# set nat destination rule 34 destination port http,https

# set nat destination rule 34 inbound-address eth0.14

# set nat destination rule 34 protocol tcp

# set nat destination rule 34 translation address 10.0.1.100

Política de Acceso a las Subredes

A continuación se detallarán las políticas de acceso a las subredes definidas anteriormente. Para una mejor comprensión se explicará VLAN por VLAN.

VLAN 1:

A esta subred solamente accederán los Administradores de Red de KARAS Project. Los equipos son los siguientes:

  • PC-router 1 – 10.0.1.1:40497/tcp
  • Switch Allied Telesys AT-GS950/24 – 10.0.1.2:80/tcp

 

Patrón:

10.0.1.0/28: ssh, 40497/tcp

10.0.1.0/28: http, https

Desde esta subred se accederá a:

  • Servidores DNS internos
  • Servidores de hora (NTP)
  • Servidor WEB/FTP (repositorios y firmwares)

 

VLAN 2:

A esta subred accederán solamente los Administradores de Red de KARAS Project. Los equipos son los siguientes:

  • Servidor Proxmox PRX-C0-1 – 10.0.1.18:ssh, 5900-5999/tcp, 8006/tcp
  • Servidor Proxmox PRX-C0-2 – 10.0.1.19:ssh, 5900-5999/tcp, 8006/tcp

 

Patrón:

10.0.1.16/28:ssh, 5900-5999, 8006

Desde esta subred se accederá a:

  • Servidores DNS internos
  • Servidores de hora (NTP)
  • Servidor WEB/FTP (repositorios)
  • Servidor de Correo para las notificaciones de los Hipervisores Proxmox

 

VLAN 10:

Desde esta subred se accederá a todas las subredes, servidores y servicios de la empresa. Ahora bien, hacia a esta subred llegarán solamente respuestas a las solicitudes hechas desde las estaciones de trabajo del Administrador de la Red y del Especialista de Seguridad Informática, dado que en esta subred no se proveen servicios.

VLAN 11:

Esta subred es el punto de convergencia hacia donde se mueve todo el tráfico de red de la empresa. A ella accederán todas las demás subredes. Los equipos que la componen son los servidores de red principales. Estos son:

  • Controlador de Dominio Secundario (PDC)/DNS-LAN – 10.0.1.66:(137,138)/udp, (139/445)/tcp, puertos asociados al servicio de Directorio Activo
  • Servidor de DNS-General/Correo/MI/Hora – 10.0.1.67:smtp, smtps, submision, imap, imaps, pop3, pop3s, (5222, 5223, 5269)/tcp, 123/udp
  • Servidor WEB – 10.0.1.68:http, https, ftp
  • Servidor Proxy de Internet/Intranet-CUBA – 10.0.1.69:3128/tcp
  • Servidor de Monitoreo y Control – 10.0.1.71: http, https, 8080/tcp, 9996/udp

 

NOTA 1: Al último servidor antes mencionado se accederá solamente desde las estaciones de trabajo del Administrador de la Red y del Especialista de Seguridad Informática, dado que en él se almacenará todo lo referente al uso del tráfico de red de la empresa.

Desde esta subred se obtendrán todas las respuestas a las solicitudes de acceso a los servicios de todas las estaciones de trabajo de la Red, pero también partirán solicitudes de acceso a otros servidores externos a la Red (esto es debido a que algunos de los servidores ubicados aquí pertenecen a la DMZ a través del NAT/PAT). O sea:

  • Servidor de Correo Externo de Tráfico Saliente – 10.0.1.99/190.6.YYY.124 —> Servidores de Correo de otras redes
  • Servidor Proxy – 10.0.1.101/190.6.YYY.126 —> Navegación en Internet/Intranet-CUBA

 

VLAN 12:

Esta es otra subred que tiene vital importancia. De ella se nutren los servidores internos de la Red, y como se mencionó anteriormente, está compuesta por cinco servidores bastión o DMZ, pero a través de NAT /PAT. Estos son:

  • Servidor de Correo Externo de Tráfico Entrante 1 – MX 1 – 10.0.1.97:domain, ntp, smtp
  • Servidor de Correo Externo de Tráfico Entrante 2 – MX 2 – 10.0.1.98:domain, ntp, smtp
  • Servidor de Correo Externo de Tráfico Saliente (solicitudes) – 10.0.1.99:(1024-65535)/tcp
  • Servidor de WEB Externo – 10.0.1.100:http, https
  • Servidor Proxy Externo (solicitudes) – 10.0.1.101:(1024-65535)/tcp

 

Desde esta subred se accederá a:

  • Servidores DNS de otras redes
  • Servidores de hora (NTP) de otras redes
  • Servidor WEB/FTP de otras redes
  • Servidores de Correo de otras redes

 

Hacia esta subred se llegará desde:

  • Servidores DNS de otras redes (consultas)
  • Servidores de Correo de otras redes (envío de correos electrónicos)
  • Etc.

 

VLAN 13:

Desde esta subred se accederá solamente a la subred de servidores de red y servicios internos de la empresa. Ahora bien, hacia a esta subred llegarán solamente respuestas desde dichos servidores a las solicitudes hechas desde las estaciones de trabajo que conforman esta subred.

Como dato adicional, se decidió ubicar el Controlador Primario de Dominio (PDC) dentro de esta subred para no cargar el tráfico de paquetes SMB, dado que, aparte del tráfico típico de la autenticación en red, este tipo de servidor tiende a ser también un servidor de archivos, esto en caso de tener un PDC al estilo de Windows NT (Samba 3.x), en caso de tener un PDC con Samba 4, pues, dicho servidor de archivos estaría alojado en tro servidor. Así el rendimiento de esta subred (que es la más crítica) no disminuirá.

VLAN 14:

En esta subred se ubicará el router de ETECSA que nos da acceso a Internet/Red-CUBA, en otras palabras, nuestra conectividad al exterior. La misma tiene una vinculación muy estrecha con la VLAN 12, en la cual estás ubicados los servidores bastión o DMZ, los cuales serán “vistos” desde fuera a través del NAT/PAT del cortafuegos.

Las características de esta subred son las mismas que las de la VLAN 12, con la diferencia de que las direcciones IP son otras. O sea, lo mismos servidores, pero con otras direcciones IP:

  • Servidor de Correo Externo de Tráfico Entrante 1 – MX 1 – 190.6.YYY.122:domain, ntp, smtp
  • Servidor de Correo Externo de Tráfico Entrante 2 – MX 2 – 190.6.YYY.123:domain, ntp, smtp
  • Servidor de Correo Externo de Tráfico Saliente (solicitudes) – 190.6.YYY.124:(1024-65535)/tcp
  • Servidor de WEB Externo – 190.6.YYY.125:http, https
  • Servidor Proxy Externo (solicitudes) – 190.6.YYY.126:(1024-65535)/tcp

 

VLAN 15:

En esta subred se ubicará el router de ETECSA que conecta a nuestro nodo con la VPN local IP/MPLS donde están conectadas las sucursales de la empresa. En dichas sucursales puede existir el mismo entorno descrito en la VLAN 13, como también pueden tener estaciones de trabajo solamente, pero todas tienen el mismo denominador común: accederá solamente a la subred de servidores de red y servicios internos de la empresa.

Ahora bien, hacia a esta subred llegarán solamente respuestas desde dichos servidores a las solicitudes hechas desde los servidores y/o estaciones de trabajo que conforman esta subred.

Implementación de las Políticas de Zona en el PC-router

VyOS, así como su predecesor Vyatta, permite configurar el cortafuegos de dos variantes:

  • Control del tráfico de entrada/salida (IN/OUT) de una interfaz de red específica
  • Política de Zona aplicada a una interfaz de red específica

 

La diferencia radica en la perspectiva con que se mire.

En el caso de la primera variante, uno debe “situarse” sobre la interfaz de red de frente a la subred conectada a la misma y “de espaldas” al PC-router. Ahora bien, todo tráfico que sale desde el PC-router a través de la interfaz de red hacia la subred tiene dirección o sentido OUT (tráfico saliente), y todo tráfico que viene desde la subred a través de la interfaz de red hacia el PC-router tiene dirección IN (tráfico entrante).

NOTA: El tener bien claro esta perspectiva nos librará de buenos dolores de cabeza a la hora de establecer reglas de cortafuegos en las interfaces. Se los digo por experiencia propia.

Entonces las reglas, o conjunto de reglas, se aplican a la interfaz en dependencia del sentido del tráfico de red.

En el caso de la segunda variante, uno debe situarse en el lado de la subred específica y solamente debe preocuparse por controlar todo el tráfico de red que va hacia ella, independientemente si son solicitudes de conexión desde otras subredes o respuestas a las mismas.

En el caso que nos ocupa, se utilizará la segunda variante. Es verdad que es la más tediosa de configurar y la que más demanda de recursos del PC-Router hace, pero es la más segura, dado que obligatoriamente se tienen que definir los conjuntos de reglas de cortafuegos para todas las zonas, incluyendo al mismo PC-router. En otras palabras, siempre se tendrán que crear N2 + N reglas, donde N es la cantidad de zonas o subredes definidas más la zona del propio cortafuegos.

NOTA: En este punto es válido aclarar que los conjuntos de reglas entre dos zonas es una equivalencia a la variante IN/OUT en las interfaces de sus respectivas subredes.

Zonas definidas

  • EquiposRed (Equipos de Internetworking)
  • Hipervisores (Gestión de los Hipervisores Proxmox VE)
  • Admines (Administradores de Red de la Empresa KARAS Project)
  • Servidores (Servidores de Red Internos de la Empresa KARAS Project)
  • DMZ (Servidores de Red Externos de la Empresa KARAS Project)
  • LAN (Servidores de dominio y estaciones de trabajo de Red de la Empresa KARAS Project)
  • WAN (Enlace de ETECSA a la Red CUBA)
  • VPN (Enlace de ETECSA a la VPN local IP/MPLS donde están conectadas las sucursales de la Empresa KARAS Project)
  • Cortafuegos (El propio PC-router VyOS)

 

NOTA: Es recomendable crear todos los conjuntos de reglas primero y luego crear las políticas de zona. Por defecto se establece como DROP la política de acceso en cada zona, por eso, una vez creada la misma, se debe establecer los conjuntos de reglas dentro de las zonas que se relacionan entre sí, dado que el tráfico se corta automáticamente en el momento que se define.

Reglas

Para una mejor organización de las reglas, se enumerarán dado el protocolo de red con el que se trabajará. Esto es bastante útil a la hora de revisar el log del cortafuegos.

No obstante, la intención principal de esto es ubicar primero las reglas asociadas a los servicios de mayor demanda en una Red LAN (DNS, Correo Electrónico, navegación Web, FTP, navegación a través de un proxy de Internet, etc.) y así sucesivamente hasta ubicar las de menor demanda. Claro está que, una vez que se establece este orden es más difícil modificarlo a posteriori, dado que habría que reconfigurar todos los conjuntos de reglas desde cero; así que las nuevas reglas que vayan apareciendo, pues, se ubicarán al final del bloque. Esto hará que el micro del PC-Router trabaje menos, ya que las reglas se evalúan secuencialmente.

Regla 1: ICMP (Ping)

Regla 2: Conexiones TCP en estado ESTABLISHED y RELATED

Regla 3: Conexiones TCP inválidas (INVALID)

Regla 10: DNS (puerto 53/{tcp|udp})

Regla 20: SMTP (puerto 25/tcp)

Regla 30: SMTPS (puerto 465/tcp)

Regla 40: SUBMISSION (puerto 587/tcp)

Regla 50: IMAP (puerto 143/tcp)

Regla 60: IMAPS (puerto 993/tcp)

Regla 70: POP3 (puerto 110/tcp)

Regla 80: POP3S (puerto 995/tcp)

Regla 90: WEB (puertos {80|443}/tcp)

Regla 100: FTP (puerto {20|21}/tcp)

Regla 110: SQUID (puerto 3128/tcp)

Regla 120: JABBER (puerto 5222/tcp)

Regla 130: JABBER-SSL (puerto 5323/tcp)

Regla 140: JABBER-SERVER (puerto 5269/tcp)

Regla 150: NetBIOS (Servicio de Nombres NetBIOS) [puerto 137/udp]

Regla 160: NetBIOS (Servicio de Datagramas NetBIOS) [puerto 138/udp]

Regla 170: NetBIOS (Servicio de Sesión NetBIOS) [puerto 139/tcp]

Regla 180: Microsoft-DS (Servicios de Directorio de Microsoft – Compartimentación de archivos mediante SMB/CIFS) [puerto 445/tcp]

Regla 190: NTP (puerto 123/udp)

Regla 200: SSH y SSH-modificado (puerto {22|40497}/tcp)

Regla 210: Telnet (puerto 23/tcp)

Regla 220: MySQL (puerto 3306/tcp)

Regla 230: PostgreSQL (puerto 5432/tcp)

Regla 240: Gestión de Proxmox (puertos {5900-5999|8006}/tcp)

Regla 250: Gestión de Openfire (Servidor Jabber) [puertos {9090|9091}/tcp]

Regla 260: Gestión Remota de Servidores Windows a través de RDP (puerto 3389/tcp)

Regla 270: Flujo de paquetes para el ManageEngine NetFlow Analyzer (puerto 9996/udp)

Regla 280: Gestión Remota del ManageEngine NetFlow Analyzer (puerto 8080/tcp)

Regla 290: Servicio del SQL Server de Microsoft (puerto 1433/tcp)

Regla 300: Monitor del SQL Server de Microsoft (puerto 1434/{tcp|udp})

Regla 310: LDAP (puerto 389/tcp)

Regla 320: LDAPS (puerto 688/tcp)

Regla 330: Microsoft Global Catalog (Servicio LDAP que contiene datos sobre los bosques de Active Directory) [puerto 3268/tcp]

Regla 340: Microsoft Global Catalog sobre SSL (similar al puerto 3268, LDAP sobre SSL) [puerto 3269/tcp]

Regla 350: Kerberos, versión 5 (Autenticación) [puerto  88/{tcp|udp}]

Regla 360: Kerberos, versión 5 (Estaclecimiento/Cambio de contraseñas) [puerto 464/{tcp|udp}]

Regla 370: Microsoft EPMAP (End Point Mapper), conocido como DCE/RPC (puerto 135/tcp)

Regla 380: Replicación de archivos (RPC, DFSR [SYSVOL]) [puerto 5722/tcp]

Regla 390: Servicios de Directorio de Microsoft (RPC, DCOM, EPM, DRSUAPI, NetLogonR, SamR, FRS) [puertos 1024-6535/{tcp|udp}]

Regla 9999: Para registro de eventos

NOTA: Si hay zonas que no tienen comunicación establecida, es válido crear conjuntos de reglas en ambos sentidos que contenga solamente la regla 9999 para registrar los eventos de intentos de accesos no autorizados o fallidos entre las zonas.

Ejemplo de código de las reglas básicas:

rule 1 {

      action accept

      description “Permitir trafico ICMP (ping)”

      icmp {

            type-name any

      }

      protocol icmp

}

 

rule 2 {

      action accept

description “Permitir conexiones TCP en estados ESTABLISHED y RELATED”

state {

            established enable

            related enable

       }

}

 

rule 3 {

      action drop

      description “Descartar todos los paquetes marcados como invalidos”

      log enable

      state {

            invalid enable

      }

}

 

rule 9999 {

      action drop

      description “Registrar eventos de todo lo que no coincida con las reglas anteriores (propositos de monitoreo del cortafuegos)”

      log enable

}

Conjuntos de reglas

Los siguientes conjuntos de reglas serán los que se aplicarán a cada zona definidas ida anteriormente

Zona – Cortafuegos (local)

firewall-netdevs

firewall-hiperv

firewall-admines

firewall-servidores

firewall-dmz

firewall-lan

firewall-wan

firewall-vpn

 

Zona – EquiposRed

netdevs-firewall

netdevs-hiperv (no hay comunicación)

netdevs-admines

netdevs-servidores

netdevs-dmz (no hay comunicación)

netdevs-lan (no hay comunicación)

netdevs-wan (no hay comunicación)

netdevs-vpn (no hay comunicación)

 

Zona Hiperv

hiperv-firewall

hiperv-netdevs (no hay comunicación)

hiperv-admines

hiperv-servidores

hiperv-dmz

hiperv-lan (no hay comunicación)

hiperv-wan (no hay comunicación)

hiperv-vpn (no hay comunicación)

 

Zona – Admines

admines-firewall

admines-netdevs

admines-hiperv

admines-servidores

admines-dmz

admines-lan (no hay comunicación)

admines-wan (no hay comunicación)

admines-vpn (no hay comunicación)

 

Zona – Servidores

servidores-firewall

servidores-netdevs

servidores-hiperv

servidores-admines

servidores-dmz

servidores-lan

servidores-wan

servidores-vpn

 

Zona – DMZ

dmz-firewall

dmz-netdevs (no hay comunicación)

dmz-hiperv (no hay comunicación)

dmz-admines

dmz-servidores

dmz-lan (no hay comunicación)

dmz-wan (no hay comunicación)

dmz-vpn (no hay comunicación)

 

Zona – LAN

lan-firewall

lan-netdevs (no hay comunicación)

lan-hiperv (no hay comunicación)

lan-admines (no hay comunicación)

lan-servidores

lan-dmz (no hay comunicación)

lan-wan (no hay comunicación)

lan-vpn (no hay comunicación)

 

Zona – WAN

wan-firewall

wan-netdevs (no hay comunicación)

wan-hiperv (no hay comunicación)

wan-admines (no hay comunicación)

wan-servidores (no hay comunicación)

wan-dmz

wan-lan (no hay comunicación)

wan-vpn (no hay comunicación)

 

En total tendremos 72 conjuntos de reglas, o sea:

CTCR = 82 + 8 = 72

Donde CTCR es la Cantidad total de conjuntos de reglas para 8 subredes.

NOTA: Se puede permitir el tráfico ICMP (ping) entre las zonas, pero puede no permitirse también. Esto es a elección del administrador de red, dado que, normalmente, entre redes se trata de no permitirlo.

Y hasta aquí la primera parte de este artículo. En ella se mostró toda la parte teórica del proceso.

Quiero recalcar una vez más que esta topología no es 100% segura porque está basada en una configuración mayoritariamente lógica, debido a la escasez de recursos con que se contó para realizarla: una PC con una sola tarjeta de red, un único switch L2 Gigabit Ethernet, etc; y el objetivo fue aprovechar al máximo el poco equipamiento que hay. Entonces, es altamente fundamental instalar o activar sistemas de cortafuegos e IDS/IPS, además de tener sistemas de monitoreo de red, en los servidores, hipervisores, etc., para elevar un poco más el nivel de seguridad. Tambíen es importante tener las últimas actualizaciones de todos los sistemas en los que se sustenta la red (PC-router, switches, hipervisores, servidores, etc.).

En la segunda parte veremos el código completo de la configuración de VyOS. Para muchos es la parte más pesada de todo el proceso, pero para mi es la más interesante (y desafiante, además).

No obstante, cualquier crítica o posible mejora es bien recibida.

😀

Acerca de Hector Suarez Planas

Es Licenciado en Ciencia de la Computación (3 de julio de 2002). Ha sido Administrador de Red en varias organizaciones, Programador y Analista de Sistemas. Actualmente se desempeña como Administrador de Red del Telecentro Tele Turquino de Santiago de Cuba. Tiene experiencia con sistemas Windows y GNU/Linux, Infraestructura de Redes (Cisco, AlliedTelesis, Netgear y HP ProCurve, Vyatta/VyOS), Servidores tanto físicos como virtuales (plataformas VMWare, Proxmox VE y Xen), Sistemas de Seguridad Informática (Snort/Suricata IDS, appliances AlienVault OSSIM), programador (Delphi, C++ Builder, Perl [poco], Python [algo]), entre otras cosas. Actualmente estoy incursionando en todo lo que tiene relación con Cloud Computing (OpenStack) y Centros de Datos. :-)
Esta entrada fue publicada en Cortafuegos, Debian, Firewall, IOS, IP-MPLS, Proxmox VE, Routing, Seguridad, VLAN, VPN, Vyatta/VyOS/EdgeOS. Guarda el enlace permanente.