Seguridad en Redes

Carlos J. Mateos Orozco

Alejandro Carrasco Muoz
Paulino Ruiz de Clavijo Vzquez

Prctica 2: Firewalls. Filtrado de paquetes

Material necesario para esta prctica:
Mquina Linux
Los objetivos de la prctica son:
Describir el funcionamiento del filtrado de paquetes.
Configurar un firewall.
Configurar filtrado de paquetes en una mquina Linux mediante Netfilter /
IPtables.
Elaborar reglas IPtables.
Qu hay que saber antes de entrar en el laboratorio:
Todo lo explicado en esta prctica.
Haber completado la prctica 1.

5.1. Introduccin
Un cortafuegos o firewall es un sistema o grupo de sistemas utilizados para
separar una mquina o una subred (zona protegida) del resto de la red (zona de
riesgo), estableciendo una poltica de control de acceso entre ambos entornos. Es
decir, el firewall acta como punto de conexin segura entre dos o ms sistemas
informticos. Un firewall puede ser un router, un PC o una red completa.
Los principales elementos que pueden conformar un firewall, entiendo el firewall como
un sistema, son el filtro de paquetes y los proxys. En esta prctica nos centraremos en el
primer elemento, el filtrado de paquetes.
El filtrado de paquetes es un proceso que consiste en denegar o permitir el flujo de
informacin entre la red interna que deseamos proteger y el resto o la red externa. Este
filtrado se hace de acuerdo a unas reglas predefinidas, y segn stas, se examinan las
cabeceras de los paquetes segn van pasando a travs de l, decidiendo la suerte
del paquete completo (aceptar, descartar, etc). El filtrado tambin se conoce como
screening, y a los dispositivos que lo implementan se les denomina chokes.
Los firewalls de filtrado de paquetes actan sobre la capa de red y la de transporte de
la pila TCP/IP. Es decir, trabajan sobre la informacin de las cabeceras de los paquetes
IP, sin llegar a analizar los datos. Por ejemplo, un firewall no puede evitar que un usuario
de la red sobre la que acta mande un email desde su equipo con otra cuenta de
correo diferente de la de su trabajo. Lo que si podra es evitar que dicho equipo

accediera al servidor de correo y desde l no se pudiese mandar ningn correo a

nadie.
Este filtrado se realiza a travs de una lista de reglas. Las reglas pueden ser de
diferentes tipos, aceptacin, rechazo o denegacin, entre otras.

5.1.1.

Stateless vs Stateful

Un filtro esttico o Stateless (sin estado) analiza las cabeceras de cada

paquete recibido (IP, TCP, UDP, ICMP...) y toma una decisin de filtrado en funcin de
los valores contenidos en los distintos campos de dichas cabeceras. No se establece
ninguna relacin entre los paquetes que atraviesan el filtro, aunque correspondan a
una misma conexin. Este es el mecanismo de filtrado clsico, sin apenas consumo
de recursos y de fcil implementacin.
Por el contrario un filtro dinmico o Stateful (de estados) permite el control de un flujo
de datos relacionados (por ejemplo, paquetes dentro de una misma conexin TCP o
entre varias conexiones). Para llevarlo a cabo es necesario mantener en memoria los
parmetros de cada conexin, tomando decisiones en funcin de la evolucin de las
mismas. Por ejemplo, slo se permite el paso de datos en sentido entrante a travs de
un puerto TCP que haya sido previamente abierto en sentido saliente, o conexiones
entrantes a un puerto dado desde una direccin origen cuando previamente se ha
iniciado una conexin saliente hacia esa misma direccin desde otro puerto concreto.
Este modelo de filtrado es ms sofisticado y permite un control ms exhaustivo del
trfico resolviendo necesidades a nivel de paquete que antes tenan que resolverse a
nivel de aplicacin (mediante proxies).

5.1.2.

Filtrado de paquetes en Linux

En Linux, el filtrado de paquetes est programado en el ncleo (como mdulo

o como componente esttico). Los ncleos de Linux han tenido capacidad de filtrado
de paquetes desde su versin 1.1:
-

1 gen (Lx 1.1): ipfw (BSD)

2 gen (Lx 2.0): ipfwadm ejecutado en espacio de usuario. Basada en el ipfw

de BSD, se encargaba de controlar reglas de filtrado del ncleo (1994).

3 gen (Lx 2.2): ipchains introduce mejoras (combinacin de mdulos y

programas de usuario) pero sigue siendo filtrado esttico.

4 gen (Lx 2.4): la API de ipchains se reescribe dando lugar a iptables

incorpora filtrado dinmico (stateful).

A partir del ncleo Linux 2.3.15 y en toda la serie 2.4 y posteriores se utiliza el mdulo
NetFilter junto con la utilidad iptables, que permite establecer las reglas de filtrado. El
entorno Netfilter permite el filtrado de paquetes (ya sea con o sin estado), la traslacin
de direcciones [y puertos] (NA[P]T) y otras manipulaciones sobre el datagrama IP
(packet mangling).

5.1.3.

NAT Enmascaramiento

En condiciones normales un datagrama IP viaja salto a salto a travs de los

routers manteniendo en su cabecera las direcciones IP origen y destino del mismo
durante todo el trayecto. Se denomina NAT (Network Address Translation) a la
alteracin del origen o destino del paquete en uno de los saltos, siendo necesario

realizar igualmente la operacin inversa en los paquetes de respuesta para que el

origen pueda recibirlos. La traslacin NAT resuelve distintas necesidades:
-

Cambio de la direccin y/o puerto destino de los datagramas recibidos en

una red, redirigindolos a una mquina concreta en funcin del servicio
requerido o distribuyndolos entre distintas mquinas destino para el equilibrio
de carga.

Cambio de la direccin destino de un datagrama, para que el servicio

requerido lo ofrezca un tercer equipo (proxy transparente).

Cambio de la direccin de origen de un datagrama, asignndole otra

