Auditoría informática del Software.

1.- Introducción.

La auditoria informática es el conjunto de técnicas, actividades y

procedimientos, destinados a analizar, evaluar, verificar y recomendar en asuntos
relativos a la planificación, control, eficacia, seguridad y adecuación del servicio
informático en la empresa, por lo que comprende un examen metódico, puntual y
discontinuo del servicio informático.
Tradicionalmente, en el entorno del proceso de datos, cuando se habla de
software, de un modo genérico, se está haciendo referencia a los programas que
se ejecutan en el ordenador. Cuando se trata de auditar el software el concepto
puede generalizarse más y extenderse con la parte “que no se ve” de una
instalación de proceso de datos. Estos aspectos lógicos de la informática son:
software del sistema, utilidades, datos, programas, bases de datos, etc...

2.- Objetivos de la Auditoría.

A continuación veremos una lista de los objetivos de la auditoria del entorno

software:
* Revisar la seguridad del logical sobre ficheros de datos y programas.
* Revisar las librerías utilizadas por los programadores.
* Examinar que los programas realizan lo que realmente se espera de ellos.
* Revisar el inventario de software.
* Comprobar la seguridad de datos y software.
* Examinar los controles sobre los datos.
* Revisar los procedimientos de entrada y salida.
* Verificar las previsiones y procedimientos de back-up.
* Revisar los procedimientos de planificación, adecuación y mantenimiento
del software del sistema.
* Revisar la documentación sobre software de base.
* Revisar los controles sobre programas producto (paquetes externos).
* Examinar la utilización de estos paquetes.
* Verificar periódicamente el contenido de los ficheros de usuario.
* Determinar que el proceso para usuarios está sujeto a los controles
adecuados.
* Examinar los cálculos críticos.
* Supervisar el uso de las herramientas potentes al servicio de los usuarios.
* Comprobar la seguridad e integridad de las bases de datos.
3.- Auditoría informática del entorno software.

Software del sistema.

Para un eficiente funcionamiento del ordenador y garantizar su continuidad es

importante la puesta en marcha y el control de todas las modificaciones al
sistema operativo, y en general, de todo el software de base del sistema.
Garantizando así la no interrupción por falta de actualización en las diferentes
versiones que con frecuencia lanzan las casas constructoras. También es
necesario establecer controles y restricciones adecuados para evitar los cambios
desautorizados en el software del sistema y el uso incontrolado de determinadas
utilidades potentes, y que no dejan la menor huella para auditoría tras su
ejecución.
El auditor, revisará la forma en que se está realizando el proceso de
modificación o alteración del software de base: es necesario que tal operación
esté organizada y dotada del nivel de seguridad que requiere una operación de
esta índole, con una correcta normativa al respecto y contemplando las
oportunas autorizaciones por parte de la dirección informática. La supervisión en
este sentido es fundamental dada la propia importancia del software a modificar.
Las instalaciones de proceso de datos disponen de potentes utilidades que
acceden a datos y programas prácticamente sin ningún tipo de control ni
restricción, permitiendo la modificación directa de estos al margen de cualquier
sistemática. Esto supone un gran riesgo para la información almacenada. Por ello
se hace necesario establecer controles sobre su utilización. Como primera medida
se catalogarían “sensibles” aquellas utilidades peligrosas para la integridad de la
información (accesos a ficheros, copias de ficheros, etc...) y que, sólo podrán ser
utilizadas por personal autorizado. Si por necesidades de la instalación alguna de
estas rutinas deben permanecer “on-line” se dispondrá de un sistema de
passwords para su utilización.
Al igual que las utilidades, determinados comandos del sistema deben tener un
carácter de uso restringido, por lo que se examinará la corrección en la definición
de los perfiles de usuario para evitar el uso indiscriminado de tales comandos.

El control de los datos.

Una frase muy utilizada en informática viene a decir que “a un sistema al que
se le proporcione basura a la entrada, nos dará basura a la salida”. El tratamiento
automático de los datos ignora su significado y atiende tan sólo a su contenido y
estructura. Ello implica que el control informático debe vigilar no sólo el valor de
la información sino también su forma. El control de los datos a la entrada es
fundamental y en la auditoría se examinará la forma en que se han establecido los
programas de control de datos en las diferentes aplicaciones productivas,
verificando que, estos programas permitan detectar:

* Inverosimilitudes en los datos, con lo que se captan algunas posibilidades de

error.
* Errores en los indicativos que están aportando falsa información sobre un ítem
erróneo o una falta de información sobre el verdadero. La mayoría de los
métodos utilizados para este fin se basan en la utilización de una letra o dígito de
control que se añade al dispositivo a depurar.
* Errores en la zona de enunciado que, al no ser muy graves, en la mayoría de los
casos puede no ser necesaria su detección por el excesivo coste de las
redundancias necesarias para tal fin. El criterio del auditor dilucidará sobre la
necesidad de este tipo de control.
* Errores en campos de importe que por su naturaleza deben cuidarse
sobremanera. Desgraciadamente, no existen procedimientos infalibles que estén
exentos de rechazar datos que sí son correctos o que, por el contrario, permitan el
paso a los incorrectos. Se pueden establecer test programados basándose en la
experiencia previa y utilizando, por ejemplo, técnicas estadísticas, pero sin perder
de vista en ningún momento la falibilidad de estos procedimientos.
* Errores por pérdida de información. Estos fallos son más fáciles de detectar y
prevenir, ya que por ejemplo se pueden programar la obligatoriedad de lleno de
campos.

Control periódico de ficheros y programas.

Dentro del marco de seguridad integral de la instalación hay que contemplar

una revisión regular de ficheros y programas, detectando, por ejemplo, que
procesos que concluyan anormalmente alteren información contenida en los
ficheros, o que las versiones disponibles de los programas fuente son las
adecuadas y no han sufrido modificación alguna.

Con el objetivo de eliminar este tipo de problemas es conveniente que en la

auditoría se revisen ciertos puntos:

* La auditabilidad de las aplicaciones, lo que se consigue proporcionando

cuadros de valores numéricos, totales de registros, con indicación de su tipo y, en
suma, toda una serie de medidas que permitan un mejor seguimiento.
* El procesamiento regular de los ficheros, investigando cualquier tipo de
información que proporcione una noción del estado de los mismos.
* El cotejo aleatorio de la coherencia entre los datos contenidos en los ficheros
antes y después de su procesamiento.
* Implantación de un software que permita un control de las versiones de los
programas, impidiendo que se obtenga copia de un programa mientras no se
“devuelva” otra copia previa y manteniendo un fichero histórico de las
modificaciones.
* La adecuada concienciación ante la importancia de registros y documentos de
forma que éstos estén clasificados al menos en las siguientes categorías:
- Vitales: por lo que deberá existir una copia exterior, es decir, almacenada en
un local diferente a aquel en que se asienta el centro de informática.
- Importantes: En esta caso su salvaguarda se almacenará en una sala diferente
de aquellas utilizadas por informática.
- Utiles: estos registros necesitarán también de una copia de seguridad que se
puede guardar en la propia sala del servicio informático.
Copia de seguridad.

Un elemento clave en la auditoría del entorno de datos y programas lo

constituye la revisión de los procedimientos de obtención de copias de seguridad.
La necesidad de la obtener copias de ficheros y programas es más que evidente
y cualquier instalación ha de intervenir unos minutos del tiempo de los
operadores al final de la jornada para obtener tales copias, como mínimo de los
ficheros y/o programas que hayan sufrido alguna modificación a lo largo del día.
Además de estas copias diarias se obtendrá otra con una periodicidad marcada
por la propia naturaleza de los procedimientos en explotación.
Si en la instalación auditada existen ordenadores personales bajo control
directo de los departamentos de usuarios, el auditor comprobará que se han
adoptado medidas según los cuales los usuarios son conscientes de la necesidad
de obtención de copias de seguridad de una manera regular, así como capaces de
obtener y almacenar dichas copias.
En todo caso es necesario que los procedimientos de back-up estén
debidamente documentados.

Selección de paquetes.

En un examen de este tipo, no debe descuidarse la revisión de la metodología

