Listas de acceso

Listas de acceso

Introducción Las listas de acceso, también llamadas listas de control de acceso (ACL, Access Control Lists), constituyen los mecanismos principales de filtrado de paquete en la mayor parte de los enrutadores de Cisco. Asimismo, las ACL se utilizan para otra serie de funciones, incluyendo el filtrado de ruta y la utilización de determinados comandos show. Por ello, resulta necesario tener un sólido conocimiento sobre las ACL para poder resolver cualquier clase de problemas y configurar los equipos de Cisco en la mayoría de las redes. Las ACL permiten controlar qué clase de coincidencia efectúa un enrutador en relación con una determinada función, como el envío de paquetes.

Por ejemplo, si no existe una forma de especificar de forma condicional qué paquetes pueden enviarse de una red a otra (como es el caso de Internet), el usuario tendrá que autorizar el envío de todos los paquetes (lo cual hace que la red en cuestión sea un objetivo sencillo para los hockers), o bien denegar todos los paquetes (lo que haría imposible la conectividad). El control general a través del filtrado de paquete constituye una función primaria de las ACL. Sin embargo, las ACL se pueden utilizar con comandos más complejos (como los mapas de ruta o las listas de distribución), lo que proporciona un grado de control muy preciso sobre la funcionalidad del enrutador. En resumidas cuentas, siempre que sea preciso utilizar alguna clase de coincidencia condicional, las ACL suelen ser la herramienta a elegir.

En el presente escrito se analizarán las características de las ACL, explicando fundamentalmente su propósito principal: el filtrado de paquetes. Aunque todos los conceptos que se estudian aquí también se aplican al resto de los comandos que utilizan las ACL, en el presente escrito no se considerarán las características de dichos comandos (en este sentido, si el lector desea consultar ejemplos de listas de distribución ACL en protocolos de enrutamiento, se recomienda consultar los capítulos que van del 22 al 26 del Manual de referencia de CISCO). Por otra parte, como para comprender el funcionamiento de las ACL es preciso conocer todas las cuestiones relacionadas con su configuración, a lo largo del presente escrito se examinan la resolución de problemas y la configuración de las ACL en lugar de analizarlas en apartados distintos. Finalmente, como TCP/IP constituye el tema fundamental del presente libro, el filtrado de paquete IPX no se analiza aquí.

Comprender el filtrado de paquetes

Los objetivos básicos del filtrado de paquete resultan muy sencillos. Supongamos que se desea que una red remota (generalmente, una red pública como Internet) acceda exclusivamente a recursos específicos situados en una red privada, al tiempo que se autoriza el acceso de la red privada a la red remota. Parece simple, ¿verdad? Desafortunadamente, es más fácil decirlo que hacerlo. Para ver por qué, conviene observar la situación que se i lustra en la ilustración No. 1, donde se pretende efectuar un filtrado de paquete.

Ilustración 1: Red simple no segura

La red que se ilustra en la figura no está utilizando la traducción de direcciones de red (NAT, Network Address Trasslation), sino que simplemente gestiona direcciones IP públicas para las dos estaciones de trabajo, proporcionándoles acceso a Internet. El problema que presenta este esquema es que, sin filtrado de paquete, cada servidor de la red privada puede comunicarse con Internet libremente, y viceversa. Suponiendo que la información bancada online del usuario está colocada en una unidad compartida situada en el servidor 64.1.1.69, la única protección que recibe el servidor ante la aparición de intrusos es el sistema de seguridad del sistema operativo, que habitualmente resulta altamente sospechoso.

Antes de aprender a resolver este problema conviene examinar el significado de algunos de los nuevos términos asociados con la NAT y el filtrado de paquete. La red interna es la red que se desea proteger de un acceso realizado desde el exterior. La red externa es la red remota. La interfaz interna es la interfaz de enrutador vinculada a la red interna. La interfaz externa es la interfaz vinculada a la red externa. Finalmente, cuando se trabaja con filtros es preciso comprender el concepto de dirección (o sentido del flujo): el tipo de tráfico, entrante o saliente, al que se aplica el filtro.

Si la dirección es entrante, el filtro se aplica al tráfico introduciendo la interfaz desde la red vinculada. En el caso de una interfaz interna, el tráfico entrante no es otra cosa que el tráfico que introduce la interfaz desde la red interna. Si este tráfico se enrula hacia la red externa, tendría que considerarse tráfico saliente en la interfaz externa. Si la dirección es saliente, el filtro se aplica al tráfico que abandona la interfaz en la red vinculada. En el caso de una interfaz interna se trata de tráfico enviado desde la interfaz interna a la red interna. Si este tráfico se enrula desde la red externa, también se debe considerar tráfico entrante en la interfaz externa.

A continuación se resolverán las cuestiones suscitadas en el ejemplo anterior. Para solucionar el problema del acceso libre a los recursos internos se puede utilizar el filtrado de paquete en el enrutador para denegar el acceso a la red interna desde Internet. Por ejemplo, es posible eliminar todo el acceso a la red interna desde Internet, de forma que se puede optar por utilizar un filtrado de paquete que rechace todos los paquetes destinados a la red interna. Para ello habría que util izar un filtro de paquete que ejecutara la función «denegar todo»o «denegar paquetes con una dirección de destino de 64.1.1.64 a 71». Posteriormente, habría que aplicar el filtrado de paquete a los paquetes entrantes en la interfaz externa (64.1.1.2/24) o a los paquetes salientes en la interfaz interna (64.1.1.6.5/29).

Parece que el problema se ha resuelto... Desafortunadamente, aún no es así. Este filtro de paquete no sólo rechazaría el acceso no autorizado (correctamente) desde el mundo exterior, sino que también denegaría los paquetes de retorno procedentes de los anfitriones internos a Internet. En otras palabras, cuando se envía un paquete a wivw.cwco.com desde el servidor 64.1.1.69, los paquetes de establecimiento de conexión TCP deberían abandonar la red privada libremente dirigiéndose a Internet, pero cuando el servidor web situado en Cisco responda, ¡el filtro debería descartar los paquetes! Obviamente, no se trata de una solución adecuada, así que hay que volver a la mesa de trabajo.

Una posible solución a este problema consiste en autorizar la existencia de paquetes que utilicen números de puerto de cliente para entrar en la red privada. Habitualmente, los clientes utilizarían puertos considerados exclusivamente como «dinámicos y privados» por la IANA, que incluye todos los puertos situados entre 49.192 y 65.535. Sin embargo, muchos clientes también utilizarían puertos comprendidos en un rango que va de 1.024 a 49.191 (definidos por la IANA como «registrados»). Esto conduce a una serie de problemas a la hora de filtrar paquetes, ya que si simplemente se rechaza cada paquete que tiene un número de puerto inferior a 49.192, se acabaría por denegar el tráfico de retorno legítimo tanto a los clientes como al tráfico de carácter sospechoso.

Así que ¿por qué no autorizar que todo el tráfico utilice un puerto de destino situado por encima de 1023? La respuesta es sencilla: porque varias aplicaciones de servidor de uso común, muchas de las cuales no deberían resultar accesibles desde servidores externos, utilizan puertos situados en ese rango (como es el caso del servidor de catálogo global de Microsoft en el Directorio Activo situado en los puertos 3268/3269 y el servidor SNA de Microsoft situado en 1477 y 1478).

Nota:

Si se desea obtener un listado completo de los números de puerto registrados y conocidos, hay que visitar la dirección http://www.iana.org/ assignments/port‐numbers.htm.