direccin antes de reenviarlo hacia el destino. Este tipo de NAT se denomina
enmascaramiento. Permite a uno o varios equipos de una red privada quedar
visibles en otra red (por ejemplo Internet) a travs de una direccin externa.
Esta es la tcnica utilizada en la actualidad para que mltiples equipos
accedan a Internet a travs de una nica direccin pblica.

Segn lo visto podemos distinguir entre

-

Source NAT (SNAT): alteracin del origen del datagrama, realizado despus
del encaminamiento del mismo y antes de su reenvo (el enmascaramiento es
una forma de SNAT).

Destination NAT (DNAT): alteracin del destino, realizado antes del

encaminamiento del datagrama (el port forwarding, el balanceo de carga y
los proxy transparentes son ejemplos de DNAT).

5.2. Netfilter Iptables

Se trata de una interfaz completa (o framework), dentro del ncleo de Linux,
que permite interceptar y manipular paquetes de red. A Netfilter pueden conectarse
otros mdulos o componentes. El mdulo ms conocido construido sobre Netfilter es
IPtables. Esta herramienta nos permite manipular Netfilter desde el espacio de usuario.
A veces se usa IPtables para referirse a toda la infraestructura ofrecida por Netfilter.
Con esto conseguimos que un mdulo del kernel, ms una utilidad de usuario
controlen el flujo de paquetes que van desde y hacia las interfaces de red.
Otro mdulo construido sobre Netfilter es Contrack (Connection Tracking System) o
sistema de seguimiento de conexiones. Con este mdulo Netfilter puede funcionar
como firewall de Inspeccin de estados (stateful inspection packet firewall), tambin
asociado a filtrado dinmico. A travs de este mecanismo, permite asociar una
cantidad de paquetes a una conexin en particular. Este tipo de inspeccin permite
que el comportamiento del firewall cambie con respecto a la informacin contenida
en el paquete, por ejemplo, de un paquete en particular que es parte de una
conexin pre-existente.
Con Netfilter, usando IPtables podemos realizar:
-

Filtrado de paquetes.
Traduccin de direcciones y puertos NAT.
Manipulaciones sobre datagramas IP (packet MANGLING).
Mantener registros de logs.
Seguimiento de conexiones (Conntrack)

Algunas de las caractersticas de Netfilter son:

Permite el uso de distintas tablas de IP para realizar el filtrado (nat, filter,
mangle y raw).
Permite el uso de plugins para nuevas condiciones y acciones (Ej: ipp2p para
filtrar conexiones a redes P2P). As, no es necesario modificar los mdulos para
agregar una extensin adicional.
Nativamente puede manejar IPv4 e IPv6, usando la misma librera y el mismo
cdigo

5.2.1.

Arquitectura de Netfilter

Netfilter realiza la gestin del filtrado mediante tablas organizadas en cadenas

(chains) y stas a su vez compuestas por reglas que se evalan sobre los paquetes
analizados en busca de condiciones segn unos parmetros y, en caso de darse
alguna, ejecutando la accin asociada.
5.2.1.1.

Cadenas (Chains)

Las cadenas son agrupaciones de reglas que se deben aplicar a los paquetes segn
momentos concretos del flujo de los paquetes a su paso por el sistema Netfilter.
Indican CUANDO actuar sobre los paquetes. Las posibles cadenas que nos
encontramos son:
-

INPUT: Determina la accin realizar cuando un paquete coincide con la regla,

a la entrada de la interfaz (filtrado de trfico entrante). Se aplica a los
paquetes destinados a la propia mquina.
OUTPUT: Determina la accin a realizar cuando un paquete coincide con la
regla, a la salida de la interfaz (filtrado de trfico saliente). Se aplica a los
paquetes originados en la propia mquina.
FORWARD: Determina la accin a tomar cuando un paquete se enva desde
una interfaz a otra. Se trata de una cadena transversal que se encuentra de
forma intermedia entre las dos siguientes.
PREROUTING: Es el primer estadio en el sistema Netfilter. Determina la primera
accin a realizar antes de que el paquete entre en el sistema.
POSTROUTING: Determina la accin a realizar, justo antes de enviar el paquete
a la interfaz destino.

PRE
ROUTING
G

Decisin de
encaminamiento

SI

POST
ROUTING
G

FORWARD

NO

INPUT

OUTPUT

Procesamiento
local

Fig. p5.1: Esquema del procesamiento de Netfilter

Cuando se recibe un paquete por cualquier interfaz se lleva a cabo, en primer lugar,
una suma de comprobacin (Checksum). Si es correcta, los paquetes transitan hacia
la evaluacin de la cadena PREROUTING (en caso de existir), cuyas reglas se
encargarn de determinar el tratamiento que deber de darse al paquete en funcin
de la direccin destino:
Si el paquete va dirigido a la propia mquina, ste es enviado a la cadena
INPUT, que en caso de superarse ser procesado localmente.
Si la direccin destino del paquete es distinta de la local, y est activada la
funcin de reenvo, se evala la cadena FORWARD. Si se superan las reglas de
esta cadena se reenva el paquete (si la funcin de reenvo no estaba
habilitada, el paquete se descarta DROP).

Activacin de reenvo de paquetes en Linux:

#echo 1 > /proa/sys/net/ipv4/ip_forward
NOTA: los paquetes que no son considerados locales son aquellos que, por lo
general, pertenecen a otra subred.
Antes de que los paquetes abandonen el sistema Netfilter y sean enviados a la interfaz
destino son recibidos por la cadena POSTROUTING.
La cadena OUTPUT solamente es utilizada cuando los paquetes han sido originados
localmente. Adems, los paquetes que pasen por la cadena OUTPUT necesariamente
pasan por POSTROUTING.
5.2.1.2.

Tablas

Cada tabla es usada para indicar al sistema de filtros sobre el tipo de procesamiento
que se debe aplicar a los paquetes, es decir, QU hacer con los paquetes. Una tabla
maneja una cierta cantidad de reglas internas que se organizan en cadenas. Existen
cuatro tablas por defecto: filter, mangle, nat y raw.

PRE
ROUTING
G

Decisin de
encaminamiento

SI

NO

DNAT
MANGLE
RAW

POST
ROUTING
G

FORWARD
FILTER
MANGLE

