Shorewall y Firewalls en Puente
Copyright © 2004, 2005 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
2005-10-21
Tabla de Contenido
Precaución
Este artículo aplica a Shorewall 3.0 y posteriores. Si está corriendo una versión de Shorewall previa a Shorewall 3.0.0 entonces por favor vea la documentación para dicha liberación de software.
Los sistemas donde normalmente corre Shorewall funcionan comos enrutadores(routers). En el contexto del modelo de referencia Open System Interconnect (OSI), un enrutador opera en la capa 3. Shorewall también puede ser desplegado en un Sistema GNU Linux que actúe como puente (bridge). Los puentes son dispositivos capa-2 en el modelo OSI (piense en un puente como en es switch ethernet).
Algunas diferencias entre enrutadores y puentes son:
-
Los enrutadores determinan el destino del paquete basado en el destino IP mientras que los puentes lo hacen basándose en la dirección destino MAC en la trama ethernet.
-
Como consecuencia de la primera diferencia, los enrutadores pueden ser conectados a más de una red IP mientras que un puente puede sólo ser parte de una única red.
-
En la mayoría de las configuraciones los enrutadores no renvían los paquetes de difusión mientras que los puentes si lo hacen.
Nota
La Sección 4 del RFC 1812 describe las condiciones bajo las cuales un enrutador puede o debe renviar los paquetes de difusión.
Note que si necesita un puente pero no necesita restringir el tráfico a través del puente entonces cualquier versión de Shorewall funcionará. Vea la Documentación Simple de Puente para los detalles.
Con la finalidad de usar Shorewall como firewal puente:
-
Su kernel debe contener el soporte de puente (CONFIG_BRIDGE=m orCONFIG_BRIDGE=y).
-
Su kernel debe tener el soporte Netfilter physdev match (CONFIG_IP_NF_MATCH_PHYSDEV=m o CONFIG_IP_NF_MATCH_PHYSDEV=y). La extensión de criterio physdev es estandar en la serie de kernel 2.6 kernel pero debo ser incluido en los kernel 2.4 (vea http://linux-net.osdl.org/index.php/Bridge). Los usuarios de Bering y Bering uCLibc deben encontrar e instalar ipt_physdev.o para su distribución y agregar “ipt_physdev” a /etc/modules.
-
Su iptables debe contener el soporte physdev match support. iptables 1.2.9 y posterior lleva este soporte.
-
Debe tener los utilidades el paquete de utilidades para puente instalado (bridge-utils).
El siguiente diagrama muestra una aplicación típica de puente/firewall. Ya existe un enrutador en el lugar cuya interface interna soporta una red y desea insertar un fireall entre el enrutador y los sistemas en la red local. En el ejemplo que se muestra la red usa direcciones RFC 1918 pero esto no es un requerimiento; el puente trabajaría exactamente igual si se usaran direcciones IP públicas (recuerde que un puente no lidia con direcciones IP).
Existen varias diferencias clave en esta configuración y la configuración normal de Shorewall:
-
El sistema Shorewall (el Puente/Firewall) tiene una única dirección IP aún cuando tenga dos interfaces de red ethernet. La dirección IP se configura en el puente en vez de a ninguna interface de red en particular.
-
Los sistemas conectados a la LAN se configuran con la dirección IP del enrutador (192.168.1.254 en el diagrama) como su default gateway.
-
traceroute no detecta el Puente/Firewall com enrutador intermedio.
-
Si el enrutador corre un servidor DHCP, las máquinas conectadas a la LAN pueden usar el servidor si la necesidad de correr dhcrelay en el Puente/Firewall.
Hay otras posibilidades aquó, podría haber un hub o switch entre el enrutador y el Puente/Firewall y podrían haber otros sistemas conectados a dicho switch. Todos los sistemas en el lado local del enrutador aún se configurarían con direcciones IP en el rango 192.168.1.0/24 como se muestra abajo.
Configurar el puente en si mismo es simple y se usa el utilitario brctl del paquete bridge-utils. Hay información de configuración de puentes en http://bridge.sf.net/.
Desafortunadamente muchas distribuciones Linux no tienen buenas herramientas
de configuración para puentes y las herramietnas GUI de configuración no
detectan la presencia de dispositivos tipo puente. Aquí se muestra un estracto
del archivo /etc/network/interfaces de Debian para
un puente de dos-puertos con una dirección estática:
auto br0
iface br0 inet static
address 192.168.1.253
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /sbin/ip link set eth0 up
pre-up /sbin/ip link set eth1 up
pre-up /usr/sbin/brctl addbr br0
pre-up /usr/sbin/brctl addif br0 eth0
pre-up /usr/sbin/brctl addif br0 eth1
Si bien no es un requerimiento darle una dirección IP a un puente, hacerlo permite al puente/fireall acceder a otros sistemas y el ser gestionado remotamente. El puente también debe tener una dirección IP para que las reglas REJECT y las políticas funcionen correctamente , de otra forma REJECT se comportaría igual que DROP. También es un requerimientos para los puentes el tener una dirección IP si son parte de un puente/enrutador
Importante
Primero ponga la configuración de su puente en funcionamiento, incluyendo el arranque del puente al arrancar (boot) el sistema, antes de configurar y arrancar Shorewall.
El puente puede tener su dirección IP asignada por medio de DHCP. Aquí se muestra un archivo de ejemplo /etc/sysconfig/network/ifcfg-br0 de un sistema SUSE™:
BOOTPROTO='dhcp'
REMOTE_IPADDR=''
STARTMODE='onboot'
UNIQUE='3hqH.MjuOqWfSZ+C'
WIRELESS='no'
MTU=''
Este es un archivo ejemplo /etc/sysconfig/network-scripts/ifcfg-br0 de un sistema Mandriva™ :
DEVICE=br0
BOOTPROTO=dhcp
ONBOOT=yes
Tanto en el sistema SuSe como en el Mandriva se requiere de un guión separado para configurar el puente mismo.
Este es el archivo de configuración y el guión que he usado en sistemas Suse™ 9.1 .
/etc/sysconfig/network/ifcfg-br0BOOTPROTO='dhcp'
REMOTE_IPADDR=''
STARTMODE='onboot'
UNIQUE='3hqH.MjuOqWfSZ+C'
WIRELESS='no'
MTU=''
/etc/init.d/bridge#!/bin/sh
################################################################################
# Script to create a bridge
#
# (c) 2004 - Tom Eastep (teastep@shorewall.net)
#
# Modify the following variables to match your configuration
#
#### BEGIN INIT INFO
# Provides: bridge
# Required-Start: coldplug
# Required-Stop:
# Default-Start: 2 3 5
# Default-Stop: 0 1 6
# Description: starts and stops a bridge
### END INIT INFO
#
# chkconfig: 2345 05 89
# description: GRE/IP Tunnel
#
################################################################################
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
INTERFACES="eth1 eth0"
BRIDGE="br0"
MODULES="tulip"
do_stop() {
echo "Stopping Bridge $BRIDGE"
brctl delbr $BRIDGE
for interface in $INTERFACES; do
ip link set $interface down
done
}
do_start() {
echo "Starting Bridge $BRIDGE"
for module in $MODULES; do
modprobe $module
done
sleep 5
for interface in $INTERFACES; do
ip link set $interface up
done
brctl addbr $BRIDGE
for interface in $INTERFACES; do
brctl addif $BRIDGE $interface
done
}
case "$1" in
start)
do_start
;;
stop)
do_stop
;;
restart)
do_stop
sleep 1
do_start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0
Axel Westerhold ha contribuido con este ejemplo de configuración con uno de dirección IP estática en sistema Fedora (Core 1 y Core 2 Test 1). Note que estos archivos también configuran el propio puente así que no hay necesidad de un guión de configuración .
/etc/sysconfig/network-scripts/ifcfg-br0:DEVICE=br0
TYPE=Bridge
IPADDR=192.168.50.14
NETMASK=255.255.255.0
ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-eth0:DEVICE=eth0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-eth1:DEVICE=eth1
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes
Florin Grad de Mandriva™ suministra este guión para configurar el puente:
#!/bin/sh
# chkconfig: 2345 05 89
# description: Layer 2 Bridge
#
[ -f /etc/sysconfig/bridge ] && . /etc/sysconfig/bridge
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
do_stop() {
echo "Stopping Bridge"
for i in $INTERFACES $BRIDGE_INTERFACE ; do
ip link set $i down
done
brctl delbr $BRIDGE_INTERFACE
}
do_start() {
echo "Starting Bridge"
for i in $INTERFACES ; do
ip link set $i up
done
brctl addbr br0
for i in $INTERFACES ; do
ip link set $i up
brctl addif br0 $i
done
ifup $BRIDGE_INTERFACE
}
case "$1" in
start)
do_start
;;
stop)
do_stop
;;
restart)
do_stop
sleep 1
do_start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0El archivo
/etc/sysconfig/bridge:BRIDGE_INTERFACE=br0 #The name of your Bridge
INTERFACES="eth0 eth1" #The physical interfaces to be bridged
Andrzej Szelachowski contribuyó con lo siguiente.
Here is how I configured bridge in Slackware:
1) I had to compile bridge-utils (It's not in the standard distribution)
2) I've created rc.bridge in /etc/rc.d:
#########################
#! /bin/sh
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
#ifconfig lo 127.0.0.1 #this line should be uncommented if you don't use rc.inet1
brctl addbr most
brctl addif most eth0
brctl addif most eth1
ifconfig most 192.168.1.31 netmask 255.255.255.0 up
#route add default gw 192.168.1.1 metric 1 #this line should be uncommented if
#you don't use rc.inet1
#########################
3) I made rc.brige executable and added the following line to /etc/rc.d/rc.local
/etc/rc.d/rc.bridge
Joshua Schmidlkofer escribe:
Bridge Setup for Gentoo
#install bridge-utils
emerge bridge-utils
## create a link for net.br0
cd /etc/init.d
ln -s net.eth0 net.br0
# Remove net.eth*, add net.br0 and bridge.
rc-update del net.eth0
rc-update del net.eth1
rc-update add net.br0 default
rc-update add bridge boot
/etc/conf.d/bridge:
#bridge contains the name of each bridge you want created.
bridge="br0"
# bridge_<bridge>_devices contains the devices to use at bridge startup.
bridge_br0_devices="eth0 eth1"
/etc/conf.d/net
iface_br0="10.0.0.1 broadcast 10.0.0.255 netmask 255.255.255.0"
#for dhcp:
#iface_br0="dhcp"
#comment this out if you use dhcp.
gateway="eth0/10.0.0.1"
Otros usuarios que hayan configurado exitosamente puentes en otras distribuciones, con direcciones dinámicas o estáticas IP, les animo a que me envíen sus respectivas configuraciones tal de publicarlas aquí.
El puenteado en Shorewall se habilita con la opción BRIDGING en /etc/shorewall/shorewall.conf:
BRIDGING=Yes
En el escenario descrito arriba, habrá probablemente dos zonas definidas --
una para internet y otra para la red local LAN así que en el archivo /etc/shorewall/zones:
#ZONE TYPE OPTIONS
fw firewall
net ipv4
loc ipv4
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
Un archivo convencional de políticas de de dos-zonas es apropiado en este
caso — /etc/shorewall/policy:
#SOURCE DEST POLICY LOG LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT info
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
Sólo el dispositivo puente mismo está configurado con una dirección IP por lo
que sólo este dispositivo está definido en el archivo /etc/shorewall/interfaces de Shorewall :
#ZONE INTERFACE BROADCAST OPTIONS
- br0 192.168.1.255
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
Las zonas se definen usando el archivo /etc/shorewall/hosts . Asumiendo que el enrutador está
conectado a eth0 y el switch a eth1:
#ZONE HOST(S) OPTIONS
net br0:eth0
loc br0:eth1
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE
Cuando se detiene Shorewall, usted querrá permitir sólo el tráfico local a
través del puente — /etc/shorewall/routestopped
#INTERFACE HOST(S) OPTIONS
br0 192.168.1.0/24 routeback
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
El archivo /etc/shorewall/rules de la muestra
two-interface es un buen lugar donde comenzar a definir un conjunto de reglas
para el firewall.
Un sistema Shorewall no necesariamente tiene que ser exclusivamente puente o enrutador -- puede actuar como ambos. Este es un ejemplo:
Este es básicamente el mismo arreglo que se muestra en la Guía de Configruación de Shorewall con la excepción que la DMZ está en puente en vez de con Proxy ARP. Los cambios en la configuración de la Guía de Configuración son:
-
El archivo
/etc/shorewall/proxyarpestá vacío en esta configuración. -
El archivo
/etc/shorewall/interfacescontiene:#ZONE INTERFACE BROADCAST OPTIONS
- br0 detect routefilter
loc eth1 detect -
El archivo
/etc/shorewall/hoststendría:#ZONE HOSTS OPTIONS
net br0:eth0
dmz br0:eth2 -
Los sistema DMZ necesitan un ruta a la red 192.168.201.0/24 via 192.0.2.176 para habilitarles y que se comuniquen con la red local.
El puenteado (bridging) no funciona sobre algunas tarjetas de redes inalámbricas — vea http://bridge.sf.net/.
-
Este es un ejemplo en Castellano detallando el puenteado entre una red pública y una red local usando Shorewall. Esta es otra configuraciont de enrutador/puente.