Documente Academic
Documente Profesional
Documente Cultură
[3.2] Introducción
[3.3] Cortafuegos
TEMA
Esquema
TEMA 3 – Esquema
Mecanismos de defensa en redes
2
Pasare la a nivel de aplicación Arquitecturas simple s
Ideas clave
Para estudiar este tema, además de las Ideas clave, lee el capítulo 3 «Firewall
Gateways» (páginas 51-83) del libro Firewalls and Internet Security: Repelling the Wily
Hacker, de William R. Cheswick, Steven M. Bellovin, y Aviel D. Rubin, disponible en:
http://www.wilyhacker.com/1e/chap03.pdf
Un equipo sin conexión a una red necesita ser accedido físicamente para poder ser
atacado. Sin embargo, un equipo conectado a una red se expone a un mayor
número de amenazas, ya que el número de vías que pueden ser utilizadas para
llevar a cabo un posible ataque se incrementa notablemente.
La necesidad de acceso físico para llevar a cabo cualquier acción en un equipo aislado
supone una primera línea de defensa. Sin embargo, en un equipo conectado a una red
pueden efectuarse acciones de manera remota que pongan en peligro el propio equipo y
los equipos conectados a la misma red. Además, el tráfico que fluye por la red no
puede ser considerado siempre fiable, por lo que es necesario disponer de algún
tipo de mecanismo que permita discriminarlo y solo deje pasar a la red interna el
tráfico legítimo. En este punto aparecen los sistemas cortafuegos cuya tarea es evitar
que los usuarios desautorizados de Internet tengan acceso a las redes privadas
conectadas con Internet, especialmente intranets.
En definitiva, este tema tiene como objetivo introducir al alumno en el mundo de los
cortafuegos y como deben emplearse para crear una red segura que dificulte o evite
intrusiones. Para ello, durante este tema se tratarán tres puntos principales:
3.2. Introducción
Suele ser necesario que algunos servicios como HTTP o DNS sean accedidos desde el
exterior y, por tanto, precisen mantenerse abiertos, lo que constituye una grave
amenaza. Para prevenir el acceso no autorizado a redes locales se utilizan los
cortafuegos. Normalmente, un cortafuegos se localiza entre Internet y la red local
con el fin de filtrar el tráfico proveniente del exterior hacía la red interna y el
proveniente de la red interna hacia el exterior.
3.3. Cortafuegos
Los cortafuegos implementan una política de seguridad que define los servicios y
accesos permitidos en términos de configuración de red, haciendo uso, entre otras, de
las siguientes funcionalidades:
Existen dos formas de implementar las reglas de filtrado (Ilustración 1) basadas en las
políticas predeterminadas del cortafuegos:
La elección de la política por defecto depende de varios factores. En función del número
de hosts externos que puedan acceder a la red, el número de servicios abiertos… una
política restrictiva puede llegar a ser complicada de mantener, ya que es necesario
indicar explícitamente en las reglas de filtrado que paquetes deben ser aceptados. No
obstante, esta es la opción más segura. Por otro lado, una política permisiva
facilita el uso de la red a los usuarios, pero el nivel de seguridad proporcionado es
más bajo.
Este tipo de pasarelas suelen ser más seguras que los cortafuegos de filtrado de
paquetes, ya que no hay que incluir reglas a nivel de red indicando todo el tráfico
permitido, solo es necesario indicar las aplicaciones admitidas.
Las pasarelas a nivel de circuito pueden ser consideradas un híbrido entre los
cortafuegos de filtrado de paquetes y las pasarelas a nivel de aplicación. En primer
lugar, el usuario debe establecer una conexión con la pasarela, al igual que en las
pasarelas a nivel de aplicación. Una vez establecida la conexión, la pasarela se comporta
como un cortafuegos de filtrado de tráfico redirigiendo las tramas entre ambos
extremos sin analizar el contenido de los mismos a nivel de aplicación.
Equipo bastión
Es un equipo que cuenta con una fuerte protección ya que estará expuesto a sufrir
ataques desde el exterior. Se sitúa entre la red exterior y la red interna.
De entre las diversas posibilidades que existen para el despliegue de una arquitectura,
dos suelen ser las más utilizadas: las arquitecturas simples y las arquitecturas de
defensa en profundidad.
Arquitecturas simples
Esta arquitectura permite mantener segura la red interna a pesar de que un atacante
haya logrado infiltrarse en la DMZ.
Además del filtrado de tráfico los cortafuegos pueden ofrecer otros servicios, algunos de
los cuales detallamos a continuación:
» Detección de intrusiones: Hay sistemas que permiten detectar los ataques más
comunes. Un ataque también se puede detectar examinando el log de tráfico
entrante permitido.
Lo + recomendado
Lecciones magistrales
No dejes de leer…
No dejes de ver…
+ Información
A fondo
El artículo está enfocado en explicar las diferentes técnicas de las que disponemos hoy
en día para proteger nuestros equipos frente a ataques provenientes de Internet. El
artículo es de pago.
Webgrafía
Firewall.com
Actividades
Para facilitar la realización de esta actividad podéis hacer uso de la máquina virtual de
NETinVM a la que podéis acceder a través del escritorio virtual.
De cara a esta actividad lo importante es comprender que tenemos una red exterior
(10.5.0.0/24) que simula ser Internet, una DMZ (10.5.1.0/24) y una red interna
(10.5.0.2/24). Las tres se encuentran unidas por un cortafuegos fw cuya configuración
segura es el objeto de esta práctica. En el gráfico pueden verse los tres interfaces de fw
y sus correspondientes direcciones IP (eth0 con IP 10.5.0.254 interfaz con Internet,
eth1 con IP 10.5.1.254 interfaz con DMZ y eth2 con IP 10.5.2.254 interfaz con Red
Interna).
Una vez configurada la topología correctamente tenéis que pulsar en el icono Run my
machines para crear la red virtual. Tras unos segundos de espera aparecerán diversos
terminales que, al cabo de unos segundos más, os permitirán acceder a cada una de las
máquinas creadas tal y como puede verse en la siguiente figura.
Con el objetivo de comprobar que las reglas que os pediremos en la actividad son
correctas podéis hacer uso de algunas herramientas dentro del entorno de NETinVM.
La primera es utilizar el logging de iptables. Para todas las reglas que creéis podéis
crear justo antes una regla idéntica, pero cuya acción en vez de ser ACCEPT o DROP
sea LOG. De este modo, antes de aceptar o descartar un paquete, iptables lo logueará.
Por ejemplo, si quisierais loguear y aceptar todas las comunicaciones que atraviesen el
cortafuegos cuyo puerto destino sea el UDP 53 deberías introducir las siguientes reglas
(el orden es importante ya que, si se ejecutase la regla ACCEPT primero, la LOG nunca
llegaría a ejecutarse):
iptables ‐A FORWARD ‐p udp ‐‐dport 53 ‐j LOG
iptables ‐A FORWARD ‐p udp ‐‐dport 53 ‐j ACCEPT
La segunda es utilizar el comando netcat tanto para crear peticiones como para simular
servicios (cuando estos no estén desplegados en la arquitectura). La sintaxis de netcat
es muy sencilla. Por ejemplo:
En este caso, el servidor web ya está establecido en dmza por lo cual no es necesario
simularlo. Desde inta lanzamos netcat, escribimos cualquier secuencia de caracteres,
pulsamos Enter y el servidor WEB responderá. Usando el comando tail en fw podemos
ver cómo se van logueando los paquetes.
Para casos en los que sea necesario comunicarse hacia o desde internet podéis utilizar
el equipo exta para recibir o generar tráfico. En el siguiente gráfico se simula un
servicio de DNS (UDP) en dicho host al cual se accede desde un equipo en la red local.
Figura 5: Comunicación con seridor DNS simulado en Internet desde red local
Una vez tenéis acceso a los 4 equipos y domináis el uso de netcat llega la hora de llevar
a cabo la actividad…
Suena el teléfono y te despiertas sobresaltado. No son horas para recibir una llamada
todavía, pero, aun así, el teléfono está sonando. Te acercas a mirar y ves una extensión
empresarial. No sabes quién es, pero por la hora parece importante. Respondes…
Tras una reunión de apenas una hora tienes una idea clara de la arquitectura y dibujas
un gráfico.
1. Decides conectarte al cortafuegos como root y listar las reglas de la tabla filter
en modo verbose.
2. El listado te muestra que se permiten demasiadas conexiones. Decides que lo mejor
es empezar desde cero y borrar todas las reglas de la tabla filter.
3. Además, no todas las cadenas de la tabla filter tienen una política restrictiva.
Estableces una política restrictiva en la cadena que falta.
4. Una vez que has establecido una base segura, llega el momento de permitir las
conexiones necesarias para Example. Lo primero es permitir el tráfico de las
conexiones ya establecidas en todas las cadenas de la tabla filter.
5. A continuación, lo primero que necesitas es que la red local tenga capacidad de
resolución de nombres. Desgraciadamente Example no cuenta con DNS propio, así
que seleccionas uno que crees seguro en Internet. Permites las nuevas
Ya has configurado el cortafuegos de forma segura, has comprobado que todo sea
correcto y crees que has terminado el trabajo…, pero no es así. El responsable de
seguridad de Example es de la vieja escuela y quiere todas las reglas documentadas.
Notas:
» Las reglas, siempre que sea posible, deben determinar acción, interfaz, protocolo,
dirección IP origen y destino, puerto/s origen y destino y el estado de la conexión.
» A pesar de que las direcciones IP utilizadas en la topología son privadas no debe
utilizarse NAT. Solo se piden las reglas de filtrado.
» Todas las acciones deben llevarse a cabo con una única regla (a excepción de la
acción 4 para la que se requieren tres reglas).
Acción Regla
1. Listar las reglas de la tabla filter en modo
detallado
Test