INPUT

SNAT
MANGLE

OUTPUT

FILTER
MANGLE
Procesamiento
local
Fig. p5.2: Esquema del procesamiento de Netfilter. Tablas

FILTER
MANGLE
NAT
RAW

FILTER: Se usa para el filtrado general de paquetes y es la tabla

predeterminada de Netfilter. Decide qu es lo que entra y qu no. Est
compuesta por las siguientes cadenas:
o INPUT
o OUTPUT
o FORWARD

NAT: Controla la traduccin de direcciones. Permite alterar las direcciones

origen y destino del datagrama, analizando algunas propiedades del mismo.
Est compuesta por las cadenas:
o PREROUTING
o POSTROUTING
o OUTPUT
Algunos usos tpicos de NAT son:
o SNAT (Source NAT): Tambin conocido como IP Masquerading. Se
cambia la direccin IP origen del datagrama al pasar por el router
(despus del encaminamiento y antes de su reenvo).
o DNAT (Destination NAT): Se modifica la direccin IP destino antes del
encaminamiento. Algunas aplicaciones de DNAT son:
Proxy transparente: Se redirecciona el datagrama a otro equipo
que ser quien proporcione los servicios requeridos.
Balanceo de carga: Se cambia la direccin destino de los datos
recibidos en un balanceador para redirigirlos a una mquina
concreta en funcin del servicio requerido o entre mquinas
distintas para balancear la carga.
Port Forwarding: El router recibe las peticiones para la subred en
la que trabaja y cambia la IP hacia la que tiene que dirigirse.

MANGLE: Analiza ciertas caractersticas del paquete y lo marca, en funcin

de su naturaleza, para que reciba cierto tratamiento especfico (ej: diferenciar
trfico en funcin de los servicios). Mangle permite la reescritura completa
de paquetes (o tramas completas). En definitiva la tabla mangle controla los
procesos de modificacin del contenido y las opciones del paquete. Las
cadenas que se agrupan en esta tabla son:
o INPUT
o OUTPUT
o FORWARD
o PREROUTING
o POSTROUTING

RAW: Se usa para configurar excepciones en el seguimiento de paquetes. La

accin que siempre se usa para esta tabla es NOTRACK. Las cadenas que se
organizan en est tabla son:
o PREROUTING
o OUTPUT

Es importante ver que cada tabla tiene unas cadenas por defecto, que no se pueden
eliminar. A las cadenas por defecto de una tabla podemos unir cadenas creadas por
nosotros mismos para un mejor funcionamiento del filtrado o el enrutamiento.

Veamos algunos ejemplos del recorrido que pueden realizar los paquetes en funcin
de su destino.

Paquetes entrantes, destino local:

PRE
ROUTING
G

Decisin de
encaminamiento

SI

NO

DNAT
MANGLE

POST
ROUTING
G

FORWARD
FILTER
MANGLE

INPUT

SNAT
MANGLE

OUTPUT

FILTER
MANGLE

FILTER
MANGLE
NAT
Procesamiento
local

Fig. p5.3: Flujo de paquetes entrantes con destino local

Tabla

Cadena

Mangle

PREROUTING

Nat

PREROUTING

Mangle
Filter

INPUT
INPUT

Notas
Datagrama recibido por una interface
Permite alterar algn parmetro de la cabecera (ej: TOS (Type Of
Service))
Permite realizar DNAT
Decisin de encaminamiento:
Si dir.destino <> dir.local Salta a Forward (reenvo)
Si no, contina
Alteraciones antes de procesamiento
Filtrado del trfico entrante
Entrega al proceso local

Tab. p5.1: Recorrido del paquete entrante con destino local

Paquetes salientes, originados en local:

PRE
ROUTING
G

Decisin de
encaminamiento

SI

NO

DNAT
MANGLE

POST
ROUTING
G

FORWARD
FILTER
MANGLE

INPUT

SNAT
MANGLE

OUTPUT

FILTER
MANGLE

FILTER
MANGLE
Procesamiento
local

Fig. p5.4: Flujo de paquetes salientes originados en local

Tabla

Cadena

Mangle
Nat
Filter
Mangle
Nat

OUTPUT
OUTPUT
OUTPUT
POSTROUTING
POSTROUTING

Notas
Datagrama recibido por una interface
Permite alterar algn parmetro de la cabecera
Traslacin de direcciones
Filtrado del trfico saliente
Alteraciones una vez entregado el datagrama
Permite realizar SNAT
Entrega al interface
Tab. p5.2: Recorrido del paquete saliente con origen local

Paquetes reenviados (encaminamiento):

PRE
ROUTING
G

Decisin de
encaminamiento

SI

NO

DNAT
MANGLE

POST
ROUTING
G

FORWARD
FILTER
MANGLE

INPUT

SNAT
MANGLE

OUTPUT

FILTER
MANGLE

FILTER
MANGLE
Procesamiento
local

Fig. p5.5: Flujo de paquetes reenviados

Tabla

Cadena

Mangle
Nat

PREROUTING
PREROUTING

Mangle
Filter
Mangle
Nat

FORWARD
FORWARD
POSTROUTING
POSTROUTING

Notas
Entrega por el proceso local
Permite alterar algn parmetro de la cabecera
Permite realizar DNAT
Decisin de encaminamiento:
Si dir.destino <> dir.local Contina
Si no, salta a INPUT
Alteraciones antes del reenvo
Filtrado del trfico reenviado
Alteraciones despus del reenvo
Permite realizar SNAT
Entrega al interfaz
Tab. p5.3: Recorrido de paquetes reenviados

5.2.2.

Operativa Netfilter / Reglas IPtables

Como se indic anteriormente, para el uso de Netfilter desde el espacio de usuario es

necesario utilizar, adems de los mdulos del kernel, la utilidad IPtables. A travs del
comando iptables es posible insertar, eliminar y modificar reglas dentro de Netfilter.
5.2.2.1.

Sintaxis

Un comando bsico de iptables est compuesto por 7 partes, cada una de los cuales
indican:
-

El comando iptables como punto de partida.

