Dec 05

Introducción.

Es muy común que debido al alto tráfico que se genera entre los nodos trabajadores de un clúster y su nodo principal, estos se separen en una red independiente y el nodo principal, con dos interfaces de red, actúe como puente entre los clientes en la red LAN y los nodos trabajadores en la red finalmente oculta.

La configuración de esto es tan simple como la simple conexión física de los dispositivos y la configuración de direcciones IP estáticas para los nodos trabajadores si es que no se desea instalar un servidor DHCP en el nodo principal para que realice esta tarea a través de la interfaz de red específica.  El problema surge cuando es necesario actualizar los nodos trabajadores o en general, que estos accedan a Internet.  Como estos se encuentran en un red diferente de la LAN, no hay nada que los enrrute hacia la WAN, quedando completamente aislados.

La solución a este problema es muy fácil de implementar gracias a las características intrínsecas de enrrutamiento de Linux (y en general de los sistemas operativos *nix).  Simplemente es necesario indicarle al nodo principal que actúe como enrrutador entre sus interfaces de red: red LAN y red de nodos trabajadores, pudiéndose aplicar los controles que se consideren necesarios a través del uso de iptables.

El panorama.

Estructura general del cluster

Estructura general del cluster

El nodo principal del cluster cuenta con dos interfaces de red: eth0 que se comunica con la red LAN de la organización y eth1 que se conecta con los nodos trabajadores, los cuales sólo cuentan con una única interfaz de red eth0.  Estos últimos se encuentran aislados del exterior ya que no son enrrutados inicialmente hacía la red LAN y eventualmente hacia Internet.

Implementación del enrrutamiento.

Configuración en el nodo principal del cluster.

Este actuará como enrrutador para la información enviada desde los nodos trabajadores y permitirles entonces acceder a las redes exteriores.  Para es necesario implementar en él las siguientes modificaciones de configuración.

Activar el envío de paquetes del kernel.

Esto se puede implementar de manera temporal, es decir, esta modificación no perdurará al reinicio del sistema, mediante la ejecución del siguiente comando.

# echo 1 > /proc/sys/net/ipv4/ip_forward

O puede implementarse de manera permanente mediante la edición de los parámetros del kernel de la siguiente manera.

# vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

Esta último método puede verifcarse mediante la ejecución del siguiente comando en el shell.

# sysctl -p | grep ipv4

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1

Establecer la regla de filtrado.

# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.56.0/24 -j MASQUERADE

Esta instrucción le indica al nodo principal que permita el paso de los paquetes que vienen desde la red de los nodos trabajadores (192.168.56.0/24) hacía la otra red, en este caso la LAN (192.168.1.0), que se accede a través de la interfaz de red eth0.

Esta modificación desde la línea de comando no es persistente, por lo cual se deberá configurar en alguno de los archivos que se ejecutan al inicio.  Probablemente el mejor sitio sea en /etc/sysconfig/iptables, sin embargo debe tenerse cuidado si se utiliza system-config-securitylevel para administrar el firewall ya que este puede sobreescribir el archivo y olvidar los cambios.

Permitir el acceso al servicio DNS.

Este paso es opcional, pero probablemente si no se lleva a cabo el enrrutamiento sea exitoso si se utilizan direcciones IP directamente mas no si se intenta acceder utilizando nombres FQDN ya que los intentos de acceso al DNS son filtrados por el nodo principal.

Para permitir el acceso al servicio DNS es necesario permitir el paso de paquetes UDP cuyo destino sea el puerto 53 de la siguiente manera.

# iptables -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

Igual que en el paso anterior, para hacer persistente esta modificación es necesario incluírla en un archivo como /etc/sysconfig/iptables o realizarla con el system-config-securitylevel si se utiliza.

Configuración de los nodos trabajadores.

Es necesario finalmente indicarle a los nodos trabajadores que el nodo principal del cluster será a partir de ahora su nueva puerta de enlace.  Para hacer esto es necesario modificar el siguiente parámetro de su configuración con la dirección IP del servidor principal configurado anteriormente.

