+

Arquitectura y configuración
de cortafuegos:

Shorewall

Técnico en Administración de
Redes y Sistemas TCP/IP
Juan José Mostazo
jmostazo@fi.upm.es
Administración de servidores seguros en Internet
+
¿Que es una puerta de enlace
(gateway)?
 Una puerta de enlace es un dispositivo que permite interco-
nectar dos redes con protocolos y arquitecturas diferentes a
todos los niveles de comunicación.

 Un router (o enrutador) no tiene por qué hacer de puerta de

enlace.

09/11/10
+
¿Que es un cortafuegos?

 Un cortafuegos (firewall) es una parte de un sistema o una

red que está diseñado para bloquear el acceso no
autorizado, permitiendo al mismo tiempo comunicaciones
autorizadas.

09/11/10
+
iptables

 Es una herramienta que permite configurar la manera en que

son tratados los paquetes de red al momento de entrar y salir
del subsitema de red del núcleo de Linux.

 El núcleo cuenta con tres listas de reglas:

 INPUT
 OUTPUT
 FORWARD

09/11/10
+
iptables - Target

 ACCEPT: Acepta la conexión.

 DROP: Ignora el intento de conexión. No informa al origen de

este hecho.

 REJECT: No permite la conexión e informa de ello al origen.

09/11/10
+
iptables - Listas de reglas

09/11/10
+
iptables – Ejemplos (1)

 Enviamos un ping a localhost:

ping –c 1 127.0.0.1

 Añadimos una regla a la lista INPUT, que descarta todos los

paquetes ICMP prodecentes de localhost:
sudo iptables -A INPUT –s 127.0.0.1 –p icmp –j DROP

 Comprobamos el estado de la lista INPUT:

sudo iptables -L INPUT

 Volvemos a enviar un ping a localhost:

ping –c 1 127.0.0.1

09/11/10
+
iptables – Ejemplos (2)

 Dos formas de eliminar una regla:

sudo iptables –D INPUT 1

sudo iptables –D INPUT –s 127.0.0.1 –p icmp –j DROP

 Volvemos a enviar un paquete ICMP a localhost:

ping –c 1 127.0.0.1

09/11/10
+
iptables – Ejemplos (3)

 Enviamos un ping a nuestro compañero de la derecha:

ping –c 1 192.168.150.2XX

 Añadimos una regla a la lista INPUT, que descarta todos los

paquetes ICMP procedentes de la subred a que
pertenecemos:
sudo iptables –A INPUT –s 192.168.128.0/17 –p
icmp –j DROP

 Comprobamos el estado de la lista INPUT:

sudo iptables -L INPUT

 Volvemos a enviar un ping al mismo compañero:

ping –c 1 192.168.150.2XX

09/11/10
+
Shorewall

 Shorewall es una herramienta para configurar puertas de

enlace (gateways)/corta fuegos (firewall) para GNU/Linux.

 Sin embargo, nosotros nos vamos a centrar en utilizar

shorewall como corta fuegos.

 Basado en iptables.

09/11/10
+
Instalamos shorewall

 apt-get install shorewall-perl

 shorewall viene por defecto sin configurar:

 En /usr/share/doc/shorewall-common/examples/one-
interface están los ficheros de ejemplo para una
configuración con una sola interfaz de red (nuestro caso).

 Copiamos los ficheros en /etc/shorewall.