La tabla a usar (filter, nat, mangle). Si no se pone nada se usa por defecto
filter.
El comando que deseamos aplicar a una cadena (insertar regla, modificar
una existente, eliminar, etc.). Para definir la operacin se usan una serie de
comandos.
La cadena a usar, que puede ser una de las cadenas por defecto (INPUT,
OUTPUT, FORWARD, PREROUTING.) o bien aquellas creadas por el usuario.
La condicin que especifica los criterios que debe de cumplir un paquete (los
campos que lo componen) para que sea aplicable la accin.
La accin a realizar para aquellos paquetes que cumplan la condicin.
Una serie de opciones que podemos aplicar para ajustar la accin.

NOTA: Cuando no se indica la tabla a usar, por defecto se usa la tabla filter. Un
comando iptables tiene la siguiente forma:

#iptables [-t table] COMANDO CADENA condicin accin [opciones]

--------------------------------------------------------------1
2
3
4
5
6
7
Ejemplo:
#iptables t filter -A INPUT p tcp --dport 23 j DROP
--------------------------------------------------------------1
2
3
4
5
6

5.2.2.2.

Comandos

Mediantes los comandos le indicamos a iptables qu deseamos hacer con la regla

que vamos a definir. Esto es, agregar una regla a una cadena, modificar una regla
existente en una cadena, eliminar el nombre de una cadena, etc.
Describimos algunos de los comandos ms comunes (todos deben escribirse en
maysculas), entre los que distinguimos por un lado los destinados al manejo de
cadenas, y por otro, al manejo de reglas dentro de una cadena.
Comando
Descripcin
-h
Lista los comandos de iptables.
MANEJO DE REGLAS
-A
Agrega una regla al final de la cadena especificada.
-D i
Elimina la regla i-sima de una cadena.

-I i
-R i

Inserta una regla dentro de una cadena en la posicin i-sima.

Reemplaza la regla i-sima por otra nueva en la cadena
especificada.
-F
Elimina todas las reglas de una cadena. Es equivalente a borrar todas
las reglas una por una.
-L
Lista las reglas de una cadena especificada.
-C
Verifica una regla antes de aadirla a la cadena especificada por el
usuario. Se suele implementar en arquitecturas con reglas complejas.
MANEJO DE CADENAS
-E
Renombra una cadena.
-N name
Crea una nueva cadena y se le pone nombre.
-X name
Borra una cadena especificada. Ha de estar vaca previamente.
-P
Cambia la poltica por defecto sobre una cadena, de forma que
cuando los paquetes atraviesan la cadena sin cumplir ninguna regla,
se envan a un objetivo como puede ser ACCEPT DROP.
-Z
Pone a cero los contadores de todas las reglas de una cadena.
Tab. p5.4: Comandos Iptables

5.2.2.3.

Reglas

Las reglas se construyen por concatenacin de condiciones y acciones asociadas.

Cada condicin evala una propiedad del paquete. Para indicar a Netfilter que
hacer con los paquetes de una transaccin, se deben crear reglas lo ms precisas
posible. La idea es que la condicin sea inequvoca, tanto como para quien cre la
regla (usuario) como para el krnel.
REGLA = <condicin,accin> :

Si se da la condicin, se ejecuta la accin asociada y se

detiene el procesamiento de la cadena.
Si no se cumple la condicin se pasa a la siguiente
regla.
Si no ha cumplido la condicin de ninguna regla en la
cadena se ejecuta la poltica por defecto sobre el
paquete (p.e. ACCEPT DROP).

A medida que se van ejecutando rdenes de iptables, se van aadiendo o

eliminando reglas asociadas a cada uno de los flujos de entrada o salida. Es
importante entender que las reglas que se aaden se procesarn de forma secuencial
(DROP y ACCEPT finalizan el procesamiento). Esto supone que para deshacer un
efecto la solucin es eliminar la regla que lo causa en vez de intentar aadir otra que
contradiga a la primera (por ejemplo no vale aadir un ACCEPT despus de un DROP
porque el segundo no anular el primero).
IMPORTANTE
En iptables las acciones se ejecutan con el parmetro j [accin], como se muestra:
#iptables A INPUT j DROP

10

A. Condiciones - operadores
Una condicin (o coincidencia match) se da como cierta cuando un paquete
cumple con los criterios indicados dentro de alguna de las cadenas. Alguno de estos
criterios pueden basarse en funcin de algn parmetro como, por ejemplo, el tipo de
protocolo (TCP, IP, ICMP,), algn puerto en particular (22), un usuario propietario del
paquete (OWNER), el estado de la transaccin (INVALID), o la combinacin de todos
ellos.
Las condiciones se construyen usando una serie de operadores que determinan qu es
lo que el paquete debe cumplir. Algunos de los ms importantes son los siguientes:
Operador
-p [protocolo]

-s [ip/mascara destino]

Descripcin
Indica sobre qu protocolo ha de realizarse la
comprobacin. Algunos valores pueden ser tcp, udp, icmp
o podemos referirnos a todos si se omite. Tambin puede
ser el nmero equivalente a un protocolo, indicados en
/etc/protocols.
Ejemplo: -p tcp,udp
Indica la direccin IP del origen del paquete. Puede
indicarse tambin de la forma IP/mscara para decirle a
Netfilter que se trata de un grupo de hosts.
Si no se especifica sta condicin se tomar como origen
todas las direcciones de difusin.

-d [ip/mascara destino]

-i [interfaz]

Se usa la opcin anterior seguida de la direccin IP y de la

mscara de red.
Ejemplo: -s 192.168.1.0/24
Indica la direccin IP destino de la transaccin
Ejemplo: -d 192.168.1.0/24
Indica la interfaz de entrada, desde donde se realiza la
transaccin o se reciben los paquetes, para una regla en
particular. (Nota: solo usado por las cadenas INPUT,
FORWARD y PREROUTING)
Con la tabla filter slo se podrn utilizar las cadenas INPUT y
FORWARD y PREROUTING cuando se utilice nat mangle.

-o [interfaz]

-f
-m