GATEWAY = 192.168.56.100

Esta modificación puede realizarse uno de los siguientes puntos de configuración de los nodos trabajadores.

  1. El archivo /etc/sysconfig/network.
  2. El archivo /etc/sysconfig/network-scripts/ifcfg-eth0.

Si el cambio se aplica en el primero de ellos, la modificación tiene un alcance global sobre todas las interfaces de red.  Si se aplica sobre el segundo archivo, la modificación será específica para la interfaz de red eth0.  En el caso de los nodos trabajadores, estos sólo tienen una única interfaz de red así que ambas opciones tienen igual implicación.

Finalmente es necesario reiniciar el servicio de red para garantizar que los cambios realizados tengan efecto.

# /etc/init.d/network restart

echo 1 > /proc/sys/net/ipv4/ip_forward

Tagged with:



En December 5 de 2010, Jorge Iván Meza Martínez escribió acerca de Permitir el acceso de los nodos del cluster a Internet a través del nodo principal.
Nov 02

Introducción.

A pesar de las apariencias iniciales, Ubuntu si incluye un firewall sólo que este no incluye reglas ya que por defecto no vienen servicios abiertos.  El firewall incluído es Netfilter y para él se incluye además una herramienta que facilita su administración llamada Uncomplicated Firewall (ufw).

Esta herramienta es muy sencilla de usar, sin embargo es de línea de comando y esto en algunas ocasiones la hace mas compleja de utilizar.  Para esto se incluye en los repositorios de Ubuntu a gufw el cual es un front-end grafico para ufw.

Instalación y ejecución de gufw.

$ sudo aptitude install gufw

Para ejecutarlo acceda a la aplicación a través de los siguientes menúes.

System > Administration > Firewall Configuration.

Funcionalidades de gufw.

En la ventana inicial de la aplicación es posible activarlo y desactivarlo, definir las políticas generales de entrada y salida, y las reglas o excepciones específicas.

Ventanan inicial de gufw

Ventanan inicial de gufw

Generalmente la política utilizada es nada entra-todo sale, es decir, se confía en el uso que las aplicaciones de la máquina va a hacer de la red.  Una aproximación mas segura sería la mas restrictiva de nada entra-nada sale pero sería necesario especificar uno a uno los sitios a los cuales se realizará conexión (incluyendo los sitios web!) así como efectivamente será necesario hacerlo para las conexiones entrantes.

Las reglas pueden crearse utilizando tres aproximaciones que van desde la mas simple en la que se eligen aplicaciones o servicios predefinidos, pasando por una intermedia en la que es posible especificar puertos y o eligiendo una opción avanzada con la cual no solo es posible elegir puertos sino que también es posible establecer rangos de direcciones IP.

Creación de reglas con gufw

Creación de reglas con gufw

También es posible verificar el registro del servicio del cual puede determinarse su nivel de profundidad.

Registro de eventos con gufw

Registro de eventos con gufw

Conclusión.

Existen otras soluciones de firewall para Linux mas elaboradas que ufw (como por ejemplo Zentyal, antes ebox), sin embargo su combinación con gufw es suficiente para las necesidades de filtrado de la mayoría de los escritorios.

Enlaces.

Tagged with:



En November 2 de 2010, Jorge Iván Meza Martínez escribió acerca de Instalar un firewall personal en GNU/Linux Ubuntu 10.10.
Jul 08

Introducción.

En este artículo se agregarán algunas mejoras en la configuración del cluster para fortalecer su seguridad mediante el establecimiento de restricciones de acceso, tanto a nivel de puertos con el firewall como a nivel de ubicaciones con los archivos hosts.

Configurando el acceso a los servicios en el firewall.

En el nodo servidor de archivos (c-nfs que es el mismo c-head) del cluster.