La solución más fácil para este pequeño problema consiste en admitir exclusivamente el tráfico de conexiones establecidas. Mediante esta acción cabe indicar al enrutador que admita la llegada de paquetes de retorno procedentes de cualquier servidor externo, posibilitando su entrada en la red privada. De esta manera, mientras la sesión TCP con el servidor remoto siga en activo, el enrutador autorizará que los paquetes entren en la red privada.

El filtrado de paquete establecido funciona de la manera siguiente:

1. Se configura un filtro establecido en la interfaz externa para los paquetes entrantes que afirme básicamente: «Admitir todas las conexiones establecidas».

2. Se envía un paquete a un servidor remoto. Puesto que el filtro de paquete está configurado para comprobar los paquetes entrantes exclusivamente en la interfaz externa, todos los paquetes procedentes de la red interna que van a Internet quedan autorizados automáticamente.

3. El servidor remoto responde. Éste debe tener los bits ACK o RST configurados en el paquete de respuesta. El filtro establecido autoriza todos los paquetes procedentes de la red externa con estos bits configurados en posición de entrada.

Obviamente, la funcionalidad descrita en el paso 3 deja un pequeño agujero en lo que respecta a la seguridad de la red. Por ejemplo, un hacker avispado podría configurar manualmente el bit ACK en un paquete TCP e introducir la red interna. Por esta razón, los mecanismos de Cisco también admiten un tipo especial de filtro de paquete, conocido como ACL reflexiva. Una ACL reflexiva crea dinámicamente entradas de filtro de paquete para así poder autorizar el acceso hacia y desde el servidor, así como el destino para el que se ha establecido la sesión. Las ACL reflexivas funcionan de la manera siguiente:

1. Se configura el filtro reflexivo en la interfaz externa para los paquetes entrantes, que afirme: «Autorizar todas las conexiones establecidas».

2. Se envía un paquete al servidor remoto usando una IP de origen específica (por ejemplo, 64.1.1.69), un puerto de origen específico (por ejemplo, 50.000), un destino IP específico (como podría ser 71.100.1.1) y un puerto de destino específico (por ejemplo, 80 para HTTP). La ACL reflexiva cons‐truye un filtro de paquete dinámico para autorizar todas las respuestas clonadas desde la red externa para entrar en la red interna hasta que haya caducado el tiempo límite o hasta que el bit FIN aparezca en la sesión. En ' este caso, la ACL reflexiva crearía una entrada que diría lo siguiente: «Autorizar todos los paquetes procedentes de la dirección de origen 71.100.1.1 con un puerto de origen de 80 y un destino de 64.1.1.69, con un puerto de destino de 50.000 para entrar en la red interna».

3. El servidor remoto responde y se envía el paquete.

4. Cuando termina la sesión (aparece el bit FIN o caduca el tiempo límite), se elimina el filtro de paquete dinámico.

Nota

En muchos servidores proxy/NAT, incluyendo el servidor ISA de Microsoft, las conexiones establecidas y las conexiones reflejadas se autorizan automáticamente, mientras que el resto de los paquetes se rechazan como efecto secundario de la creación de la tabla NAT/PAT. Aunque no se trata técnicamente de un filtrado de paquete, su funcionamiento es el mismo.

El filtrado reflexivo simplifica las cosas, facilitando la autorización eficaz del tráfico interno para acceder a la red externa. Sin embargo, esta clase de filtrado tiene dos características que hay que tener en cuenta:

• El filtrado reflexivo no funciona con todas las aplicaciones. Específicamente, aquellas aplicaciones que cambian los números de puerto en el transcurso de la sesión (por ejemplo, FTP y RPC) deben autorizarse estáticamente.

• Asimismo, se pueden utilizar filtros reflexivos para autorizar sólo aquellos tipos específicos de tráfico que vayan a emplearse para acceder a la red externa desde la red interna.

A continuación se examinará el primer punto. Ciertas aplicaciones cambian dinámicamente los puertos en el transcurso de una sesión. Dichas aplicaciones deben autorizarse para transmitir elementos (si se requiere) de forma estática. Por ejemplo, FTP utiliza dos puertos, 20 y 21, en el transcurso de las comunicaciones. Cuando se establece una conexión FTP se utiliza el puerto 21 para transferir el control de sesión de estilo Telnet. Sin embargo, cuando se comienza a descargar un archi‐vo se utiliza el puerto 20 para la transferencia. Las ACL reflexivas no conocen el puerto de transferencia de archivo. Lo único que conocen es el puerto utilizado inicialmente, por tanto la ACL bloquearía la transferencia FTP. La llamada de procedimiento remoto (RPC, Remote Procedure Cali], utilizada por la mayor parte de las aplicaciones de servidor de Microsoft, funciona de manera similar, pero añade un elemento de complejidad adicional. Tras la conexión inicial, RPC escoge un puerto al azar en 1024 para establecer una comunicación.

Para resolver las cuestiones relacionadas con estos tipos de aplicaciones existen dos posibilidades:

• Cambiar a una solución de cortafuegos más sólida que comprenda los detalles de nivel de aplicación (eficaz, pero quizás muy cara).

• Catalogar esta clase de aplicaciones, el puerto utilizado y los puertos abiertos.

Nota:

Algunas soluciones proxy/cortafuegos ya incluyen la mayoría de los filtros de nivel de aplicación que puedan resultar necesarios. El soporte FTP, por ejemplo, está disponible por omisión en la mayoría de los productos comerciales.

Puesto que la primera solución escapa al marco planteado en el presente libro, se analizará la segunda. La forma más sencilla de implementarla consiste en activar ACL reflexivas y luego verificar qué aplicaciones no funcionan. Con el tiempo, el usuario sabrá qué aplicaciones podrá considerar como ACL estáticas para adaptarse prácticamente a todas las situaciones (como FTP), pero, inicialmente, se explicará la forma más rápida de comenzar. Una vez que se haya determinado cuáles son las aplicaciones que no tienen soporte de las ACL reflexivas, se pueden rastrear los puertos utilizados por esta aplicación y configurar las ACL para transmitir este tráfico específico. Por ejemplo, para que todos los clientes puedan utilizar FTP habría que configurar una ACL estática que dijera lo siguiente: «Autori‐zar todo el tráfico con un puerto de origen de 20 y una dirección de destino equivalente a todas las direcciones presentes en la red interna».

En el caso de las aplicaciones que elijan puertos aleatorios, como es el caso de RPC, la solución resulta algo más compleja. Si la aplicación sólo utiliza un pequeño rango de puertos, simplemente habrá que abrir los puertos en dicho rango. Sin embargo, si la aplicación utiliza un extenso rango de puertos (como RPC) el trabajo se complica. El primer paso consiste en obligar a la aplicación a que utilice un rango de puertos más pequeño. Así, por ejemplo, en el caso de RPC, se puede modificar el registro de Windows en los anfitriones (normalmente, servidores) que requieran conectividad RPC a través del cortafuegos. Una vez definido un rango pequeño de puertos aleatorios, para utilizarlos basta con añadir una sentencia de ACL estática que permita que dichos puertos se comuniquen con estos puertos específicos.

Por ejemplo, si hay cinco servidores en el rango de direcciones IP 70.1.1.5 a 70.1.1.9 que necesiten comunicarse utilizando RBC con otro servidor en la dirección IP 140.0.0.1, en primer lugar habría que obligar a que, en todos los servidores, RPC utilizara puertos dentro de un rango dado, como puede ser el comprendido entre 50.000 y 60.000. Luego habría que añadir una sentencia ACL en la interfaz externa del cortafuegos para la red 70.1.1.0 que dijera lo siguiente: «Autorizar paquetes entrantes con una dirección de origen de 140.0.0.1 que use cualquier número de puerto con una dirección de destino en el rango comprendido entre 70.1.1.5 y 70.1.1.9, y con un puerto de destino en el rango situado entre 50.000 y 60.000». En el cortafuegos correspondiente a la red 140.0.0.0 simplemente habría que reflejar esta sentencia.