Ejemplo: -i eth0
-i eth+
Indica la interfaz de salida de la transaccin para una
regla en particular (Nota: slo usada por OUTPUT,
FORWARD y POSTROUTING en las tablas nat y mangle).
Ejemplo: -o eth0
-o eth+
Aplicacin de la regla slo a los paquetes fragmentados.
Uso de mdulos para extender funcionalidades.
Tab. p5.5: Operadores Iptables

11

B. Condiciones - extensiones
Adems de estos operadores existen otros que junto a stos extienden sus
funcionalidades concretando aun ms la condicin que se desea determinar. A estos
operadores se denominan extensiones.
Operador

Extensin
--sport

Descripcin
Puerto origen. Solo para tcp y udp.

--dport

Ejemplo: -p tcp --sport 0:53

-p tcp,udp --sport 1023
Puerto destino. Solo para tcp y udp.

--tcp-flags arg1 arg2

Ejemplo: -p tcp --dport 23

-p tcp,udp --dport 0:1023
Para los paquetes TCP que se analicen
se comprueban una serie de flags.
En esta opcin deben establecerse dos
argumentos:
arg1: Los indicadores a
comprobar
arg2: indicadores habilitados
Los valores que se pueden usar son:
ACK
RST
FIN
SYN
URG
PSH
Ejemplo: -p tcp -tcp-flags SYN,ACK,RST
SYN

-p [protocolo]

--syn

--icmp-type

mac
-m [mdulo]

Se comprueban todos los indicadores

pero solo SYN debe estar habilitado.
Indica que el flan SYN debe estar
activado y que el indicador ACK debe
ponerse a cero cuando, en un mensaje
TCP, se realiza una peticin de
establecimiento de conexin.
Ejemplo: -p tcp --syn
Selecciona los paquetes ICMP y
comprueba de qu tipo de mensaje
(de control) se trata.
Ejemplo: -p icmp -icmp-type echo-reply
-p icmp -icmp-type timeexceded
Mdulo MAC: Comprueba la direccin
MAC de los paquetes.
-m mac --mac-source <dir.MAC> : Se
comprueba la direccin MAC origen
Ejemplo:

12

state

-m mac --mac-source 00:02:3F:34:9B:E1

-j DROP
Mdulo STATE: Comprueba el estado
de la conexin del paquete. Puede ser:
NEW: Creacin de nueva conexin.
ESTABLISHED: El paquete forma parte de
una conexin establecida.
RELATED: Conexin relacionada a una
ya establecida.
INVALID: Paquetes no identificados en
ninguna conexin.

limit

Ejemplo:
-m state --state NEW -j DROP
Mdulo LIMIT: Establece un nmero
lmite de veces que una regla puede
ser aceptada en un determinado
periodo de tiempo.
-m limit --limit <nmero>[/tiempo]
Ejemplo: -m limit --limit 5/s
El tiempo puede ser:
second, min, hour, day
Tambin se puede especificar un
nmero determinado de paquetes a
recibir:

multiport

-m limit --limit-burst <nPaquetes>

Mdulo MULTIPORT: Comprobacin de
varios puertos simultaneamente. Hay
que especificar el tipo de protocolo.
-m multiport --[d/s]ports <puertos>

recent

Ejemplo:
-p tcp -m multiport --dports 53,80,442
Mdulo RECENT: Permite monitorizar
conexiones recientes y limitarlas.
Se aaden IPs a una lista con la que se
comparan posteriores intentos de
conexin.
Evita ataques de fuerza bruta y DoS.
Algunos operadores que extienden a
recent son:
--set: Crea una nueva lista de Ips
--name: Renombra una lista (por
defecto es la lista DEFAULT).
--update: Comprueba si las Ips ya
existen en una lista.

13

--hitcount: Nmero mximo de

ocurrencias.
--seconds: Intervalo de tiempo en
segundos.
Tab. p5.6: Extensiones

Las condiciones pueden precederse de alguno de los siguientes operadores:

operadores
! excluye los adaptadores especificados
+ todos los adaptadores deben concordar en una regla particular
C. Acciones
Indica el destino final en el proceso de filtrado de un paquete o de una transaccin.
Indica realmente que hacer " una vez que se ha cumplido la condicin. Algunas
acciones son comunes de todas las cadenas. Otras, son especficas.
Algunas acciones bsicas son:

ACCEPT: Aceptar el paquete/transaccin.

DROP: Rechaza el paquete/transaccin.
REJECT: Rechaza el paquete/transaccin. A diferencia de DROP, notifica al
emisor que el paquete/transaccin fue descartado.
MASQUERADE: Enmascaramiento de la direccin IP origen de forma dinmica.
Esta accin es slo vlida en la tabla NAT en la cadena POSTROUTING
DNAT: Enmascaramiento de la direccin destino. Muy usada para re-enrutado
de paquetes.
SNAT: Enmascaramiento de la IP origen. De forma similar a MASQUERADE, pero
con IP fija.
LOG: Crea una entrada en el fichero de log.

Otras acciones:
DENY
REDIRECT
RETURN
MIRROR
En principio, solo se corresponde una accin por cada condicin cumplida.
5.2.2.4.

Otras opciones

-n Salida numrica de direcciones y puertos.

-v Modo verbose (imprime todos los resultados por pantalla).
..

14

5.2.3.

Poltica por defecto

Se ha mencionado con anterioridad que mediante iptables -P se puede cambiar la