Es necesario configurar el servicio de NFS para que utilice siempre un conjunto conocido de puertos, de lo contrario utilizará valores aleatorios lo que hace muy difícil establecer los parámetros para el firewall.  Para hacer esto se deben remover los comentarios de las siguientes líneas en el archivo de configuración mencionado.

# vi /etc/sysconfig/nfs

# TCP port rpc.lockd should listen on.
LOCKD_TCPPORT=32803
# UDP port rpc.lockd should listen on.
LOCKD_UDPPORT=32769
# Port rpc.mountd should listen on.
MOUNTD_PORT=892
# Port rpc.statd should listen on.
STATD_PORT=662

Ajustar la configuración de iptables para permitir las conexiones de NFS agregando las nuevas líneas resaltadas.

# vi /etc/sysconfig/iptables

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

## NFS
# portmap/sunrpc
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 111 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 111 -j ACCEPT
# statd
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 662 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 662 -j ACCEPT
# mountd
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 892 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 892 -j ACCEPT
# nfs
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 2049 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 2049 -j ACCEPT
# lockd_tcp
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 32803 -j ACCEPT
# lockd_udp
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 32769 -j ACCEPT
## /NFS

## Condor
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p tcp -m tcp --dport 9000:9999 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p udp -m udp --dport 9000:9999 -j ACCEPT
## /Condor

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Importante (1): el parámetro -s permite restringir la fuente válida de los paquetes, para este cluster es cualquier equipo de la red 192.168.1.x.   En caso de que el cluster tenga nodos por fuera de su propia red es necesario omitir este parámetro, de lo contrario, estos nodos externos no podrán conectarse con el cluster.

Importante (2): el rango de puertos permitido por el firewall -9000:9999- deberá corresponder con las variables IN_LOWPORT e IN_HIGHPORT especificadas en el archivo /nfs/condor/condor-etc/condor_config.cluster durante la instalación y configuración de Condor.

Reiniciar los servicios para que tenga efecto la configuración del firewall recién realizada.

# /etc/init.d/iptables restart

# /etc/init.d/nfs restart

# /etc/init.d/nfslock restart

Verificar desde otro equipo la visibilidad de los puertos en el nodo servidor de archivos del cluster (opcional).

# nmap -sS c-nfs

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:09 COT
Interesting ports on c-nfs (192.168.1.210):
Not shown: 946 filtered ports, 50 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
111/tcp  open  rpcbind
2049/tcp open  nfs

9618/tcp open  unknown*

# nmap -sU c-nfs

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:09 COT
Interesting ports on c-nfs (192.168.1.210):
Not shown: 985 filtered ports
PORT      STATE         SERVICE
111/udp   open|filtered rpcbind
631/udp   open|filtered ipp
2049/udp  open|filtered nfs
9000/udp  closed        cslistener
9001/udp  closed        unknown
9020/udp  closed        unknown
9103/udp  closed        unknown
9199/udp  open|filtered unknown
9200/udp  closed        wap-wsp
9370/udp  closed        unknown
9876/udp  closed        sd
9877/udp  closed        unknown
9950/udp  closed        unknown
10000/udp closed        unknown
32769/udp open|filtered unknown

En los nodos trabajadores (c-wn1 y c-wn2) del cluster.

Ajustar la configuración de iptables para permitir las conexiones de Condor agregando las nuevas líneas resaltadas.

# vi /etc/sysconfig/iptables

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

## Condor
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p tcp -m tcp --dport 9000:9999 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state ESTABLISHED,NEW -p udp -m udp --dport 9000:9999 -j ACCEPT
## /Condor

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Revisar las anotaciones importantes (1 y 2) hechas en la configuración del firewall del nodo c-nfs con respecto al parámetro -s y el rango de puertos.

Reiniciar el servicio para que tenga efecto la configuración del firewall recién realizada.

# /etc/init.d/iptables restart

Verificar desde otro equipo la visibilidad de los puertos en los nodos trabajadores del cluster (opcional).