que tenga la empresa auditada en lo que se refiere a la selección y adquisición de
paquetes de software. Esta metodología de selección deberá incluir una
evaluación técnica que nos asegure que efectivamente el programa que vamos a
adquirir podrá funcionar en la empresa y evalué los aspectos de seguridad,
documentación, mantenimiento, etc.
El proceso de selección deberá concluir con un informe detallado que incluya
todos los posibles análisis efectuados, así como las razones que indujeron a tomar
una u otra alternativa.
 Desarrollos con herramientas evolucionadas.

Los lenguajes de cuarta generación constituyen una importante línea de

evolución de la informática de gestión. Ahora bien, la utilización de estas
técnicas no debe hacerse perdiendo de vista algunos puntos de importancia de
cara a las aplicaciones ya existentes y a los futuros desarrollos, por lo cual la
revisión y seguimiento que se realice sobre el uso de estas herramientas se fijara
en:

* La coordinación necesaria entre el staff de proceso de datos y los

departamentos de usuarios. Se trata así de evitar el uso indiscriminado de estas
herramientas de desarrollo, pues de lo contrario no sería nada anormal
encontrarse con aplicaciones alternativas a las convencionales desarrolladas por
informática para solucionar problemas puntuales.
* La documentación y formación facilitadas a los usuarios. Se trata de evitar los
individualismos de los usuarios cuando estos estén realizando desarrollos
valiéndose de las técnicas evolucionadas que se les han facilitado. Además de la
adecuada formación que requiere la óptima explotación del paquete, es necesario
imbuir al usuario las normas imprescindibles de seguridad y documentación que
conlleva cualquier desarrollo.
* La fiabilidad e integridad de la información que los usuarios consiguen con
estos procedimientos. A tal fin se hace necesario la implantación de
procedimientos de seguridad que restrinjan la libre disposición de la información
por cualquier tipo de usuario.

En definitiva se trata de que el auditor se fije en la forma en que se está

utilizando el software evolucionado y cómo puede esto repercutir en el nivel de
eficiencia y seguridad general de datos y programas de la instalación.

Seguridades en bases de datos.

Los sistemas de bases de datos soportan hoy en día los sistemas de

información de la mayoría de las empresas mecanizadas. Son, por tanto, un
elemento a tener en cuenta a la hora de dictaminar sobre la situación de la
informática de una empresa.
Las características de construcción de las bases de datos motivan la aparición
de nuevos riesgos por lo que el auditor debe conocer los principios y conceptos
fundamentales de diseño de una base de datos (más concretamente del sistema de
gestión de la base de datos). Esto, de forma global y en particular obtendrá una
visión preliminar de la base de datos a examinar, en sus aspectos de
implementación y soporte físicos, de administración, etc.
Principales riesgos a los que está sometida una base de datos:

* Inadecuada asignación de responsabilidades.

* Inexactitud de los datos.
* Pérdida de actualizaciones.
* Adecuación de los “audit trail”.
* Accesos desautorizados a los datos.
* Actualizaciones en el software base.
* Documentación no actualizada.
A la hora de auditar una base de datos se pueden establecer una serie de puntos
a controlar, puntos con cuya revisión se conformará una idea sobre la situación
real de la base, y son:
* Mantenimiento de programas que manejan datos de la base.
* Controles de la validación en la entrada de datos.
* Autorizaciones de acceso
* Procedimiento de manejo de datos erróneos.
* Objeto del procesamiento.
* Datos concurrentes o compartidos.
* Prevención y detecciones de los interbloqueos.
* Asignación de funciones y responsabilidades.
* Controles de salida.
* Situación del diccionario de datos.
* Documentación del sistema y de sus configuraciones
* Entrenamiento del personal.

4.- Etapas de la auditoria de una aplicación informática.

- Recogida de información y documentación Sobre la aplicación: se realiza un

estudio preliminar en el que recogemos toda aquella información que nos pueda
ser útil para determinar los puntos débiles existentes y aquellas funciones de la
aplicación que puedan entrañar riesgos.
- Determinación de los objetivos y alcance de la auditoria: Es preciso conseguir
una gran claridad y precisión en la definición de objetivos de la auditoria, del
trabajo y pruebas que se proponen realizar, delimitando perfectamente su alcance
de manera que no ofrezca dudas de interpretación.
- Planificación de la auditoria: en este caso es de crucial importancia acertar con
el momento mas adecuado para su realización. No es conveniente que coincida
con el periodo de implantación porque los usuarios no están muy familiarizados
con la aplicación, pero al mismo tiempo el retraso excesivo puede alargar el
periodo de exposición a riesgos.
- Trabajo de campo, informe e implantación de mejoras: consiste en la ejecución
del programa de trabajo establecido. Respecto al informe se recogerán las
características del trabajo realizado, sus conclusiones, recomendaciones o
propuestas de mejora. La implentación de las mejoras identificadas en la
auditoria.

5.- Herramientas de uso más común en la auditoria de una aplicación.

- Entrevistas: son de larga utilización a lo largo de toda la auditoria.

- Encuestas: pueden ser de utilidad tanto para determinar el alcance y objetivos
de la auditoria, como para la materialización de los objetivos relacionados con el
nivel de satisfacción de los usuarios.
- Observación del trabajo realizado por los usuarios: es necesario observar como
trabajan los usuarios: Puede ayudar a detectar que el trabajo final sea bueno y por
lo tanto los controles establecidos sean efectivos.
- Pruebas de conformidad: son actuaciones orientadas específicamente a
comprobar que determinados procedimientos, normas o controles internos, se
cumplen o funcionan de acuerdo a lo previsto o esperado.
- Pruebas substantivas o de validación: orientadas a detectar la presencia o
ausencia de errores o irregularidades en procesos, controles o actividades
internos integrados en ellos.
- Uso de ordenador: es el uso de las aplicaciones software que se pueden utilizar
para realizar la auditoria, los cuales son de gran ayuda para facilitar el trabajo.

BIBLIOGRAFIA.

Auditoria Informática.
Gonzalo Alonso Rivas.
Ediciones DÍAZ DE SANTOS, S.A.
1. Introducción
1.1. Definición de firewall
Un cortafuegos o firewall es un sistema de defensa basado en el hecho de que
todo el tráfico de entrada o salida a la red debe pasar obligatoriamente por un
sistema de seguridad capaz de autorizar, denegar, y tomar nota de todo aquello
que ocurre, de acuerdo con una política de control de acceso entre redes.

Controla tanto la comunicación desde el exterior como el tráfico generado desde

la propia máquina o red interna. Actúa a base de normas que establece el
administrador de seguridad o, en su defecto, el administrador de red o el usuario
final. Dichas reglas definen las acciones correspondientes a llevar a cabo cuando
se recibe un paquete que cumpla unas determinadas características.

Apesar de que hay programas que se venden bajo la denominación de firewall,

un firewall NO es un programa, sino que consiste en un conjunto de
medidas hardware y software destinadas a asegurar una instalación de red.

En definitiva, se trata de cualquier sistema empleado para "separar" una máquina o una
subred del resto, protegiéndola de servicios y protocolos que puedan suponer una amenaza
a la seguridad desde el exterior. El espacio protegido por un cortafuegos se
denomina perímetro de seguridad, mientras que la red externa recibe el nombre
de zona de riesgo.

Figura 1.1: Esquema básico de un firewall.

Resulta evidente que la forma de aislamiento más efectiva es el mantenerse
desconectado de la red externa (Figura 1.2). Sin embargo, esta situación resulta
poco habitual, ya que la mayoría de organizaciones necesitan compartir
información a largas distancias (Figura 1.3). En dicha situción es en la que
resulta efectivo implementar cierta separación lógica entre la máquina o red
interna e Internet mediante un cortafuegos (Figura 1.4).

Figura 1.2 Figura 1.3 Figura 1.4

Como se puede observar, la seguridad siempre será relativa al tipo de servicios

que se quiera ofrecer a los usuarios autorizados, según se establece en la política
de seguridad.