poltica de aceptar (ACCEPT) o descartar (DROP) determinados paquetes. Este
comportamiento genrico, que afecta a todo tipo de trfico, puede despus ser
refinado aadiendo nuevas reglas que modifiquen el comportamiento por defecto.
Por ejemplo, se puede decidir aceptar todo el trfico inicialmente pero despus
aadir una nueva regla que impida determinado tipo de trfico, como una conexin
FTP.
En vez de descartar un paquete mediante DROP es posible realizar un REJECT, que
enva un datagrama ICMP de "puerto inalcanzable" (sta es la accin por defecto).
Emplear REJECT en lugar de DENY impide el acceso a los puertos de una forma ms
corts pero tambin permite a un posible atacante comprobar ms rpidamente qu
puertos se encuentran abiertos en nuestro sistema.
Con IPtables el administrador define una poltica por defecto para el trfico entrante o
saliente y despus, con un conjunto de reglas adicionales, habilita o bloquea
determinado trfico de red. En este proceso resulta fundamental definir bien cul es la
poltica por defecto ms conveniente.
Si lo que se desea es un sistema lo ms restringido posible entonces lo ms conveniente
es descartar cualquier tipo de trfico excepto el que se autorice explcitamente. En
este caso podemos comenzar como en el ejercicio 1, impidiendo cualquier trfico
saliente para despus aadir tan slo aquellas comunicaciones que deseamos
autorizar, como por ejemplo los accesos al servidor DNS y las conexiones ssh a un
determinado servidor. Cualquier otro trfico distinto del autorizado ser rechazado por
esa restrictiva poltica por defecto.
Sin embargo, tambin es posible que lo que deseemos sea tan slo impedir cierto tipo
de trfico que resulta "molesto" sin alterar el resto de servicios. Quiz queremos evitar
que una determinada aplicacin pueda funcionar, por ejemplo que los usuarios no
puedan imprimir en una cierta impresora remota desde ese ordenador. En este caso se
impone partir de una poltica por defecto que acepte todo tipo de trfico para
despus introducir una regla que bloquee especficamente el trfico que se dirija a
esa impresora de red.
A lo largo de esta prctica continuaremos basndonos en una poltica por defecto
basada en aceptar todo el trfico que no est explcitamente rechazado por otras
reglas (poltica permisiva).

15

5.3. Ejercicio guiado

Comprueba la lista de reglas activas
#iptables L
Como situacin inicial se nos mostrar, para la tabla filter (pues no se especifica la
tabla), que para cada una de sus tres cadenas por defecto (INPUT, FORWARD y
OUTPUT) la poltica a seguir es aceptar todo tipo de trfico (policy ACCEPT) sin importar
ni el origen, ni el destino ni el protocolo usado. Esta configuracin, que podramos
denominar permisiva, no pone restricciones sobre el trfico de entrada (INPUT) o de
salida (OUTPUT) ni tampoco sobre el posible trfico que atravesar nuestro ordenador
si ste actuara como un router (FORWARD).
Ejercicio 1:
a. Introducir el siguiente comando en el que se usa la opcin P
#iptables P OUTPUT DROP
b. Hacer un #ping localhost Qu ocurre?
Lo que ocurre es que esta orden modifica la poltica por defecto para todo el trfico
saliente, incluido aquel que no abandona el sistema (localhost) de modo que el
sistema se ha convertido en una especie de agujero negro en la red del que ningn
paquete puede salir. Un efecto parecido (aunque no tan drstico) se puede producir
si desconectamos el cable de red (en este caso el ping anterior seguira funcionando
correctamente).
Ejercicio 2:
a. Devolver el equipo a su estado inicial. Teclear ahora:
#iptables P OUTPUT ACCEPT
b. Comprueba que de nuevo los servicios de red vuelven a funcionar. Ejecutar la
orden #ping localhost y observa que sucede.
En la situacin actual, que es la misma que al principio, todo el trfico puede fluir sin
restriccin. Muchas empresas colocan un cortafuegos entre su red local y la conexin
a Internet. Este dispositivo incluye algunas reglas que filtran determinados paquetes
con el fin de mejorar la seguridad de la red interna. En esta prctica podemos hacer
que nuestro ordenador rechace, de manera selectiva, determinado tipo de trfico.
Para ello vamos a necesitar reglas un poco ms finas que la empleada en el primer
ejercicio.
Ejercicio 3:
a. Vamos a bloquear el trfico local, es decir, el que se produce en el dispositivo
lo. Para ello tecleamos la siguiente orden:
#iptables A INPUT i lo j DROP
b. Seguidamente verificamos si tiene el efecto deseado tecleando ping localhost
Obtenemos respuesta? Prueba a hacer ping www.dte.us.es Funciona?
c. Para poder restablecer el trfico local solo hay que eliminar la regla anterior
tecleando:

16

#iptables D INPUT 1
En este ejercicio hemos visto como, mediante el parmetro i, podemos especificar un
dispositivo de red (puedes ejecutar ifconfig para ver la lista de dispositivos de red y su
configuracin actual), y con j podemos especificar qu hacer con el trfico que
coincida con esa regla.
El dispositivo "lo" no es en realidad una tarjeta de red sino la representacin de las
comunicaciones internas mediante la direccin de loopback 127.0.0.1. En el ejemplo
hemos determinado que todo el trfico que se reciba (INPUT) por el dispositivo lo tiene
que descartarse (DROP). Pero para que muchas reglas sean tiles no basta poder
especificar el dispositivo sino que es necesario poder afinar indicando qu protocolo
y/o puertos definen una regla en particular.
Ejercicio 4:
a. Comprueba que se puede acceder mediante SSH a un equipo que tenga este
servicio levantado y establece una conexin utilizando tu usuario y contrasea.
#ssh usuario@host_remoto
b. Abre otra terminal en tu ordenador, y en ella teclea:
#iptables A INPUT p tcp --sport 22 j DROP
c. Ahora vuelve a la ventana de tu conexin SSH y teclea lo que sea. Qu
sucede? Por qu?
d. Vuelve a la segunda Terminal y teclea:
#iptables D INPUT 1
Qu sucede? Aun sigues conectado por SSH al host remoto?
En este ejemplo hemos creado una regla que no especifica el dispositivo de red sino el
protocolo (TCP) y tambin el puerto origen de los segmentos (--sport 22). En una
conexin SSH los paquetes que vienen del servidor SSH tienen como puerto origen el 22
que es el puerto en el que se ofrece el servicio SSH.
De modo anlogo es posible aplicar esta misma estrategia para bloquear el acceso a
cualquier otro servicio. No obstante, las reglas se pueden aplicar tanto al trfico
entrante como al saliente, o bien a ambos. En el ejercicio anterior se bloqueaba el
trfico SSH entrante (INPUT). Si has tardado ms de un minuto entre el paso 2 y el paso
4 del ejercicio es posible que la conexin SSH se haya interrumpido. En ese caso lo ms
conveniente es que lo vuelvas a repetir intentando ser algo ms rpido (lo que
permitir que la conexin no se interrumpa y obtengas un resultado diferente).
Tambin es posible crear reglas que atiendan a las direcciones de los paquetes.
Ejercicio 5:
a. Abre un navegador y carga la pgina www.dte.us.es
b. Ahora en una ventana de Terminal teclea:
#iptables A OUTPUT p tcp d www.dte.us.es --dport 80 j DROP
c.