# sudo nmap -sS c-wn1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:20 COT
Interesting ports on c-wn1 (192.168.1.211):
Not shown: 948 filtered ports, 51 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
9898/tcp open  unknown*

# nmap -sU c-wn1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-07-07 23:20 COT
Stats: 0:16:12 elapsed; 0 hosts completed (1 up), 1 undergoing UDP Scan
UDP Scan Timing: About 94.24% done; ETC: 23:37 (0:00:59 remaining)
Interesting ports on c-wn1 (192.168.1.211):
Not shown: 988 filtered ports
PORT      STATE         SERVICE
631/udp   open|filtered ipp
9000/udp  closed        cslistener
9001/udp  closed        unknown
9020/udp  closed        unknown
9103/udp  closed        unknown
9199/udp  closed        unknown
9200/udp  closed        wap-wsp
9370/udp  closed        unknown
9876/udp  closed        sd
9877/udp  closed        unknown
9950/udp  closed        unknown
10000/udp closed        unknown

En todos los nodos (c-head, c-wn1 y c-wn2) del cluster.

Configurar al firewall del nodo para que inicie automáticamente con el sistema operativo.

# chkconfig iptables on

# chkconfig --list iptables

iptables           0:off    1:off    2:on    3:on    4:on    5:on    6:off

Configurando el acceso a los servicios según su orígen.

Servicio de SSH.

En cada uno de los nodos (c-head, c-wn1 y c-wn2) realizar los siguientes ajustes a la configuración de TCP Wrappers para especificar el filtro de las conexiones.

# vi /etc/hosts.allow

sshd: 192.168.1.

# vi /etc/hosts.deny

sshd: all

Servicio de NFS.

En el nodo servidor de archivos (c-nfs) realizar los siguientes ajustes a la configuración de TCP Wrappers para especificar el filtro de las conexiones.

# vi /etc/hosts.allow

## NFS
portmap: 192.168.1.
lockd:   192.168.1.
rquotad: 192.168.1.
mountd:  192.168.1.
statd:   192.168.1.

# vi /etc/hosts.deny

## NFS
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

Estas configuraciones propuestas permiten que se realicen conexiones a los nodos del cluster desde cualquier ubicación de la red 192.168.1.0 y que se nieguen los intentos de conexión desde cualquier otra ubicación.  Si se desea un nivel de granularidad mas preciso en la selección de ubicaciones es posible especificar las direcciones IP en una lista separada por comas.  Consulte mas información acerca de las opciones de sintáxis de este archivo en la Red Hat Linux Reference Guide: Chapter 15. TCP Wrappers and xinetd.

Servicio de Condor.

La configuración del acceso a Condor se realiza a través de sus propios ajustes de configuración, especialmente en /nfs/condor/condor-etc/condor_config.cluster.  Este tema específico será objeto de una revisión posterior.  Para mas información consultar el capítulo acerca de Seguridad del manual de Condor.

Enlaces.

Tagged with:



En July 8 de 2010, Jorge Iván Meza Martínez escribió acerca de C-Cluster: Asegurando las conexiones al cluster.
Jun 07

Introducción.

En el presente artículo se detalla el procedimiento para crear la máquina virtual de la cabeza (head) del cluster a partir de la máquina virtual genérica creada anteriormente además se realizan ajustes de configuración, incluyendo la red, que son genéricos a todos los demás nodos.

Creación de la máquina virtual para c-head.

Clonar la máquina virtual genérica con la especificación del nuevo nodo.

$ virt-clone --connect=qemu:///system  \
-o scientificlinux-5.5_x64-general \
-n c-head \
-f /u/vms/c-head.img \
--debug --force

Desde el servidor iniciar la máquina virtual recién creada.

$ virsh start c-head

Desde el equipo cliente donde se esté realizando la administración de las máquinas realice la conexión con la máquina recién iniciada.

$ virt-viewer -c qemu+ssh://ivy/system c-head