CONSEJO

Si se desea consultar información detallada sobre cómo obligar a RPC para que utilice un rango específico de puertos en las plataformas de servidor de Microsoft en uso hay que consultar el artículo Q154596: http://support. microsoft.com/def a u lt.aspx?scid=kb;EN‐US;q154596.

Sin embargo, en el caso del filtrado de paquetes se puede actuar de una forma más compleja y elegir la posibilidad de autorizar exclusivamente ciertos tipos de tráfico desde los anfitriones internos para permitir que salgan a la red externa. Por ejemplo, suponiendo que sólo se desea proporcionar acceso a Internet para navegación web, pero no se quiere que los usuarios empleen otras aplicaciones estándar de Internet, como FTP, Telnet y SMTP, o bien si no se desea que los clientes internos tengan la capacidad de utilizar aplicaciones no admitidas (y que en ocasiones consumen un gran ancho de banda) como es el caso de Quake o Napster, habría que crear una ACL reflexiva que diga lo siguiente: «Autorizar que los anfitriones internos accedan a todos los anfitriones externos utilizando el puerto 80 (HTTP) y 443 (HTTPS/SSL)». Posteriormente habría que aplicar la ACL a la interfaz de enrutador interna para el tráfico entrante.

Consejo

Por regla general, hay que intentar aplicar el filtrado de paquete tan cerca del borde de la red como sea posible. Asimismo, hay que intentar filtrar el tráfico cuando se entra en una interfaz (dirección de entrada) en lugar de hacerlo cuando se sale de ella (dirección de salida). Esta estrategia ayuda a conservar los recursos del enrutador, eliminando la necesidad de que éste efectúe un proceso en el paquete antes de arrojarlo al «cubo de bits».

Uso de la NAT y la PAT con filtrado de paquetes

La traducción de direcciones de red (NAT, Netwvork Address Translation) puede simplificar la vida del programador evitando que tenga que concentrarse en la cuestión del acceso no autorizado a anfitriones situados en la red privada. Por definición, la NAT y la traducción de direcciones de puerto (PAT, Pon Address Translation) generan tablas de traducción dinámicamente (aunque también cabe la posibilidad de definir entradas estáticas) para autorizar anfitriones procedentes del mundo externo de modo que entren en la red interna. Asimismo, estas entradas dinámicas se crean sólo cuando un anfitrión interno necesita acceder al mundo externo. Si un anfitrión externo desea comunicarse con un anfitrión interno y el mecanismo NAT no dispone de una entrada en la tabla de traducción para el anfitrión de destino, el paquete se rechaza. Por consiguiente, como si se tratara de un subproducto NAT, los recursos internos ya tienen un nivel de seguridad similar al de una ACL reflexiva.

Nota:

Si desea conocer las características de la NAT puede consultar el Captulo 6 de CISCO, Manual de referencia‐

Si en la red interna existen anfitriones que deben resultar accesibles desde anfitriones situados en la red externa, como puede ser el caso de un servidor web, basta con agregar una entrada estática en la NAT similar a la entrada que habitualmente se colocaría en un filtro de paquete estándar, exceptuando el hecho de que hay que especificar la dirección externa y el puerto asociado con el servidor web, así como la dirección interna y el puerto asociado con dicho servidor. Por ejemplo, en la ilustración No. 2 se muestra la red que aparecía en la Ilustración No. 1 con la incorporación del direccionamiento privado destinado a la red interna (el enrutador está ejecutando la NAT) y un servidor web en la red interna. En este caso habría que estipular que todo el tráfico externo estuviera autorizado para acceder al servidor web, pero sólo en lo que respecta a HTTP (no se debe autorizar el acceso al servidor web utilizando cual‐quier otro protocolo). Asimismo, habría que permitir que los clientes internos accedieran a los recursos externos, pero sólo en lo que respecta a FTP, HTTP, HTTPS, POP3 y SMTP. El resto de las comunicaciones quedarían denegadas.

Ilustración 2: Ejemplo de red con inclusión NAT y un servidor web

A continuación se incluye un listado de los filtros de interfaz interna correspondientes a la ilustración No. 2 (en la localización marcada con un 1):

1. Filtros de interfaz interna correspondientes a la ilustración No 2

Para albergar estos requerimientos hay que crear una sentencia NAT que autorice que todas las direcciones públicas se usen para una traducción dinámica. Luego habría que agregar una traducción estática (conocida como correspondencia estática) que asociara a 64.1.1.2, puerto 80, con 192.168.1.100, puerto 80. Debido a la naturaleza de la NAT, estas dos acciones rechazan que el tráfico entre en la red interna desde un anfitrión remoto que no se inicie mediante un anfitrión interno o que esté destinado al HTTP en el servidor web. A continuación, para evitar que los anfitriones internos utilicen protocolos distintos de FTP (20, 21), HTTP (80), HTTPS (443), POP3 (110) y SMTP (25) basta con aplicar un filtro de paquete al tráfico entrante en la interfaz interna que señale lo siguiente:

• Autorizar el tráfico desde cualquier anfitrión interno utilizando cualquier puerto de origen destinado a cualquier anfitrión externo, utilizando los puertos de destino 20, 21. 80, 443, 110 O o 25. • Autorizar el tráfico desde 192.168.1.100 utilizando el puerto de origen 80 para cualquier dirección de destino y puerto. • Rechazar el tráfico restante.

Como es lógico, una vez efectuados todos estos pasos para proteger la red, probablemente el lector puede darse cuenta de que sigue existiendo un elemento vulnerable: el propio cortafuegos. Si un hacker tuviera la intención de comprometer el cortafuegos, el resto de las configuraciones de seguridad también quedarían comprometidas. Para tratar de evitar este desastre potencial es preciso desactivar todos los servicios necesarios en el enrutador, efectuando un filtrado de paquete/ NAT. En una situación de cortafuegos individual o único, si el cortafuegos está efectuando una PAT, es preciso ser particularmente cuidadoso en lo que respecta al filtrado de paquete en la interfaz externa. Por omisión, en un enrutador de Cisco, la PAT (también conocida como sobrecarga NAT) intenta asignar el mismo número de puerto a los paquetes traducidos. En otras palabras, si un anfitrión interno está intentando comunicarse con un anfitrión externo utilizando un puerto de origen de 12.000, la NAT intenta utilizar el mismo puerto para la dirección traducida. Sin embargo, como es posible que el puerto de origen se haya elegido anteriormente (otro anfitrión interno puede estar utilizando 12.000 como puerto de origen), es posible que la NAT tenga que asignar un número de puerto diferente. Cuando la NAT tiene que cambiar el puerto de una sesión, asigna aleatoriamente un puerto no utilizado a la comunicación desde uno de los tres rangos de puerto

siguientes: 1‐511, 512‐1023 y 1024‐65535. La NAT siempre asigna un puerto al paquete traducido, que estará en el mismo rango que el puerto de pretraducción. Por ejemplo, si el cliente utilizó originalmente el puerto 443, la NAT elegiría un puerto situado entre 1 y 511 para la traducción de paquetes, dando por supuesto que ya se ha utilizado el puerto 443. Puesto que el puerto que la NAT elige para una conexión de cliente particular no se puede predecir, la posibilidad de realizar un filtrado de paquete en la interfaz externa resulta limitada. Por esta razón, es preciso considerar cuidadosamente el filtrado de paquete correspondiente a la ¡nterfaz externa del enrutador antes de implementar la NAT. Nota: La configuración de la NAT en un enrutador de Cisco escapa al marco propuesto por el presente libro. Para obtener más información al respecto hay que visitar las páginas http://www.cisco.com/warp/pubí¡c/cc/ pd/iosw/ioft/ionetn/prodlit/1195_pp.htm y http://www.cisco.com/warp/ public/cc/pd/¡osw/ioft/iofwft/prodlit/¡osnt_qp.htm.