Intenta recargar la pgina en el navegador. Qu ocurre?

17

d. Prueba a visitar otra pgina. Funciona?

Como puedes observar, en este ejercicio hemos creado una regla que descarta el
trfico TCP saliente destinado al servidor www.dte.us.es y destinado al puerto 80 (HTTP).
Esta regla no afecta al trfico similar enviado a cualquier otro servidor. Con esta regla
slo se impide el acceso al servidor web principal del DTE. Es posible crear un conjunto
de reglas similares para poder impedir el acceso a una lista de distintos servidores web.
Recuerda que a menos que borres esta regla, su efecto perdurar hasta que el equipo
sea reiniciado.

Registro de sucesos
La funcionalidad de IPtables no slo permite especificar reglas para descartar
paquetes (como hemos visto en varios de los ejemplos). Con una poltica por defecto
de descartar paquetes (DROP) las reglas deberan ser especificadas para aceptar
determinados tipos de trfico. Pero adems de estas funciones las reglas pueden
producir acciones de registro que se anotarn en el registro de sucesos del sistema (en
el archivo /var/log/messages).
Para crear reglas que generen una entrada en el registro cuando coincida con la
regla de un paquete se usar la opcin j LOG. Estas reglas no determinan si el
paquete se acepta o se rechaza, por que se aplicar la accin que corresponda
como si esta regla de registro no existiera.
El inters de poder registrar determinados sucesos asociados con el trfico de red
depende de las situaciones que se estn considerando. Puede tener un efecto
informativo para el administrador sobre multitud de datos que pudieran estar
registrados en otros lugares o no. Por ejemplo, si deseamos conocer cuntas personas
se conectan cada da a nuestro servidor FTP es muy posible que el programa servidor
disponga de un detallado archivo de registro con esa informacin, pero si se trata de
un servidor muy elemental podra no generar tipo alguno de informacin de registro.
Vamos a suponer que nos encontramos en este segundo caso y que nos piden
determinar cuntos clientes se conectan cada da a un servidor.
Lo primero que necesitamos es determinar que condicin consideramos como vlida
para establecer que ha llegado un nuevo cliente. La ms sencilla (aunque no
necesariamente la ms correcta) es considerar que cada nueva conexin al puerto 21
de nuestro servidor es un nuevo cliente.
Ejercicio 6:
a. Crea la regla que realizar el registro:
#iptables A INPUT p tcp --dport 22 j LOG
b. Ahora vamos a acceder al servidor FTP local. Teclea: #ftp localhost Qu
ocurre?
c. Es posible que te hayas dado cuenta de que en tu equipo no hay servidor FTP.
No importa. Ahora teclea dmesg y analiza la ltima lnea que aparece. Qu
ves? Sabras interpretarla?
Con la regla del apartado 6.a se produce el registro de cada paquete que llega a tu
equipo y va destinado al servidor FTP (incluso aunque no tengas servidor FTP). Sin
embargo existe un serio problema que no resulta aparente de momento, gracias a
que no dispones de servidor FTP local. El problema reside en que esa regla de registro
se cumple para cada segmento FTP recibido de cada conexin. Eso quiere decir que
un mismo cliente puede generar miles de entradas en una misma conexin. Llenar un

18

archivo de registro con muchos datos poco significativos es una muy mala idea. Para
realizar un registro en condiciones se necesita que slo se registre una vez a cada
cliente. Una forma de hacer esto es considerar slo el segmento del comienzo de la
conexin, que por tanto tiene el flag SYN activo.
Ejercicio 7:
a. Comencemos anulando la regla anterior.
b. Ahora crearemos una regla de registro que realmente si detecta las peticiones
de conexin al puerto 21. Para ello teclearemos:
#iptables A INPUT p tcp --dport --tcp-flags ALL SYN j LOG
c.

Si ahora intentamos conectarnos al servidor FTP (que no tenemos)

observaremos con dmesg un resultado similar al del ejercicio anterior.

Puede parecer que hemos repetido lo mismo que el ejercicio 6 pero no es as. Ahora la
regla de registro presta atencin al campo de "flags" de la cabecera TCP, se analizan
todos los bits de la cabecera (por eso el valor ALL) y se registran todos los segmentos
recibidos que tengan el bit SYN activado.

Modificando direcciones y/o puertos de destino (NAT)

En el siguiente ejercicio vamos a crear una regla para que todos los segmentos TCP
afectados cambien su direccin de destino.
Ejercicio 8:
a. Abre el navegador y visita la pagina www.dte.us.es
b. Teclea la siguiente regla:
#iptables t nat A OUTPUT p tcp d 150.214.141.196 --dport 80
j DNAT --to 150.214.188.143:80
c. Vuelve a cargar la pgina web del apartado 1. Qu ocurre?
d. Elimina la regla del paso 8.b
Si repasamos la orden creada podemos ver que ahora la regla j no es ni LOG ni DROP
como en casos anteriores sino DNAT. Esta regla permite reescribir las direcciones y/o los
puertos de destino de un segmento. En este caso todos los segmentos TCP dirigidos a
servidores web dentro del DTE (subnet 150.214.141.196) sern redirigidos al servidor web
de la direccin 158.42.250.41 (portal del LSI).
Se puede observar en esta regla que se especifica una nueva tabla (-t nat) mientras
que hasta ahora la tabla usada era la tabla por defecto (-t filter), la cual no era
necesario detallar en la lnea de rdenes. Esta nueva tabla permite realizar
operaciones de traduccin de puertos y direcciones (NATP) como las que realiza uno
de los routers que proporcionan con las conexiones de cable o ADSL.