sudo cp /usr/share/doc/shorewall-
common/examples/one-interface/* /etc/shorewall/

 Hay que activarlo editando el fichero /etc/default/shorewall

y configurando la variable “startup” para que valga 1.
sudo vim /etc/default/shorewall
09/11/10
+
Estructura de la configuración

 /etc/shorewall:
 shorewall.conf: Configuración general de shorewall.
 interfaces: Configura las interfaces de red que van a participar.
 zones: Define las zonas en las que se va a dividir la red.
 policy: Define las políticas por defecto que se van a seguir.
 rules: Define las excepciones de las políticas definidas.

 Hay más ficheros, pero son opcionales.

09/11/10
+
Fichero <shorewall.conf> (I)
 Configuración general de shorewall:
 Opciones sobre los registros (logs): paths, formatos, etc...
 Opciones asociadas al comportamiento de pasarela (router).
 Opciones globales del firewall.

 STARTUP_ENABLED = Yes | No. Indica si se desea o no que

autoarranque shorewall al iniciar el equipo.

 LOG_MARTIANS = Yes | No. Activa/desactiva el filtrado de

paquetes con direcciones imposibles (paquetes
“marcianos”).

 La configuración por defecto nos vale por ahora, sólo

cambiaremos STARTUP_ENABLED=Yes.
09/11/10
+
Probando Shorewall

 Enviamos un ping a nuestro compañero de la derecha:

ping –c 1 192.168.150.2XX

 Iniciamos Shorewall:
sudo /etc/init.d/shorewall start

 Volvemos a enviar un ping al mismo compañero:

ping –c 1 192.168.150.2XX

 Hacemos la misma prueba parando Shorewall.

09/11/10
+
Tablas en los ficheros de
configuración
 El resto de ficheros de configuración siguen una estructura
en forma de tabla.
 Por ejemplo:
# ZONE | INTERFACE | BROADCAST | OPTIONS
net1 eth0 192.168.168.63
net2 ppp0 - dhcp
 En este caso tenemos 4 columnas.
 A la hora de añadir filas, toda sucesión de espacios y/o tabuladores
contigua se consideran un separador de columnas.
 En este caso las columnas BROADCAST y OPTIONS son opcionales.
 En caso de no asignar valor a una columna y querer asignar valor a
una que va después, hay que usar “-”.

09/11/10
+
Fichero <zones>

 Define las zonas en las que se va a dividir la red.

 Las zonas nos permitirán organizar las reglas dependiendo

de su origen/destino.

 Formato:
ZONE | TYPE | OPTIONS | IN | OUT
| | | OPTIONS | OPTIONS
 Zone: nombre de la zona
 Type:
 ipv4: indica que la zona usa ipv4.
 firewall: indica que la zona define al firewall. Solo puede haber
una zona de tipo firewall.
 El resto de opciones no nos conciernen.
09/11/10
+
Zonas especiales

 Independientemente del contenido del fichero <zones>,

existen varias zonas predefinidas, entre las que destacan:
 “all”: Se puede usar para indicar cualquier zona.
 “$FW”: Se puede usar para referirse a la zona del firewall.

09/11/10
+
Fichero <interfaces> (1)

 Formato:
ZONE | INTERFACE | BROADCAST | OPTIONS

 ZONE: Zona a la que se asignará el interfaz de red. Tiene

que estar previamente definida en el fichero <zones>.

 INTERFACE: Nombre del interfaz de red.

 BROADCAST: Indica las direcciones de red usadas para la

difusión de paquetes en este interfaz.
 Se puede proporcionar una lista de IPs separadas por comas:
192.168.128.255,192.168.255.255
 Se puede usar “detect” para que shorewall detecte
automáticamente estas direcciones.

09/11/10
+
Fichero <interfaces> (2)

 OPTIONS:
 dhcp: Indica que se va a permitir el tráfico dhcp en este interfaz.
 routefilter: Activa los filtros anti-escucha/usurpación en este
interfaz.
 logmartians: Activa el registro de los paquetes “marcianos”.
 blacklist: Activa el filtrado mediante listas negras de direcciones
IP.
 maclist: Activa el filtrado mediante listas de direcciones MAC.
 nosmurfs: Filtra los paquetes “pitufos” (provenientes de una
dirección de difusión).

09/11/10
+
Fichero <policy> (1)
 Formato:
SOURCE DEST POLICY LOG … …
LEVEL
SOURCE: Zona origen. Se puede usar “all” para indicar que la
política se aplicará para cualquier zona de origen.
DEST: Zona destino. Se puede usar “all” para indicar que la
política se aplicará para cualquier zona de destino.
POLICY: Política que se va a aplicar.
 ACCEPT: Acepta la conexión.
 DROP: Ignora el intento de conexión. No informa al origen de
este hecho.
 REJECT: No permite la conexión e informa de ello al origen.
LOG_LEVEL: Nivel en el que se registrarán las conexiones.

09/11/10
+
Fichero <policy> (2)

 El orden de las entradas es importante. Si una conexión casa

con varias reglas, se aplicará la regla que esté antes en el
fichero policy.

 Es recomendable añadir una regla

all all REJECT

al final del fichero para evitar sustos.

09/11/10
+
Niveles de registro (syslog)
 debug (mensajes de depuración)

 info (mensajes de información)

 notice (mensaje indicando)

 warning (Aviso)

 err (errores)

 crit (errores críticos)

 alert (errores que requieren una atención inmediata)

 emerg (errores indicando que sistema es inestable)

 none (no registrar) 09/11/10

+
Fichero <rules> (1)

 Permite añadir las excepciones pertinentes a las políticas

establecidas en el fichero <policy>
 Una vez más, el orden de las reglas es importante, dado que
se van evaluando en orden.

 Columnas básicas:
 ACTION: Acción a realizar en caso que se cumplan las
condiciones.
 SOURCE: Origen de la conexión.
 DEST: Destino de la conexión.
 PROTO: Protocolo usado en la conexión.
 DEST PORT: Puerto de destino.
 SOURCE PORT: Puerto de origen.
09/11/10
+
Fichero <rules> (2)
 Acciones básicas:
 ACCEPT, DROP y REJECT

 SOURCE y DEST:
 Se indican mediante zonas: $FW, all, ...
 Se puede limitar a ciertas direcciones:
 Una IP: <net:155.186.235.1>
 Una subred: <net:155.186.235.0/255.255.255.0> o
<net:155.186.235.0/24>
 Un rango: <net:192.168.2.11-192.168.2.17>
 Una dirección de nivel físico (MAC):
<loc:~00-A0-C9-15-39-78>
 Cualquier combinación hecha mediante comas:
<net:192.168.2.11-192.168.2.17,192.168.2.200>
09/11/10
+
Fichero <rules> (3)

 SOURCE y DEST (Continuación):

 También se puede especificar una interfaz de red:
<net:eth0:192.168.1.5>
 O exclusiones:
 <net:!192.168.1.5>: Una IP de la zona net excepto
192.168.1.5.
 <net:155.186.235.0/24!155.186.235.1>: Una IP de
la zona net y dentro de la red 155.186.235.0/24 excepto la IP
155.186.235.1

09/11/10
+
Fichero <rules> (4)

 PROTO:
 Protocolos normales, como pueden ser: tcp, udp, icmp.
 Se pueden mezclar usando comas: “tcp,udp”.
 También se puede indicar “all” para indicar todos los protocolos

 DEST PORT y SOURCE PORT:

 Es una lista de puertos (separada por comas):
 Puede ser un numero de puerto
 Un puerto especificado mediante un nombre de servicio (ver
/etc/services)
 Un rango: 6000:6003

09/11/10
+
Ejemplo básico (1)

 Ejemplo de fichero <policy>:

# SOURCE | DEST | POLICY | LOG | ...
# LEVEL |
$FW net ACCEPT
net $FW DROP info
all all REJECT info

 Ejemplo de fichero <rules>:

# ACTION | ORIGIN | DEST | PROTO | DEST
# PORT
ACCEPT net $FW icmp
ACCEPT net $FW tcp 80
ACCEPT net:192.168.1.1 $FW tcp 22

09/11/10
+
Macros (1)

 Permiten simplificar las reglas (no hace falta indicar los

parámetros obvios, por ejemplo, el protocolo y los puertos)
 Existen plantillas predefinidas para los servicios básicos:
 SSH
 HTTP, HTTPS
 DNS
 Ping
…

09/11/10
+
Macros (2)

 Se usan en la columna ACTION, pero dado que no implican la

acción que se va a realizar, hay que combinar la plantilla con
la acción a realizar. Se pueden usar dos sintaxis:
 <Plantilla>/<ACTION>. Ejemplo:
HTTP/ACCEPT net $FW
 <Plantilla>(<ACTION>). Ejemplo:
Ping(DROP) net $FW

09/11/10
+
Macros (3)

 Las macros están definidas en el directorio

/usr/share/shorewall

#ACTION SOURCE PROTO DEST SOURCE RATE USER/

# PORT PORT(S) LIMIT GROUP
PARAM - - icmp 8

09/11/10
+
Registrando los sucesos

 Además, podemos configurar para que al aplicarse una

regla, esta se almacene en los registros del sistema.
 Para ello basta con añadir “:<nivel de registro>” en la
columna de ACTION.

 Por ejemplo:
REJECT:info net $FW icmp

 También se puede aplicar cuando se usan macros:

Ping(DROP):info net $FW

09/11/10
+
Ejemplo básico (2)

 Ejemplo de fichero <rules> usando plantillas:

# ACTION | ORIGIN | DEST | PROTO

HTTP/ACCEPT net $FW

SSH/ACCEPT net:192.168.1.1 $FW
Ping(ACCEPT) net $FW

09/11/10
+
Fichero hosts (1)
 Formato:
ZONE | HOST(S) | OPTIONS

 ZONE: nombre de la zona a la que se van a asociar las

direcciones IP. Tiene que estar definida en el fichero
<zones>.

 HOSTS: Direcciones IP que formarán parte de la zona.

 Formato: <interfaz de red>:<lista de Ips>
 La lista de IPs es una combinación (usando comas) de los
siguientes elementos:
 Una dirección IP.
 Un rango de direcciones IP.
 Una red.
 También se pueden usar las exclusiones (usando “!”)
09/11/10
+
Fichero hosts (2)

 OPTIONS:
 blacklist
 maclist
 tcpflags
 nosmurfs

09/11/10
+
Ejemplo de fichero <hosts>

 Ejemplo:
#ZONE HOST(S) OPTIONS
subred1 eth1:192.168.128.0/17

 En este ejemplo, estamos creando una zona que contiene a

las IP de la subred 192.168.128.0/17

 Si consideramos que a través de eth1 salimos a internet, este

mecanismo nos permite simplificar las reglas del fichero
rules en caso de que tengamos alguna afinidad con esta
subred.

09/11/10
+
Restringir por usuario/grupo

 Solo funciona cuando se estar restringiendo paquetes con

origen en el firewall.
 Formato [!][nombre de usuario][:nombre de grupo]

 Ejemplo:
ACCEPT $FW net tcp - 80 - - www-data

 El usuario www-data es el que normalmente ejecuta los

servidores web en linux (apache2, lighttpd, etc...)

09/11/10
+
Acciones avanzadas: Limit (1)

 Permite limitar el número de accesos de un cliente

(identificado por IP) a un puerto.
 Formato:
Limit:<nivellog>:<etiqueta>,<nconexiones>,<seg
undos>

 Ejemplo:
Limit:none:SSHA,3,60 net $FW tcp 22
 En este caso, un cliente solo podría iniciar tres conexiones al
puerto 22 en una franja de tiempo de 60 segundos.
 No se registrarán los intentos fallidos de conexión

09/11/10
+
Acciones avanzadas: Limit (2)

 La acción Limit etiqueta las IP con la etiqueta indicada para

poder controlar el numero de conexiones. Esta se podría
usar para realizar reglas más complejas.

 Sin embargo, para su uso normal, es importante usar una

etiqueta diferente para cada una de las reglas Limit que
usemos.

09/11/10
+
Utilizando listas negras (1)

 shorewall.conf:
 BLACKLISTNEWONLY=No – Se comprueban las listas negras cada
vez que se recibe una paquete de red.
 BLACKLISTNEWONLY=Yes – Solo se comprueban las listas negras
cuando se establece una conexión.
 BLACKLIST_DISPOSITION=DROP | REJECT
 BLACKLIST_LOGLEVEL= Nivel en el que se registrarán los
paquetes filtrados por las listas negras.

09/11/10
+
Utilizando listas negras (2)
 Hay que activar la opción blacklist en los interfaces de red
en los que queramos que se filtre mediante las listas negras.

 El fichero /etc/shorewall/blacklist contiene una lista negra

estática.
 Si se modifica el fichero /etc/shorewall/blacklist se puede
recargar sin parar shorewall mediante el comando “shorewall
refresh”

 También se puede añadir elementos a la lista negra de forma

dinámica:
 shorewall [drop|reject] <IP>: Fuerza que se ignoren o rechacen
(dependiendo de si se usa drop o reject) todos los paquetes
provenientes de <IP>.
 shorewall allow <IP>: Borra a <IP> de la lista negra.
09/11/10
+
Ejemplo de uso de listas negras

 Crear un script que descargue y procese las listas de IPs de:

http://www.spamhaus.org/drop/drop.lasso

 Ejecutar: shorewall refresh

09/11/10
+
fail2ban
 Programa que revisa los registros de ciertas aplicaciones
(ssh, smtp, ...) y avisa a shorewall para bloquee las
conexiones de las IPs que generen un determinado número
de fallos de autenticación.

 Instalación:
apt-get install fail2ban
cd /etc/fail2ban
modificar jail.conf: En nuestro caso, lo importante es
modificar banaction para que notifique a shorewall.

 Es bastante recomendado añadir

“BLACKLISTNEWONLY=No” al fichero shorewall.conf
 Con “invoke-rc.d fail2ban start” arrancamos el
servicio.
09/11/10
+
Extendiendo shorewall

 Shorewall permite añadir nuevas funcionalidades haciendo

uso de scripts en Perl.
 Ejemplo:
 Descargamos los ficheros:
wget http://antares.ls.fi.upm.es/shorewall-
knock.tar.bz2
 Descomprimimos los ficheros en /etc/shorewall
sudo tar -xjvf shorewall-knock.tar.bz2
/etc/shorewall
 Ahora disponemos de tres nuevas acciones:
 Knock
 KnockTrap
 KnockDoor
09/11/10
+
Llamando a la puerta

 Con las nuevas acciones podemos configurar el corta fuegos

de una forma interesante: ¡Podemos dejar entrar solo a la
gente que llame a la puerta de forma correcta!

 La acción Knock añade una etiqueta a la IP que case con la

regla.

 La acción KnockTrap elimina una etiqueta en caso de que se

cumplan las condiciones de la regla.

 La acción KnockDoor fuerza que se ignore el paquete en

caso de que la IP de origen no tenga una etiqueta dada.
Además comprueba que esta etiqueta la haya obtenido en un
periodo de tiempo determinado.

09/11/10
+
Ejemplos usando KnockDoor (1)

 Fichero <rules>
Knock:none:EnableSSH net $FW tcp 1234
KnockDoor:none:EnableSSH,10 net $FW tcp 22

 Por defecto, el puerto ssh va a estar cerrado.

 En caso de que alguien acceda al puerto 1234, la acción Knock

le asignará la etiqueta EnableSSH. Este control de etiquetas se
lleva a cabo relativo a la dirección IP de origen.

 La acción KnockDoor comprueba si la dirección origen esta

marcada con la etiqueta EnableSSH y esta ha sido obtenida
como mucho hace 10 segundos, en cuyo caso permite la
conexión. En caso contrario la ignora.

09/11/10
+
Ejemplos usando KnockDoor (2)

 El problema de la implementación anterior es con los escaneados

de puertos.
 Por ejemplo, si se hace un escaneo de puertos que vaya comprobando
los puertos de forma descendente, pasaría primero por el puerto 1234
y luego por el puerto 22. En ese caso el puerto sería visible para el
escaneador de puertos.

 Podemos mejorar la eficiencia del mecanismo si usamos las

siguientes reglas en el fichero <rules>:
KnockTrap:none:EnableSSH net $FW tcp 1233,1235
Knock:none:EnableSSH net $FW tcp 1234
KnockDoor:none:EnableSSH,10 net $FW tcp 22

09/11/10
+
Aspectos de un firewall no vistos
en clase
 Shorewall no permite controlar las conexiones en base a las
aplicaciones.
 No puedes decir que solo apache2 puede escuchar en el puerto
80.
 Tampoco puedes indicar que Firefox solo pueda acceder al
puerto 80.

 En Unix, el único control de este tipo es que solo las

aplicaciones ejecutadas por root pueden usar los puertos en
el rango 1-1000.
 En Linux existe la posibilidad de controlar este
comportamiento con otras herramientas, por ejemplo con
SELinux o appArmor.

09/11/10
+
Cosas a tener en cuenta (1)
 Administrar un cortafuegos en remoto (por ejemplo,
mediante ssh) no es muy recomendable ya que se puede
perder la conexión al modificar inadecuadamente las reglas
del firewall.
 En caso de hacerlo, hay que tomar precauciones. Por ejemplo,
utilizar “shorewall safe-restart” para actualizar las reglas del
firewall. Este comando reiniciará shorewall y nos preguntará si
todo a ido bien, en caso de no contestar (cosa que pasaría si
perdemos la conexión), pararía el firewall.

 La función de un firewall es controlar las conexiones que se

pueden realizar. En ningún caso se puede esperar que un
firewall elimine los fallos de seguridad de los servicios a los
que deje acceder, en el mejor de los casos ayudará a
evitarlos, pero seguramente no los elimine completamente.

09/11/10
+
Cosas a tener en cuenta (2)

 Antiguamente las direcciones MAC estaban grabadas a

fuego en el hardware de red. Últimamente es muy fácil
cambiar la dirección MAC por software (sobre todo en las
tarjetas de red inalámbricas), lo que hace que no sean muy
fiables (por lo menos no son una panacea) a la hora de filtrar.

09/11/10