Comprender la DMZ

Una zona desmilitarizada (DMZ, Demilitarized Zone) (también conocida como subred protegida o «apantallada») constituye una medida de seguridad adicional para garantizar que la disponibilidad de recursos de acceso público no comprometa la seguridad de la red interna. Una DMZ separa los recursos de acceso público de los recursos completamente privados, colocándolos en subredes distintas, auto‐rizando el bloqueo de los recursos privados e incluso proporcionando seguridad a los recursos públicos.

Nota:

Aunque esto se puede considerar una blasfemia en algunos círculos de seguridad en redes, en el presente escrito se usa el término cortafuegos para representar cualquier mecanismo que filtre paquetes para el control del acceso, incluyendo tanto enrutadores de Cisco estándar como los productos cortafuegos específicos, como los de las series PIX, a menos que se indique expresamente otra cosa.

Las DMZ se pueden estructurar de diversas formas, pero en este escrito sólo se analizarán las configuraciones más frecuentes:

• DMZ con cortafuegos individual. Este tipo de DMZ consta de un cortafuegos individual con tres o más interfaces, y al menos una de las interfaces conectadas a la red interna, a la red externa y a la DMZ. Estas DMZ son más eficaces en términos de coste, pero los beneficios de seguridad (más allá de un único cortafuegos que no tenga DMZ) resultan mínimos.

• DMZ con cortafuegos dual. Esta clase de DMZ es una de las más comunes y consiste en un cortafuegos externo, un cortafuegos interno y una DMZ situada entre ambos. Los recursos internos quedan protegidos por el cortafuegos interno, mientras que los recursos de la DMZ están protegidos por el cortafuegos externo. Este tipo de estructura DMZ puede incrementar la seguridad sustancialmente: el cortafuegos dual proporciona una protección suplementaria a los recursos internos. Sin embargo, el problema surge cuando se considera que la DMZ con cortafuegos dual tiende a ser mucho más cara que una con cortafuegos individual, y, al mismo tiempo, su manejo puede requerir conocimientos adicionales (especialmente, si se siguen las recomendaciones que los distintos fabricantes realizan sobre los cortafuegos).

• DMZ con cortafuegos triple. Se trata de una estructura que utiliza tres cortafuegos para proteger la red interna y que, al mismo tiempo, utiliza DMZ interna y externa. Esta configuración de cortafuegos

sólo se usa en instituciones en las que la seguridad es un elemento muy importante y suele implicar toda una serie de aplicaciones subsidiarias. Aunque resultan extremadamente seguros, estos cortafuegos son extremadamente caros tanto en lo que respecta a su implementación como a su mantenimiento.

En primer lugar se examinará la solución del cortafuegos individual. La ilustración. 3 muestra un único cortafuegos con tres interfaces. Los servidores web y otros servidores de acceso público están situados en la DMZ, mientras que todos los recursos internos están totalmente protegidos en la subred interna. Asimismo hay que observar que el servidor SQL utilizado por el servidor web para generar eí procesamiento está situado en la red interna.

Ilustración 3: Sistema de cortafuegos individual DMZ

A continuación se incluye un listado de los filtros de interfaz correspondientes a las localizaciones numeradas en la ilustración. 3.

1. Filtros de interfaz internos correspondientes a la ilustración. 3.

2. Filtros DMZ correspondientes a la ilustración. 3.

3. Filtros de interfaz externa correspondientes a la ilustración. 3.

Nota:

Hay que tener en cuenta que la mayoría de los fabricantes de cortafuegos, incluyendo Cisco, utilizan la regla de la «primera coincidencia». Todos los filtros correspondientes a una determinada dirección en una interfaz dada se examinan en orden y se utiliza el primer filtro coincidente.

A continuación se analizarán las características de los filtros de paquete, empezando por el filtro externo. El primer filtro situado en la interfaz externa permite que cualquier anfitrión alcance cualquier servidor público en la DMZ utilizando cualquiera de los puertos correspondientes a los servicios que se suministran en dichos servidores. En otras palabras, si en la DMZ se dispone de un servidor web, un servidor FTP o un servidor SMTP, se tendría acceso al servidor web utilizando el puerto 80 o el 443, al tiempo que se tiene acceso al puerto FTP utilizando los puertos 20 y 21, y acceso al servidor SMTP utilizando el puerto 25.

El segundo filtro en la interfaz externa es un filtro reflexivo que facilita la comunicación inicialmente establecida mediante los anfitriones internos para retornar a dichos anfitriones. El filtro final presente en la interfaz externa rechaza el resto de las comunicaciones (en las ACL de Cisco no es necesario, ya que siempre hay una denegación implícita al final). No se aplican filtros hacia el exterior de la interfaz externa, por lo que se autoriza todo el tráfico en dicho sentido.

Asimismo, conviene observar el orden de los filtros orientados hacia dentro. El primer y segundo filtro admiten conexiones específicas, mientras que el tercero deniega todas las conexiones. Puesto que el filtro que efectúa la denegación está situado al final, se convierte desde un punto de vista funcional en un elemento que deniega al resto. Si los paquetes coincidieran con el primer filtro (destinados a un servidor público situado en un puerto público), serían autorizados y finalizaría el procesamiento de filtro correspondiente a esta interfaz. En caso contrario, se examinaría el filtro siguiente. Si el paquete coincide con el segundo filtro (si fuera un paquete de respuesta para una sesión previamente establecida mediante un anfitrión interno o basado en DMZ) también quedaría autorizado y finalizaría el procesamiento de filtro correspondiente a esta interfaz. Si el paquete no coincidiera con ningún filtro sería denegado. Nuevamente, hay que recordar que los filtros se procesan en orden, y una vez que se logra una coincidencia, finaliza el procesamiento de filtro correspondiente a esa interfaz.

En el caso de las DMZ, los dos primeros filtros, orientados hacia dentro, autorizan al servidor web (y sólo al servidor web) presente en la DMZ para que se comunique con el servidor SQL asegurado en la red interna, utilizando exclusivamente el protocolo SQL. La estipulación de que SQL debe ser el único protocolo utilizado garantiza que, en caso de que los hackers ataquen a otros servidores públicos, no puedan tener acceso a la base de datos segura situada en el servidor SQL. El tercer filtro, orientado hacia fuera, es un filtro reflexivo que autoriza todas las comunicaciones que se establecen desde anfitrión DMZ. El tercer filtro es necesario debido a la presencia del cuarto filtro orientado hacia fuera, que deniega el resto de paquetes. Utilizando esta técnica de filtrado cabe garantizar que el servidor SQL seguro no sólo se aborde desde anfitriones externos, sino también desde servidores situados en la DMZ.

Finalmente, en el caso de la red interna, los dos filtros orientados hacia dentro permiten que el servidor SQL se comunique exclusivamente con el servidor web en la DMZ utilizando el protocolo SQL. Este filtro, aunque no se requiera estrictamente, garantiza la seguridad del servidor SQL asegurándose de que dicho servidor no pueda comunicarse con un anfitrión externo distinto del servidor web y luego utilice exclusivamente SQL como aplicación. Si el usuario no ha generado esta sentencia, un administrador situado físicamente junto al servidor SQL podría abrir una sesión a un sitio web utilizando dicho servidor.