Los cortafuegos son uno de las dos enfoques básicos que se han dado al aspecto
de la seguridad en redes telemáticas. Por una parte se trata de la defensa en
profundidad de los servidores que vayan a ser accedidos desde las redes públicas
(proteger cada una de las máquinas susceptibles de ser accedidas por personas no
autorizadas) y por otra parte, defensa del perímetro de seguridad respecto del
exterior, es decir, llevar toda la carga correspondiente a la seguridad en la red
corporativa al elemento de conexión de dicha red con el exterior o con las redes
en las que se encuentren las personas que pueden querer acceder a nuestros
recursos de forma no autorizada. En este último aspecto es donde aparece el
concepto de firewall.

Las funciones básicas de un cortafuegos se pueden resumir en:

 Filtrar los accesos no autorizados (mediante filtrado de paquetes, o bien

observando el contenido de las unidades de protocolo de Transporte,
Sesión, Presentación, y aplicación).
 Llevar la contabilidad de las transacciones que se llevan a cabo en la
red.
 Alertar en caso de ataques o de comportamiento extraño de los sistemas
de comunicación.

1.2. Otras definiciones

En este apartado se hace referencia al significado de algunos de los conceptos
empleados durante el trabajo:

Host

Sistema informático conectado a una red.

Máquina o host bastión (o gates)
Sistema especialmente asegurado, pero vulnerable en principio a todo tipo de
ataques por estar abierto a Internet. 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. Filtra
el tráfico de entrada y salida. Esconde la configuración de la red hacia fuera.
Paquete
Unidad fundamental de comunicación entre redes.
Filtrado de paquetes (screening)
Acción de denegar o permitir el flujo de tramas entre dos redes de acuerdo a unas
normas predefinidas. Los dispositivos que lo implementan se
denominan chokes (puede ser la máquina bastión o un elemento diferente).
Proxy
Aplicación o dispositivo hardware que hace de intermediario entre los usuarios,
normalmente entre una red local e Internet. El proxy recibe peticiones de
usuarios y las redirige a Internet.
Algunas de sus características son:
 Servidor de caché: cuando un usuario accede a una página, el
proxy mira si dicha página se encuentra en caché y la "entrega" al
usuario. En caso contrario, el proxy accede a Internet, obtiene la
página y se la envía al usuario.
 Actúa de forma transparente al usuario (aunque el usuario tendrá
que indicar que accede a Internet a través de un proxy, así como la
dirección IP del proxy y el puerto por el que accede).
 Puede realizar funciones de filtrado respecto al acceso de páginas
de Internet.
Política de seguridad
Documento firmado por la alta gerencia de la empresa y mediante el cual se
especifican distintos aspectos referentes a la seguridad informática de la misma
empresa, como por ejemplo:
- número de caracteres de las contraseñas de los usuarios,
- periodo de tiempo de validez de las contraseñas,
- protocolos que se van a permitir entre las máquinas internas y las externas.
- control del acceso restringido a los recursos internos.
2. Decisiones previas al diseño
2.1. Decisiones políticas
2.2. Decisiones técnicas

2.1. Decisiones políticas

A la hora de diseñar o configurar un firewall para una organización es necesario
tomar una serie de decisiones políticas, que se explican a continuación:

1 - Política de seguridad de la organización propietaria del firewall

La configuración y el nivel de seguridad potencial varía según la finalidad con la

que se instala el cortafuegos.
2- Nivel de monitorización, redundancia y control deseado en la organización
Para la implementación de la política a seguir es necesario indicar básicamente
qué se va a permitir y qué se va a denegar. Para ello, se puede adoptar una de las
siguientes posturas:

- Postura restrictiva: se deniega todo excepto lo que explícitamente se permita

(lo más recomendable).
- Postura permisiva: se permite todo excepto lo explícitamente negado.

3 - Valoración económica
El coste económico del firewall (instalación, puesta a punto y mantenimiento)
debe estar en función del valor económico de lo que se desea proteger.

2.2. Decisiones técnicas

Una vez establecidas las decisiones políticas, se ha de tomar una serie de
decisiones técnicas entre las que destacan las siguientes:

1 - Situación del firewall.

Existen diferentes posibilidades para situar un cortafuegos respecto de la red

interna y externa, siempre y cuando abarque todos los equipos que conforman el
perímetro de seguridad de la red interna. De hecho, la instalación de más de
un firewall puede ayudar a aunmentar la seguridad de las partes más importantes
de la organización.
2 - Elemento o elementos físicos a utilizar como host bastión.
Para ello, existen dos principios básicos:

- Mínima complejidad
- Máxima seguridad

Cuanto más simple sea el host bastión (ofrece menos servicios), más fácil será su
mantenimiento y por tanto mayor su seguridad. Es vital la seguridad de dicha
máquina para que el firewall funcione correctamente. Si su seguridad se viera
comprometida, la amenaza se trasladaría a todos los equipos que se encuentran
dentro del perímetro de seguridad.

3 - Elemento a utilizar como choke.

Generalmente suele ser un router con capacidad para filtrar paquetes, aunque
también se puede utilizar un sistema Unix para realizar está función.

3. Componentes de un cortafuegos
En todo cortafuegos existen tres componentes básicos para los cuales se ha de
implementar los mecanismos necesarios para hacer cumplir la política de
seguridad:

3.1. El filtrado de paquetes.

3.2. El proxy de aplicación.
3.3. La monitorización y detección de actividad sospechosa.

3.1. El filtrado de paquetes

El filtrado de paquetes, además de utilizarse para reducir la carga de red, también
se emplea para implementar distintas políticas de seguridad en una red. Respecto
al objetivo principal de dichas políticas de seguridad, es habitual el hecho de
evitar el acceso no autorizado entre dos redes, manteniendo los accesos
autorizados.

Los sistemas de filtrado de paquetes encaminan los paquetes entre los hosts de
una red interna y los hosts de una red externa. De modo selectivo, permiten o
bloquean ciertos tipos de paquetes de acuerdo a una política de seguridad, como
se puede ver en la figura 3.1.2. El tipo de router que se usa en el filtrado de
paquetes se conoce con el nombre de screening router.
 Figura 3.1.1.: Filtrado de paquetes

El funcionamiento es el siguiente:

1. Se analiza la cabecera de cada trama,

2. Se comprueban reglas establecidas de antemano que contemplan:
- Información de la cabecera de la trama:
- el protocolo utilizado (TCP, UDP, ICMP),
- las direcciones fuente y destino,
- los puertos fuente y destino,
- Información que conoce el router acerca del paquete:
- la interfaz del router por donde se ha de reenviar el paquete,
- la interfaz por donde ha llegado el paquete,
3 En función de dichas reglas, la trama es bloqueada o se le permite seguir su
camino.

Un ejemplo sobre cómo se debería programar un screening router para

seleccionar los paquetes que van desde y hacia nuestro sistema, sería el siguiente:

- Bloquear todas las posibles conexiones desede sistemas de fuera de la red

interna, excepto de las conexiones SMTP (para poder recibir correo).

- Bloquear todas las conexiones hacia y desde ciertos sistemas que no nos den
confianza.

- Permitir los servicios de email y FTP, pero bloquear los servicios peligrosos
como TFTP, el sistema X Window, RPC y los servicios "r" (rlogin, rsh, rcp, ...).

Especificación de las reglas

Habitualmente, las reglas 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.

ORIGEN DESTINO TIPO PUERTO ACCIÓN

158.42.0.0 * * * drop
* 195.53.22.0 * * drop
150.128.40.0 * * * accept
* 193.22.34.0 * * drop
Tabla 3.1.1.: Reglas de filtrado

Por ejemplo, supongamos que se tienen las reglas de filtrado de la tabla 3.1.1,
con lo que se pueden dar los siguientes casos:

- Llega un paquete procedente de una máquina de la red 158.42.0.0: se bloquea

su paso, sin importar el destino de la trama.

- Tráfico hacia la red 195.53.22.0: se bloquea.

- Llega un paquete de un sistema de la red 150.128.40.0 hacia 193.22.34.0: una

de las reglas indica que se le permita el paso, pero la siguiente regla indica que se
bloquee sin importar el origen:

- si las reglas se comprueban desde el principio, el paquete atravesaría el

cortafuegos, ya que al analizar las tercera entrada de la fila se finalizarían las
comprobaciones.
- si las reglas se comprueban desde el final, el paquete se bloquearía
inmediatamente.
Como se puede ver, el orden de las entradas en la tabla es determinante para lo
que pueda suceder.