Cambios en otros campos (MANGLE)

Con diferentes propsitos es posible modificar los valores de otros campos en nuestro
trfico. Uno de los candidatos es el campo de tipo de servicio (TOS) de la cabecera IP.
Personalizado para una determinada aplicacin es posible adecuar el valor de este
campo a las necesidades de la misma. Incluso aunque su valor no sea respetado ms

19

all de nuestro sistema, puede ser interesante para que distintos flujos de trfico
simultneo se puedan tratar adecuadamente segn nuestra eleccin.
Para el ltimo ejemplo vamos a escoger algo ms sencillo: el campo de tiempo de
vida (TTL) de la cabecera IP, con el que se especifica el nmero mximo de saltos
(entre routers) permitidos para alcanzar un destino.
El valor utilizado por nuestro ordenador para este campo viene prefijado en la
configuracin del sistema operativo y, aunque se puede modificar la mayora de
administradores no tienen razones para hacerlo. Sin embargo, no todos los sistemas
operativos utilizan el mismo valor, y si nos fijamos, es posible que veamos
computadores con distintos valores iniciales para el TTL (podemos usar la orden ping
para determinarlo).
Supongamos que deseamos modificar el valor del campo TTL para cierto tipo de
trfico (no para todos nuestros paquetes). Es posible crear una regla con IPtables que
realice ese cambio selectivo.
Ejercicio 9:
a. Cmo sabes el valor TTL para llegar a un cierto destino?
#traceroute destino
b. Aade la siguiente regla:
#iptables t mangle A POSTROUTING j TTL --ttl-set 5
c.

Comprueba si puedes acceder a www.eii.us.es www.dte.us.es

Con ese valor tan slo se pueden realizar cuatro saltos antes de que el datagrama sea
descartado. Esto limita enormemente el nmero de redes que se pueden visitar. Un
valor TTL=1 impedira atravesar un nico router y solo permitira la comunicacin directa
con otros ordenadores en la misma subred.
d. Comprueba si puedes acceder a www.google.com

20

5.4. Ejercicios

Listado de reglas activas para cada tabla

Vaciar de reglas una cadena (ej. INPUT) en la tabla mangle

Filtro de mensajes ICMP de origen local

Filtrar todo el trafico ICMP de entrada

Permitir que la interfaz eth0 pueda enviar paquetes ICMP

Filtro de sesiones Telnet en una determinada interfaz

Permite el reenvo de paquetes a travs del router desde direcciones locales

Junto con la regla anterior, enmascara todo el trfico interno para compartir la
conexin a Internet

Acepta el trfico entrante al puerto 80 y permite su reenvo

21

Denegar la conexin al puerto 22, protocolo tcp, de la interfaz eth1

Cambia la direccin destino para las conexiones al puerto 80 recibidas en la

interfaz ppp0 y redirige los datagramas al puerto 80 del equipo 192.168.0.100

Rechazar la conexin al puerto 65000, protocolo UDP, de la interfaz eth0, desde

los computadores de la red local del tipo 192.168.0.0/24

Denegar el trfico desde la eth0 a la eth1 (FORWARD)

Denegar el trfico desde la eth0 a la eth1 del protocolo tcp

Denegar el trfico hacia el puerto 25, en la interfaz eth1 a los paquetes

marcados con las banderas SYN y ACK a la vez.

Nota: La opcin --tcp-flags requiere dos argumentos. El primero, los flags a examinar, y
el segundo, los flags que deben estar en 1. En este caso, IPTables examina todos los
flags, pero obliga que SYN y ACK deban estar en 1 para realizar la accin asociada.

22

5.5. Caso prctico

En base a la red desplegada y configurada en la prctica 1, se pretende
configurar una red sencilla en la que tengamos un equipo intermedio que realice las
labores de router de filtrado de paquetes usando IPtables. Este equipo ser vm1, el
cual, hasta el momento, realiza las labores de Gateway entre la red interna de
mquinas virtuales, y la red de laboratorio.
192.168.0.2

mv2

Red de mquinas
virtuales

mv1
Gateway de red
de mquinas
virtuales
+
Firewall
10.1.15.199

192.168.0.0/24

192.168.0.1

Red DTE

mv3
10.1.12.0/22
INTERNET
192.168.0.3

10.1.15.200

Mquina fsica

Fig. p5.6: Red de prcticas

1. Establecer en el firewall la poltica de descartar todo el trfico procedente de la red

interna que no haya sido explcitamente aceptado por una regla definida.
2. Crear una regla en el firewall para que los equipos de la red interna puedan salir a
Internet y tener trfico WEB a pesar de la poltica definida.
3. Crear una regla en el firewall para evitar que la mquina con IP 192.168.0.2 pueda
conectar a un servidor SSH levantado en la mquina anfitrin.
4. Supongamos que instalamos un servicio SSH en nuestro firewall para que pueda ser
accedido desde el exterior. Crear la regla IPtables necesaria para que se permitan
estas conexiones desde el exterior pero no desde la red interna.
5. En el apartado anterior permitimos el acceso por SSH desde la red externa. Esto
puede ser inseguro. Un intruso que descubra que en esa mquina est levantado el
servicio SSH en el puerto 22 puede intentar acceder a ella por medio de un ataque de
fuerza bruta. Aadir las reglas necesarias en la mquina que implementa el filtrado de
paquetes para bloquear un posible ataque de fuerza bruta contra el servicio SSH. Se
recomienda bloquear el acceso al puerto 22 desde un equipo que intenta acceder si
en 1 minuto se han registrado ms de 8 intentos de login fallidos.
6. Realizar un ataque de fuerza bruta desde el exterior de la red de mquinas virtuales
(p.ej, desde la mquina anfitrin) con la herramienta medusa contra el servicio SSH de
la mquina mv1.
7. Evitar que los equipos de la red interna usen GTalk. Eliminar previamente las reglas
creadas anteriormente y establecer una poltica ACCEPT en las cadenas de la tabla
filter.

23