Inicie una sesión con el usuario root para realizar las siguientes tareas de administración.

Desactivar el inicio del sistema de ventanas.

La siguiente modificación impide que se inicie automáticamente el sistema de ventanas del sistema operativo, esto con el fin de agilizar su inicio y disminuír los riesgos de seguridad relacionados con sus protocolos.  En términos del cluster este paso es opcional y de ser necesario puede omitirse.  De cualquier manera el sistema de ventanas puede ser iniciado manualmente mediante el comando startx.

Modifique el nivel de ejecución por defecto (5) al multiusuario sin ventanas (3).

# vi /etc/inittab

id:3:initdefault:

Desactivar servicios.

Desactivcación del firewall.

La desactivación del firewall es temporal y se realiza mientras se configuran los nodos, posteriormente es necesario restaurarlo previos ajustes a la configuración.  No se recomienda que los nodos permanezcan conectados a una red pública como Internet durante el proceso de instalación, especialmente en esta etapa en la que carecen de firewall.

# chkconfig --list iptables

iptables    0:off    1:off    2:on    3:on    4:on    5:on    6:off

# chkconfig iptables off

Desactivcación de la actualización automática de Yum.

Por su parte la actualización automática del sistema operativo es considerada como un riesgo para el cluster ya que es posible que actualice paquetes críticos a nuevas versiones que no hayan sido probadas y que desestabilicen al servidor.  De cualquier manera, es posible verificar manualmente cuales son los paquetes suceptibles de ser actualizados mediante la ejecución del comando yum check-update y de forzar la actualización manualmente mediante la invocación del comando yum update.

# /etc/init.d/yum stop

# chkconfig --list yum

yum    0:off    1:off    2:on    3:on    4:on    5:on    6:off

# chkconfig yum off

Configuración del archivo de hosts.

La configuración de este archivo es esencial para poder identificar los diferentes nodos del cluster a partir de su nombre, especialmente en etapas tempranas en las que aún no se cuenta con un servicio de DNS que los incluya.

Los nombres de los diferentes nodos que componen el cluster corresponden a la siguiente definición.

  • El nodo principal: c-head.
  • El nodo que expone el sistema de archivos compartido: c-nfs, corresponderá físicamente con la misma máquina de c-head.
  • Los nodos de procesamiento (worker nodes) serán c-wn1 y c-wn2 respectivamente.

# vi /etc/hosts

127.0.0.1  localhost.localdomain localhost
::1        localhost6.localdomain6 localhost6

192.168.1.210    c-head.jorgeivanmeza.com c-head c-nfs.jorgeivanmeza.com c-nfs
192.168.1.211    c-wn1.jorgeivanmeza.com c-wn1
192.168.1.212    c-wn2.jorgeivanmeza.com c-wn2

Configuración del hostname.

# vi /etc/sysconfig/network

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-head.jorgeivanmeza.com

El valor de la variable GATEWAY debe ajustarse según la dirección IP de la pasarela real de la red.

Configuración de la dirección IP.

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.210

El valor de la variable IPADDR debe coincidir con la dirección IP del servidor según la planeación realizada (ver /etc/hosts).

Reiniciar el servicio de red para tomar en cuenta los cambios recién realizados.

# /etc/init.d/network restart

Configuración de los servicios de nombres a utilizarse.

# vi /etc/nsswitch.conf

#hosts: db files nisplus nis dns
hosts:  files dns

Configuración de los servidores DNS.

En esta sección es necesario que se ajusten las direcciones IP de los servidores DNS que se van a utilizar.  En este caso se van a utilizar los servidores DNS públicos de Google.

# vi /etc/resolv.conf

search jorgeivanmeza.com
nameserver 8.8.8.8
nameserver 8.8.4.4

Detener al servidor.

# halt

Enlaces.

Tagged with:



En June 7 de 2010, Jorge Iván Meza Martínez escribió acerca de Cluster-C: Creación del nodo “head” del cluster y su configuración de red.