- Llega un paquete que no cumple ninguna de las reglas: la acción depende de la

implementación:

- se deniega el paso por defecto (lo más recomendado),

- se aplica el contrario de la última regla especificada,
- se permite el paso por defecto, ...
ORIGEN DESTINO TIPO PUERTO ACCIÓN
* * * * acción
 Tabla 3.1.2.: Reglas de filtrado: regla por defecto.
Para evitar el dilema, lo mejor es insertar al final de la tabla una regla con la
acción por defecto del tipo, como se puede observar en al tabla 3.1.2,
donde acción tomará el valor drop o accept, según los paquetes que no cumplan
ninguna de las reglas se deseen bloquear o pemitir el paso respectivamente.
Ciertas implementaciones permiten indicar si el bloqueo de un paquete se
notificará a la máquina origen mediante un mensaje ICMP.

Servicio Puerto Servicio Puerto Servicio Puerto Servicio Puerto Servicio Puerto
bootp 67,68 shell 514 dns 53 ntp 123 echo 7
tftp 69 syslog 514 gopher 70 imap 143 discard 9
rpc 111 ftp 20,21 http 80 snmp 161 systat 11
rexec 512 telnet 23 pop 109,110 timed 525 finger 79
rlogin 513 smtp 25 uucp 117,540 printer 515 who 513
rsh 514 time 37 nntp 119 rip 520 whois 43
Tabla 3.1.3.: Puertos correspondientes a diferentes servicios.

Podríamos definir una regla que no dejara pasar ningún paquete proveniente de
Internet, cuyo destino fuese nuestro ordenador y, más concretamente, el puerto
80 (HTTP) de nuestro ordenador. En la tabla 3.1.3 se muestran algunos de los
servicios junto con los puertos correspondientes, que pueden interesar vigilar.

Características:

El filtrado de paquetes cuenta con una serie de puntos fuertes que se indican a
continuación:

- Resulta muy rápido y económico instalar un control basado en el filtrado de

paquetes.

- Resulta totalmente transparente.

- Si el número de reglas creadas no es muy elevado, no llega a imponer una

sobrecarga importante de procesamiento en el screening router, por lo que el
rendimiento de la red no se verá afectado.

Por el contrario, también cabe indicar una serie de debilidades del filtrado de
paquetes:
- Definir las reglas de filtrado puede convertirse en una tarea muy complicada, ya
que existen muchos aspectos en la especificación de los servicios de Internet y de
los protocolos que, si no se conocen a fondo para su correcta configuración,
pueden dejar abierta la puerta a ataques variados (ataques de falsificación de
dirección IP origen, ataques de enrutamiento de origen, ataques de
fragmentación, etc.).

- Cuanto mayor sea el número de reglas, menor será el rendimiento del screening
router, que en principio está diseñado únicamente para enrutar paquetes, no para
tomar decisiones acerca de si debería o no debería hacerlo.

- Si el cortafuegos acepta un servicio no es capaz de bloquear selectivamente

ciertos comandos del servicio o rechazar ciertos contenidos, por lo que son
susceptibles a ataques basados en datos.

Diferencia entre un router ordinario y un screening router:

Un router ordinario simplemente mira la dirección de destino de cada paquete y

escoge el mejor modo de enviar el paquete hacia dicho destino. La decisión sobre
cómo manejar el paquete se basa únicamente en su destino. Se pueden dar dos
posibles casos:

- el router sabe enviar el paquete hacia su destino y lo envía

- el router no sabe enviar el paquete hacia su destino y devuelve el paquete a su
origen con un mensaje ICMP de "destino inalcanzable".
Por otra parte, un screening router examina los paquetes más detenidamente.
Además de determinar si puede encaminar el paquete hacia su destino, decide si
se debería hacerlo, de acuerdo a la política de seguridad con la que se ha
configurado.

3.2. El proxy de aplicación

Un proxy de aplicación es una aplicación software capaz de filtrar las conexiones
a servicios, es decir, capaz de reeenviar o bloquear conexiones a servicios.
Los proxies cogen las peticiones de los usuarios sobre servicios de Internet, como
FTP y Telnet, y responden a dichas peticiones según la política de seguridad.
Los proxies proporcionan conexiones y actúan de pasarela entre la propia
máquina o la red interna y la red externa. Por este motivo, también se
denominan pasarelas de nivel de aplicación.

La actuación de un proxy entre un usuario de la red interna y un servicio de la red

externa es más o menos transparente.
Como se puede observar en la figura 3.2.1 un proxy requiere dos componentes:
un servidor proxy y un proxy cliente. El servidor proxy se ejecuta en
un host situado entre la red interna y la externa, mientras que el proxy cliente es
una versión especial de un programa cliente normal como Telnet o FTP cliente,
que se comunica con el servidor proxy como si fuera el servidor "real" de la red
externa. El servidor proxy evalua las peticiones del proxy cliente y decide si
aprobar o denegar la petición.Si la petición se aprueba deacuerdo a la política de
seguridad, el servidor proxy contacta con el servidor "real" y mandará las
respuestas del servidor "real" al proxy cliente.

Figura 3.2.1.: Proxy de aplicación.

Con los proxies de aplicación se cuenta con una serie de ventajas sobre seguridad
como por ejemplo las siguientes:

- Sólo permiten la utilización de servicios para los que existe un proxy, por lo que
el administrador de red tiene un control absoluto sobre los servicios soportados
por el proxy.

- En comparación con el filtrado de paquetes, en la pasarela es posible filtrar

protocolos basándose en algo más que en la cabecera de las tramas. De este
modo, resulta posible tener habilitado un servicio con sólo una serie de comandos
permitidos.

- La pasarela de aplicación permite un grado de ocultación de la estructura del

perímetro de seguridad, ya que se pueden enmascarar la dirección de las
máquinas de la red interna. Es decir, actúan como traductores de direcciones de
red (NAT).
- Debido al hecho de que las aplicaciones proxy son componentes software
ejecutándose en la máquina bastión, se facilita la autenticación y la auditoría del
tráfico sospechoso antes de que alcance el host destino.

- Se simplifican las reglas de filtrado implementadas en el router, ya que

únicamente se permite el tráfico hacia la pasarela, bloqueando el resto. Además,
la definición de las reglas de filtrado a nivel de aplicación es mucho más sencilla
que a nivel de paquete, pudiendo implementar reglas más conservadoras con
mayor flexibilidad.

Por otra parte, a la hora de instalar una pasarela de aplicación nos encontramos
con los siguientes inconvenientes:
- Los cortafuegos más antiguos requerían que el usuario de la red interna
instalara software especial de cliente para cada uno de los servicios habilitados.
Otros requerían que, empleando el software de cliente habitual, se siguieran
ciertas indicaciones de uso. De este modo, nuevas aplicaciones de Internet
exigían escribir e instalar nuevos servicios proxy en el firewall y nuevos clientes
proxy en los ordenadores de los usuarios. Hoy en día, los cortafuegos de
aplicación son completamente transparentes para los usuarios finales.

- Es un elemento usualmente más caro y de rendimiento menor que un filtro de

paquetes.

- En el caso de protocolos cliente-servidor, se requieren dos pasos para conectar

hacia la zona segura o hacia el resto de la red.

- Algunas implementaciones necesitan clientes modificados para funcionar

correctamente.

- Se puede producir una degradación en el rendimiento, en el caso de que sean

muchos los servicios proxy en la misma máquina y las reglas de filtrado sean
complejas.

- Para una total seguridad, se requiere un mecanismo adicional que restrinja las
comunicaciones directas entre las máquinas de la red interna y las del exterior,
como es el filtrado de paquetes.

Una variante de las pasarelas de aplicación la constituyen las pasarelas de nivel

de circuito (Circuit-level Gateways), que son sistemas capaces de redirigir
conexiones (reenviando tramas). Estos sistemas no pueden procesar o filtrar
paquetes en base al protocolo utilizado, sino que se limitan únicamente a
autenticar al usuario (a su conexión) antes de establecer el circuito virtual entre
sistemas. Además resultan ventajosos en cuanto a que proveen de servicios a un
amplio rango de protocolos. Sin embargo, necesitan software especial que tenga
las llamadas al sistema clásicas sustituidas por funciones de librería seguras,
como SOCKS.