Nota:

Si el servidor web estuviera comunicándose realmente con el servidor SQL interno, empleando SQL como protocolo, y el servidor SQL fuera un servidor SQL de Microsoft, el puerto que habría que abrir sería el 1433. Sin embargo, como puede utilizarse como extremo para el servidor SQL cualquier otro tipo de aplicación u otra versión comercial de SQL (como es el caso de la versión de Oracle), en este ejemplo no se ha incluido el número de puerto en bruto. Cuando se utilice esta técnica hay que saber cuáles son los puertos que pueden abrirse.

Aunque los administradores que naveguen por la web desde un servidor realmente no tienen mucho de qué preocuparse, existe la remota posibilidad de que la sesión a un sitio web pudiera verse secuestrada por un hacker y, puesto que la sesión se estableció previamente mediante el servidor SQL, los paquetes que enviara el hacker al servidor SQL podrían tener autorización para franquear el cortafuegos. Para eliminar esta posibilidad se pueden crear dos filtros para desactivar todas las comunicaciones SQL que se produzcan fuera de la red interna, exceptuando los paquetes necesarios para que el servidor web utilice los puertos SQL.

Consejo:

Cabe aplicar esta misma filosofía y técnica de filtrado a prácticamente todos los servidores internos, eliminando la posibilidad de acceso no autorizado. Por ejemplo, se puede aplicar un filtro adicional antes del tercer filtro para denegar el bloque de dirección asignado a los servidores internos desde el uso de recursos externos. Sin embargo, hay que tener en cuenta que esta técnica de filtrado requiere que los administradores del servidor utilicen estaciones de trabajo estándar para transferir actualizaciones y cualquier otro archivo de servidor necesario desde Internet, y que luego compartan las unidades de disco de las estaciones de trabajo !o utilicen redes secretas) para transferir los archivos a los servidores, provocando un esfuerzo administrativo adicional (lo cual no resulta necesario en un principio, aunque depende de la política de seguridad).

Los cinco filtros siguientes colocados en la interfaz interna se usan para controlar el acceso a Internet desde los anfitriones internos. Estos cinco filtros permiten que cualquier anfitrión situado en la subred interna acceda a Internet utilizando los puertos 80 (HTTP), 443 (HTTPS/SSL), 20 o 21 (FTP) y 25 (SMTP), al tiempo que deniega cualquier otro acceso. Aunque el bloque de dirección IP que aparece reflejado en los filtros (192.168.1.X) no es estrictamente necesario (ya que se podría utilizar la sentencia any [cualquiera] para una subred individual), se incluye aquí para mostrar cómo utilizar la dirección de origen para permitir que los usuarios de una subred accedan a Internet mientras se deniega el acceso a Internet a otros usuarios situados en una subred diferente. Si otra subred (por ejemplo, 192.168.2.0) tuviera estos filtros, se denegaría a la segunda subred la conectividad a la DMZ y a Internet.

Después de analizar las características del filtro mediante un cortafuegos individual se examinarán las DMZ con cortafuegos dual. En la Figura. 4 se observan cortafuegos duales, internos y externos, pero en medio de ambos aparece una DMZ.

Ilustración 4: DMZ con cortafuegos dual.

Los filtros de interfaz para las localizaciones numeradas ¡lustradas en la Figura 4 aparecen en el listado siguiente:

1. Filtros de interfaz internos correspondientes a la ilustración. 4

2. Filtros de interfaz externa correspondientes a la ilustración. 4

3. Filtros de interfaz interna correspondientes a la ilustración. 4

4. Filtros de interfaz externa correspondientes a la ilustración. 4

La interfaz externa en el cortafuegos 3600 tiene básicamente las mismas ACL que la interfaz externa del cortafuegos ilustrado en la Figura 27.3. Un filtro no reflexivo permite la comunicación con los servidores públicos utilizando los números de puerto adecuados, una ACL reflexiva autoriza el paso del tráfico de retorno desde los anfitriones internos y una sentencia deny en blanco se ocupa del tráfico no autorizado. La interfaz interna del cortafuegos 3600 autoriza el paso a todo el tráfico hacia el exterior de la red.

La interfaz del P1X está autorizada a establecer comunicación exclusivamente desde el servidor web público para acceder al servidor SQL con una lista de acceso no reflexiva. Luego se ocupa de garantizar que no se produzca comunicación alguna desde cualquier mecanismo distinto del servidor web que pueda alcanzar el servidor SQL, con una lista de acceso no reflexiva que deniegue específicamente cualquier clase de comunicación con el servidor SQL. Puesto que la entrada que permite al servidor web acceder al servidor SQL está colocada en primer lugar en la lista, mientras se utilicen los puertos correctos, el servidor web generará una coincidencia con la sentencia permit en primer lugar y tendrá autorización para acceder al servidor SQL.

La sentencia siguiente es una sentencia reflexiva que permite que todas las comunicaciones establecidas desde los clientes internos accedan a los recursos externos. Finalmente, se deniega el resto de las comunicaciones externas entrantes mediante el uso de una sentencia deny en blanco, situada en la interfaz PIX externa.

Las últimas sentencias se aplican a la interfaz interna del PIX. Estas sentencias permiten que los clientes internos accedan a recursos externos utilizando HTTP. HTTPS/SSL, FTP y SMTP. Existe una sentencia adicional que autoriza al servidor SQL a comunicarse con el servidor web en la DMZ. Por último, una sentencia deny en blanco rechaza el resto de las comunicaciones.

La ventaja que supone la utilización de una DMZ de cortafuegos dual consiste en la consecución de un nivel de seguridad adicional de los recursos. Cuando se utilizan cortafuegos duales resulta más difícil realizar entradas no autorizadas, ya que dos mecanismos deben estar comprometidos para acceder con éxito a los recursos internos. Si se utilizan cortafuegos de distintos fabricantes, la seguridad de la red aumenta, ya que el hacker debe tener los conocimientos necesarios para acceder a plataformas completamente distintas. Lógicamente, la desventaja viene marcada por el coste de la red y los posibles quebraderos de cabeza en lo que respecta a su configuración. Sin embargo, en las redes de tamaño intermedio, los cortafuegos duales resultan muy populares.

Nota:

El ejemplo que aparece en la Figura .4 utiliza un cortafuegos dedicado para la red interna, con la estructura de un cortafuegos PIX de Cisco. Aunque la funcionalidad de cortafuegos básica consiste en el "filtrado de paquetes (que pueden realizar la mayoría de los enrutadores, los cortafuegos verdaderos tienen una serie de funciones (incluyendo el filtro de paquete de estado completo) que pueden mejorar el nivel de seguridad general de toda la red. En este capítulo se analiza exclusivamente el filtrado de paquetes. Para obtener mayor información sobre los cortafuegos dedicados, puede consultar la dirección http://secinf.net/ifwe.html.

En las situaciones en que se emplean cortafuegos triples cabe garantizar un alto nivel de seguridad, incluso cuando se requiera implementar contextos de filtrado muy complejos. Por ejemplo, en la Figura. 5 se muestra un ejemplo de diseño de alta seguridad con cortafuegos triple, utilizando DMZ duales. La DMZ externa se emplea para alojar los recursos de dominios absolutamente públicos, mientras que la DMZ interna sirve para alojar el servidor SQL, así como los recursos externos a la red (semipúblicos), como servidores VPN y servidores web externos a la red (como el acceso a web de Outlook). El cortafuegos externo se utiliza para proteger a los servidores que tengan acceso a Internet, mientras que el cortafuegos medio se emplea para proteger los recursos externos a la red. Finalmente, el cortafuegos interno protege exclusivamente los recursos internos, haciendo que esta configuración de cortafuegos constituya una barrera formidable contra los posibles intentos de acceso no autorizado.

