Integração de IPT ABLES e Snort para Segurança de Rede

Vista previa del material en texto

INSTITUTO TECNOLOGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY 
INTEGRACIÓN DE IPT ABLES Y SNORT 
TESIS QUE PARA OPTAR EL GRADO DE 
MAESTRO EN CIENCIAS COMPUTACIONALES 
PRESENTA 
JORGE HERRERÍAS GUERRERO 
Asesor: Dr. ROBERTO GóMEZ CÁRDENAS 
Comité de tesis: Dr. Nora Erika Sánchez Velázquez 
Dr. Felipe Rolando Menchaca 
Atizapán de Zaragoza, Edo. Méx., Diciembre de 2003. 
2 
CONTENIDO 
INTRODUCCION ......................................................................................................................... 4 
1 CORTAFUEGOS .................................................................................................................. 7 
1.1 CONCEPTOS TEÓRICOS ............................................................................................. 8 
1.2 CARACTERÍSTICAS DE DISEÑO .... : .......................................................................... 9 
1.3 COMPONENTES DE UN CORTAFUEGOS .............................................................. 11 
1.3.1 FILTRADO DE PAQUETES ................................................................................ 11 
1.3.2 PROXY DE APLICACIÓN .................................................................................. 13 
1.3.3 MONITOREO DE LA ACTIVIDAD ................................................................... 13 
1.4 ARQUITECTURAS DE CORTAFUEGOS ................................................................. 14 
1.4.1 CORTAFUEGOS DE FILTRADO DE PAQUETES ........................................... 14 
1.4.2 DUAL-HOMED HOST ......................................................................................... 15 
1.4.3 SCREENED HOST ............................................................................................... 15 
1.4.4 SCREENED SUBNET (DMZ) ............................................................................. 17 
1.4.5 OTRAS ARQUITECTURAS ................................................................................ 18 
1.5 IPTABLES .................................................................................................................... 19 
1.5.1 ¿POR QUÉ FILTRAR PAQUETES? ................................................................... 19 
1.5.2 COMANDO IPTABLES ....................................................................................... 21 
1.5.2.1 Tablas ................................................................................................................ 21 
1.5.2.2 Estructura ........................................................................................................... 22 
1.5.2.3 Comandos .......................................................................................................... 22 
1.5.2.4 Parámetros ......................................................................................................... 24 
1.5.2.5 Opciones de identificación de paquetes ............................................................. 25 
1.5.2.6 Módulos con opciones de selección adicionales ............................................... 27 
1.5.2.7 Opciones del objetivo ........................................................................................ 28 
1.5.2.8 Opciones de listado ............................................................................................ 30 
1.5.3 GUARDAR INFORMACIÓN DE IPT ABLES .................................................... 30 
1.5.4 MEJORAS SOBRE IPCHAINS ............................................................................ 31 
2 SISTEMAS DE DETECCIÓN DE INTRUSOS ............................................................... 33 
2.1 CLASIFICACIÓN DE LOS IDS .................................................................................. 34 
2.2 REQUISITOS DE UN IDS ........................................................................................... 36 
2.3 IDS BASADOS EN MÁQUINA .................................................................................. 37 
3 
2.4 IDS BASADOS EN RED ...................................................................... ... .... ... ........... 39 
2.5 DETECCIÓN DE ANOMALÍAS .............................................................................. .42 
2.6 DETECCIÓN DE USOS INDEBIDOS .............. ...................... ....... ........... ....... ... ..... .44 
2.7 SNORT ...................................................................................................................... 46 
2.7.1 FORMAS DE USO ............................................................................................ 47 
2.7.1.1 Modo sniffer ................................................................................................... 49 
2.7.1.2 Modo Registro de paquetes ............................................................................. 50 
2.7.1.3 Modo NIDS .................................................................................................... 51 
2.7.2 REGLAS ............................................................................................................ 53 
. 
3 ™PLEMENTACION ..................................................................................................... 56 
3.1 ARQillTECTURA ..................................................................................................... 57 
3.2 MODELO DE DATOS IDMEF ................................................................................. 57 
3.2.1 LA CLASE IDMEF-MESSAGE ......................................................................... 60 
3.2.2 LA CLASE ALERT ........................................................................................... 60 
3.2.2.1 La Clase ToolAlert ......................................................................................... 62 
3.2.2.2 La Clase CorrelationAlert ............................................................................... 63 
3.2.2.3 La Clase OverflowAlert .............................................. .................................... 64 
3.2.3 LA CLASE HEARTBEAT ..................................... ....... ....... ......................... ..... 65 
3.2.4 LAS CLASES PRINCIPALES ........................................................................... 66 
3.2.4.1 La Clase Analyzer. ............................................. .............. .......................... ..... 66 
3.2.4.2 La Clase Classification ................................................................................... 68 
3.2.4.3 La Clase Source ....................................................................... .... ....... ............ 69 
3.2.4.4 La Clase Target ......................................................................................... ...... 70 
3.2.4.5 La Clase Assessment ............................................... ....................................... 71 
3. 2. 4. 6 La Clase AdditionalData ........................................................ .... ... ....... ... ........ 72 
3.3 IMPLEMENTACIÓNDELIDMEF: LIBIDMEF ....................................................... 72 
3.4 PLUG-IN ................................................................................................................... 75 
3. 5 ESTRATEGIA DE RESPUESTA .............................................................................. 78 
CONCLUSIONES ................................................................................................................... 83 
REFERENCIAS ....................................................................................................................... 85 
4 
INTRODUCCIÓN 
La seguridad en las redes computacionales está llegando a ser cada vez más importante en la 
medida en que la gente pasa más tiempo conectada. Poner en riesgo la seguridad de las redes es, 
con frecuencia, mucho más fácil y común de lo que nos podríamos imaginar. ¿Puede un intruso 
leer o escribir archivos o ejecutar programas que podrían causar daño? ¿Puede borrar datos 
críticos? Este conjunto de acciones,entre muchas otras conforma lo que llamaremos riesgo, es 
decir la posibilidad de que un intruso pueda tener éxito en el intento de acceder a nuestro sistema. 
Hay que tener en cuenta que ningún sistema de computadoras puede ser completamente seguro. 
Lo más que es posible hacerse es que le sea más dificil a alguien acceder al sistema sin permiso. 
De entre las varias herramientas que podemos encontrar para lograr lo anterior, podemos utilizar 
dos: los cortafuegos1 y los sistemas de detección de intrusos2. 
Los cortafuegos son un medio de controlar a qué información se le permite entrar y salir de la red 
local. Normalmente, la computadora donde se encuentra el cortafuegos está conectada a Internet 
y a la red local, y el único acceso desde la red local a Internet es a través del cortafuegos. De este 
modo, el cortafuegos puede controlar lo que pasa en una u otra dirección entre Internet y la red 
interna. 
El núcleo del sistema operativo Linux contiene utilidades avanzadas para la filtración de 
paquetes, es decir, utilidades propias de un cortafuegos convencional. Las versiones de los 
núcleos anteriores al 2.4 tenían la posibilidad de manipular paquetes usando ipchains que a su 
vez usaba listas de reglas que se aplicaban a los paquetes en cada paso del proceso de filtrado. La 
presentación del núcleo 2.4 trajo consigo iptables, que es parecido a ipchains pero con mejoras en 
el funcionamiento y en el control disponible a la hora de filtrar paquetes. 
Sin embargo, en muchos casos los controles de los cortafuegos no pueden protegemos ante un 
ataque. Por poner un ejemplo sencillo, pensemos en un cortafuegos donde hemos implementado 
I Se usará cortafuegos como traducción dcjirewa/1. 
~ En adelante nos referiremos a los Sistemas de Detección de Intrusos con sus siglas en inglés IDS. 
5 
una política que deje acceder al puerto 80 de nuestros servidores Web desde cualquier máquina 
de Internet~ ese cortafuegos sólo comprobará si el puerto destino de una trama es el que hemos 
decidido para el servicio HTIP, pero seguramente no tendrá en cuenta si ese tráfico representa un 
ataque o una violación de nuestra política de seguridad. Esto significa que no detendrá a un pirata 
que trate de acceder al archivo de contraseñas de una máquina aprovechando un error del servidor 
Web. A los sistemas utilizados para detectar las intrusiones o los intentos de intrusión se les 
denomina sistemas de detección de intrusos. Llamaremos intrusión a un conjunto de acciones que 
intentan poner en riesgo la integridad, la confidencialidad o la disponibilidad de un recurso. 
Debemos esperar que en cualquier momento alguien consiga romper la seguridad de nuestro 
entorno informático, y por tanto hemos de ser capaces de detectar ese problema tan pronto como 
sea posible (incluso antes de que se produzca, cuando el potencial atacante se limite a probar 
suerte contra nuestras máquinas). Aunque nadie haya conseguido violar nuestras políticas de 
seguridad, es vital contar con un sistema de detección de intrusos, ya que éste se encargará de 
mostramos todos los intentos que una multitud de piratas hace para penetrar en nuestro entorno, 
lo que no nos dejará caer en ninguna falsa sensación de seguridad. Si somos conscientes de que a 
diario hay gente que trata de romper nuestros sistemas, no cometeremos el error de pensar que 
nuestras máquinas están seguras porque nadie sabe de su existencia o porque no son interesantes 
para un pirata. 
Snort es un sistema de detección de intrusos con la licencia de software libre capaz de realizar 
análisis de tráfico en tiempo real y de registrar de paquetes en redes IP. Snort también puede 
realizar análisis de protocolos, búsqueda de contenidos y puede ser usado para detectar una gran 
variedad de ataques. Existen tres formas en las que Snort puede ser configurado: sniffer3, registro 
de paquetes y detector de intrusos en red. Este último es el más complejo y configurable, ya que 
habilita a la herramienta para el análisis de tráfico de red y, lo que es más importante, para el 
reconocimiento de cualquier intento de intrusión. 
A pesar de todas las ventajas que las herramientas descritas anteriormente presentan, éstas no 
garantizan la seguridad del sistema contra distintos tipos de ataques, por lo que en un momento 
dado lo más valioso de la organización, la información, puede estar en riesgo. Es por esta razón, 
que este trabajo tiene por objetivo el diseño de un protocolo de comunicación entre ambas 
herramientas, lo que permitirá conformar un sistema de respuesta automática ante diversos tipos 
de ataques. 
La comunicación entre ambas herramientas se llevará a cabo bajo el formato de intercambio de 
mensajes de detección de intrusiones (IDMEF) propuesto por el Grupo de Trabajo en Detección 
de Intrusiones (IDWG). Dicho modelo es una representación orientada a objetos de los datos de 
las alertas y se encuentra implementado en XML debido a la flexibilidad que provee, la que lo 
hace una buena elección para los fines requeridos: un documento que pueda variar de acuerdo a 
las condiciones presentadas, dependiendo de factores tales como el tipo de ataque, el tipo de 
herramienta usada y la fuente y objetivo del mismo entre otros. 
'Programa que monitorca la información que circula por la red con el objetivo de capturar información ajena 
6 
Las alertas generadas con el formato IDMEF XML serán escuchadas en tiempo real por un 
agente, el cual usará la información proporcionada para reconfigurar el cortafuegos y, de esta 
manera, frenar el ataque o intento de intrusión. 
El presente trabajo se encuentra organiz.ado de la siguiente forma: en el primer capítulo se 
introduce al lector a la teoría de cortafuegos y posteriormente profundizamos en el cortafuegos de 
Linux iptables; en el segundo capítulo hablamos acerca de los sistemas de detección de intrusos 
para dar paso a uno de los IDS más importantes, Snort, y por último, el tercer capítulo trata los 
asuntos relacionados con la implementación del protocolo de comunicación entre las 
herramientas referidas en los capítulos anteriores. Al final del documento se presentan las 
conclusiones y una propuesta para un trabajo futuro en la misma línea. 
7 
1 CORTAFUEGOS 
Un cortafuegos es un sistema o grupo de sistemas que hace cumplir una política de control de 
acceso entre dos redes. De una forma más clara, podemos definir un cortafuegos como cualquier 
sistema (desde un simple ruteador4 hasta varias redes en serie) utilizado para separar, en cuanto a 
seguridad se refiere, una máquina o subred del resto, protegiéndola así de servicios y protocolos 
que desde el exterior puedan suponer una amenaz.a a la seguridad. El espacio protegido, 
denominado perímetro de seguridad, suele ser propiedad de la misma organización, y la 
protección se realiza contra una red externa, no confiable, llamada zona de riesgo. 
A / B ( :~ ~ 
~ 
-
-
i i - A :&'.:: 
IN et l.AN - IN et lAN - ---
( • ~ \ .. - --- ~ • - -/ ;.__ • 
e -.... 
• =~ 
IN et - - LAN 
- - ---
• 
--
Figura 1.1 (a) Aislamiento. (b) Conexión total. (c) Cortafuegos entre la zona de riesgo y el 
perímetro de seguridad. 
I Dispositivo de conexión y distribución de datos en una red encargado de dirigir el tráfico entre redes_ 
8 
Evidentemente, la forma de aislamiento más efectiva para cualquier política de seguridad consiste 
en el aislamiento físico, es decir, no tener conectada la máquina o la subred a otros equipos o a 
Internet (figura 1.1 (a)). Sin embargo, en la mayoría de organiz.aciones, los usuarios necesitan 
compartir información con otras personas situadas en muchas ocasiones a miles de kilómetros de 
distancia, con lo que no es posible un aislamiento total. El punto opuesto consistiría en una 
conectividad completa con la red (figura 1.1 (b )), lo que desde el punto de vista de la seguridad es 
muy problemático: cualquiera, desde cualquier parte del mundo, puede potencialmente tener 
acceso a nuestros recursos. Un término medio entre ambas aproximacionesconsiste en 
implementar cierta separación lógica mediante un cortafuegos (figura 1.1 (c)). 
1.1 CONCEPTOS TEÓRICOS 
Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones de partes o 
características de funcionamiento del mismo; por máquina o hosr bastión se conoce a un sistema 
especialmente asegurado, pero en principio vulnerable a todo tipo de ataques por estar abierto a 
Internet, que tiene como función ser el punto de contacto de los usuarios de la red interna de una 
organización con otro tipo de redes. El host bastión filtra tráfico de entrada y salida, y también 
esconde la configuración de la red hacia fuera. 
Por filtrado de paquetes entendemos la acción de denegar o permitir el flujo de tramas entre dos 
redes (por ejemplo la interna, protegida con el cortafuegos, y el resto de Internet) de acuerdo con 
unas normas predefinidas; aunque el filtro más elemental puede ser un simple ruteador, 
trabajando en el nivel de red del modelo de referencia OSI, esta actividad puede realizarse 
además en un puente o en una máquina individual. El filtrado también se conoce como screening, 
y a los dispositivos que lo implementan se les denomina chokes; el choke puede ser la máquina 
bastión o un elemento diferente. 
Un proxy es un programa (trabajando en el nivel de aplicación de OSI) que permite o niega el 
acceso a una aplicación determinada entre dos redes. Los clientes proxy se comunican sólo con 
los servidores proxy, que autorizan las peticiones y las envían a los servidores reales o las 
deniegan y las devuelven a quien las solicitó. 
Físicamente, en casi todos los cortafuegos existen al menos un choke y una máquina bastión, 
aunque también se considera cortafuegos a un simple ruteador filtrando paquetes, es decir, 
actuando como choke; desde el punto de vista lógico, en el cortafuegos suelen existir servidores 
proxy para las aplicaciones que han de atravesar el sistema, y que se sitúan habitualmente en el 
host bastión También se implementa en el choke un mecanismo de filtrado de paquetes, y en 
" Cualquier computadora conectada a la red y que dispone de un número IP y un nombre definido. es decir. cualquier 
computadora que puede enviar o recibir información a otra computadorn. 
9 
alguno de los dos elementos se suele situar otro mecanismo para poder monitorear y detectar la 
actividad sospechosa. 
Los cortafuegos son cada vez más necesarios en nuestras redes, pero todos los expertos 
recomiendan que no se usen en lugar de otras herramientas, sino junto a ellas; cualquier 
cortafuegos, desde el más simple al más avanzado, presenta dos gravísimos problemas de 
seguridad: por un lado, centraliz.an todas las medidas en un único sistema, de forma que si éste se 
ve puesto en alguna clase de riesgo y el resto de nuestra red no está lo suficientemente protegido 
el atacante consigue amenaz.ar a toda la subred simplemente poniendo en jaque a una máquina. El 
segundo problema relacionado con éste es la falsa sensación de seguridad que un cortafuegos 
proporciona: generalmente un administrador que no disponga de este elemento va a preocuparse 
de la integridad de todas y cada una de sus máquinas, pero en el momento en que instala el 
cortafuegos y lo configura asume que toda su red es segura, · por lo que se suele descuidar 
enormemente la seguridad de los equipos de la red interna. Esto, como acabamos de comentar, es 
un grave error ya que en el momento que un pirata acceda a nuestro cortafuegos automáticamente 
va a tener la posibilidad de controlar toda nuestra red. 
Además, un cortafuegos evidentemente no protege contra ataques que no pasan por él: esto 
incluye todo tipo de ataques internos dentro del perímetro de seguridad,· pero también otros 
factores que a priori no deberían suponer un problema. El típico ejemplo de estos últimos son los 
usuarios que instalan sin permiso, sin conocimiento del administrador de la red, y muchas veces 
sin pensar en sus consecuencias, un simple módem6 en sus estaciones de trabajo; esto, tan 
habitual en muchas organizaciones, supone la violación y la ruptura total del perímetro de 
seguridad, ya que posibilita accesos a la red no controlados por el cortafuegos. Otro problema de 
sentido común es la reconfiguración de los sistemas al pasarlos de una zona a otra con diferente 
nivel de seguridad, por ejemplo al mover un equipo que se encuentra en el área protegida a la 
DMZ (zona desprotegida). Este acto, que en ocasiones no implica ni tan siquiera el movimiento 
fisico del equipo, sino simplemente conectarlo en una toma de red diferente, puede ocasionar 
graves problemas de seguridad en nuestra organización, por lo que cada vez que un cambio de 
este estilo se produzca no sólo es necesaria la reconfiguración del sistema, sino la revisión de 
todas las políticas de seguridad aplicadas a esa máquina. 
1.2 CARACTERÍSTICAS DE DISEÑO 
Existen tres decisiones básicas en el diseño o la configuración de un cortafuegos; la primera de 
ellas, la más importante, hace referencia a la política de seguridad de la organización propietaria 
del cortafuegos: evidentemente, la configuración y el nivel de seguridad potencial será distinto en 
una empresa que utilice un cortafuegos para bloquear todo el tráfico externo hacia el dominio de 
su propiedad (excepto, quizás, las consultas a su página Web) frente a otra donde sólo se intente 
evitar que los usuarios internos pierdan el tiempo en la red, bloqueando por ejemplo todos los 
h Dispositivo de comunicaciones capaz de hacer \llla conexión a Internet a través de la red telefónica convencional. 
10 
servicios de salida al exterior excepto el correo electrónico. Sobre esta decisión influyen, aparte 
de motivos de seguridad, motivos administrativos de cada organismo. 
La segunda decisión de diseño a tener en cuenta es el nivel de monitoreo, redundancia y control 
deseado en la organización; una vez definida la política a seguir, hay que definir cómo 
implementarla en el cortafuegos indicando básicamente qué se va a permitir y qué se va a 
denegar. Para esto existen dos aproximaciones generales: o bien se adopta una postura restrictiva 
( denegamos todo lo que explícitamente no se permita) o bien una permisiva (permitimos todo 
excepto lo explícitamente negado); evidentemente es la primera la más recomendable de cara a la 
seguridad, pero no siempre es aplicable debido a factores no técnicos sino humanos ( esto es, los 
usuarios y sus protestas por no poder ejecutar tal o cual aplicación a través del cortafuegos). 
Por último, la tercera decisión a la hora de instalar un sistema de cortafuegos es meramente 
económica: en función del valor estimado de lo que deseemos proteger, debemos gastar más o 
menos dinero, o no gastar nada. Un cortafuegos puede no entrañar gastos extras para la 
organización, o suponer un gran desembolso: seguramente un departamento o laboratorio con 
pocos equipos en su interior puede utilizar un computadora con Linux, Solaris o FreeBSD a 
modo de cortafuegos, sin invertir nada en él, pero esta aproximación evidentemente no funciona 
cuando el sistema a proteger es una red de tamaño considerable; en este caso se pueden utilizar 
sistemas propietarios, que suelen ser caros, o aprovechar los ruteadores de salida de la red, algo 
más barato pero que requiere más tiempo de configuración que los cortafuegos sobre el sistema 
operativo Unix en una computadora de los que hemos hablado antes. De cualquier forma, no es 
recomendable a la hora de evaluar el dinero a invertir en el cortafuegos fijarse sólo en el costo de 
su instalación y puesta a punto, sino también en el de su mantenimiento. 
Estas decisiones, aunque concernientes al diseño, eran básicamente políticas; la primera decisión 
técnica a la que nos vamos a enfrentar a la hora de instalar un cortafuegos es elemental: ¿dónde lo 
situamos para que cumpla eficientemente su cometido? Evidentemente, si aprovechamos como 
cortafuegos un equipo ya existente en la red, por ejemplo un ruteador, no tenemos muchas 
posibilidadesde elección: con toda seguridad hemos de dejarlo donde ya está; si por el contrario 
utilizamos una máquina Unix con un cortafuegos implementado en ella, tenemos varias 
posibilidades para situarla con respecto a la red externa y a la interna. Sin importar dónde 
situemos al sistema hemos de recordar siempre que los equipos que queden fuera del cortafuegos, 
en la zona de riesgo, serán igual de vulnerables que antes de instalar el cortafuegos; por eso es 
posible que si por obligación hemos tenido que instalar un cortafuegos en un punto que no 
protege completamente nuestra red, pensemos en añadir cortafuegos internos dentro de la misma, 
aumentando así la seguridad de las partes más importantes. 
Una vez que hemos decidido dónde situar nuestro cortafuegos se debe elegir qué elemento o 
elementos fisicos utilizar como bastión; para tomar esta decisión existen dos principios básicos: 
mínima complejidad y máxima seguridad_. Cuanto más simple sea el host bastión, cuanto menos 
servicios ofrezca, más fácil será su mantenimiento y por tanto mayor su seguridad; mantener esta 
máquina especialmente asegurada es algo vital para que el cortafuegos funcione correctamente, 
ya que va a soportar por sí sola todos los ataques que se efectúen contra nuestra re_d al ser 
elemento más accesible de ésta. Si la seguridad de la máquina bastión se ve puesta en nesgo, la 
11 
amenaza se traslada inmediatamente a todos los equipos dentro del perímetro de seguridad. Suele 
ser una buena opción elegir como máquina bastión un servidor corriendo alguna de las versiones 
de Unix, ya que aparte de la seguridad del sistema operativo tenemos la ventaja de que la mayor 
parte de aplicaciones de cortafuegos han sido desarrolladas y comprobadas desde hace años sobre 
dicha plataforma. 
Una vez que ya hemos decidido qué utilizar como cortafuegos y dónde situarlo; hemos de 
implementar sobre él los mecanismos necesarios para hacer cumplir nuestra política de seguridad. 
En todo cortafuegos existen tres componentes básicos para los que debemos implementar 
mecanismos: el filtrado de paquetes, el prory de aplicación y el monitorec> y detección de 
actividad sospechosa. 
1.3 COMPONENTES DE UN CORTAFUEGOS 
1.3.1 FILTRADO DE PAQUETES 
Cualquier ruteador IP utiliza reglas de filtrado para reducir la carga de la red; por ejemplo, se 
descartan paquetes cuyo TfL ha llegado a cero, paquetes con un control de errores erróneos o 
simplemente tramas de broadcast7. Además de estas aplicaciones, el filtrado de paquetes se 
puede utilizar para implementar diferentes políticas de seguridad en una red; el objetivo principal 
de todas ellas suele ser evitar el acceso no autorizado entre dos redes, pero manteniendo intactos 
los accesos autorizados. Su funcionamiento es habitualmente muy simple: se analiza la cabecera 
de cada paquete, y en función de una serie de reglas establecidas de antemano la trama es 
bloqueada o se le permite seguir su camino; estas reglas suelen contemplar campos como el 
protocolo utilizado (TCP, UDP, ICMP ... ), las direcciones fuente y destino, y el puerto destino, lo 
cual ya nos dice que el cortafuegos ha de ser capaz de trabajar en los niveles de red (para 
discriminar en función de las direcciones origen y destino) y de transporte (para hacerlo en 
función de los puertos usados). Además de la información de cabecera de las tramas, algunas 
implementaciones de filtrado permiten especificar reglas basadas en la interfaz del ruteador por 
donde se ha de reenviar el paquete, y también en la interfaz por donde ha llegado hasta nosotros. 
¿Cómo se especifican tales reglas? Generalmente se expresan como una simple tabla de 
condiciones y acciones que se consulta en orden hasta encontrar una regla que permita tomar una 
decisión sobre el bloqueo o el reenvío de la trama; adicionalmente, ciertas implementaciones 
permiten indicar si el bloqueo de un paquete se notificará a la máquina origen mediante un 
mensaje ICMP. Siempre hemos de tener presente el orden de análisis de las tablas para poder 
implementar la política de seguridad de una forma correcta; cuanto más complejas sean las reglas 
y su orden de análisis, más difícil será para el administrador comprenderlas. 
- Paquete de datos enYiado a todos los nodos de una red 
12 
Por ejemplo, imaginemos una hipotética tabla de reglas de filtrado de la siguiente forma: 
Origen Destino Tipo Puerto Acción 
158.43.0.0 * * * Den y 
* 195.53.22.0 * * Den y 
158.42.0.0 * * * Allow 
* 193.22.34.0 * * Den y 
Si al cortafuegos donde está definida la política anterior llegara un paquete proveniente de una 
máquina de la red 158.43.0.0 se bloquearla su paso, sin importar el destino de la trama; de la 
misma forma, todo el tráfico hacia la red 195.53.22.0 también se detendría. Pero, ¿qué sucedería 
si llega un paquete de un sistema de la red 158.42.0.0 hacia 193.22.34.0? Una de las reglas nos 
indica que dejemos pasar todo el tráfico proveniente de 158.42.0.0, pero la siguiente nos dice que 
si el destino es 193.22.34.0 lo bloqueemos sin importar el origen. En este caso depende de 
nuestra implementación particular y el orden de análisis que siga: si se comprueban las reglas 
desde el principio, el paquete atravesaría el cortafuegos, ya que al analizar la tercera entrada se 
finalizarían las comprobaciones; si operamos al revés, el paquete se bloquearía porque leemos 
antes la última regla. Como podemos ver, ni siquiera en esta tabla sencilla las cosas son obvias, 
por lo que si extendemos el ejemplo a un cortafuegos real podemos hacemos una idea de hasta 
que punto hemos de ser cuidadosos con el orden de las entradas de nuestra tabla. 
¿Qué sucedería si, con la tabla del ejemplo anterior, llega un paquete que no cumple ninguna de 
nuestras reglas? El sentido común nos dice que por seguridad se debería bloquear, pero esto no 
siempre sucede así; diferentes implementaciones ejecutan diferentes acciones en este caso. 
Algunas deniegan el paso por defecto y otras dejan pasar este tipo de tramas. De cualquier forma, 
para evitar problemas cuando uno de estos datagramas llega al cortafuegos, lo mejor es insertar 
siempre una regla por defecto al final de nuestra lista con la acción que deseemos realizar por 
defecto; si por ejemplo deseamos bloquear el resto del tráfico que llega al cortafuegos con la 
tabla anterior, y suponiendo que las entradas se analizan en el orden habitual, podríamos añadir a 
nuestra tabla la siguiente regla: 
Origen Destino Tipo Puerto Acción 
------------------------------ ----------------------------------------
* * * * Den y 
La especificación incorrecta de estas reglas constituye uno de los problemas de seguridad 
habituales en los cortafuegos de filtrado de paquetes; no obstante, el mayor problema es que un 
sistema de filtrado de paquetes es incapaz de analizar (y por tanto verificar) datos situados por 
encima del nivel de red del modelo OSI. A esto se le añade el hecho de que si utilizamos un 
simple ruteador como filtro, las capacidades de re~ist~o de infor~~ción del mismo suelen ser 
bastante limitadas, por lo que en ocasiones es d1fic1l la detecc1on de un ataq~e; se puede 
considerar un mecanismo de prevención más que de detección. Para intentar solucionar estas Y 
13 
otras vulnerabilidades, es recomendable utilizar aplicaciones de software capaces de filtrar las 
conexiones a servicios, a las cuales se les denomina proxies de aplicación. 
1.3.2 PROXY DE APLICACIÓN 
Además del filtrado de paquetes, es habitual que los cortafuegos utilicen aplicaciones para 
reenviar o bloquear conexiones a servicios como .finger, telnet o FTP; a tales aplicaciones se les 
denomina servicios prory, mientras que a la máquina donde se ejecutan se le llama gateway. 
Los servicios proxy poseen una serie de ventajas de cara a incrementar nuestra seguridad; en 
primer lugar, permiten únicamente la utilización de servicios para los que existe un proxy, por lo 
que si en nuestra organización el gateway contiene únicamente proxies para telnet, HTTP yFTP, 
el resto de servicios no estarán disponibles para nadie. Una segunda ventaja es que en el gateway 
es posible filtrar protocolos basándose en algo más que la cabecera de las tramas, lo que hace 
posible por ejemplo tener habilitado un servicio como FTP pero con órdenes restringidas 
(podríamos bloquear todos los comandos put para que nadie pueda subir ficheros a un servidor). 
Además, los gateways permiten un grado de ocultación de la estructura de la red protegida (por 
ejemplo, el gateway es el único sistema cuyo nombre está disponible hacia el exterior), facilita la 
autenticación y la auditoria del tráfico sospechoso antes de que alcance el host destino y, quizás 
más importante, simplifica enormemente las reglas de filtrado implementadas en el ruteador (que 
como hemos dicho antes pueden convertirse en la fuente de muchos problemas de seguridad): 
sólo hemos de permitir el tráfico hacia el gateway y bloquear el resto. 
El principal inconveniente que encontramos a la hora de instalar un gateway es que cada servicio 
que deseemos ofrecer necesita su propio proxy; además se trata de un elemento que 
frecuentemente es más caro que un simple filtro de paquetes, y su rendimiento es mucho menor 
(por ejemplo, puede llegar a limitar el ancho de banda efectivo de la red). En el caso de 
protocolos cliente-servidor, como telnet, se añade la desventaja de que necesitamos dos pasos 
para conectar hacia la zona segura o hacia el resto de la red; incluso algunas implementaciones 
necesitan clientes modificados para funcionar correctamente. 
1.3.3 MONITOREO DE LA ACTIVIDAD 
Monitorear la actividad de nuestro cortafuegos es algo indispensable para la seguridad de todo el 
perímetro protegido; el monitoreo nos facilitará información sobre los intentos de ataqu~ q_u~ 
estemos sufriendo, así como la existencia de tramas que aunque no supongan un ataque a pnon s1 
que son al menos sospechosas. 
¿Qué información debemos registrar? Además de l~s regist~os ~stándar (los que i~cluyen 
estadísticas de tipos de paquetes recibidos, frecuencias, o dlfecc1ones fuente Y d~stmo) se 
recomienda auditar información de la conexión (origen y destino, nombre de usuano, hora Y 
14 
duración), intentos de uso de protocolos denegados, intentos de falsificación de dirección por 
parte de máquinas internas al perímetro de seguridad (paquetes que llegan desde la red externa 
con la dirección de un equipo interno) y tramas recibidas desde ruteadores desconocidos. 
Evidentemente, todos esos registros han de ser leídos con frecuencia, y el administrador de la red 
ha de tomar medidas si se detectan actividades sospechosas; si la cantidad de /ogs8 generada es 
considerable nos puede interesar el uso de herramientas que filtren dicha información. 
Un excelente mecanismo para incrementar mucho nuestra seguridad puede ser la sustitución de 
servicios reales en el cortafuegos por programas trampa o honeypots. La idea es sencilla: se trata 
de pequeñas aplicaciones que simulan un determinado servicio, de forma que un posible atacante 
piense que dicho servicio está habilitado y prosiga su ataque, pero que realmente nos están 
enviando toda la información posible sobre el pirata. Este tipo de programas, una especie de 
troyano9, suele tener una finalidad múltiple: aparte de detectar y notificar ataques, el atacante 
permanece entretenido intentando un ataque que cree factible, lo que por un lado nos beneficia 
directamente, esa persona no intenta otro ataque quizás más peligroso, y por otro nos permite 
entretener al pirata ante una posible traz.a de su conexión. Evidentemente, nos estamos 
arriesgando a que nuestro atacante descubra el mecanismo y lance ataques más peligrosos, este 
mecanismo nos permite descubrir posibles exploits10 utilizados por los piratas y observar a qué 
tipo de atacantes nos enfrentamos. 
1.4 ARQUITECTURAS DE CORTAFUEGOS 
1.4.1 CORTAFUEGOS DE FILTRADO DE PAQUETES 
Un cortafuegos sencillo puede consistir en un dispositivo capaz de filtrar paquetes, un choke: se 
trata del modelo de cortafuegos más antiguo, basado simplemente en aprovechar la capacidad de 
algunos ruteadores, denominados screening routers, para hacer un enrutado selectivo, es decir, 
para bloquear o permitir el tránsito de paquetes mediante listas de control de acceso en función de 
ciertas características de las tramas, de forma que el ruteador actúe como gateway de toda la red. 
Generalmente estas características para determinar el filtrado son las direcciones origen y destino, 
el protocolo, los puertos origen y destino (en el caso de TCP y UDP), el tipo de mensaje (en el caso 
de ICMP) y los interfaces de entrada y salida de la trama en el ruteador. 
En un cortafuegos de filtrado de paquetes los accesos desde la red interna al exterior que no están 
bloqueados son directos (no hay necesidad de utilizar proxies, como sucede en los cortafuegos 
basados en una máquina con dos tarjetas de red), por lo que esta arquitectura es la más simple de 
implementar (en muchos casos sobre hardware ya ubicado en la red) y la más utilizada en 
organizaciones que no precisan grandes niveles de seguridad. No obstante, elegir un cortafuegos 
~ Archivo de texto que almacena genernlmente datos sobre procesos determinados. 
9 Programa que contiene un código dañino dentro de d.11os aparentemente inofensivos. 
1
" Método concreto de utili,.ación de un bug que permite entrnr de forma ilegítima en un sistema infonnático. 
15 
tan sencillo puede no ser recomendable en ciertas situaciones o para organizaciones que requieren 
una mayor seguridad para su subred, ya que los simples cho/ces presentan más desventajas que 
beneficios para la red protegida. El principal problema es que no disponen de un sistema de 
monitoreo sofisticado, por lo que muchas veces el administrador no puede determinar si el 
ruteador está siendo atacado o si su seguridad ha sido puesta en riesgo. Además las reglas de 
filtrado pueden llegar a ser complejas de establecer, y por tanto es dificil comprobar su 
corrección: habitualmente sólo se comprueba a través de pruebas directas, con los problemas de 
seguridad que esto puede implicar. 
Si a pesar de esto decidimos utilizar un ruteador como filtro de paquetes, como en cualquier 
cortafuegos es recomendable bloquear todos los servicios que no se utilicen desde el exterior 
(especialmente NIS, NFS, X-Window y TFfP), así como el acceso desde máquinas no confiables 
hacia nuestra subred. Además, es también importante para nuestra seguridad bloquear los 
paquetes con encaminamiento en origen activado. 
1.4.2 DUAL-HOMED HOST 
El segundo modelo de cortafuegos está formado por simples máquinas Unix equipadas con dos o 
más tarjetas de red y denominadas anfitriones de dos bases (dual-homed hosts) o multibase 
(multi-homed hosts), y en las que una de las tarjetas se suele conectar a la red interna a proteger y 
la otra a la red externa a la organización. En esta configuración el choke y el bastión coinciden en 
el mismo equipo: la máquina Unix. 
El sistema ha de ejecutar al menos un servidor prory para cada uno de los servicios que deseemos 
pasar a través del cortafuegos, y también es necesario que el IP Forwarding esté deshabilitado en 
el equipo: aunque una máquina con dos tarjetas puede actuar como un ruteador, para aislar el 
tráfico entre la red interna y la externa es necesario que el choice no enrute paquetes entre ellas. 
Así, los sistemas externos verán al host a través de una de las tarjetas y los internos a través de la 
otra, pero entre las dos partes no puede existir ningún tipo de tráfico que no pase por el 
cortafuegos: todo el intercambio de datos entre las redes se ha de realizar bien a través de 
servidores prory situados en el host bastión o bien permitiendo a los usuarios conectar 
directamente al mismo. La segunda de estas aproximaciones es sin duda poco recomendable, ya 
que un usuario que consiga aumentar su nivel de privilegios en el sistema puede romper toda la 
protección del cortafuegos, además suele ser incómodopara los usuarios tener que acceder a una 
máquina que haga de puente entre ellos e Internet. De esta forma, la ubicación de proxies es lo 
más recomendable, pero puede ser problemático el configurar cierto tipo de servicios o 
protocolos que no se diseñaron teniendo en cuenta la existencia de un proxy entre los dos 
extremos de una conexión. 
16 
1.4.3 SCREENED HOST 
Un paso más en términos de seguridad de los cortafuegos es la arquitectura screened host o 
choke-gate, que combina un ruteador con un host bastión. y donde el principal nivel de seguridad 
proviene del filtrado de paquetes ( es decir, el ruteador es la primera y más importante línea de 
defensa). En la máquina bastión. único sistema accesible desde el exterior, se ejecutan los proxies 
de las aplicaciones, mientras que el choice se encarga de filtrar los paquetes que se puedan 
considerar peligrosos para la seguridad de la red interna, permitiendo únicamente la 
comunicación con un reducido número de servicios. 
Pero, ¿dónde situar el sistema bastión, en la red interna o en el exterior del ruteador? La mayoría 
de autores recomiendan situar el ruteador entre la red exterior y el host bastión, pero otros 
defienden justo lo contrario. En todo caso, aparte de por estos matices, asumiremos la primera 
opción por considerarla mayoritaria entre los expertos en seguridad informática; así, cuando una 
máquina de la red interna desea comunicarse con el exterior existen dos posibilidades: 
• El choke permite la salida de algunos servicios a todas o a parte de las máquinas internas a 
través de un simple filtrado de paquetes. 
• El choke prohíbe todo el tráfico entre máquinas de la red interna y el exterior, permitiendo 
sólo la salida de ciertos servicios que provienen de la máquina bastión y que han sido 
autorizados por la política de seguridad de la organización. 
La primera aproximación entraña un mayor nivel de complejidad a la hora de configurar las listas 
de control de acceso del ruteador, mientras que si elegimos la segunda la dificultad está en 
configurar los servidores prory (recordemos que no todas las aplicaciones soportan bien estos 
mecanismos) en el host bastión. Desde el punto de vista de la seguridad es más recomendable la 
segunda opción. ya que la probabilidad de dejar escapar tráfico no deseado es menor. Por 
supuesto, en función de la política de seguridad que definamos en nuestro entorno, se pueden 
combinar ambas aproximaciones, por ejemplo permitiendo el tráfico entre las máquinas internas 
y el exterior de ciertos protocolos difíciles de encaminar a través de un prory o sencillamente que 
no entrañen mucho riesgo para nuestra seguridad y obligando para el resto de servicios a utilizar 
el host bastión. 
La arquitectura screened host puede parecer a primera vista más peligrosa que la basada en una 
simple máquina con varias interfaces de red; en primer lugar, tenemos no uno sino dos sistemas 
accesibles desde el exterior, por lo que ambos han de ser configurados con las máximas medidas 
de seguridad. Además, la mayor complejidad de diseño hace más fácil la presencia de errores que 
puedan desembocar en una violación de la política implementada, mientras que con un host con 
cios tarjetas nos aseguramos de que únicamente aquellos servicios con un proxy configurado 
podrán generar tráfico entre la red externa y la interna (a no ser que por error activemos el IP 
Forwarding). Sin embargo, aunque estos problemas son reales, se resuelven tomando las 
precauciones necesarias a la hora de diseñar e implementar el cortafuegos y definiendo una 
política de seguridad correcta. De cualquier forma, en la práctica esta arquitectura de cortafuegos 
está cada vez más en desuso debido a que presenta dos puntos únicos de fallo, el choke y el 
bastión: si un atacante consigue controlar cualquiera de ellos. tiene acceso a toda la red protegida; 
17 
por tanto, es más popular, y recomendable, una arquitectura screened subnel, de la que vamos a 
hablar a continuación. 
1.4.4 SCREENED SUBNET (DMZ) 
La arquitectura Screened Subnel, también conocida como red perimétrica o De-Militarized Zone 
(DMZ), es con diferencia la más utilizada e implementada hoy en día, ya que añade un nivel de 
seguridad en las arquitecturas de cortafuegos situando una subred (DMZ) entre las redes externa 
e interna, de forma que se consiguen reducir los efectos de un ataque exitoso al host bastión: en 
los modelos anteriores toda la seguridad se centraba en el bastión, de forma que si la seguridad 
del mismo se veía puesta en riesgo, la amenaza se extendía automáticamente al resto de la red. 
Como la máquina bastión es un objetivo interesante para muchos piratas, la arquitectura DMZ 
intenta aislarla en una red perimétrica de forma que un intruso que accede a esta máquina no 
consiga un acceso total a la subred protegida. 
IN et 
HostBastión 
Route.r 
exterior 
Firewall 
Routcr 
interior 
LAN 
Figura 1.2 Arquitectura DMZ 
Screened subnel es la arquitectura más segura, pero también la más compleja; se utilizan dos 
ruteadores, denominados exterior e interior, conectados ambos a la red perimétrica como se 
muestra en la figura 1.2. En esta red perimétrica, que constituye el sistema cortafuegos, se incluye 
el host bastión y también se podrían incluir sistemas que requieran un acceso controlado, como 
baterías de módems o el servidor de correo, que serán los únicos elementos visibles desde fuera 
de nuestra red. El ruteador exterior tiene como misión bloquear el tráfico no deseado en ambos 
sentidos (hacia la red perimétrica y hacia la red externa), mientras que el interior hace lo mismo 
pero con el tráfico entre la red interna y la perimétrica: así, un atacante habría de romper la 
18 
seguridad de ambos ruteadores para acceder a la red protegida; incluso es posible implementar 
una zona desmilitariz.ada con un único ruteador que posea tres o más interfaces de red, pero en 
este caso si se pone en riesgo este único elemento se rompe toda nuestra seguridad, frente al caso 
general en que hay que poner en riesgo a ambos, tanto el externo como el interno. También 
podemos, si necesitamos mayores niveles de seguridad, definir varias redes perimétricas en serie, 
situando los servicios que requieran de menor fiabilidad en las redes más externas: así, el atacante 
habrá de saltar por todas y cada una de ellas para acceder a nuestros equipos; evidentemente, si 
en cada red perimétrica se siguen las mismas reglas de filtrado, niveles adicionales no 
proporcionan mayor seguridad. 
Esta arquitectura de cortafuegos elimina los puntos únicos de fallo presentes en las anteriores: 
antes de llegar al bastión (por definición, el sistema más vulnerable) un atacante ha de saltarse las 
medidas de seguridad impuestas por el ruteador externo. Si lo consigue, como hemos aislado la 
máquina bastión en una subred estamos reduciendo el impacto de un atacante que logre 
controlarlo, ya que antes de llegar a la red interna ha de poner en riesgo también al segundo 
ruteador; en este caso extremo, la arquitectura DMZ no es mejor que un screened host. Por 
supuesto, en cualquiera de los tres casos (riesgo en el ruteador externo, el host bastión o del 
ruteador interno) las actividades de un pirata pueden violar nuestra seguridad, pero de forma 
parcial: por ejemplo, simplemente accediendo al primer ruteador puede aislar toda nuestra 
organización del exterior, creando una negación de servicio importante, pero esto suele ser menos 
grave que si lograra acceso a la red protegida. 
Aunque, como hemos dicho antes, la arquitectura DMZ es la que mayores niveles de seguridad 
puede proporcionar, no se trata de la panacea de los cortafuegos. Evidentemente existen 
problemas relacionados con este modelo: por ejemplo, se puede utilizar el cortafuegos para que 
los servicios fiables pasen directamente sin acceder al bastión, lo que puede dar lugar a un 
incumplimiento de la política de la organización. Un segundo problema, quizás más grave, es que 
la mayor parte de la seguridadreside en los ruteadores utiliz.ados, ya que como hemos dicho antes 
las reglas de filtrado pueden ser complicadas de configurar y comprobar, lo que puede dar lugar a 
errores que abran importantes brechas de seguridad en nuestro sistema. 
1.4.5 OTRAS ARQUITECTURAS 
Algo que puede incrementar en gran medida nuestra seguridad y al mismo tiempo facilitar la 
administración de los cortafuegos es utilizar un bastión diferente para cada protocolo o servicio 
en lugar de uno sólo; sin embargo, esta arquitectura presenta el grave inconveniente de la 
cantidad de máquinas necesarias para implementar el cortafuegos, lo que impide que muchas 
organizaciones la puedan adoptar. Una variante más barata consistiría en utilizar un único bastión 
pero servidores proxy diferentes para cada servicio ofrecido. 
Cada día es más habitual en todo tipo de organizaciones dividir su red en diferentes subredes; 
esto es especialmente aplicable en empresas medianas, donde con frecuencia se han de conectar 
oficinas separadas geográficamente. En esta situación es recomendable incrementar los niveles de 
19 
seguridad de las zonas que presentan mayor riesgo insertando cortafuegos internos entre estas 
zonas y el resto de la red. Aparte de incrementar la seguridad, los cortafuegos internos son 
especialmente recomendables en zonas de la red desde la que no se permite la conexión con 
Internet debido a las políticas: como laboratorios de prácticas, donde una simple computadora 
con Linux que deniegue cualquier conexión con el exterior será suficiente para evitar que los 
usuarios se dediquen a conectar a páginas Web desde equipos no destinados a estos usos. 
1.5 IPT ABLES 
El núcleo de Linux contiene utilidades avanzadas para filtrado de paquetes, el proceso de 
controlar los paquetes de red cuando intentan entrar, moverse o salir del sistema. Los núcleos 
anteriores al 2.4 tenían la posibilidad de manipular paquetes usando ipchains que a su vez usaba 
listas de reglas que se aplicaban a los paquetes en cada paso del proceso de filtrado. La 
presentación del núcleo 2.4 trajo consigo iptables, que es parecido a ipchains pero con mejoras en 
el funcionamiento y en el control disponible a la hora de filtrar paquetes. 
1.5.1 ¿POR QUÉ FILTRAR PAQUETES? 
El tráfico se mueve a través de una red en paquetes, que son colecciones de datos en diferentes 
tamaños. Un archivo que se envía por red entre dos computadoras puede estar compuesto por 
diferentes paquetes, los cuales contendrán una parte pequeña de los datos del archivo. La 
computadora emisora toma el archivo y lo parte en diferentes paquetes para enviarlo por la red, 
usando las reglas del protocolo particular de red que se esté utilizando. La otra computadora 
recibe los paquetes y, usando el método especificado por el protocolo, los reensambla para volver 
a construir el archivo. 
Cada paquete contiene información que le ayuda a navegar por la red y moverse hacia su destino. 
El paquete puede decirle a las computadoras a lo largo del camino, así como a la computadora 
destino, de dónde viene, a dónde va, qué tipo de paquete es, y otras muchas cosas más. La 
mayoría de los paquetes se diseñan para transportar datos, pero algunos protocolos pueden usar 
los paquetes de forma especial. El protocolo Transmission Control Protocol (TCP), por ejemplo, 
utiliza un paquete SYN, que no contiene datos, para iniciar la comunicación entre dos sistemas. 
Hay 3 razones principales por las cuales queremos filtrar dichos paquetes: 
• Control. Cuando se está usando Linux para conectar la máquina a otra red ( corno 
Internet) tienes la oportunidad de permitir ciertos tipos de tráfico y de desactivar otros. 
Por ejemplo, la cabecera de un paquete permite la dirección del destinatario del paquete, 
así se puede prevenir que los paquetes vayan a cierta parte de la red. 
20 
• Seguridad. Cuando una máquina con Linux es lo único Internet y una red interna, es 
recomendable y necesario restringir el acceso. Por ejemplo, se debe tener cuidado con los 
posible ataques provenientes de Internet como el conocido "Ping de la muerte". 
• Vigilancia. Algunas veces una mala configuración de una máquina en una red local puede 
decidir devolver todos los paquetes al resto del mundo. Se deberla decirle al filtro que nos 
avise cuando ocurra algo anormal. 
El núcleo de Linux contiene la caracteristica interna de filtrado de paquetes, que le permite 
aceptar algunos de ellos en el sistema mientras que intercepta y para a otros. El núcleo 2.4 
contiene tres tablas de cadenas; aquí hablaremos de la tabla de filtros. La tabla de filtros contiene 
tres juegos de listas de reglas por defecto llamadas cadenas INPUT, OUTPUT y FORWARD; cada 
paquete que se envía o recibe desde la máquina está sujeto a una de estas listas de reglas. Cuando 
un paquete entra en el sistema a través de la interfaz de red, el núcleo decide si su destino es el 
sistema local (cadena INPUT) o cualquier otro destino (cadena FORDWARD) para determinar qué 
lista de reglas se va a utilizar con el mismo. De la misma forma, si un paquete tiene su origen en 
el sistema, el núcleo lo verificará con la cadena OUTPUT. 
Cada paquete puede que sea verificado contra muchas, muchas reglas antes de llegar al final de 
una cadena. La estructura y propósito de estas reglas puede variar, pero normalmente buscan 
identificar un paquete que viene de o se dirige a una dirección IP en particular o un conjunto de 
direcciones que usen un determinado protocolo y servicio de red. 
Independientemente de su destino, cuando un paquete cumple una regla en particular de una de 
las listas de reglas, se asignan a un objetivo (target) particular o una acción a aplicárseles. Si la 
regla especifica un objetivo ACCEPT para un paquete que la cumpla, el paquete se salta el resto 
de las verificaciones de la regla y se permite que continúe hacia su destino. Si una regla 
especifica un objetivo DROP, el paquete "se deja caer", significando esto que no se permite que el 
paquete acceda al sistema y no se envía ninguna respuesta de vuelta al servidor que envió el 
paquete. Si una regla especifica un objetivo REJECT, el paquete se deja caer, pero se envía un 
mensaje de error al emisor. 
Cada cadena tiene una política ACCEPT, DROP o REJECT sobre el paquete o puede ser enviado 
al espacio de usuario con QUEUE. Si ninguna de las reglas de la cadena se aplica al paquete, 
entonces el paquete se trata de acuerdo a la política por defecto de las cadenas. 
En resumen, el procedimiento de filtrado compara el paquete contra cada una de las reglas de la 
cadena a la que pertenece, cada una de ellas dice "si la cabecera de un paquete se parece a esto, 
entonces esto es lo que se debe hacer con ese paquete". Si una regla no corresponde con el 
paquete, entonces la siguiente regla de la cadena se examina. Finalmente, si no hay más reglas 
que consultar, el núcleo mirará la política para decidir qué se debe hacer. En un sistema con una 
buena política de seguridad, la política normalmente será hacer DROP del paquete. 
1. Cuando un paquete llega por una de las interfaces, el núcleo mira el_destino de dicho 
paquete. si no está destinado a ese equipo el paquete es enrutado. 
21 
2. Si está destinado a ese equipo, el paquete pasa a la cadena de entrada. Si la pasa, cualquier 
proceso esperando el paquete lo recibirá. 
3. De otro modo, si el núcleo no tiene activado el reenvío, o si no sabe cómo reenviar el 
paquete, éste será ignorado (DROP). Si el reenvío está activado y el paquete está destinado 
para otra interfaz de red, entonces el paquete irá a la cadena de reenvío {FORDWARD). Si 
es aceptado, se enviará fuera. 
4. Finalmente, si un programa ejecutándose en el equipo puede enviar paquetes, éstos 
pasarán por la cadena de salida {OUTPUT) inmediatamente. Si dice aceptar, entonces el 
paquete saldrá a donde quiera que esté destinado. 
El comando iptables le permite configurar estas listas de reglas, así como configurar nuevas 
cadenas y tablas para ser usadas en sisituación particular. 
1.5.2 COMANDO IPTABLES 
Las reglas que permiten a los paquetes ser filtrados por el núcleo se ponen en ejecución 
ejecutando el comando iptables con una serie de opciones que identifican qué tipos de paquetes 
van a ser filtrados, el origen o destino de los mismos, y qué hacer con el paquete si cumple la 
regla. Las opciones usadas con una regla de iptables en particular deben estar agrupadas 
localmente, basándonos en el propósito y en las condiciones de la regla general del cortafuegos, 
para que una regla sea válida. 
1.5.2.1 Tablas 
Un aspecto muy potente de iptables es que se pueden utilizar múltiples tablas para decidir el 
destino de un paquete en particular, dependiendo del tipo de paquete que se esté monitoreando y 
de qué es lo que se va a hacer con el paquete. Gracias a la naturaleza extensible de iptables se 
pueden crear tablas especializadas que se almacenarán en el directorio para objetivos especiales: 
/etc/modules/<núcleo-version>/núcleo/net/ipv4/netfilter 
lptables es capaz de ejecutar múltiples conjuntos de reglas ipchains en las cadenas definidas, en 
las que cada conjunto cumple un rol específico. 
La tabla por defecto, llamada fil ter, contiene las cadenas estándar por defecto para INPUT, 
OUT PUT y FORWARD. Esto es parecido a las cadenas estándar que se utilizan con ipchains. 
Además, por defecto, iptab/es también incluye dos tablas adicionales que realizan tareas de 
filtrado específico de paquetes. La tabla na t se puede utilizar para modificar las direcciones de 
origen y destino grabadas en un paquete, y la tabla rnang le permite alterar los paquetes de 
forma especializada 
22 
Cada tabla contiene cadenas por defecto que realizan las tareas necesarias basándose en el 
objetivo de la tabla, pero se pueden configurar fácilmente nuevas cadenas en el resto de las 
tablas. 
1.5.2.2 Estructura 
De forma general la estructura del comando es la siguiente: 
iptables [-t <table-name>] <command> 
<chain-name> <parameter-1> 
<option-1> 
<parameter-n> <option-n> 
La opción <table-name> permite al usuario seleccionar una tabla diferente de la tabla 
fil ter por defecto que se usa con el comando. La opción <command> es el centro del 
comando, dictando cuál es la acción específica a realizar, como pueda ser añadir o borrar una 
regla de una cadena particular, que es lo que se especifica en la opción <chain-name>. Tras 
<chain-name> se encuentran los pares de parámetros y opciones que realmente definen la 
forma en la que la regla funcionará y qué pasará cuando un paquete cumpla una regla. 
Cuando miramos a la estructura de un comando iptables es importante recordar que la longitud y 
complejidad de un comando iptables puede cambiar en función de su propósito. Un comando 
simple para borrar una regla de una cadena puede ser muy corto mientras que un comando 
diseflado para filtrar paquetes de una subred particular usando un conjunto de parámetros 
específicos y opciones puede ser mucho más largo. Una forma de pensar en comandos iptab/es es 
reconocer que algunos parámetros y opciones que se pueden utilizar pueden crear la necesidad de 
utilizar otros parámetros y opciones para especificar algo de los requisitos de la anterior opción. 
Para construir una regla válida, esto deberá ser así para todos los parámetros y reglas que 
requieran satisfacer otro conjunto de opciones. 
1.5.2.3 Comandos 
Los comandos le dicen a iptables que realice una tarea específica y solamente un comando se 
permite por cada cadena de comandos iptab/es. Excepto el comando de ayuda, todos los 
comandos se escriben en mayúsculas. 
Los comandos de iptables son: 
• -A - Añade la regla iptahles al final de la cadena especificada. Este es el comando 
utilizado para simplemente añadir una regla cuando el orden de las reglas en la cadena no 
importa 
23 
• -e - Verifica una regla en particular antes de añadirla en la cadena especificada por el 
usuario. Este comando puede ser de ayuda para construir reglas iptables complejas 
pidiéndole que introduzca parámetros y opciones adicionales. 
• - D - Borra una regla de una cadena en particular por número ( como el 5 para la quinta 
regla de una cadena). Es posible también introducir la regla entera e iptables borrará la 
regla en la cadena que corresponda. 
• - E - Renombra una cadena definida por el usuario. Esto no afecta a la estructura de la 
tabla. Tan sólo le evita el problema de borrar la cadena. creándola bajo un nuevo nombre, 
y reconfigurando todas las reglas de dicha cadena. 
• - F - Libera la cadena seleccionada, que borra cada regla de la cadena. Si no se 
especifica ninguna cadena, este comando libera cada regla de cada cadena-
• - h - Proporciona una lista de estructuras de comandos útiles, así como una resumen 
rápido de parámetros de comandos y opciones. 
• - I - Inserta una regla en una cadena en un punto determinado. Asigne un número a la 
regla a insertar e iptables lo pondrá allí. Si no especifica ningún número, iptables 
posicionará su comando al principio de la lista de reglas. 
• - L - Lista todas las reglas de la cadena especificada tras el comando. Para ver una lista 
de todas las cadenas en la tabla fil ter por defecto. La sintaxis siguiente deberá 
utilizarse para ver la lista de todas las reglas de una cadena específica en una tabla en 
particular: 
iptables -L <nombre-cadena> -t <nombre-tabla>. 
• -N - Crea una nueva cadena con un nombre especificado por el usuario. 
• - P - Configura la política por defecto para una cadena en particular de tal forma que 
cuando los paquetes atravieses la cadena completa sin cumplir ninguna regla. serán 
enviados a un objetivo en particular, como puedan ser ACCEPT o DROP. 
• - R - Reemplaza una regla en una cadena en particular. Deberá utilizar un número de 
regla detrás del nombre de la cadena para reemplazar esta cadena. La primera regla de una 
cadena se refiere a la regla número 1. 
• - X - Borra una cadena especificada por el usuario. No se permite borrar ninguna de las 
cadenas predefinidas para cualquier tabla. 
• - z - Pone ceros en los contadores de byte y de paquete en todas las cadenas de una tabla 
en particular. 
24 
1.5.2.4 Parámetros 
Una vez que se hayan especificado algunos comandos de iptab/es , incluyendo aquellos para 
crear, añadir, borrar, insertar o reemplaz.ar reglas de una cadena en particular, se necesitan 
parámetros para comenzar la construcción de la regla de filtrado de paquetes. 
• -e Reestablece el valor de los contadores de una regla en particular. Este parámetro 
acepta las opciones PKTS y BYTES para especificar qué contador hay que resetear. 
• -d Configura el nombre de la máquina destino, dirección IP o red de un paquete que 
cumplirá la regla. Cuando se especifique una red, puede utiliz.ar dos métodos diferentes 
para describir las máscaras de red, como 
192.168.0.0/255.255.255.0ó192.168.0.0/24. 
• - f Aplica esta regla sólo a los paquetes fragmentados. 
Usando la opción "!" después de este parámetro, sólo los paquetes no fragmentados se 
tendrán en cuenta. 
• -i Configura las interfaces de entrada de red, como ethü o pppü, para ser usadas por 
una regla en particular. Con iptables, este parámetro opcional sólo debería de ser usado 
por las cadenas INPUT y FORWARD cuando se utilice junto con la tabla f i 1 ter y la 
cadena PREROUTING con las tablas nat y mangle. 
Este parámetro proporciona varias opciones útiles que pueden ser usadas antes de 
especificar el nombre de una interfaz: 
o ! - Dice a este parámetro que no concuerde, queriendo decir esto que las 
interfaces especificadas se excluirán de esta regla. 
o + - Caracter comodín usado para hacer coincidir todas las interfaces que 
concuerden con una cadena en particular. Por ejemplo, el parámetro -i eth+ 
aplicará esta regla a todas las interfaces Ethernet de su sistema excluyendo 
cualquier otro tipo de interfaces, como pueda ser la pppO. 
Si el parámetro - i se utiliza sin especificar ninguna interfaz, todas las interfaces estarán 
afectadas por laregla. 
• -j Dice a iptab/es que salte a un objetivo en particular cuando un paquete cumple una 
regla en particular. Los objetivos válidos que se usarán tras la opción - j incluyen 
opciones estándar, ACCEPT, DROP, QUEDE y RETURN, así como opciones extendidas 
que están disponibles a través de módulos que se cargan por defectos con el paquete RPM 
de iptables de RedHat Linux, como LOG, MARK y REJECT, así como otras 
25 
En lugar de especificar la acción objetivo, puede también dirigir un paquete que cumpla la 
regla hacia una cadena definida por el usuario fuera de la cadena actual. Esto le permitirá 
aplicar otras reglas contra este paquete y filtrarlo mejor con respecto a otros criterios. 
Si no especifica ningún objetivo, el paquete se mueve hacia atrás en la regla sin llevar a 
cabo ninguna acción. A pesar de todo, el _contador para esta regla se sigue incrementando 
en uno, a partir del momento en el que el paquete cumplió la regla especificada. 
• -o Configura la interfaz de red de salida para una regla en particular y sólo puede ser 
usada con las cadenas OUTPUT y FORWARD en la tabla fil ter y la cadena 
POSTROUTING en las tablas nat y mangle. Estas opciones de los parámetros son los 
mismos que para los de la interfaz de red de entrada ( opción - i ). 
• -p Configura el protocolo IP para la regla, que puede ser i cmp, t cp, udp o a 11 (todos 
los anteriores) para usar cualquier protocolo. Además, se pueden usar otros protocolos 
menos usados de los que aparecen en / etc/protocols. Si esta opción se omite al 
crear una regla, la opción al 1 es la que se selecciona por defecto. 
• - s Configura el origen de un paquete en particular usando la misma sintaxis que en el 
parámetro de destino (opción -d). 
1.5.2.5 Opciones de identificación de paquetes 
Los diferentes protocolos de red proporcionan opciones especializadas de concordancia que 
pueden ser configurados de forma específica para identificar un paquete en particular usando 
dicho protocolo. Por supuesto el protocolo deberá ser especificado en un primer momento en el 
comando iptables, como con la opción siguiente para hacer que las opciones de dicho protocolo 
estén disponibles: -p tcp <nombre-protocolo> 
Protocolo TCP 
Estas opciones de identificación están disponibles en el protocolo TCP (-p tcp ): 
• --dport Configura el puerto de destino para el paquete. Se puede utilizar un nombre de 
servicio de red (como www o smtp), un número de puerto o un rango de números de 
puertos para configurar esta opción. Para ver los nombres o alias de los servicios de red y 
los números de puertos que usan mire el archivo / etc/ services. Además es posible 
usar la opción --destination-port para especificar esta opción de identificación de 
paquete. 
Para especificar un rango de números de puertos separe los dos números de puertos con 
dos puntos(:), como en -p tcp --dport 3000: 3200. El rango válido más grande 
es O: 65535. 
26 
También se puede usar el caracter de punto de exclamación ( ! ) como bandera tras la 
opción --dport para indicar a iptables que seleccione los paquetes que no usen ese 
servicio o puerto. 
• --sport Configura el puerto de origen del paquete, usando las mismas opciones que --
dport. También se puede usar --source-port para especificar esta opción. 
• --syn Provoca que todos los paquetes designados de TCP, comúnmente llamados 
paquetes SYN, cumplan esta regla. Cualquier paquete que esté llevando un payload de 
datos no será tocado. Si se sitúa un punto de exclamación (!)como bandera tras la opción 
- - s yn se provoca que todos los paquetes no-SYN sean seleccionados. 
• --tcp-f lags Permite que los paquetes TCP con conjuntos de bits específicos o 
banderas (tlags}, sean seleccionados para una regla. Esta opción de selección acepta dos 
parámetros, que son las banderas para los diferentes bits ordenados en una lista separada 
por comas. El primer parámetro es la máscara, que configura las banderas que serán 
examinados en el paquete. El segundo parámetro se refiere a las banderas que se deben 
configurar en el paquete para ser seleccionado. Las banderas posibles son ACK, FIN, 
PSH, RST, SYN y URG. Adicionalmente, se pueden usar ALL y NONE para seleccionar 
todas las banderas o ninguno de ellos. 
Por ejemplo, una regla iptables que contiene -p tcp --tcp-flags ACK, FIN, SYN 
SYN tan sólo seleccionará los paquetes TCP que tengan la bandera SYN activo y las 
banderas ACK y FIN sin activar. 
Como en otras _opciones, al usar el punto de exclamación ( ! ) tras - -t cp- flag s invierte 
el efecto de la opción, de tal forma que las banderas del parámetro no tendrán que estar 
presentes para poder ser seleccionados. 
• --tcp-option Intenta seleccionar con opciones específicas de TCP que pueden estar 
activas en un paquete en particular. Esta opción se puede revertir con el punto de 
exclamación ( ! ). 
Protocolo UDP 
Estas opciones de selección están disponibles para el protocolo UDP (-p udp ): 
• --dport Especifica el puerto destino del paquete UDP usando el nombre del servicio, el 
número del puerto, o un rango de puertos. La opción de selección de paquetes - -
destination-port se puede utilizar en lugar de --dport. 
• - - sport Especifica el puerto origen del paquete UDP usando el nombre del serv1c10 
número de puerto, o rango de puertos. La opción --source-port puede ser usada en 
lugar de --sport. 
27 
Protocolo ICMP 
Los paquetes que usan el protocolo de control de mensajes de Internet (Internet Control Message 
Protocol, ICMP) pueden ser seleccionados usando la siguiente opción cuando se especifique -p 
icmp: 
• --icmp-type Selecciona el nombre o el número del tipo ICMP que concuerde con la 
regla. Se puede obtener una lista de nombres válidos ICMP tecleando el comando 
iptables -p icmp -h. 
1.5.2.6 Módulos con opciones de selección adicionales 
Las opciones de selección adicionales, que no son específicas de ningún protocolo en particular, 
están también disponibles a través de módulos que se cargan cuando el comando iptables los 
necesite. Para usar una de estas opciones es necesario cargar el módulo por su nombre incluyendo 
-m <nombre-modulo> en el comando iptables que crea la regla. 
Un gran número de módulos, cada uno de ellos con sus diferentes opciones de selección de 
paquetes, están disponibles por defecto. También es posible crear módulos que proporcionen 
funcionalidades de selección adicionales para requisitos específicos. 
El módulo 1 imi t permite poner un límite en el número de paquetes que podrán ser 
seleccionados por una regla en particular. Esto es especialmente conveniente cuando se usa la 
regla de logging ya que hace que el flujo de paquetes seleccionados no llene nuestros archivos 
log con mensajes repetitivos ni utilice demasiados recursos del sistema. 
• - -1 imi t - Configura el número de coincidencias en un intervalo de tiempo, 
especificado con un número y un modificador de tiempo ordenados en el formato 
<número>/<tiempo>. Por ejemplo si se usa --limit 5/hour sólo se permitirá 
que una regla sea efectiva cinco veces a la hora. 
Si no se utiliza ningún número ni modificador de tiempo, se asume el siguiente valor por 
defecto: 3/hour. 
• - -1 imi t - bur s t - Configura un límite en el número de paquetes capaces de cumplir 
una regla en un determinado tiempo. Esta opción deberá ser usada junto con la opción - -
1 imi t, y acepta un número para configurar el intervalo de tiempo. 
Si no se especifica ningún número, tan sólo cinco paquetes serán capaces inicialmente de 
cumplir la regla. 
28 
El módulo state, que utiliza la opción --state, puede seleccionar un paquete con los 
siguientes estados de conexión particulares: 
• ESTABLISHED El paquete seleccionado se asocia con otros paquetes en una conexión 
establecida. 
• INVALID El paquete seleccionado no puede ser asociado a una conexión conocida. 
• NEW El paquete seleccionado o bien está creando una nueva conexión o bien fonna parte 
de una conexión de dos caminos que antes no había sido vista. 
•RELATED El paquete seleccionado está iniciando una nueva conexión en algún punto de 
la conexión existente. 
Estos estados de conexión se pueden utilizar en combinación con otros separándolos mediante 
comas como en -m state --state INVALID, NEW. 
Para seleccionar una dirección MAC 11 de un dispositivo Ethernet en particular utilice el módulo 
mac, que acepta --mac-source con una dirección MAC como opción. Para excluir una 
dirección MAC de una regla, ponga un punto de exclamación ( ! ) tras la opción --mac-
source. 
1.5.2. 7 Opciones del objetivo 
Una vez que un paquete cumple una regla en particular, la regla puede dirigir el paquete a un 
número de objetivos (destinos) diferentes que decidirán cuál será su destino y, posiblemente, las 
acciones adicionales que se tomarán, como el guardar un registro de lo que está ocurriendo. 
Adicionalmente, cada cadena tiene un objetivo por defecto que será el que se utilice si ninguna de 
las reglas disponibles en dicha cadena se puede aplicar a dicho paquete, o si ninguna de las reglas 
que se aplican al mismo especifica un objetivo concreto. 
Existen pocos objetivos estándar disponibles para decidir qué ocurrirá con el paquete: 
• <user-defined-chain> El nombre de una cadena que ya ha sido creada y definida 
con anterioridad junto con esta tabla con reglas que serán verificadas contra este paquete, 
además de cualquier otra regla en otras cadenas que se deban verificar contra este 
paquete. Este tipo de objetivo resulta útil para examinar un paquete antes de decidir qué 
ocurrirá con él o guardar información sobre el paquete. 
• ACCEPT - Permite que el paquete se mueva hacia su destino (o hacia otra cadena, si no 
ha sido configurado ningún destino ha sido configurado para seguir a esta cadena). 
11 Dirección de un dispositivo hardware conectado a un medio compartido. 
29 
• DROP - Deja caer el paquete. El sistema que envió el paquete no es informado del fallo. 
El paquete simplemente se borra de la regla que está verificando la cadena y se descarta. 
• QUEUE - El paquete se pone en una cola para ser manejado en el espacio de usuario, 
donde un usuario o una aplicación, por ejemplo, podrá hacer algo con él. 
• RETURN - Para la verificación del paquete contra las reglas de la cadena actual. Si el 
paquete con un destino RETURN cumple una regla de una cadena llamada desde otra 
cadena, el paquete es dewelto a la primera cadena para retomar la verificación de la regla 
allí donde se dejó. Si la regla RETURN se utiliza en una cadena predefinida, y el paquete 
no puede moverse hacia la cadena anterior, el objetivo por defecto de la cadena actual 
decide qué hará con él. 
Además de estos objetivos estándar, se pueden usar otros más con extensiones llamadas módulos 
de objetivos (target modules}, que trabajan de forma similar a como los hacían los módulos de las 
opciones de selección. 
Existen varios módulos extendidos de objetivos, la mayoría de los cuales tan sólo se aplicarán a 
tablas o situaciones específicas. Un par de estos módulos de los más populares e incluidos por 
defecto en RedHat Linux son: 
• LOG Guarda un registro de todos los paquetes que cumplen esta regla. Como estos 
paquetes son monitoreados por el núcleo, el archivo / etc/ syslog. conf determina 
dónde se escribirán esas entradas en el archivo de registro (log). Por defecto, se sitúan en 
el archivo /var / log/messages. 
Se pueden usar varias opciones tras el objetivo LOG para especificar la manera en la que 
tendrá lugar el registro: 
o --log-level Configura un nivel de prioridad al evento de registro del sistema. 
Se puede encontrar una lista de los eventos del sistema en la página del manual de 
syslog. conf, y sus nombres se pueden usar como opciones tras la opción --
log-level. 
o -- log-ip-options Cualquier opción en la cabecera de un paquete IP se 
guarda en el registro. 
o --log-prefix Pone una cadena de texto antes de la línea de registro cuando 
ésta sea escrita. Acepta hasta 29 caracteres tras la opción -- log-pre f ix. Esto 
puede ser útil para escribir filtros del registro del sistema para ser usados 
conjuntamente junto con el registro de paquetes. 
o --log-tcp-options Cualquier opción en la cabecera de un paquete TCP se 
guarda en el registro 
30 
o --log-tcp-sequence Escribe le número de secuencia TCP del paquete en el 
registro del sistema. 
• REJECT Envía un paquete de error de vuelta al sistema que envió el paquete, y lo deja 
caer (DROP). Este objetivo puede ser útil si queremos notificar al sistema que envió el 
paquete del problema. 
El objetivo REJECT acepta una opción --reject-with <type> para proporcionar 
más detalles para ser enviados junto con el paquete de error. El mensaje port-
unreachable es el error <type> que se envía por defecto cuando no se utiliza junto 
con otra opción. Para obtener una lista completa de todas las opciones <type> que se 
pueden utilizar, vea la página del manual de iptables. 
1.5.2.8 Opciones de listado 
El comando de listado por defecto, iptables -L, proporciona una visión básica de la tabla de 
filtros por defecto de las cadenas de reglas actuales. Existen opciones adicionales que 
proporcionan más información y la ordenan de diferentes formas: 
• -v Muestra la salida por pantalla, como el número de paquetes y bytes que cada cadena 
ha visto, el número de paquetes y bytes que cada regla ha encontrado y qué interfaces se 
aplican a una regla en particular. 
• - x Expande los números en sus valores exactos. En un sistema ocupado, el número de 
paquetes y bytes vistos por una cadena en concreto o por una regla puede estar abreviado 
usando K (miles), M (millones), y G (billones) detrás del número. Esta opción fuerza a 
que se muestre el número completo. 
• -n Muestra las direcciones IP y los números de puertos en formato numérico, en lugar de 
utilizar el nombre del servidor y la red tal y como se hace por defecto. 
• --line-numbers Proporciona una lista de cada cadena junto con su orden numérico 
en la cadena. Esta opción puede ser útil cuando esté intentando borrar una regla específica 
en una cadena, o localizar dónde insertar una regla en una cadena. 
1.5.3 GUARDAR INFORMACIÓN DE IPTABLES 
Las reglas creadas con el comando iptables se almacenan solamente en RAM 12_ Si tiene que 
reiniciar su sistema tras haber configurado varias reglas de iptah/es, éstas se perderán y tendrá 
1
: Memoria de acceso <1lca1orio en donde la compuladorn almacena elatos para rápido acceso. 
31 
que volver a teclearlas. Si quiere que determinadas reglas tengan efecto en cualquier momento 
que inicie su sistema, necesita guardarlas en el archivo/ etc/ sysconf ig / iptables. 
Para hacer esto, ordene sus tablas, cadenas y reglas de la forma en que deben de estar la próxima 
vez que se inicie el sistema o se reinicie iptables. y teclee el comando / sbin/ service 
iptables save como usuario root. Esto hace que el script de inicio de iptables ejecute el 
programa/ sbin/ iptables-save y escriba la configuración actual de iptables en el archivo 
/ etc/ sysconf ig/ iptables. Este archivo debería ser de sólo lectura para el usuario root, 
para que las reglas de filtrado de paquetes no sean visibles por el resto de los usuarios. 
La próxima vez que se inicie el sistema, el script de inicio de iptables volverá a aplicar las reglas 
guardadas en / etc/ sysconf ig/ iptables usando el comando / sbin/ iptables-
restore. 
Mientras que siempre es una buena idea el verificar cada nueva regla de iptables antes de que se 
escriba en el archivo /etc/sysconfig/iptables. es posible copiar las reglas de iptables 
en este archivo a partir de otra versión del sistema de este archivo. Esto permite distribuir 
rápidamente conjuntos de reglas iptables a diferentes máquinas de una sola vez. Simplemente es 
necesario reiniciar iptables para que las nuevas reglas tengan efecto. 
1.5.4 MEJORAS SOBRE IPCHAINS 
En un primer momento, ipchains e iptables parecen ser bastante similares. Al fin y al cabo ambos 
son métodos de filtrado de paquetes