Next: Kerberos Up:
Seguridad de la subred Previous: Algunos servicios y protocolos
Índice General
Subsecciones
Según [Ran95], un firewall
o 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 router 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 amenaza 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.
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 12.1 (a)). Sin embargo, en la mayoría de organizaciones
- especialmente en las de I+D - 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 12.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 aproximaciones consiste en implementar cierta separación lógica
mediante un cortafuegos (figura 12.1 (c)).
Figura 12.1: (a) Aislamiento. (b) Conexión total. (c)
Firewall entre la zona de riesgo y el perímetro de seguridad.
Antes de hablar de cortafuegos es casi obligatorio dar una serie de definiciones
de partes o características de funcionamiento de un firewall; por
máquina o host bastión (también se denominan
gates) 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
firewall, y el resto de Internet) de acuerdo a unas normas predefinidas; aunque
el filtro más elemental puede ser un simple router, trabajando
en el nivel de red del protocolo 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 firewall
a un simple router 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
situan habitualmente en el host bastión. También se implementa
en el choke un mecanismo de filtrado de paquetes, y en alguno de los dos
elementos se suele situar otro mecanismo para poder monitorizar y detectar la
actividad sospechosa.
En este capítulo hablaremos de los tipos de cortafuegos más habituales
y de sus características, así como de las posibles políticas
de seguridad que pueden implementar; también comentaremos aspectos de dos
de los cortafuegos más utilizados hoy en día: FW-1 y la
herramienta de Linux ipchains. Los firewalls 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, centralizan todas las medidas en un único
sistema, de forma que si éste se ve comprometido y el resto de nuestra
red no está lo suficientemente protegido el atacante consigue amenazar
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 un firewall 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
- recordemos que es un sistema muy expuesto a ataques externos - automáticamente
va a tener la posibilidad de controlar toda nuestra red.
Además - esto ya no es un problema de los firewalls sino algo de
sentido común -, 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 modem en sus PCs o 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 (veremos
más adelante lo que estas siglas significan); este acto - que en ocasiones
no implica ni tan siquiera el movimiento físico 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 ([Mel97]).
Existen tres decisiones básicas en el diseño o la configuración
de un cortafuegos [Ran95]; la primera de ellas, la más importante,
hace referencia a la política de seguridad de la organización propietaria
del firewall: 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 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 monitorización,
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 firewall).
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 firewall puede no entrañar gastos extras para la organización,
o suponer un desembolso de varios millones de pesetas: seguramente un departamento
o laboratorio con pocos equipos en su interior puede utilizar un PC con Linux,
Solaris o FreeBSD a modo de cortafuegos, sin gastarse nada en él (excepto
unas horas de trabajo y unas tazas de café), 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 routers de salida de la red, algo más
barato pero que requiere más tiempo de configuración que los cortafuegos
sobre Unix en PC de los que hemos hablado antes. De cualquier forma, no es recomendable
a la hora de evaluar el dinero a invertir en el firewall fijarse sólo
en el coste 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 router,
no tenemos muchas posibilidades de 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 donde 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 firewall; 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 físicos utilizar como bastión; para
tomar esta decisión existen dos principios básicos ([CZ95]): 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 efectuen contra nuestra red al ser elemento más
accesible de ésta. Si la seguridad de la máquina bastión
se ve comprometida, la amenaza se traslada inmediantamente 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 versión
de Unix (desde una SPARC con Solaris a un simple PC con Linux o
FreeBSD), ya que aparte de la seguridad del sistema operativo tenemos la ventaja
de que la mayor parte de aplicaciones de firewalling han sido desarrolladas
y comprobadas desde hace años sobre Unix ([Rob94]).
Evidentemente, a la vez que elegimos un bastión para nuestro cortafuegos
hemos de decidir qué elemento utilizar como choke; generalmente
suele ser un router con capacidad para filtrar paquetes, aunque también
puede utilizarse un sistema Unix para realizar esta función. En el punto
12.4 se comentan diferentes arquitecturas de cortafuegos
con los elementos utilizados en cada una de ellas como chokes y como bastiones.
Ya hemos decidido qué utilizar como firewall y dónde situarlo;
una vez hecho esto 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 ([BCOW94]):
el filtrado de paquetes, el proxy de aplicación y la monitorización
y detección de actividad sospechosa. Vamos a hablar a continuación
de cada uno de estos componentes.
Cualquier router IP utiliza reglas de filtrado para reducir
la carga de la red; por ejemplo, se descartan paquetes cuyo TTL
ha llegado a cero, paquetes con un control de errores erróneos, o simplemente
tramas de broadcast. 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. Además de la información
de cabecera de las tramas, algunas implementaciones de filtrado permiten especificar
reglas basadas en la interfaz del router por donde se ha de reenviar el
paquete, y también en la interfaz por donde ha llegado hasta nosotros ([Cha92]).
¿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 ([Mog89]). 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. Independientemente del formato, la forma de generar las tablas
dependerá obviamente del sistema sobre el que trabajemos, por lo que es
indispensable consultar su documentación; algunos ejemplos particulares
- pero aplicables a otros sistemas - pueden encontrarse en [CHS91] ( routers NetBlazer), [Par98]
( routers Cisco), [RA94] ( TIS Internet
Firewall Toolkit sobre Unix) y también en la obra indispensable al
hablar de cortafuegos: [CZ95] ( screend,
NetBlazer, Livingston y Cisco).
Por ejemplo, imaginemos una hipotética tabla de reglas de filtrado de la
siguiente forma:
Origen Destino Tipo Puerto Accion
----------------------------------------------------------------------
158.43.0.0 * * * Deny
* 195.53.22.0 * * Deny
158.42.0.0 * * * Allow
* 193.22.34.0 * * Deny
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 bloquearía
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 nuestra tabla - muy simple - las cosas son obvias,
por lo que si extendemos el ejemplo a un firewall real podemos hacernos
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, otras aplican el contario de la última
regla especificada (es decir, si la última entrada era un Allow
se niega el paso de la trama, y si era un Deny se permite), 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 - recordemos una vez más la cuestión
del orden - con la acción que deseemos realizar por defecto; si por ejemplo
deseamos bloquear el resto del tráfico que llega al firewall 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 Accion
----------------------------------------------------------------------
* * * * Deny
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 OSI
([Ste98]). A esto se le añade el hecho
de que si utilizamos un simple router como filtro, las capacidades de
registro de información del mismo suelen ser bastante limitadas, por lo
que en ocasiones es difícil la detección de un ataque; se puede
considerar un mecanismo de prevención más que de detección.
Para intentar solucionar estas - y otras vulnerabilidades - es recomendable utilizar
aplicaciones software capaces de filtrar las conexiones a servicios; a
dichas aplicaciones se les denomina proxies de aplicación, y las
vamos a comentar en el punto siguiente.
Además del filtrado de paquetes, es habitual que los cortafuegos utilicen
aplicaciones software para reenviar o bloquear conexiones a servicios
como finger, telnet o FTP; a tales aplicaciones
se les denomina servicios proxy, mientras que a la máquina donde
se ejecutan se le llama pasarela de aplicación.
Los servicios proxy poseen una serie de ventajas de cara a incrementar
nuestra seguridad ([WC94]); en primer lugar, permiten únicamente
la utilización de servicios para los que existe un proxy, por lo
que si en nuestra organización la pasarela de aplicación contiene
únicamente proxies para telnet, HTTP y
FTP, el resto de servicios no estarán disponibles para nadie.
Una segunda ventaja es que en la pasarela 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 application
gateways permiten un grado de ocultación de la estructura de la red
protegida (por ejemplo, la pasarela es el único sistema cuyo nombre está
disponible hacia el exterior), facilita la autenticación y la auditoría
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 router (que como hemos dicho antes pueden convertirse
en la fuente de muchos problemas de seguridad): sólo hemos de permitir
el tráfico hacia la pasarela, bloqueando el resto.
¿Qué servicios ofrecer en nuestro gateway, y cómo
hacerlo? La configuración de la mayoría de servicios 'habituales'
está muy bien explicada (como el resto del libro) en el capítulo
8 de [CZ95]. Además, en numerosos artículos
se comentan problemas específicos de algunos servicios; uno muy recomendable,
centrado en el sistema de ventanas X Window, pero donde también
se habla de otros protocolos, puede ser [TW93].
El principal inconveniente que encontramos a la hora de instalar una pasarela
de aplicación 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, si el análisis
de cada trama es costoso). 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.
Una variante de las pasarelas de aplicación la constituyen las pasarelas
de nivel de circuito (Circuit-level Gateways, [CB94]),
sistemas capaces de redirigir conexiones (reenviando tramas) pero que no pueden
procesar o filtrar paquetes en base al protocolo utilizado; se limitan simplemente
a autenticar al usuario (a su conexión) antes de establecer el circuito
virtual entre sistemas. La principal ventaja de este tipo de pasarelas es que
proveen de servicios a un amplio rango de protocolos; no obstante, necesitan
software especial que tenga las llamadas al sistema clásicas sustituidas
por funciones de librería seguras, como SOCKS ([KK92]).
Monitorizar la actividad de nuestro cortafuegos es algo indispensable para la
seguridad de todo el perímetro protegido; la monitorización nos
facilitará información sobre los intentos de ataque que estemos
sufriendo (origen, franjas horarias, tipos de acceso...), así como la existencia
de tramas que aunque no supongan un ataque a priori sí que son
al menos sospechosas (podemos leer [Bel93b]
para hacernos una idea de que tipo de tramas 'extrañas' se pueden llegar
a detectar).
¿Qué información debemos registrar? Además de los
registros estándar (los que incluyen estadísticas de tipos de paquetes
recibidos, frecuencias, o direcciones fuente y destino) [BCOW94] recomienda auditar información de la
conexión (origen y destino, nombre de usuario - recordemos el servicio
ident - 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) y tramas recibidas desde routers
desconocidos. Evidentemente, todos esos registros han de ser leidos con frecuencia,
y el administrador de la red ha de tomar medidas si se detectan actividades sospechosas;
si la cantidad de logs 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 ([Bel92]). 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 troyano, 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 traza de su conexión.
Evidentemente, nos estamos arriesgando a que nuestro atacante descubra el mecanismo
y lance ataques más peligrosos, pero como el nivel de conocimientos de
los atacantes de redes habituales en general no es muy elevado (más bien
todo lo contrario), este mecanismo nos permite descubrir posibles exploits
utilizados por los piratas, observar a qué tipo de atacantes nos enfrentamos,
e incluso divertirnos con ellos. En la Universidad Politécnica de Valencia
existen algunos sistemas con este tipo de trampas, y realmente es curioso observar
cómo algunos intrusos siguen intentando aprovechar bugs que fueron
descubiertos - y solucionados - hace más de cuatro años (ejemplos
típicos aquí son PHF y algunos problemas de
sendmail). En [Che92], un artículo clásico a la hora
de hablar de seguridad (también se comenta el caso en el capítulo
10 de [CB94]), se muestra cómo Bill Cheswick, un experto
en seguridad de los laboratorios AT&T estadounidenses, es capaz de analizar
detenidamente gracias a estos programas las actividades de un pirata que golpea
el gateway de la compañía.
Arquitecturas de cortafuegos
Un firewall sencillo puede consistir en un dispositivo capaz de filtrar
paquetes, un choke; se trata del modelo de cortafuegos más antiguo
([Sch97]), basado simplemente en aprovechar la capacidad
de algunos routers para bloquear o filtrar paquetes en función
de su protocolo, su servicio o su dirección IP de forma que el router
actue como gateway de la subred. Los accesos desde la red interna al exterior
no 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 y la más
utilizada en organizaciones que no precisan grandes niveles de seguridad - como
las que vemos aquí -.
No obstante, elegir un cortafuegos tan sencillo puede no ser recomendable en ciertas
situaciones, o para organizaciones que requieren una mayor seguridad para su subred,
ya que los simples chokes presentan más desventajas que beneficios
para la red protegida. El principal problema es que no disponen de un sistema
de monitorización sofisticado, por lo que muchas veces el administrador
no puede determinar si el router está siendo atacado o si su seguridad
ha sido comprometida. Además las reglas de filtrado pueden llegar a ser
complejas de establecer, y por tanto es difícil 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 router como filtro de paquetes,
es recomendable bloquear todos los servicios que no se utilicen desde el exterior
(especialmente NIS, NFS, X-Window y TFTP), así como el acceso desde máquinas
no confiables hacia nuestra subred; es también importante para la seguridad
bloquear los paquetes con encaminamiento en origen activado.
El segundo modelo de cortafuegos estaba formado por simples máquinas Unix
equipadas con dos tarjetas de red y denominadas anfitriones de dos bases ([SH95]), 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 Unix ha de ejecutar al menos un servidor proxy 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 router,
para aislar el tráfico entre la red interna y la externa es necesario que
el choke no enrute paquetes entre ellas. Todo el intercambio de datos
entre las redes se ha de realizar a través de servidores proxy
situados en el host bastión, o bien permitiendo a los usuarios
conectar directamente al mismo (algo muy poco recomendable, ya que un usuario
que consiga aumentar su nivel de privilegios en el sistema puede romper toda la
protección del cortafuegos, por ejemplo reactivando el IP Forwarding).
Un paso más en términos de seguridad de los cortafuegos es la arquitectura
screened host o choke-gate, que combina un router con
un host bastión, y donde el principal nivel de seguridad proviene
del filtrado de paquetes. En la máquina bastión, único sistema
accesible desde el exterior, se ejecutan los proxies de las aplicaciones,
mientras que el choke 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 router? La mayoría de autores ([Ran93], [Sem96]...) recomiendan situar el router entre
la red exterior y el host bastión, pero otros ([WC94]) defienden justo lo contrario: situar el bastión
en la red exterior no provoca aparentemente una degradación de la seguridad,
y además ayuda al administrador a comprender la necesidad de un elevado
nivel de fiabilidad en esta máquina, ya que está sujeta a ataques
externos y no tiene por qué ser un host fiable; de cualquier forma,
asumiremos la primera opción por considerarla mayoritaria entre los expertos
en seguridad informática. De esta forma, cuando una máquina de la
red interna desea comunicarse con el exterior ha de hacerlo a través de
servidores proxy situados en el host bastión, y los usuarios
externos sólo pueden acceder a la red interna también a través
de este sistema.
La arquitectura Screened Subnet, también conocida como red perimétrica
o De-Militarized Zone (DMZ) 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ón13.1, de forma que si la seguridad
del mismo se veía comprometida, 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.
Screened subnet es la arquitectura más segura, pero también
la más compleja; se utilizan dos routers, denominados exterior
e interior, conectados ambos a la red perimétrica como se muestra en la
figura 12.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 router 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; de esta forma, un atacante habría
de romper la seguridad de ambos routers para acceder a la red protegida.
Incluso es posible si se desean mayores niveles 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.
Figura 12.2: Arquitectura
DMZ.
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 firewall 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 seguridad reside en los routers
utilizados; como hemos dicho antes las reglas de filtrado sobre estos elementos
pueden ser complicadas de configurar y comprobar, lo que puede dar lugar a errores
que abran importantes brechas de seguridad en nuestro sistema.
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 firewall, 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 ofertado.
Cada día es más habitual en todo tipo de organizaciones dividir
su red en diferentes subredes; esto es especialmente aplicable en entornos de
I+D o empresas medianas, donde con frecuencia se han de conectar campus o sucursales
separadas geográficamente, edificios o laboratorios diferentes, etc. En
esta situación es recomendable incrementar los niveles de seguridad de
las zonas más comprometidas (por ejemplo, un servidor donde se almacenen
expedientes o datos administrativos del personal) insertando cortafuegos internos
entre estas zonas y el resto de la red. Aparte de incrementar la seguridad,
firewalls internos son especialmente recomendables en zonas de la red desde
la que no se permite a priori la conexión con Internet, como laboratorios
de prácticas: un simple PC con Linux o FreeBSD que deniegue cualquier conexión
con el exterior del campus va a ser suficiente para evitar que los usuarios se
dediquen a conectar a páginas web o chats desde equipos
no destinados a estos usos. Concretamente en el caso de redes de universidades
sería muy interesante filtrar las conexiones a IRC o a
MUDs, ya sea a nivel de aulas o laboratorios o a nivel de todo el campus,
denegando en el router de salida de la red hacia INet cualquier tráfico
a los puertos 6667, 8888 y similares; aunque realmente esto no evitaría
que todos los usuarios siguieran jugando desde los equipos de la universidad -
por ejemplo a través de un servidor que disponga de conexión en
otros puertos -, sí conseguiría que la mayor parte de ellos dejara
de hacerlo.
Quizás el cortafuegos más utilizado actualmente en Internet es
FireWall-1, desarrollado por la empresa Check Point Software Technologies
Ltd. ( http://www.checkpoint.com). Incorpora una nueva arquitectura
dentro del mundo de los cortafuegos: la inspección con estado ( stateful
inspection). Firewall-1 inserta un módulo denominado Inspection
Module en el núcleo del sistema operativo sobre el que se instala,
en el nivel software más bajo posible (por debajo incluso del nivel
de red), tal y como se muestra en la figura 12.3; así, desde ese nivel tan bajo, Firewall-1
puede interceptar y analizar todos los paquetes antes de que lleguen al resto
del sistema; se garantiza que ningún paquete es procesado por ninguno de
los protocolos superiores hasta que Firewall-1 comprueba que no viola
la política de seguridad definida.
|
| Figura 12.3: Ubicación del Inspection Module
dentro de la pila de protocolos OSI. |
Firewall-1 es capaz de analizar la información de una trama en
cada uno de los siete niveles OSI y a la vez analizar información de estado
registrada de anteriores comunicaciones; el cortafuegos entiende la estructura
de los diferentes protocolos TCP/IP - incluso de los ubicados en
la capa de aplicación -, de forma que el Inspection Module extrae
la información relevante de cada paquete para construir tablas dinámicas
que se actualizan constantemente, tablas que el firewall utiliza para
analizar comunicaciones posteriores. En el módulo de inspección
se implantan las políticas de seguridad definidas en cada organización
mediante un sencillo lenguaje denominado INSPECT, también
diseñado por Check Point Software Technologies; desde un cómodo
interfaz se genera un script en este lenguaje, que se compila y se inserta
en el Inspection Module.
Instalar Firewall-1 en una máquina Unix no ofrece ninguna dificultad:
simplemente hemos de desempaquetar el software y ejecutar la orden
fwinstall, que paso a paso nos guiará a través de la configuración
del programa; incluso se encargará de crear los scripts necesarios
para lanzar el cortafuegos al reiniciar el sistema. Una vez instalado, Firewall-1
ofrece un cómodo interfaz gráfico para la configuración de
políticas del sistema ( fwui); no obstante, siempre tenemos la
opción de trabajar en modo texto mediante la orden fw. En el
paquete también viene incluido un visor gráfico de logs
( fwlv, mostrado en la figura 12.4); los logs del programa no se guardan por
defecto en ficheros ASCII, sino en un formato propio en el directorio
/etc/fw/logs/, por lo que o bien el visor gráfico o bien la utilidad
fw son necesarios para visualizarlos o exportarlos directamente a ficheros
de texto:
| Figura 12.4: Una imagen de fwlv. |
anita:/etc/fw/bin# ./fw log
Date: May 2, 2000
3:28:43 ctl anita >daemon started sending log to localhost
3:49:27 ctl anita >daemon started sending log to localhost
4:30:30 ctl anita >daemon started sending log to localhost
anita:/etc/fw/bin# ./fw logexport -o /etc/fw/logs/salida.ascii
Starting pass 1 of the log file.
Starting pass 2 of the log file..
100.00% of log file processed.
anita:/etc/fw/bin# cat /etc/fw/logs/salida.ascii
num;date;time;orig;type;action;alert;i/f_name;i/f_dir;sys_msgs
0;2May2000; 3:28:43;anita;control;ctl;;daemon;inbound;started sending log
to localhost
1;2May2000; 3:49:27;anita;control;ctl;;daemon;inbound;started sending log
to localhost
2;2May2000; 4:30:30;anita;control;ctl;;daemon;inbound;started sending log
to localhost
anita:/etc/fw/bin#
La gran potencia y flexibilidad de Firewall-1 hacen imposible que se puedan
explicar con detalle todas sus características; para más información,
una excelente lectura puede ser [Gon99]. También la documentación que
acompaña al producto, y la disponible en el servidor web de
Check Point Software Technologies, es de gran ayuda para cualquier administrador
que utilice este cortafuegos en su red.
Por último, una pequeña advertencia; como Firewall-1 inserta
módulos en el núcleo del operativo, es dependiente de la versión
del kernel utilizada. Todas las versiones más o menos modernas
funcionan correctamente sobre Solaris 2.6 y la última también sobre
Solaris 7; no obstante, sobre este último el resto de versiones no funcionan
bien, aunque se instalen correctamente. Es posible, y esto lo digo por experiencia,
que la máquina no arranque tras instalar el software debido a las
modificaciones de los scripts de arranque (concretamente los ubicados
en /etc/rcS.d/), que al ser invocados desde /sbin/rcS producen
errores que impiden montar correctamente los discos y proseguir el arranque; para
solucionar estos problemas, lo más rápido es eliminar cualquier
modificación que la instalación de Firewall-1 haya realizado
sobre los programas ejecutados al iniciar el sistema. Para Solaris 8 aún
no existen versiones del producto, como tampoco existen para Linux; ambas se supone
que están siendo desarrolladas en la actualidad.
ipfwadm es una herramienta proporcionada con Linux para la implementación
de políticas de filtrado de paquetes en este clon de Unix. Deriva del código
de filtrado en BSD ( ipfw), y debido a sus limitaciones (por ejemplo,
sólo puede manejar los protocolos TCP, UDP o ICMP) ipfwadm ha
sido reescrito para convertirse en ipchains a partir del núcleo
2.1.102. Por tanto, ipchains es en la actualidad el software
de firewalling en Linux IPv4; aunque todas las versiones de Linux lo incorporan
por defecto, se puede descargar una versión actualizada desde http://www.rustcorp.com/linux/ipchains/.
Aparte de una versión actualizada del software, en esta dirección
se puede encontrar [Rus99], consulta imprescindible para todo aquel
que pretenda trabajar con ipchains; la mayor parte de esta sección
está basada en esa obra. Otro documento que incluye también excelentes
ejemplos es [Mou00].
En Linux el filtrado de paquetes está construido en el kernel (se
habla con más detalle del núcleo de este sistema operativo en la
sección 9.2); para poder utilizar ipchains hemos
de compilar el núcleo con las opciones CONFIG_FIREWALL
y CONFIG_IP_FIREWALL activadas (asumiendo
que tenemos una versión del kernel 2.2, en caso contrario es conveniente
actualizar el núcleo). Cuando ya estamos ejecutando un núcleo con
el firewalling activado utilizaremos ipchains para insertar
y eliminar reglas de filtrado en él; al tratarse de información
dinámica, cada vez que el sistema se reinicie las reglas establecidas se
perderán, por lo que es recomendable crear un script que se ejecute
al arrancar el sistema y que las vuelva a definir (es recomendable consultar las
páginas de ipchains-save e ipchains-restore para construir
dicho shellscript).
El núcleo de Linux utiliza tres listas de reglas denominadas chains;
se trata de input, output y forward. Cuando recibe
un paquete utiliza la primera de estas listas para decidir si lo acepta, y si
es así comprueba a dónde tiene que enrutar el paquete; en caso de
que el destino sea una máquina diferente utiliza la lista forward
para enviarlo. Por último, la lista output se utiliza obviamente
antes de enviar un paquete por un interfaz de red. Los elementos de cada lista
se denominan reglas y definen - junto a los targets, de los que hablaremos
a continuación - qué hacer con los paquetes que cumplen ciertas
características; si un paquete no cumple ninguna de las reglas que deciden
qué hacer con él, lo mejor si queremos un sistema seguro es rechazarlo
o denegarlo. Mediante ipchains podemos definir listas, modificarlas
y eliminarlas13.2 y, más importante, definir las reglas
para cada lista. Para estudiar las opciones de esta orden se pueden consultar
las páginas ipchains(8), ipfw(4), ipchains-restore(8)
e ipchains-save(8).
Cuando un paquete cumple cumple una determinada regla de una chain definimos
qué hacer con él mediante lo que ipchains denomina 'objetivo'
o target (quizás una traducción menos literal pero más
clarificadora sería 'destino'). Aunque existen más targets,
son tres los que más se suelen utilizar: ACCEPT permite
el paso de un paquete, DENY lo bloquea, y REJECT
también lo bloquea pero a diferencia del anterior envía al origen
una notificación mediante un mensaje ICMP de tipo
DEST_UNREACH (siempre que el paquete bloqueado no sea también
de tipo ICMP). Realmente, aunque REJECT y DENY
nos parezcan igual de seguros - y de hecho en la mayoría de situaciones
lo sean - siempre es más recomendable utilizar DENY, ya
que mediante mensajes ICMP un posible atacante podría conseguir
información sobre nuestras políticas de filtrado, lo que podría
llegar a comprometer nuestra seguridad.
Veamos un ejemplo: imaginemos que deseamos denegar todo el tráfico ICMP
que llega a nuestra máquina Linux (realmente no sería recomendable
filtrar los paquetes ICMP de tipo 3); para ello deberíamos
ejecutar una sentencia como la siguiente:
rosita:~# ipchains -A input -p icmp -j DENY
rosita:~#
Con la opción '-A' estamos indicando que añadimos la regla
a la chain especificada ('input', lo que viene a decir que la
regla afecta a los paquetes entrantes), '-p' nos permite especificar
el protocolo deseado (puede ser tcp, udp o icmp),
y '-j' indica el objetivo, en este caso DENY; otras opciones
que nos podría haber sido útil son '-s', que permite especificar
la dirección de la máquina origen, y también '-L',
que muestra la configuración actual de nuestras políticas de filtrado:
rosita:~# ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
target prot opt source destination ports
DENY icmp ------ anywhere anywhere any -> any
DENY icmp ------ anywhere anywhere any -> any
ACCEPT icmp ------ anywhere anywhere any -> any
rosita:~#
ipchains permite registrar mediante syslogd los paquetes que
cumplan cierta regla - por norma general, todos -. Un registro exhaustivo de las
acciones que se toman en el núcleo con respecto al filtrado de paquetes
no es conveniente: la gran cantidad de información guardada hace imposible
detectar actividades sospechosas, y además no es difícil que se
produzcan ataques de negación de servicio, ya sea por disco ocupado o por
tiempo consumido en generar y guardar registros. Por tanto, lo habitual es almacenar
sólamente los paquetes que no sean rutinarios (por ejemplo, intentos de
conexión desde direcciones no autorizadas, ciertos paquetes ICMP
no habituales...). El núcleo de Linux, a través de klogd
y de syslogd, registra eventos con prioridad 'info' (al provenir
del kernel, su tipo es obviamente 'kernel'); si estos registros
se almacenan en el fichero /var/adm/fwdata, sus entradas serán
de la siguiente forma:
rosita:~# tail -1 /var/adm/fwdata
Packet log: input DENY eth0 PROTO=6 158.42.22.41:1032 195.195.5.1:23
L=34 S=0x00 I=18 F=0x0000 T=254
rosita:~#
El anterior mensaje nos dice principalmente que un paquete con protocolo 6 (corresponde
a TCP en nuestro archivo /etc/protocols) proveniente
de la dirección 158.42.22.41 y destinado a nuestro servicio telnet
ha sido denegado; el resto de la información no la veremos aquí
(se puede consultar la documentación del producto para ver el significado
concreto de todos y cada uno de los campos registrados).
ipchains es una herramienta flexible, potente e, igual de importante,
gratuita, que funciona sobre un sistema operativo también gratuito; quizás
para una organización de I+D o para una empresa no muy grande sea difícil
permitirse soluciones comerciales cuyo precio puede ascender a varios millones
de pesetas, especialmente si se van a instalar cortafuegos internos o arquitecturas
DMZ de varios niveles. Sin embargo, no hay excusa para no utilizar este producto
de filtrado; un pequeño PC corriendo Linux es más que suficiente
para, en muchas ocasiones, garantizar - o al menos incrementar - la seguridad
de un laboratorio, un aula informática o un conjunto de despachos.
Notas al pie
- ... bastión13.1
- Excepto en el primero, compuesto únicamente por un choke.
- ... eliminarlas13.2
- A excepción de las tres listas predefinidas, que no se pueden borrar.
Next: Kerberos Up:
Seguridad de la subred Previous: Algunos servicios y protocolos
Índice General