Ilustración 5: DMZ con cortafuegos triple

A continuación se incluye un listado de los filtros de interfaz correspondientes a las localizaciones numeradas de la Figura.5.

1. Filtros de interfaz interna para la Figura. 5

2. Filtros de interfaz externa para la Figura. 5





Los diseños que implican cortafuegos triples pueden justificar el esfuerzo que supone su creación, aunque sólo se utilizan en las redes más extensas y con mayor preocupación por las cuestiones de seguridad, o en determinadas situaciones.

Configuración de las ACL

El primer paso a la hora de configurar las ACL consiste en comprender la sintaxis de las listas de acceso. En el caso de una lista de acceso estándar, la sintaxis no resulta demasiado compleja. Sin embargo, en el caso de las listas de acceso extendidas, la sintaxis puede resultar un poco más confusa.

En este apartado se analiza la configuración de las listas de acceso utilizando ACL estándar y extendidas, tanto en estilo denominado como en estilo numerado.

En la Tabla No. 1 se describen las características de los comandos empleados en este apartado.

Tabla 1: Comandos de listas de acceso

Comando Descripción Modo

access‐list [número de lista de acceso] [deny \ permit] [origen] [máscara comodín de origen] [log]

Crea una lista de acceso IP numerada de carácter estándar

Configuración global

access‐list [número de lista de acceso] [deny I permit] [protocolo] [origen] [máscara comodín de origen] [operadores de puerto (opcionales)] [destino] [máscara comodín de destino] [operadores de puerto (opcionales)] [established] [log]

Crea una lista de acceso numerada de carácter extendido


ip access‐list standard [nombre] Crea una lista de acceso numerada de carácter estándar


[deny I permit] [origen] [comodín de origen] [log]

Introduce sentencias en una lista de acceso IP denominada de carácter estándar

Configuración de listas de acceso

ip access‐list extended [nombre]

Crea una lista de acceso IP denominada de carácter extendido


[deny \ permit] [protocolo] [origen] [máscara comodín de origen] [operadores de puerto (opcionales)] [destino] [máscara comodín de origen] [operadores de puerto (opcionales)] [established] [log]

Introduce sentencias en una lista de acceso IP denominada de carácter extendido

Configuración de listas de acceso

ip access‐group [número o nombre de lista de acceso] [in I out]

Aplica una lista de acceso a una interfaz Configuración de interfaz

show ip access‐list [número o nombre de lista de acceso]

Muestra una o todas las listas de acceso IP Ejecución de usuario

show access‐lists [número o nombre de lista de acceso]

Muestra una o todas las listas de acceso IP Ejecución de usuario

El primer comando que aparece en la lista, access‐list, se usa para crear listas de acceso IP numeradas de carácter estándar y extendido. El factor decisivo que indica si una lista de acceso debe ser estándar o extendida es simplemente el número utilizado para definir la lista de acceso. Si dicho número está comprendido entre 1 y 99, la lista de acceso será una ACL IP estándar. Si, por el contrario, el número utilizado se sitúa entre 100 y 199, la lista de acceso será una ACL IP extendida.

Nota: En las nuevas versiones del IOS, las ACL numeradas con valores comprendidos entre 1300 y 1999 también están disponibles para las ACL IP estándar.

La configuración de las listas de acceso en el formato numerado sigue una serie de reglas de carácter simple:

• Las listas de acceso coinciden con las sentencias introducidas utilizando comandos de lista de acceso múltiples con el mismo número, para crear listas multisentencia.

• Las listas de acceso coinciden con las sentencias procesadas en el orden introducido, donde la primera sentencia coincide con el paquete que se está utilizando.

• Se incluye una sentencia deny al final de cada ACL, lo que significa que una vez que se aplica a una interfaz, todos los paquetes que no coincidan con cualquiera de las sentencias permit presentes en una ACL se abandonarán automáticamente.

• Las sentencias individuales presentes en las listas de acceso numeradas no pueden modificarse. Para eliminar una sentencia ACL hay que utilizar el comando no access‐üst [número], eliminando todas las sentencias asociadas con dicha ACL.

A medida que se exploren las características de los comandos access‐list, el usuario aprenderá más sobre la estructura de estas reglas. Para los principiantes se explica a continuación cómo se construye una lista de acceso IP numerada estándar.

Listas de acceso estándar

La sintaxis utilizada para el comando access‐list cuando se construye un listado numerado estándar resulta muy sencilla: access‐list [número de lista de acceso] [deny I permit] [origen] [máscara comodín de origen] [conectar]. El número debe situarse, lógicamente, en el rango que va de 1 a 99. La sección deny \ permit especifica la acción que se va a efectuar (abandonar o enviar) en relación con los paquetes que cumplen esta sentencia match. Las secciones origen y máscara comodín de origen definen qué paquetes deben coincidir, basándose en la dirección de origen, y el parámetro opcional log indica al IOS que conecte con paquetes que coincidan con esta lista de acceso con la función syslog.

Las únicas partes de una lista de acceso IP estándar que generan cierta dificultad son las secciones de dirección de origen y la de máscara comodín. La sección origen es la parte de la dirección de origen con la que se desea coincidir. Por ejemplo, si se desea coincidir con todas las direcciones de origen en la red 172.16.0.0, habría que introducir 172.16.0.0 como dirección de origen. Verdaderamente, se puede co‐locar cualquier cosa que se desee en los últimos octetos de la dirección (siempre y cuando se configure la máscara correctamente), pero no tiene sentido introducir una dirección completa cuando lo único que se desea es efectuar una coincidencia con los primeros dos octetos. La máscara realmente determina qué cantidad de la dirección de origen forma parte de la coincidencia. La máscara está escrita en el formato wildcard (comodín), y quizás pueda parecer que está colocada en orden inverso a cómo cabría esperar. En una máscara comodín, las partes de la dirección que se describen mediante el valor binario 0 en la máscara deben coincidir exactamente, mientras que se ignoran las partes que tienen un valor binario 1.

Por ejemplo, para efectuar una coincidencia con 172.16.0.0‐172.16.255.255, habría que introducir la dirección de origen de 172.16.0.0 con una máscara comodín de 0.0.255.255. Siguiendo la misma lógica, para efectuar una coincidencia con cada dirección IP situada entre 192.168.1.128 y 192.168.1.255 habría que introducir una dirección de origen de 192.168.1.128 con una máscara comodín de 0.0.0.127. Esta combinación coincide con las direcciones IP seleccionadas, ya que en lenguaje binario todos los bits que tienen un valor O deben coincidir con la IP de origen escogida (192.168.1.128), mientras que todos los valores binarios 1 pueden ser diferentes. Cuando se convierte a binario, esta combinación tiene el siguiente aspecto:

IP ‐ 192.168.1.128 : 11000000.10101000.00000001.10000000 IP ‐ 192.168.1.255 : 11000000.10101000.00000001.11111111 Mask ‐ 0.0.0.127 : 00000000.00000000.00000000.01111111 Basándose en esta información, si se desea configurar un filtro de paquete utilizando ACL estándar para bloquear todas las transmisiones desde 192.168.1.1, autorizar todas las comunicaciones desde el resto de la red 192.168.1.0 y denegar todas las demás, habría que crear el filtro de paquete con los comandos siguientes: Router(config)#access‐list 1 deny 192.168.1.1 0.0.0.0 Router (config)#access‐list 1 permit 192.168.1.0 0.0.0.255 Nota: Para especificar un anfitrión individual hay que utilizar la palabra clave host en la ACL. Por ejemplo, en el comando anterior, en lugar de escribir access‐list 1 deny 192.168.1.1 0.0.0.0, habría que escribir typed access‐list 1 deny host 192.168.1.1. Para garantizar la creación de esta lista de accesos se pueden utilizar los comandos show ip access‐list o show access‐lists: Routert show access‐lists Standard IP access list 1