3.3.La monitorización y detección de actividad

sospechosa
Un firewall, como cualquier sistema de seguridad bueno, ha de permitir el
seguimiento de los registros anómalos y permitidos realizados hacia y desde el
sistema. Por lo tanto , resulta imprescindible monitorizar la actividad
del firewall para la seguridad del perímetro protegido. La monitorización facilita
información sobre:
- Intentos de ataque: origen, franjas horarias, tipos de acceso, ...
- Existencia de tramas sospechosas.
La información que se debe registrar es la siguiente:
- Tipos de paquetes recibidos, frecuencias, direcciones fuente y destino,
- Información de la conexión: origen y destino, nombre de usuario, hora y
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)
- Tramas recibidas desde routers desconocidos.
Para registrar esta información es necesario indicar las siguientes características:
- Información de servicio: fecha y hora.
- Información remota: la/s dirección/es IP del presunto atacante, así como su
puerto y el protocolo de comunicación utilizado.
- Información Local: dirección IP de destino y su puerto de acceso.
- Filtrado de Información: forma en que ha actuado el filtro que empleamos y qué
adaptador de red lo hizo.
- Paquetes de información: primeras líneas (de identificación) de cada uno de los
paquetes (generalmente, en formato hexadecimal).
Todos estos registros quedan almacenados en archivos de registro (log), que han
de ser leidos con frecuencia y el administrador de la red ha de tomar medidas si
se detectan actividades sospechosas.

Cabe mencionar la tecnología Stateful Multi-Layer Inspection (SMLI) que

constituye una extensión del filtrado de paquetes, ya que no se limita a examinar
los paquetes a nivel de red, sino que los analiza a todos los niveles de la pila de
protocolos, al tiempo que extrae información relevante sobre el estado de la
comunicación y de la aplicación. Para cada conexión TCP o UDP, el cortafuegos
crea una tabla con las direcciones IP de origen y destino, números de puertos
origen y destino, números de secuencia de los paquetes, entre otros datos
adicionales asociados a la conexión en particular.
De este modo, gracias a su motor de isnpección y la información de estado de la
conexión almacenada en las tablas, el firewall puede implantar la política de
seguridad de la organización.

Este motor de inspección cuenta con una serie de ventajas como las que se
describen a continuación:

- El rendimiento no se ve afectado notablemente, ya que son más rápidos al

operar principalmente a los niveles bajos de la pila de protocolos. De este modo,
no afecta el número de usuarios conectados a través del cortafuegos.

- Se puede adaptar a protocolos y aplicaciones nuevamente definidos, facilitando

así la escalabilidad. Es decir, el cortafuegos es transparente para las aplicaciones
y los usuarios, ya que no necesitan modifiacr o instalar software adicional.

Como contrapunto, la tecnología SMLI no es capaz de evitar los ataques más

sofisticados enmascarados a nivel de aplicación, como desboradamientos de
buffer o comandos de aplicación ilegales o inseguros.

4. Tipos de cortafuegos
Un firewall actúa en los niveles 3 (nivel de red) a 7 (nivel de aplicación) del
modelo de referencia OSI. Según la forma de implementar la política de
seguridad de la organización, se distinguen tres tipos de cotafuegos dependiendo
del nivel en el que se implementa:

1. - Cortafuegos a nivel 3 de modelo de referencia OSI (nivel de red o nivel IP en

redes TCP/IP)

Se pueden considerar como filtros de paquetes, ya que lo que hacen es filtrar los
intentos de conexión, fundamentalmente en base a las direcciones IP de origen y
destino, el puerto de destino de los paquetes IP y el protocolo. Puesto que
analizar este tipo de información resulta sencillo, este tipo de cortafuegos suelen
ser muy rápidos y trasparentes al usuario.
2. - Cortafuegos a nivel 4 del modelo de referencia OSI (nivel de transporte o
nivel de TCP en redes TCP/IP)
En este caso, distinguen si los paquetes corresponden a un inicio de conexión o
bien se trata de paquetes cuyas conexiones ya están establecidas.
3. - Cortafuegos a nivel 7 del modelo de referencia OSI (nivel de aplicación)
Los cortafuegos de este tipo actúan a modo de proxy para las diferentes
aplicaciones que va a controlar.Dicho control se realiza interceptando las
comunicaciones a nivel del protocolo de comunicaciones propio de cada servicio;
se conocen los detalles del protocolo de comunicaciones del servicio
interceptado, se analiza su correcto funcionamientoy se añaden los pasos de
control precisos de cada servicio.
De este modo, se pueden implementar políticas de seguridad para los protocolos
como las siguientes:

- para el protocolo SMTP, se puede indicar la dirección de destino que tiene que
tener el correo entrante o la dirección de origen que tiene que tener el correo
saliente.
- para el protocolo HTTP, se pueden evitar los controles ActiveX o applets de
Java de las páginas que se descarguen los usuarios, o incluso denegarles el acceso
a ciertas URLs.
- para el protocolo FTP, se puede permitir el acceso a servidores únicamente a
determinado directorio y sólo para enviar o descargar ficheros.

Este tipo de cortafuegos puede suponer una mayor carga de trabajo, pero se
consigue un control más fuerte de todo el proceso de comunicación de los
servicios habilitados.

5. Utilidades de un firewalll
Un cortafuegos ofrece los aspectos que se describen a continuación:

1- Aislamiento de Internet.

El firewall restringe el acceso hacia/desde la red interna sólo a ciertos servicios, a

la vez que analiza todo el tráfico que pasa por el mismo.
2- Cuello de botella.
Busca concentrar la administración y monitorización de la seguridad de la red en
un solo punto. Mantiene a los atacantes y peligros alejados de la red interna,
prohibe en los dos sentidos servicios susceptibles a ataques y proporciona
protección ante algunos tipos de ataques basados en el "enrutamiento" de
paquetes.
3- Auditoría y registro de uso.
Constituye un buen lugar donde recopilar información sobre el uso de la red. En
su calidad de punto único de acceso, el cortafuegos puede registrar toda la
actividad entre la red exterior y la interior. Con todos estos datos, el
administrador puede posteriormente estudiar estadísticamente el tipo de tráfico,
las horas de mayor carga de trabajo, el ancho de banda consumido y, por
supuesto, todos los intentos de intrusión o las pistas dejadas por un atacante.
4- Seguridad de contenidos.
Una característica incorporada por un número cada vez mayor de cortafuegos es
la inspección antivirus del material transmitido a través de determinados
servicios. Presenta el problema de consumir muchos recursos, ya que se deben
descomprimir o decodificar ciertos ficheros (ZIP, MIME, Uuencode),
escanearlos y tomar una decisión antes de retransmitirlos dentro de la
red.Algunos cortafuegos bloquean también programas en Java, controles
ActiveX, guiones en JavaScript o en VisualBasic Script, que pueden ser
potencialmente peligrosos, bien formando parte del contenido de un mensaje de
correo o de una página web.
5- Autenticación.
Algunos cortafuegos permiten autenticarse utilizando métodos sofisticados,
basados en tarjetas inteligentes, contraseñas de un solo uso, llaves hardware, etc.
6- Ocultamiento del rango de direccionamientos internos de la organización.
Es lo que se conoce como NAT (Network Address Translation) que realiza una
traducción de las direcciones de red, de modo que las direcciones de las
máquinas internas quedan ocultas cara el exterior. Una posibilidad sería contar
con un rango reducido de direcciones válidas en Internet y un elevado número de
direcciones privadas para las máquinas internas a las que no se permite un acceso
desde la red externa.

6. Amenazas fuera del alcance de un

cortafuegos
Los cortafuegos no suponen la solución definitiva a todos los problemas de
seguridad. A pesar de todas sus ventajas, existen amenazas fuera de su alcance,
contra las cuales se deben buscar otros métodos de protección. Algunas de estas
amenazas son:

1. Ataques internos dentro del perímetro de seguridad de la organización.

