En esta entrada tenemos un tutorial para explicar paso a paso como configurar las reglas de firewall en Vyatta, una vez hayamos comprendido el funcionamiento que explicábamos en la entrada El stateful firewall de Vyatta y la topología ejemplo propuesta, explicamos la orientación que queremos darle a nuestro firewall Vyatta para obtener de él el funcionamiento esperado. Cuando todos los conceptos estén entendidos el proceso de configuración del firewall de Vyatta será bastante sencillo e intuitivo.

Antes de comenzar a describir el funcionamiento que tendrá el módulo firewall de Vyatta y expresarlo en reglas para poder configurarlo conviene recordar que:

flujo_funcionamiento_vyatta




Una vez tenemos los deberes hechos vamos a describir como será el funcionamiento del módulo firewall de Vyatta según los permisos que vamos a definir para cada uno de los grupos que componen nuestro esquema ejemplo. También necesitamos en este punto definir como vamos a aplicar los grupos de reglas a las interfaces y la funcionalidad del firewall de Vyatta que vamos a usar:

  1. En primer lugar hay que elegir entre configurar un firewall basado en reglas o un firewall basado en zonas, cualquier opción es buena, pero a mi juicio el firewall basado en reglas es algo más sencillo por ser más intuitivo, así que elegimos configurar el módulo firewall de Vyatta basado en reglas.

  2. Después tenemos que decidir como vamos a aplicar los grupos de reglas a las interfaces de Vyatta (sentido del flujo de datos), como comentamos en el manual El stateful firewall de Vyatta los grupos de reglas pueden aplicarse a las interfaces como entrada, salida o como locales (in, out, local), en este caso el sentido del flujo de datos para analizar el tráfico con el módulo de firewall elegido va a ser de entrada (in), así, cada interfaz de Vyatta tendrá de controlar el tipo de tráfico que entra por ella sin tener que preocuparse por el que sale ya que habrá sido gestionado por el firewall de la interfaz correspondiente.

  3. Lo siguiente es definir los permisos de acceso de red para cada una de las subredes, para esto, vamos a definir las políticas de conexión que cada departamento va a tener:

    Nota: En esta entrada tenemos los servicios que Vyatta refleja como servicios conocidos y su número de puerto asignado.

    • Departamento de Ventas (VLAN 10):
      • En cuanto al tráfico local que será gestionado por la máquina Vyatta a este grupo le vamos a permitir las consultas DHCP de cliente (puerto 68 TCP y UDP), las consultas DNS (puerto 53 TCP y UDP), este tráfico será local (con destino a la propia máquina Vyatta y administrado por ella), con lo que tendremos que crear un grupo de reglas con las conexiones permitidas para asignar a la interfaz VLAN 10 (bond0.10) como tráfico local.
      • Acceso permitido a los servidores de la empresa (VLAN 80) solo para los servicios http (puerto 80), https (puerto 443), Microsoft SQL (puerto 1433 TCP), MySQL (puerto 3306 TCP).
      • Permitiremos también que tengan acceso a servidores de correo seguros POP, SMTP e IMAP (puertos 995, 465 y 993 TCP) de cualquier sitio de Internet (podríamos limitar el acceso solo a los servidores de correo corporativos, luego veremos como hacerlo).
      • Permitiremos el acceso a páginas web de clientes y a algunos servicios de banca, paquetería, etc.
    • Departamento de Marketing (VLAN 20):
      • Al igual que el departamento de Ventas, el de Marketing, en cuanto al tráfico local que será gestionado por la máquina Vyatta le vamos a permitir las consultas DHCP de cliente (puerto 68 TCP y UDP), las consultas DNS (puerto 53 TCP y UDP), este tráfico será local (con destino a la propia máquina Vyatta y administrado por ella), con lo que tendremos que crear un grupo de reglas con las conexiones permitidas para asignar a la interfaz VLAN 10 (bond0.10) como tráfico local.
      • Acceso permitido a los servidores de la empresa (VLAN 80) solo para los servicios http (puerto 80), https (puerto 443), Microsoft SQL (puerto 1433 TCP), MySQL (puerto 3306 TCP).
      • Permitiremos también que tengan acceso a servidores de correo seguros POP, SMTP e IMAP (puertos 995, 465 y 993 TCP) de cualquier sitio de Internet (podríamos limitar el acceso solo a los servidores de correo corporativos, luego veremos como hacerlo).
      • El acceso permitido a páginas web será a páginas de servicios de marketing online (páginas amarillas, google analitycs, google adwords…) y acceso de administración al servidor web corporativo.
    • Departamento de Administración (VLAN 30):
      • Tráfico local DHCP y DNS.
      • Acceso a servidores corporativos (http, https, MS-SQL, MySQL)
      • Acceso a servidores seguros de correo públicos.
      • Acceso a servicios de banca online y acceso a webs de proveedores.
    • Departamento de Gerencia (VLAN 40):
      • Tráfico local DHCP y DNS.
      • Acceso a servidores corporativos (http, https, MS-SQL, MySQL)
      • Acceso a servidores seguros de correo públicos.
      • Acceso libre a Internet (solo a puertos conocidos).
    • Zona desmilitarizada – DMZ (VLAN 50):
      • Los servidores alojados dentro de la DMZ solo podrán responder a consultas que vengan de Internet. No podrán iniciar ningún tipo de conexión por ellos mismos.
      • Acceso a servidores de actualización del sistema operativo, regla deshabilitada por defecto pero creada para poder modificar siempre que sea necesario actualizar alguno de los servidores alojados en la DMZ.
    • Departamento de I+D (VLAN 60):
      • Tráfico local DHCP, DNS y de administración SSH.
      • Acceso a servidores corporativos para trabajo (http, https, MS-SQL, MySQL) y para administración (SSH, https, escritorio remoto, etc).
      • Acceso de administración a los servidores de la DMZ (SSH, https, escritorio remoto, etc).
      • Acceso a servidores seguros de correo públicos.
      • Acceso libre a Internet (solo a puertos conocidos).
    • Departamento de Desarrollo (VLAN 70):
      • Tráfico local DHCP y DNS.
      • Acceso a servidores corporativos para trabajo (http, https, MS-SQL, MySQL) y para administración (SSH, https, escritorio remoto, etc).
      • Acceso de administración a los servidores de la DMZ (SSH, https, escritorio remoto, etc).
      • Acceso a servidores seguros de correo públicos.
      • Acceso libre a Internet (solo a puertos conocidos).
    • Servidores corporativos (VLAN 80):
      • Los servidores corporativos solo podrán responder a consultas que vengan de la red local. No podrán iniciar ningún tipo de conexión por ellos mismos.
      • Acceso a servidores de actualización del sistema operativo, regla deshabilitada por defecto pero creada para poder modificar siempre que sea necesario actualizar alguno de los servidores de la empresa.



    Con esto tenemos reflejados todos los permisos en cuanto a departamentos de la empresa, estos permisos los convertiremos en reglas y se las asignaremos a cada una de las interfaces de openredesR1 y openredesR2 según corresponda.

  4. Lo que falta por hacer es asignar las reglas de firewall al resto de interfaces que no son las correspondientes a las VLANs, por ejemplo, tenemos que establecer qué tipo de tráfico permitimos que entre por la interfaz conectada a Internet, que tipo de tráfico permitimos que entre por las VPNs, etc.

    Continuamos con las reglas de la interfaz conectada a Internet:

    • En openredesR1 como tráfico local vamos a permitir el tráfico de la VPN STS, tráfico hacia el puerto 1194 UDP, desde el puerto 1194 UDP y desde la IP pública de openredesR2 (192.0.2.20).
      También vamos a permitir la entrada de tráfico de las VPNs RA vtun0 y vtun1 que es tráfico UDP destinado a los puertos 1195 y 1196 desde cualquier IP pública (para no limitar desde donde se genera la conexión VPN). También permitiremos la respuesta al tráfico generado por nuestras máquinas Vyatta (ntp, actualizaciones, DNS).
      Como tráfico entrante permitiremos el tráfico destinado a los servidores públicos alojados en la DMZ, en este caso será tráfico destinado a servicios web y correo.
      El resto de tráfico entrante permitido serán conexiones que se han iniciado desde dentro a servicios en Internet y es tráfico de respuesta a esas peticiones internas.

    • De igual forma, en openredesR2, como tráfico local solo vamos a permitir tráfico destinado al puerto 1194, desde el puerto 1194 y con origen la IP pública de openredesR1 (192.0.2.10). También permitiremos la respuesta al tráfico generado por nuestras máquinas Vyatta (ntp, actualizaciones, DNS).
      En la red gestionada por openredesR2 no tenemos ningún servicio público accesible desde Internet, con lo que solo permitiremos la respuesta de conexiones iniciadas internamente desde puertos conocidos, en este caso serán conexiones de respuesta a peticiones web, mail…

  5. Y por último las reglas de tráfico que entra por las VPNs:

    • Por vtun10 de openredesR1 permitiremos como tráfico local el tráfico OSPF (en caso de haberlo configurado) y el tráfico de administración generado por el departamento de I+D.
      Como tráfico de entrada, permitiremos de las respuestas a peticiones a los servidores corporativos iniciadas en el extremo de openredesR1.
    • Por vtun10 de openredesR2 permitiremos como tráfico local solo el tráfico OSPF.
      Como tráfico de entrada, permitiremos la respuesta a las conexiones de administración que los departamentos I+D y Desarrollo hagan a los equipos de la DMZ, así como el tráfico entrante con destino a los servidores corporativos destinado a servicios permitidos.
    • Por las VPNs de acceso remoto vtun0 y vtun1 vamos a permitir solamente el tráfico destinado a los servicios ofrecidos por los servidores corporativos.


En este punto ya sabemos cómo queremos el funcionamiento del módulo de firewall de Vyatta para gestionar los accesos en toda la red empresarial, ahora vamos a ir generando los grupos de reglas para cada una de las interfaces de nuestros sistemas Vyatta.


Consejos:

  • Tenemos que tener claro a la hora de crear las reglas el hecho de que se irán analizando por el sistema de menor a mayor número de regla y si se llega a alguna regla que concuerda con los datos del paquete analizado se aplicara dicha regla y no se seguirán analizando las reglas siguientes, por lo que es necesario colocar las reglas más restrictivas primero y después las más genéricas.
  • También es aconsejable dejar espacio entre reglas para facilitar modificaciones futuras, es decir, no crear todas las reglas consecutivas (1, 2, 3, 4, 5, etc) si no dejar espacio entre ellas (10, 20, 30, etc.)
  • Una buena práctica es crear siempre una regla que bloquee los paquetes con estado de conexión invalido, este tráfico es tráfico en un estado no conocido por la máquina de estados del sistema de rastreo de conexiones, podremos entender su funcionamiento con un intenso repaso a esta entrada.







vyatta_modernrouting_large