deny 192.168.1.1 permit 192.168.1.0, wildcard bits 0.0.0.255

Router# show ip access‐list Standard IP access list 1

deny 192.168.1.1 permit 192.168.1.0, wildcard bits 0.0.0.255

Router# El orden de los comandos en una ACL resulta muy importante. Por ejemplo, si se reorganizan estas sentencias, la dirección 192.168.1.1 tendría autorización para comunicarse, ya que dicha dirección coincide con 192.168.1.0 0.0.0.255. Hay que recordar que una ACL simplemente utiliza la primera sentencia coincidente e ignora el resto. Por lo general, lo lógico es colocar las entradas más específicas en la parte superior de la lista. El truco consiste en examinar mentalmente el orden de la lista, punto por punto, y garantizar que todos los objetivos se encuentren satisfechos en el listado. Sin embargo, a medida que la lista se complica, este proceso se hace cada vez más complejo. Por ejemplo, hay que suponer que se desea configurar un listado que efectúe las siguientes tareas:

• Autorizar todas las direcciones situadas en el rango que va de 192.168.1.64 ; a 192.168.1.127.

• Autorizar las que van de 192.168.1.1 a 192.168.1.3. • Autorizar todas las direcciones comprendidas entre 10.0.2.0 y 10.255.255.255. • Denegar todas las demás direcciones.

En este caso, se podría utilizar la siguiente lista de acceso para cumplir estas metas: Router(config)#access‐list 1 permit 10.0.0.0 0.255.255.255 Router(config)#access‐list 1 permit 192.168.1.64 0.0.0.127 Router(config)#access‐list 1 permit host 192.168.1.1 Router(config)#access‐list 1 permit host 192.168.1.2 Router(config)#access‐list 1 permit host 192.168.1.3 Router(config)#access‐list 1 deny 10.0.1.0 0.0.0.255 ¿Usted reconoce los problemas que surgen con esta lista? A continuación se examinará cada objetivo en orden para garantizar el análisis de cada uno de los problemas.

En primer lugar, se desea autorizar el rango que va de 192.168.1.64 a 127. Mirando en la lista, la segunda sentencia cumple este objetivo. Sin embargo, la sentencia access‐list 1 permit 192.168.1.64 0.0.0.127 coincide con todas las direcciones IP situadas entre 192.168.1.0 y 192.168.1.127. El segundo objetivo consiste en autorizar el rango que va desde 192.168.1.1 hasta 192.168.1.3 para establecer la comunicación. Aunque la tercera, la cuarta y la quinta sentencia efectúan esta tarea, ésta no es la manera más eficaz de hacerlo. Además, la segunda sentencia del listado se alcanzaría antes de acceder a estas sentencias. El tercer objetivo consiste en autorizar todas las direcciones situadas en el rango que va de 10.0.2.0 a 10.255.255.255 para establecer la comunicación. Aunque la primera sentencia, access‐list 1 permit 10.0.0.0 0.255.255.255, cumple esta tarea, coincide con todas las direcciones desde la red 10.0.0.0. El objetivo final es denegar todos los paquetes, lo cual no se lleva a cabo debido a las siguientes razones:

• La segunda sentencia autoriza al rango que va de 192.168.1.0 a 192.168.1.63 para que establezcan la comunicación.

• La primera sentencia autoriza todas las direcciones de la red 10.0.0.0 (10.0.0.0 a 10.255.255.255) para que establezcan la comunicación, lo cual no coincide con el rango especificado.

Para eliminar estos problemas habría que reconstruir la lista de la siguiente manera: Router(config)#access‐list 1 deny 10.0.0.0 0.0.1.255 Router(config)#access‐list 1 permit 10.0.0.0 0.255.255.255 Router(config)#access‐list 1 permit 192.168.1.64 0.0.0.63 Router(config)#access‐list 1 permit 192.168.1.0 0.0.0.3 Hay que observar que, en este caso, se puede realizar esta tarea con sólo cuatro sentencias. La primera sentencia deniega el rango de dirección IP que va de 10.0.0.0 a 10.0.1.255, ya que la dirección y la máscara coinciden de la siguiente manera:

La segunda sentencia autoriza todas las direcciones de la red 10.0.0.0 que no coincidan con la primera sentencia. La tercera sentencia admite todos los paquetes situados en el rango que va de 192.168.1.64 a 192.168.1.127, como se muestra a continuación:

La cuarta sentencia autoriza todos los paquetes que van de 192,168‐1‐1 a 192.168.1.3, como se muestra a continuación:

Nota: En realidad, el último filtro también coincide con 192.168.1.0, pero como esta dirección no se puede utilizar en una red de clase C sin superred, no tiene sentido denegar la dirección específicamente. El deny implícito situado al final de la lista de acceso se ocupa del último objetivo, que consiste en rechazar todos los demás paquetes.

Una vez creada la lista de acceso, será preciso aplicarla a una interfaz y elegir una dirección utilizando el comando ip access‐group [número o nombre de lista de acceso] [entrada\salida]. Hay que recordar que cuando se aplica una lista de acceso se suele desear hacerlo tan cerca del origen del paquete como sea posible. De esta manera, si se desea utilizar esta lista para realizar una coincidencia interna con los usuarios que entren en el enrutador, habría que aplicar la lista a la interfaz de enrutador interna con la dirección entrante, como se muestra a continuación: Router{config‐if )# ip access‐group 1 in Nota: Hay que tener en cuenta que sólo se puede aplicar una lista de acceso individual en cualquier interfaz para el tráfico orientado hacia dentro o hacia fuera (una ACL por dirección). Por tanto, es preciso garantizar que todas las metas requeridas puedan alcanzarse con una ACL individual. En el caso de una lista de acceso denominada, el proceso es casi idéntico, exceptuando el hecho de que se modifica la ACL. Cuando se introduce la ACL se emplea el comando ip access‐list standard [nombre]. Este comando permite cambiar al modo de configuración de lista de acceso para la lista de acceso denominada, como se ilustra a continuación: Router(config)#ip access‐list standard test Router (config‐std‐nacl) # Una vez en el modo de configuración de lista de acceso se pueden introducir los parámetros de lista de acceso utilizando sentencias permit o deny: Router(config‐std‐nacl)# deny 10.0.0.0 0.0.255.255 Router(config‐std‐nacl)# permit 172.16.0 0.0.255.255 Estas sentencias se procesan en el orden en que se introduzcan, como ocurre con las listas de acceso numeradas. La única diferencia está en el hecho de que, a diferencia de las listas de acceso numeradas, se pueden eliminar comandos individuales en una lista de acceso denominada mediante el uso de sentencias específicas no deny o no permit:

Consejo: La diferencia fundamental que existe entre una lista de acceso denominada y una numerada radica en la capacidad de utilizar nombres descriptivos para listas de acceso denominadas y la capacidad de modificar entradas individuales en las listas de acceso numeradas. Sin embargo, esta última diferencia suele quedar anulada, ya que basta con copiar la sentencia de lista de acceso en el portapapeles desde una lista de acceso numerada (mostrada en un comando show run o show star) y reordenar la lista a placer. Una vez terminado este proceso, basta con eliminar la lista de acceso original con un comando no access‐list (número] y pegar la lista de acceso modificada en la ventana del terminal. Hay que observar que la sentencia host aparece en la parte superior de la lista de acceso incluso si se introduce después de otras sentencias. Se trata de un elemento específico que permite acceder a listas que pertenecen a un anfitrión determinado, ya que tienen un carácter más específico y, habitualmente, deberían colocarse en la parte superior de la lista. También hay que advertir la presencia de la sentencia permit any. La palabra clave any constituye una forma rápida de garantizar que todos los paquetes coincidan con un filtro. La palabra clave any es la misma que se especificó en un IP de 0.0.0.0 (a decir verdad, cualquier IP) con una máscara 255.255.255.255. Listas de acceso extendidas Después de conocer las ACL estándar, en este apartado se explicarán las complejidades propias de las ACL extendidas. En una ACL extendida se pueden especificar muchos más parámetros, protocolos (incluyendo IP, TCP y UDP), direcciones de destino y puertos (para TCP y UDP). Nota: Las ACL IP extendidas numeradas pueden utilizar rangos que van de100 a 199 o de 2000 a 2699. Con una ACL extendida se debe especificar un protocolo para generar la coincidencia. El protocolo con el que se establece dicha coincidencia puede ser cualquier número de protocolo IP situado entre 1 y 255, o cualquiera de las siguientes palabras clave

• IP (para coincidir con todos tos paquetes IP). • ICMP. • TCP • EIGRR • IGRP • OSPF • Los protocolos restantes escapan al propósito de este apartado (PIM, IPINIP GRE, NOS o IGMP).

Cuando se genera una coincidencia con TCP o UDP se abren otras posibilidades interesantes. Se puede elegir la posibilidad de establecer coincidencias con puertos de origen o de destino. Cuando se coincide con puertos es preciso tener la capacidad de efectuar la coincidencia basándose en cinco operadores:

• It. Menor que el número listado. • gt. Mayor que el número listado. • eq. Igual que el número listado. • neq. Distinto del número listado. • range. Todos los puertos situados en el rango especificado mediante dos números.

Nota: También se pueden especificar puertos mediante el uso de palabras clave en lugar de números. Entre las palabras clave IOS reconocidas para puertos se incluyen las siguientes: bgp, echo, finger, ftp, ftp‐data, gopher, irc, nntp, pop2, pop3, smtp, syslog, telnet, whois, y www. Asimismo, es posible especificar la autorización de paquetes (o su rechazo, aunque esto último no resulta útil) basándose en el paquete que forma parte de una sesión previamente establecida mediante el uso de la palabra clave established. De esta misma manera, se puede utilizar la palabra clave established para las sentencias reflexive en las ACL. Para ver de qué forma casan todas estas piezas adicionales en una ACL extendida, a continuación se analizará un conjunto de metas de filtrado y se explicará cómo alcanzar estos objetivos. Las metas

requeridas para filtrar los paquetes entrantes en la interfaz externa del enrutador se enumeran a continuación:

• Deben autorizarse todos los paquetes destinados a 192.168.1.1 utilizando un puerto 80 de destino TCP.

• Deben autorizarse todas las comunicaciones que se originen desde la red privada a los servidores web externos que utilicen HTTP y HTTPS.

• Deben autorizarse todas las comunicaciones entrantes desde el anfitrión externo 10.1.1.1 que utilicen números de puerto de origen TCP y UDP que vayan de 22.000 a 44.000.

• Deben autorizarse todas las comunicaciones entrantes al anfitrión 192.168.1.200. • Deben autorizarse todas las sesiones no establecidas que entren en la interfaz externa y utilicen

puertos de destino conocidos al anfitrión 192.168.1.100. • Debe rechazarse todo el tráfico restante.

Para alcanzar el primer objetivo hay que introducir una sentencia similar a la siguiente: Router(config)#access‐list 100 permit tcp any host 192.168.1.1 eq 80 La palabra clave any indica al enrutador que debe realizar una coincidencia con cualquier IP de origen. Como el puerto no se especifica a continuación, se efectúa una coincidencia con todos los puertos de origen. La sección host 192.168.1.1 indi ca al enrutador que debe efectuar una coincidencia con el anfitrión de destino 192.168.1.1. Finalmente, eq 80 indica al enrutador que debe efectuar una coinci‐dencia con el puerto destino 80. Este filtro efectúa exactamente la tarea requerida: establece coincidencia con todas las comunicaciones procedentes de cualquier anfitrión destinado a 192.168.1.1 utilizando el puerto de destino 80 TCP 80 (HTTP). Para establecer una coincidencia con el próximo objetivo hay que emplear sentencias similares a las siguientes: Router(config)ftaccess‐list 100 permit tcp any eq 80 any established Router(config)#access‐list 100 permit tcp any eq 443 any established Como lo que se desea es autorizar exclusivamente los paquetes que utilicen HTTP o HTTPS para regresar a los anfitriones situados en la red interna, es necesario establecer una coincidencia con el puerto de origen en 80 y 443 en lugar de hacerlo con el de destino. Asimismo, puesto que únicamente se desea devolver paquetes procedentes exclusivamente de las sesiones previamente establecidas por estos anfitriones, se utiliza la palabra clave established. Para autorizar todas las comunicaciones entrantes procedentes del anfitrión externo 10.1.1.1 utilizando números de puerto de origen TCP y UDP comprendidos entre 22.000 y 44.000, hay que introducir dos sentencias similares a las siguientes: Router(config)#access‐list 100 permit tcp 10.1.1.1 range 22000 44000 any Router(config)#access‐list 100 permit udp 10.1.1.1 range 22000 44000 any Para autorizar todas las conexiones internas al anfitrión 192.168.1.200 hay que utilizar la sentencia siguiente: Router(config)#access‐list 100 permit ip any host 192.168.1.200 Finalmente, para autorizar conexiones utilizando puertos de destino conocidos al anfitrión 192.168.1.100 hay que utilizar la sentencia siguiente: Router(config)#access‐list 100 permit ip any host 192.168.1.100 lt 1024 Una vez terminada la construcción de la ACL, cabe aplicarla a la interfaz externa del enrutador, utilizando el comando estándar ip access‐group [número o nombre de lista de acceso][in \out].

Las ACL extendidas denominadas siguen los mismos principios generales las ACL numeradas, por lo que aquí no se analizarán sus características Basta aplicar los principios relacionados con las ACL extendidas a los comandos enumerados en el apartado dedicado a las ACL denominadas estándar. Siguiendo este procedimiento, el usuario podrá crear ACL extendidas denominadas. Referencias Bibliográficas: HILL, Brian. CISCO Manual de referencia. McGaw‐Hill/Interamericana de España. Pp 963‐990.

ACL extendidas y ACL reflexivas

Hay que observar que una ACL extendida que utiliza la palabra clave established no es lo mismo que una ACL reflexiva verdadera. Una ACL reflexiva verdadera lleva un registro de las sesiones y construye entradas ACL de carácter temporal basándose en dichas sesiones, mientras que la palabra clave established simplemente examina los bits ACK y RST en paquetes y autoriza cualquier paquete que cumpla los criterios de filtro configurados con estos bits. El simple uso de la palabra clave established, aunque puede reducir la complejidad de la ACL y deshacer la mayor parte de los intentos de entrada, no detendrá a un hacker hábil que sepa cómo manipular los bits ACK o RST en un paquete y, por tanto, no deben utilizarse en redes de alta seguridad. En el presente libro no se analizarán con detalle las características de las ACL reflexivas, pero si el lector desea más información al respecto, se recomienda visitar la dirección http://www.dsco.comando/univercd/cc/td/doc/ product/software/ios 121/12 Icgcr/secur_c/scprt3/scdreflx.htm.

Listas de acceso

Documents

Transcript of Listas de acceso