Resulta conocido el hecho de que el mayor número de ataques informáticos y de
robos de información es perpetrado por los trabajadores de la propia
organización, empleados desleales o espías infiltrados.
2. Ataques que no pasan a través del cortafuegos.
Los accesos realizados por los trabajadores de la compañía vía módem a
ordenadores de la red no son filtrados por el cortafuegos. Comunmente se los
conoce como puertas traseras a la red, ya que permiten entrar sin pasar por la
puerta principal (el cortafuegos).
3. Ataque de virus sofisticados.
A pesar de la protección antivirus que proporcionan algunos cortafuegos, esta
tarea resulta difícil dada la variedad de plataformas y redes, la diversidad de
codificaciones de ficheros binarios y la mutabilidad de los virus. El cortafuegos
se debe considerar sólo como una primera línea de defensa y no como una
barrera absoluta, por lo que cada una de las máquinas de la red interna debería de
contar con su propio software antivirus debidamenrte actualizado.
4. Ataques basados en datos.
Dado que muchos de los programas que se acceden a través de protocolos
permitidos por el cortafuegos tienen fallos, éste se ve impotente a la hora de
impedir que se lleven a cabo.
5. Ataques de los que no se tiene conocimiento.
El ingenio de los hackers siempre avanza más rápidamente que los diseñadores
de aplicaciones de protección, descubriendo ataques a servicios que se
consideraban como seguros.
A parte de las amenazas que no cubre un cortafuegos, nos encontramos con otros
problemas como pueden ser los siguientes:

- Producen una falsa sensación de seguridad, ya que cuando se instala un

cortafuegos, el administrador puede tender a despreocuparse de todas y cada una
de las máquinas que conforman la red interna de la organización.

- Es necesaria la reconfiguración de los sistemas al pasarlos de una zona a otra

con diferente nivel de seguridad.

- Centralizan todas las medidas de seguridad en un único sistema, de forma

que si éste se ve comprometido y el resto de la subred no está lo suficientemente
protegida, el atacante consigue amenazar a toda la subred simplemente con el
ataque a una máquina.

7. Arquitecturas de firewalls
7.1. Cortafuegos de filtrado de paquetes
7.2. Arquitectura Dual-Homed Host
7.3. Screened Host
7.4. Screeened Subnet
7.5. Otras arquitecturas

7.1. Cortafuegos de filtrado de paquetes

El modelo de cortafuegos más antiguo consiste en un dispositivo capaz de filtrar
paquetes, lo que se denomina choke. Está basado simplemente en aprovechar la
capacidad que tienen algunos routers para bloquear o filtrar paquetes en función
de su protocolo, su servicio o su dirección IP.

Esta arquitectura es la más simple de implementar y la más utilizada en

organizaciones que no precisan grandes niveles de seguridad, donde
el router actúa como de pasarela de la subred y no hay necesidad de
utilizar proxies, ya que los accesos desde la red interna al exterior no bloqueados
son directos. Resulta recomendable bloquear todos los servicios que no se
utilicen desde el exterior, así como el acceso desde máquinas que no sean de
confianza hacia la red interna.

Sin embargo, los chokes presentan más desventajas que beneficios para la red
protegida, puesto que no disponen de un sistema de monitorización sofisticado y
el administrador no distingue entre si el router está siendo atacado o si su
seguridad se ha visto comprometida. Por otra parte, las reglas de filtrado pueden
llegar a ser complejas de establecer y por lo tanto, se hace difícil comprobar su
correción.

7.2. Arquitectura Dual-Homed Host

Este modelo se compone de simples máquinas Unix, denominadas anfitriones de
dos bases, equipadas con dos tarjetas de red: una se conecta a la red interna a
proteger y la otra a la red externa. De este modo, los sistemas de la red interna se
pueden comunicar con el dual-homed host, así como los sistemas del exterior
también se pueden comunicar con el dual-homed host; es decir, el tráfico entre la
red interna y el exterior está completamente bloqueado. En este caso el choke y
el bastión coinciden en el mismo equipo.

Los dual-homed hosts pueden proporcionar un nivel de control muy elevado.

Como no se permite el tráfico de paquetes entre la red interna y la externa, un
paquete de fuente externa será indicativo de alguna clase de problema de
seguridad. Todo el intercambio de datos entre las redes se realiza a través
de servidores proxy situados en el host bastión. Para cada uno de los servicios
que se deseen pasar a través del firewall, se ha de ejecutar un servidor proxy.
También es necesario que esté desabilitado el IP Forwarding para que
el choke no encamine paquetes entre las dos redes.

El uso de proxies es mucho menos problemático, pero puede no estar disponible

para todos los servicios en los que estemos interesados. La siguiente arquitectura
de cortafuegos incorpora opciones extra que permiten proporcionar nuevos
servicios.

7.3. Screened Host

En esta arquitectura se combina un screening router con un host bastión y el
principal nivel de seguridad proviene del filtrado de paquetes. El screening
router está situado entre el host bastion y la red externa, mientras que el host
bastión está situado dentro de la red interna.

El filtrado de paquetes en el screening router está configurado de modo que

el host bastión es el único sistema de la red interna accesible desde la red externa.
Incluso, únicamente se permiten ciertos tipos de conexiones. Cualquier sistema
externo que intente acceder a los sistemas internos tendrán que conectar con
el host bastión. Por otra parte, el filtrado de paquetes permite al host establecer
las conexiones permitidas, de acuerdo con la política de seguridad, a la red
externa.

Figura 7.3.1.: Screened Host.

La configuración del filtrado de paquetes en el screening router se puede hacer
de dos formas:

- Permitir a otros hosts internos establecer conexiones a hosts de la red exterior

para ciertos servicios.
- Denegar todas las conexiones desde los hosts de la red interna , forzando a los
hosts a utilizar los servicos proxy a través del host bastion.
Es decir, los servicios se pueden permitir directamente via filtrado de paquetes o
indirectamente via proxy, tanto para los usuarios internos como para los usuarios
externos.

7.4. Screeened Subnet

La arquitectura Screened Subnet también se conoce con el nombre de red
perimétrica o De-Militarized Zone (DMZ). En los modelos anteriores, la
seguridad se centraba completamente en el host bastión, de manera que si la
seguridad del mismo se veía comprometida, la amenaza se extendía
automáticamente al resto de la red. En cambio, en este modelo se 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 consigue reducir los efectos de
un ataque exitoso al host bastión. La arquitectura DMZ intenta aislar la
máquina bastión en una red perimétrica, de forma que si un intruso accede a esta
máquina no consigue un acceso total a la subred protegida.

Figura 7.4.1:Screened Subnet.

Se trata de la arquitectura de firewalls más segura, pero también más compleja.
En este caso se emplean dos routers, exterior e interior, ambos conectados a la
red perimétrica como se observa en la figura 7.4.1. En dicha red perimétrica, que
constituye el sistema cortafuegos, se incluye el host bastión. 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 la
red interna.

La misión del router exterior es bloquear el tráfico no deseado en ambos

sentidos, es decir, tanto hacia la red perimétrica como hacia la red externa. En
cambio, el router interior bloquea el tráfico no deseado tanto hacia la red
perimétrica como hacia la red interna. De este modo, para atacar la red protegida
se tendría que romper la seguridad de ambos routers.

En el caso en que se desee obtener un mayor nivel de seguridad, se pueden

definir varias redes perimétricas en serie, situando los servicios que requieran de
menor fiabilidad en las redes más externas. Un posible atacante tendría que pasar
por todas y cada una de las redes perimétricas para llegar a acceder a los equipos
de la red interna. Resulta evidente que cada red perimétrica ha de seguir
diferentes reglas de filtrado, ya que en caso contrario los niveles adicionales no
proporcionarían una mayor seguridad.

Aunque se trata de la arquitectura más segura, también pueden aparecer

problemas. Uno de ellos se puede dar cuando se emplea el cortafuegos para que
los servicios fiables pasen directamente sin acceder al bastión, lo que puede
desencadenar en un incumplimiento de la política de seguridad. Otro problema,
es que la mayor parte de la seguridad reside en los routers empleados. Las reglas
de filtrado sobre estos elementos pueden ser complicadas de establecer y
comprobar, lo que puede desembocar en importantes fallos de seguridad del
sistema.

7.5. Otras arquitecturas

Una manera de incrementar en gran medida el nivel de seguridad de la red
interna y al mismo tiempo facilitar la administración de los cortafuegos consiste
en emplear un host bastión distinto para cada protocolo o servicio en lugar de un
único host bastión. Muchas organizaciones no pueden adoptar esta arquitectura
porque presenta el inconveniente de la cantidad de máquinas necesarias para
implementar el cortafuegos. Una alternativa la constituye el hecho de utilizar un
único bastión pero distintos servidores proxy para cada uno de los servicios
ofrecidos.
Otra posible arquitectura se da en el caso en que se divide la red intena en
diferentes subredes, lo cual es especialmente aplicable en organizaciones que
disponen de distintas entidades separadas. En esta situación es recomendable
incrementar los niveles de seguridad de las zonas más comprometidas situando
cortafuegos internos entre dichas zonas y la red exterior. Aparte de incrementar
la seguridad, los firewalls internos son especialmente recomendables en zonas de
la red desde la que no se permite a priori la conexión con Internet.

8. IPTABLES: Herramienta para el

filtrado de paquetes
Se trata de la herramienta de última generación sobre filtros de paquetes en
Linux, flexible y potente. Para su uso es necesario disponer de un kernel 2.3.15
o superior.

En Linux, el filtrado de paquetes está construido en el kernel y para poder

utilizarlo se ha de compilar el núcleo configurando las siguientes opciones:

CONFIG_PACKET: Permite aplicaciones y programas que necesitan trabajar

directamente en ciertas máquinas de red. Un ejemplo sería tcpdump o snort.

CONFIG_NETFILTER: Para usar el computador como un firewall o pasarela a

Internet. Totalmente necesario para el objetivo de este apartado.

CONFIG_IP_NF_IPTABLES: Para realizar cualquier clase de filtrado,

masquerading o NAT. Es necesario para poder utilizar IPTables.

Por otra parte, hay que añadir los drivers aporpiados para las interfaces trabajen
adecuadamente, es decir, Ethernet, PP y SLIP. En el caso de que se quieran
emplear las opciones más avanzadas de IPTables, es necesario una
configuración apropiada en el kernel. Seguidamente se muestran las opciones
disponibles en el kernel 2.4.9 para este propósito:
CONFIG_IP_NF_CONNTRACK: Para usar NAT y Masquerading.

CONFIG_IP_NF_MATCH_LIMIT: Añade la posibilidad de controlar cuantos

paquetes por minuto se supone que son afectados con una cierta regla.
CONFIG_IP_NF_MATCH_MAC: Permite examinar paquetes basados en
direcciones MAC. Todos los adaptadores Ethernet tienen su propia dirección
MAC.

CONFIG_IP_NF_MATCH_MARK: Para filtrar paquetes basándose en el target

MARK.

CONFIG_IP_NF_MATCH_MULTIPORT: Para filtrar paquetes con un amplio

rango de puertos destino y puertos fuente.

CONFIG_IP_NF_MATCH_TOS: Para filtrar paquetes basándose en el campo

TOS (Type Of Service).

CONFIG_IP_NF_MATCH_TCPMSS: Para filtrar paquetes TCP SYN basándose

en el campo MSS.

CONFIG_IP_NF_MATCH_STATE: Contará como ESTABLECIDO cuando se

haya dado el tráfico en las dos direcciones en una conexión TCP, por ejemplo.

CONFIG_IP_NF_MATCH_UNCLEAN: Para filtrar paquetes TCP, UDP o ICMP

que parezcan extraños o incorrectos.

CONFIG_IP_NF_MATCH_OWNER: Para permitir que únicamente el usuario

root pueda tener acceso a Internet.

CONFIG_IP_NF_FILTER: Añade la tabla básica de filtrado en la que se

encuentran las chains INPUT; OUTPUT Y FORWARD.

CONFIG_IP_NF_TARGET_REJECT: Para permitir enviar un mensaje de error

ICMP para los paquetes que son rechazados.

CONFIG_IP_NF_TARGET_MIRROR: Para devolver los paquetes de entrada

rechazados al emisor de los mismos.

CONFIG_IP_NF_NAT: Para permitir la traducción de direcciones de red

(NAT).

CONFIG_IP_NF_TARGET_MASQUERADE: Para añadir la target masquerade.

CONFIG_IP_NF_COMPAT_IPCHAINS:Para añadir la compatibilidad con

IPChains.
CONFIG_IP_NF_COMPAT_IPFWADM: Para añadir la compatibilidad con
IPWadm.

Con la herramienta IPTables se puede insertar y borrar reglas desde la tabla de

filtrado de paquetes del kernel. Como se trata de información dinámica, es
recomendable crear un script que se ejecute cada vez que se arranque el
sistema, que defina las reglas establecidas.

Existen tres listas de reglas de filtrado (firewall chains o chains) predefinidas:

- Chain de entrada (INPUT)

- Chain de salida (OUTPUT)
- Chain de reenvío (FORWARD)

Dichas listas de reglas se interpretan del modo siguiente:

Llega un paquete

"Ruteo" o "Enrutamiento": el kernel mira el destino de dicho paquete

Destino = el propio equipo Destino = otro interfaz de red

No se tiene
El paquete pasa Se tiene activado
activado el
a la chain INPUT el reenvío
reenvío

El El paquete pasa
El paquete se El paquete no se
paquete no se a la chain
acepta acepta
acepta FORWARD
 El proceso El
El
esperando el paquete
paquete
paquete lo no se
se acepta
recibe. acepta

Un programa
decide enviar
paquetes

Los paquetes
Los paquetes se
pasan RED
aceptan
a la chain
OUTPUT

Los paquetes no
se aceptan

Tabla 8.1: Interpretación de las chains.

Las listas de reglas se basan en la cabecera de los paquetes para determinar la

acción a llevar a cabo (lo que en ipchains se denomina "objetivo" o target). Si
una regla no se puede aplicar a un determinado paquete, entonces se examina la
siguiente regla y así sucesivamente hasta encontrar una regla que se le pueda
aplicar y que determine si se acepta o se rechaza dicho paquete.

Si en una lista no existe ninguna regla que se pueda aplicar al paquete en

cuestión, entonces el kernel examina la política de seguridad para averiguar que
acción se toma en ese caso (acción por defecto). Normalmente, en un sistema con
una buena política de seguridad, se ignora el paquete (DROP) en lugar de
aceptarlo (ACCEPT).
Cabe señalar que únicamente las chains predefinidas (INPUT,
OUTPUT, FORWARD) disponen de política (ACCEPT o DROP). Si un paquete
no cumple ninguna de las reglas de una chain definida, entonces regresa a la
chain anterior.

Especificación de una regla

Para añadir una regla a una lista de reglas existente se emplea el siguiente
comando:
$iptables -A nombre_chain [ -s | --source | --src | -s ! ] direccion

[ -d | --destination |--dst ] direccion

[ -i | --in-interface ] interfaz_entrada
[ -o | --out-interface ] interfaz_salida
[ -p | -p ! ] protocolo
-j [ accept | drop ]

El interrogante tras un parámetro se refiere a todos los casos excepto el indicado

en la especificación de la regla.
Las direcciones de origen o de destino se pueden especificar de diferentes
maneras:

- nombre completo:
'moon.act.uji.es'
- dirección IP específica:
'150.128.82.211'
- direcciones IP desde 150.128.82.0 a 150.128.82.255:
'150.128.82.0/24'
- cualquier dirección:
'0/0'

La especificación del protocolo puede realizarse mediante:

- un número : valor número del protocolo para IP
- un nombre : TCP, UDP, ICMP.

Comando y
Significado
ejemplo

-A, --append
$iptables -A Añade una regla al final de la chain indicada.
INPUT ...

-D, --delete
$iptables -D Borra una regla de la chain indicada.
INPUT ...

-R, --replace
Reemplaza una regla de una chain determinada, cuyo
$iptables -R
INPUT 1 ... número se indica, por la que se especifica seguidamente.

-I, --insert
Añade una regla a una chain determinada con el número
$iptables -I
INPUT 1 ... indicado.
 -F, --flush
Vacia la chain indicada o bien todas las chains si no se
$iptables -F
INPUT especifica ninguna.

-L, --list Lista las entradas de una chain determinada o bien todas
$iptables -L las chains en ausencia de la especificación de una chain
INPUT determinada.

-N, --new-
chain Indica al kernel la creación de una nueva chain con el
$iptables -N nombre especificado.
nueva

-Z, --zero
Identifica todos los contadores de una determinada chain
$iptables -Z
INPUT o de todas si no se especifica ninguna.

-X, --delete-
chain
Borra la chain indicada, que no debe tener ninguna regla.
$iptables -X
nueva

-P, --policy
Indica al kernel que establezca una política por defecto en
$iptables -P
INPUT DROP una chain determinada.

-E, --rename-
chain Canvia el nombre a una chain creada por el propio
$iptables -E usuario.
nueva kiss

Tabla 8.2: Comandos básicos para el manejo de chains.

En una regla también se puede especificar una interfaz, es decir, el dispositivo

físico por el que entran o salen los paquetes. Para las listas de reglas predefinidas
se pueden especificar lógicamente:

- para la chain INPUT: interfaz de entrada

- para la chain OUTPUT: interfaz de salida
- para la chain FORWARD: interfaz de entrada e interfaz de salida

Para indicar todos los interfaces que empiecen por una cadena se emplea: "-i
cadena+". Por otra parte, para indicar todos los interfaces excepto el especificado
se utiliza: "-i ! interfaz". El uso del interrogante para indicar todos las
posibilidades de un parámetro excepto el indicado se puede dar en todas las
opciones de especificado de una regla.
 Comando y
Significado
ejemplo

-p, --protocol
$iptables -A Indica un protocolo determinado para los paquetes que
OUTPUT -p ICMP se desean filtrar. Ejemplos: TCP, UDP e ICMP.
...

-s, --src --
source
$iptables -A Indica un filtrado basado en la direccion fuente de los
OUTPUT -s paquetes (dirección IP).
150.128.40.100
...

-d, --dst --
destination
$iptables -A Indica un filtrado basado en la direccion destino de los
OUTPUT -d paquetes (dirección IP).
150.128.40.100
...

-in, --in-
interface El filtrado se basa en la interfaz de donde proviene el
$iptables -A paquete.
INPUT -i eht0

-out, --out-
interface
El filtrado se basa en la interfaz a donde se dirigen los
$iptables -A
FORWARD -o paquetes.
eht0

Tabla 8.3: Parámetros para especificar las reglas de filtrado.

Comando y ejemplos Significado

-sport, --source-prot
$iptables -A INPUT -p TCP --sport 22 Indica el puerto fuente.
$iptables -A INPUT -p UDP --sport 53

-sport, --source-prot
$iptables -A INPUT -p TCP --sport 22 Indica el puerto destino.
$iptables -A INPUT -p UDP --sport 53

Tabla 8.4: Parámetros adicionales para el protocolo TCP y UDP.

Ejemplo:
Si se hace un ping a anubis.uji.es se está enviando tantos paquetes ICMP del
tipo 8 (petición de eco) como se indique con el parámetro "-c" y se recibirán los
paquetes ICMP del tipo 0 (respuesta del eco) como se observa en la figura 8.2..

$ping -c 5 anubis.uji.es
PING anubis.uji.es (150.128.40.100): 56 data bytes
64 bytes from 150.128.40.100: icmp_seq=0 ttl=253
time=1.1 ms
64 bytes from 150.128.40.100: icmp_seq=1 ttl=253
time=1.0 ms
64 bytes from 150.128.40.100: icmp_seq=2 ttl=253
time=1.4 ms
64 bytes from 150.128.40.100: icmp_seq=3 ttl=253
time=1.0 ms
64 bytes from 150.128.40.100: icmp_seq=4 ttl=253
time=1.0 ms

--- anubis.uji.es ping statistics ---

5 packets transmitted, 5 packets received, 0% packet
loss
round-trip min/avg/max = 1.0/1.1/1.4 ms
Ejemplo 8.1.1
Si se añade la siguiente regla a la chain INPUT:
$iptables -A INPUT -s 150.128.40.100 -p icmp -j DROP

entonces los paquetes que provienen de anubis serán ignorados. El efecto se

puede ver en la figura 8.3 al repetir de nuevo la misma operación.
$ping -c 5 anubis.uji.es
PING anubis.uji.es (150.128.40.100): 56 data bytes

--- anubis.uji.es ping statistics ---

5 packets transmitted, 0 packets received, 100%
packet loss
Ejemplo 8.1.2

En ocasiones los paquetes se fragmentan a la hora de ser enviados de forma que

las cabeceras que consultan las reglas de filtrado únicamente aparecen en el
primer paquete. Por ello, existe un parámetro que permite especificar reglas para
el segundo y siguientes fragmentos:

-f | --fragment

Ejemplo:
Si se quieren ignorar todos los fragmentos que se envien a anubis se emplearía
la orden:
$ipchains -A output -f -d anubis.uji.es -j DROP

Eliminar una regla de una lista

Para añadir una regla a una chain existente, conociendo el número de dicha
regla, se emplea el siguiente comando:
$iptables -D nombre_lista número_regla

En el caso en que se desconozca el número de la regla, basta con sustituir -A por

-D en la orden de especificación de la regla a borrar:
$iptables -D nombre_lista -s direccion -p protocolo -j accion

Ejemplo:
Supongamos que se desea eliminar la regla anteriormente definida. Si se trata
de la única regla que hemos definido en la chain INPUT, bastará con la orden:
$iptables -D INPUT 1

Si por el contrario desconocemos el número de la regla estonces ejecutamos:

$iptables -D INPUT -s 150.128.40.100 -p icmp -j DROP

Manejo de nuevas listas de reglas

A parte de las chains predefinidas, el usuario puede crear sus propias listas de
reglas con la orden:
$iptables [-N | --new-chain ] nombre_chain

Si en un momento dado, el usuario decide borrar una lista de reglas que haya
creado anteriormente, en primer lugar ha de vaciar la lista con el siguiente
comando:
$iptables [-F | --flush ] nombre_chain

Una vez vacía, la chain se elimina a través de la orden:

$iptables [-X | --delete-chain ] nombre_chain

Para ver el contenido de una lista de reglas existe el siguiente comando:

$iptables-L nombre_chain

Ejemplo:
Se establecen polícas por defecto de denegar:
$ iptables -P INPUT DROP
$ iptables -P OUTPUT DROP
$ iptables -P FORWARD DROP

Se deniega la entrada de todos lo paquetes ICMP:

$ iptables -A INPUT -p ICMP -j DROP

$ iptables -L
Chain input (policy DROP):
Chain forward (policy DROP):
Chain output (policy DROP):
target prot opt source destination ports
DROP icmp ------ anywhere anywhere any -> any

Hay que tener en cuenta que el usuario nunca podrá borrar ninguna de las chains
predefinidas (INPUT, OUTPUT, FORWARD), aunque por le contrario si será
posible vaciarlas.

Especificaciones de destino
A parte de las acciones pre-compiladas (DROP y ACCEPT) a llevar a cabo en una
regla, el usuario puede definir chains que se especifiquen como acción. Las
chains definidas por el usuario pueden a su vez "saltar" a otras chains definidas
por él mismo (la regla de una chain tiene como acción otra chain).

Ejemplo:

Supongamos que la chain INPUT está formada por las reglas especificadas en la
tabla xx y el usuario ha definido una nueva lista de reglas
llamada own_test como se puede ver en la tabla xx:

Chain INPUT

Rule1: -p TCP -j own_test

Rule2: -p UDP -j DROP

Tabla 8.4.

Chain own_test

Rule1: -s 192.168.1.1 -j
DROP
 Tabla 8.5.

Analicemos el caso en el que llega un paquete TCP de la dirección IP

192.168.1.1. El paquete pasa a la chain INPUT y se examina la primera regla;
como la cumple se lleva a cabo la acción especificada, que es 'saltar' a la
chain own_test. El paquete cumple la única regla de dicha lista, por lo que se
produce la acción indicada, es decir, se ignora. Ya no sería necesario seguir
comprobando las reglas de la chain INPUT.