Guía de configuración de la Seguridad de Cisco IOS: Sujeción del avión de los datos, versión 12.2SR
Cómo configurar el Context-based Access Control
6 Agosto 2013 - Traducción Automática | Otras Versiones: PDFpdf 405 KB | Inglés (19 Febrero 2008) | Comentarios

Contenidos

Configurar el control de acceso basado en el contexto

Contenido

Requisitos previos para configurar el Context-Based Access Control

Restricciones para configurar el Context-Based Access Control

Tráfico FTP y CBAC

Compatibilidad de IPSec y CBAC

Información sobre el Context-Based Access Control

Qué hace CBAC

Filtrado de Tráfico

Inspección del Tráfico

Alertas y Pistas de Auditoría

Prevención de intromisión

Qué No Hace CBAC

Cómo Funciona CBAC: Descripción General

Cómo Funciona CBAC: Detalles

Se examinan los paquetes

Una tabla de estado mantiene la información de estado de la sesión

Se aproxima el UDP “sesiones”

Las entradas de lista de acceso se crean y se borran dinámicamente para permitir el tráfico de retorno y las conexiones de datos adicionales

Cuándo y dónde Configurar CBAC

El Proceso CBAC

Protocolos admitidos CBAC

Soporte a protocolo RTSP y de H.323 para las aplicaciones multimedia

Soporte RTSP

Soporte de H.323

Impacto en la Memoria y en el Rendimiento

Selección de una Interfaz: Interno o Externo

Configurar las listas de IP Access en la interfaz

Configuración Básica

Interfaz Externa

Interfaz Interna

Sesiones medio abiertas

Examen de la fragmentación del paquete del IP

Examen genérico TCP y UDP

Guías de consulta para configurar un Firewall

Examen RTSP

RTSP con el RDT

RTSP con TCP solamente (modo entrelazado)

RTSP con SMIL

RTSP con RTP (IP/TV)

H.323 V2

Como Interpretar el Syslog y los Mensajes de la Consola Generados por CBAC

Mensajes de error de la Detección de Ataques de Negación de Servicio

Mensajes de Error de Detección de Ataques SMTP

Mensajes de Error de Bloqueo Java

Mensajes de error de FTP

Mensajes del Rastro de Auditoría

Desactivación de CBAC

Cómo configurar el Context-Based Access Control

Configurar el tiempo de espera global agotado y los umbrales

Definición de una regla del examen

Configuración de la Inspección de Protocolo de la Capa de Aplicación

Configuración de la Inspección TCP y UDP Genérica

Aplicación de la regla del examen a una interfaz

Configurar el registro y el rastro de auditoría

Verificar el CBAC

Monitoreo y Mantenimiento de CBAC

Debugging del Control de Acceso Basado en Contexto

Comandos Genéricos de Debug

Comandos de Debug del Nivel de Transporte

Comandos de Debug del Application Protocol

Ejemplos de la configuración CBAC

Ejemplo de Configuración de Interfaz Ethernet

Ejemplo de Configuración de la Interfaz ATM

Ejemplo de Configuración de Oficina Remota a ISP

Ejemplo de Configuración de Oficina Remota a Sucursal

Ejemplo de Configuración de Sucursal de Dos Interfaces

Ejemplo de Configuración de Sucursal de Interfaz Múltiple


Configurar el control de acceso basado en el contexto


Este capítulo describe cómo configurar el Control de acceso basado en el contexto (CBAC). El CBAC proporciona las funciones avanzadas del filtrado de tráfico y se puede utilizar como parte integrante del su Firewall de red. Para más información con respecto a los Firewall, refiera al capítulo “descripción del Firewall Cisco IOS.”

Contenido

Requisitos previos para configurar el Context-Based Access Control

Restricciones para configurar el Context-Based Access Control

Información sobre el Context-Based Access Control

Cómo configurar el Context-Based Access Control

Monitoreo y Mantenimiento de CBAC

Ejemplos de la configuración CBAC

Requisitos previos para configurar el Context-Based Access Control

Si usted intenta configurar el Control de acceso basado en el contexto (CBAC) pero no tiene una buena comprensión de cómo el CBAC trabaja, usted puede ser que introduzca inadvertidamente los riesgos de seguridad al Firewall y a la red protegida. Usted debe estar seguro que usted entiende qué CBAC hace antes de que usted configure el CBAC.

Como con todos los dispositivos de interconexión de redes, proteja el acceso en el Firewall configurando las contraseñas según lo descrito en el “configurar del capítulo de las contraseñas y de los privilegios”. Debe considerar también la configuración de la autenticación, autorización y contabilización de usuarios según lo descrito en la parte "Autenticación, Autorización y Contabilización (AAA)" de esta guía. Las guías de consulta adicionales para ayudarle a establecer una buena política de seguridad se pueden encontrar en “el capítulo de la descripción del Firewall Cisco IOS”.

Restricciones para configurar el Context-Based Access Control

El CBAC tiene las restricciones siguientes:

El CBAC está disponible solamente para protocolo IP el tráfico. Solamente se examinan el TCP y los paquetes UDP. (El otro tráfico IP, tal como ICMP, no se puede examinar con el CBAC y se debe filtrar con las Listas de acceso básicas en lugar de otro.)

Si usted configura de nuevo sus Listas de acceso cuando usted configura el CBAC, sea consciente que si sus Listas de acceso bloquean el tráfico TFTP en una interfaz, usted no podrá al netboot sobre esa interfaz. (Esto no es una limitación CBAC-específica, sino es funciones de la lista de acceso existente de la parte de.)

Los paquetes con el Firewall como la dirección de origen o de destino no son examinados por el CBAC.

El CBAC ignora los mensajes inalcanzables de ICMP.

Soportes del examen del protocolo del H.323V2 y RTSP solamente las aplicaciones del servidor cliente siguientes de las multimedias: Cisco IP/TV, jugador de RealNetworks RealAudio G2, Apple QuickTime 4.

Usted puede utilizar el CBAC así como el resto de características de escudo de protección mencionadas previamente en “el capítulo de la descripción del Firewall Cisco IOS”.

El CBAC trabaja con la transferencia y el process switching rápidos.

Esta sección también discute las restricciones respecto a:

Tráfico FTP y CBAC

Compatibilidad de IPSec y CBAC

Tráfico FTP y CBAC

Con el FTP, el CBAC no permite las conexiones de tercera persona (de tres vías transferencia FTP).

Cuando el CBAC examina el tráfico FTP, permite solamente los canales de datos con el puerto destino en el rango de 1024 a 65535.

El CBAC no abrirá un canal de datos si la autenticación de servidor del FTP cliente falla.

Compatibilidad de IPSec y CBAC

Cuando el CBAC y el IPSec se habilitan en el mismo router, y el router de escudo de protección es un punto final para el IPSec para el flujo determinado, después el IPSec es compatible con el CBAC (es decir, el CBAC puede hacer su examen normal que procesa en el flujo).

Si el router no es un punto final de IPSec, pero el paquete es un paquete IPsec, después el CBAC no examinará los paquetes porque el número de protocolo en el encabezado IP del paquete IPsec no es TCP o UDP. El CBAC examina solamente el UDP y los paquetes TCP.

Información sobre el Context-Based Access Control

Qué hace CBAC

Qué No Hace CBAC

Cómo Funciona CBAC: Descripción General

Cómo Funciona CBAC: Detalles

Cuándo y dónde Configurar CBAC

El Proceso CBAC

Protocolos admitidos CBAC

Soporte a protocolo RTSP y de H.323 para las aplicaciones multimedia

Impacto en la Memoria y en el Rendimiento

Selección de una Interfaz: Interno o Externo

Configurar las listas de IP Access en la interfaz

Sesiones medio abiertas

Examen de la fragmentación del paquete del IP

Examen genérico TCP y UDP

Guías de consulta para configurar un Firewall

Examen RTSP

H.323 V2

Como Interpretar el Syslog y los Mensajes de la Consola Generados por CBAC

Desactivación de CBAC

Qué hace CBAC

El CBAC trabaja para proporcionar la protección de la red en los niveles múltiples usando las funciones siguientes:

Filtrado de Tráfico

Inspección del Tráfico

Alertas y Pistas de Auditoría

Prevención de intromisión

Filtrado de Tráfico

CBAC filtra inteligentemente los paquetes TCP y UDP en función de la información de sesión de protocolo de la capa de aplicación. Puede configurar CBAC para permitir que el tráfico TCP y UDP especificado atraviese un firewall solamente cuando la conexión se inicie dentro de la red que se desea proteger. CBAC puede inspeccionar el tráfico para comprobar si hay sesiones que se originen en cualquiera de los lados del firewall y se puede utilizar para los perímetros de la intranet, la extranet e Internet de la red.

Sin el CBAC, el filtrado de tráfico se limita a las aplicaciones de la lista de acceso que examinan los paquetes en la capa de red, o a lo más, la capa de transporte. Sin embargo, el CBAC examina la información no sólo de la capa de red y de la capa de transporte pero también examina la información del Application Layer Protocol (tal como información de la conexión FTP) para aprender sobre el estado de la sesión. Esto permite el soporte de los protocolos que implican los múltiples canales creados como resultado de las negociaciones en el canal de control. La mayor parte de los protocolos de las multimedias así como algunos otros protocolos (tales como FTP, RPC, y SQL*Net) implican los múltiples canales.

Usando el CBAC, el bloqueo de las Javas se puede configurar para filtrar el tráfico HTTP basado en la dirección del servidor o para negar totalmente el acceso a los subprogramas java que no se integran en haber archivado o un archivo comprimido. Con las Javas, usted debe proteger contra el riesgo de usuarios que descargan inadvertidamente los applet destructivos en su red. Para proteger contra este riesgo, usted podría requerir a todos los usuarios inhabilitar las Javas en su navegador. Si esto no es una solución aceptable, usted puede crear una regla de la inspección de CBAC para filtrar los subprogramas java en el Firewall, que permite que los usuarios descarguen solamente los applet que residen dentro del Firewall y los applet de confianza desde fuera del Firewall. Para el filtrado de contenido extenso de las Javas, exploración activa-x, o del virus, usted puede ser que quiera considerar comprar un producto dedicado del filtrado de contenido.

Inspección del Tráfico

El CBAC examina el tráfico que viaja con el Firewall para descubrir y para manejar la información del estado para el TCP y las Sesiones UDP. Esta información del estado se utiliza para crear las aperturas temporales en las Listas de acceso del Firewall para permitir el tráfico de retorno y las conexiones de datos adicionales para las sesiones autorizadas.

La inspección de los paquetes en la capa de la aplicación, y mantener la información TCP y de Sesión UDP, proporciona el CBAC con la capacidad de detectar y de prevenir los tipos determinados de ataques a la red tales como SYN-inundación. Un ataque de inundación SYN ocurre cuando un atacante de la red inunda un servidor con una presa de los pedidos la conexión y no completa la conexión. El volumen resultante de conexiones entreabiertas puede abrumar el servidor, haciéndolo negar el servicio a las peticiones válidas. Los ataques a la red que niegan el acceso a un dispositivo de red se llaman los ataques del servicio negado (DOS).

El CBAC ayuda a proteger contra los ataques DOS de otras maneras. El CBAC examina los números de secuencia del paquete en las conexiones TCP para ver si están dentro de los rangos esperados — el CBAC cae cualquier paquete sospechoso. Usted puede también configurar el CBAC para caer las conexiones entreabiertas, que requieren el proceso y a los recursos de memoria del Firewall para mantener. Además, el CBAC puede detectar inusualmente las altas velocidades de las nuevas conexiones y de los mensajes de alerta del problema.

El CBAC puede ayudar protegiendo contra ciertos ataques DOS que implican los paquetes hechos fragmentos IP. Aunque el Firewall evita que un atacante haga las conexiones reales a un host dado, el atacante puede interrumpir los servicios proporcionados por ese host. Esto es hecha enviando muchos fragmentos NON-iniciales IP o enviando los paquetes fragmentados completos a través de un router con un ACL que filtre el primer fragmento de un paquete fragmentado. Estos fragmentos pueden inmovilizar los recursos en el host de destino mientras que intenta volver a montar los paquetes incompletos.

Alertas y Pistas de Auditoría

CBAC también genera alertas en tiempo real y pistas de auditoría. Las características aumentadas del rastro de auditoría utilizan el SYSLOG para seguir todas las transacciones de la red; sellos del tiempo de grabación, host de origen, computadora principal de destino, puertos usados, y el número total de bytes transmitidos, para la información avanzada, basada en la sesión. Las alertas en tiempo real envían los mensajes de error SYSLOG a las consolas de administración centrales cuando se detecta actividad sospechosa. Utilizando las reglas de inspección de CBAC, puede configurar alertas e información de auditoría para cada Application Protocol. Por ejemplo, si usted quiere generar la información del rastro de auditoría para el tráfico HTTP, usted puede especificar eso en la regla CBAC que cubre el examen HTTP.

Prevención de intromisión

El CBAC proporciona las cantidades limitadas de detección de intrusos para proteger contra los ataques específicos S TP. Con la detección de intrusos, los mensajes de Syslog se revisan y se monitorean para las “firmas específicas del ataque.” Los tipos determinados de ataques a la red tienen las características específicas, o firmas. Cuando el CBAC detecta los ataques, reajusta las conexiones que ofenden y envía la Información de syslog al servidor de Syslog. Refiera a la sección “ejemplos de la configuración CBAC” más adelante en este capítulo para una lista de firmas soportadas.

Además de la detección de intrusos limitada ofrecida por el CBAC, el conjunto de funciones del Cisco IOS Firewall ofrece la tecnología de la detección de intrusos para las Plataformas del alcance medio y del router de mayor capacidad usando el Cisco IOS Intrusion Prevention System (IPS). El Cisco IOS IPS reestructura y substituye el sistema existente de la detección de intrusos del Cisco IOS (IDS). Es ideal para cualquier perímetro de red, y especialmente para las ubicaciones en las cuales están desplegando a un router y la seguridad complementaria entre los segmentos de red se requiere. También puede proteger las conexiones del intranet y del extranet donde se asigna por mandato la seguridad complementaria, y la sucursal localiza la conexión con la oficina corporativa o Internet.

El Cisco IOS IPS actúa como un sensor en línea de la detección de intrusos, los paquetes de observación y sesiones mientras que él atraviesa el router y analizar cada paquete para hacer juego las firmas unas de los IPS del Cisco IOS. Cuando un ISP Cisco IOS detecta actividad sospechosa, responde antes de que la seguridad de la red pueda verse comprometida y registra el evento mediante mensajes syslog de CIsco IOS o de Intercambio de evento de dispositivo de seguridad (Security Device Event Exchange / SDEE).

Para más información sobre el Cisco IOS IPS, refiera al módulo el “que configura Cisco IOS Intrusion Prevention System (IPS).”

Qué No Hace CBAC

El CBAC no proporciona la filtración inteligente para todos los protocolos; trabaja solamente para los protocolos que usted especifica. Si usted no especifica cierto protocolo para el CBAC, las listas de acceso existente determinarán cómo se filtra ese protocolo. No se creará ningunas aperturas temporales para los protocolos no especificados para la inspección de CBAC.

El CBAC no protege contra los ataques que originan contra dentro de la red protegida a menos que ese tráfico viaje a través de un router que tenga el conjunto de funciones del Cisco IOS Firewall desplegado en él. El CBAC detecta y protege solamente contra los ataques que viajan con el Firewall. Éste es un escenario en el cual usted puede ser que quiera desplegar el CBAC en un router basado en intranet.

El CBAC protege contra los tipos determinados de ataques, pero no cada tipo de ataque. El CBAC no se debe considerar una defensa perfecta, impenetrable. Los atacantes determinados, expertos pudieron poder poner en marcha los ataques eficaces. Mientras que no hay cosa tal como una defensa perfecta, el CBAC detecta y previene la mayor parte de los ataques populares en su red.

Cómo Funciona CBAC: Descripción General

El CBAC crea las aperturas temporales en las Listas de acceso en las interfaces de escudo de protección. Se crean estas aperturas cuando las salidas de tráfico especificado su red interna con el Firewall. Las aperturas permiten el volver del tráfico (que sería bloqueado normalmente) y canales de datos adicionales para ingresar su red interna detrás con el Firewall. El tráfico se permite detrás con el Firewall solamente si es parte de la misma sesión que el tráfico original que accionó el CBAC al salir con el Firewall.

En este capítulo, los términos “entrantes” y “salientes” se utilizan para describir a la dirección del tráfico en relación con la interfaz del router en la cual el CBAC es aplicado. Por ejemplo, si una regla CBAC es entrante aplicado en la interfaz E0, después los paquetes que ingresan la interfaz E0 de la red serán examinados. Si una regla CBAC es saliente aplicado en la interfaz E0, después los paquetes que dejan la interfaz E0 a la red serán examinados. Esto es similar al trabajo de la manera ACL.

Por ejemplo, considere una regla de la inspección de CBAC nombrada los hqusers, y suponga que la regla es entrante aplicado en la interfaz E0:

router (config-if)# ip inspect hqusers in

Este comando hace el CBAC examinar los paquetes que entran en esta interfaz de la red. Si un paquete está intentando iniciar una sesión, el CBAC entonces determinará si se permite este protocolo, crea una sesión CBAC, agrega los ACL apropiados para permitir el tráfico de retorno y para hacer cualquier examen contento necesario en cualesquiera paquetes futuros para esta sesión.

Los términos “entrados” y la “salida” se utilizan para describir las interfaces en las cuales el tráfico de la red ingresa o sale el router de escudo de protección. Un paquete ingresa el router de escudo de protección vía la interfaz de entrada, es examinado por el software de escudo de protección y después sale al router vía la interfaz de salida.

En el cuadro 1, las listas de acceso de entrada en el s0 y el s1 se configuran para bloquear el tráfico de Telnet, y no hay lista de acceso de salida configurada en el E0. Cuando el pedido de conexión para la sesión telnet User1 pasa con el Firewall, el CBAC crea una apertura temporal en la lista de acceso de entrada en el s0 para permitir volver el tráfico de Telnet para la sesión telnet User1. (Si la misma lista de acceso se aplica a ambo s0 y s1, la misma apertura aparecería en ambas interfaces.) En caso necesario, el CBAC también habría creado una apertura similar en una lista de acceso de salida en el E0 para permitir el tráfico de retorno.

El cuadro 1 CBAC abre los agujeros temporales en las Listas de acceso del Firewall

Cómo Funciona CBAC: Detalles

Esta sección describe cómo el CBAC examina los paquetes y mantiene la información del estado sobre las sesiones para proporcionar la filtración inteligente.

Se examinan los paquetes

Con el CBAC, usted especifica qué protocolos usted quiere ser examinado, y usted especifica una interfaz y una dirección de la interfaz (en o hacia fuera) donde el examen origina. Solamente los protocolos especificados serán examinados por el CBAC.

Los paquetes que ingresan el Firewall son examinados por el CBAC solamente si primero pasan la lista de acceso de entrada en la lista de la interfaz de entrada y de acceso de salida en la interfaz de salida. Si un paquete es negado por la lista de acceso, el paquete es caído y no examinado simplemente por el CBAC.

La inspección de CBAC sigue los números de secuencia en todos los paquetes TCP, y cae esos paquetes con los números de secuencia que no están dentro de los rangos esperados.

La inspección de CBAC reconoce los comandos específicos a la aplicación (tales como comandos ilegales S TP) en el canal de control, y detecta y previene ciertos ataques del nivel de la aplicación.

Cuando el CBAC sospecha un ataque, la característica DOS puede tomar varias medidas:

Genere los mensajes de alerta

Proteja a los recursos del sistema que podrían impedir el funcionamiento

Bloqueares paquete de los atacantes sospechosos

CBAC usa valores de umbral y de tiempo de espera para administrar la información de estado de la sesión, ayudando a determinar cuándo se debe descartar las sesiones que no se establecen completamente. Fijando los valores de agotamiento del tiempo para las ayudas de las sesiones de red previenen los ataques DOS liberando encima de los recursos del sistema, cayendo las sesiones después de una determinada cantidad de hora. Fijando los valores de umbral para las ayudas de las sesiones de red previenen los ataques DOS controlando el número de sesiones medio abiertas, que limita al periodo de los recursos del sistema aplicados a las sesiones medio abiertas. Cuando se cae una sesión, el CBAC envía un mensaje de la restauración a los dispositivos en las puntas de los ambos extremos (fuente y destino) de la sesión. Cuando el sistema bajo ataque DOS recibe un comando reset, libera, o libera para arriba, los procesos y los recursos relacionados con esa sesión incompleta.

El CBAC proporciona tres umbrales contra los ataques DOS:

El número total de TCP medio abierto o de Sesiones UDP

El número de sesiones medio abiertas basadas sobre el tiempo

El número de las sesiones medio abiertas TCP-solamente por el host

Si se excede un umbral, el CBAC tiene dos opciones:

Envíe un mensaje de la restauración al final señala de la más vieja sesión medio abierta, haciendo los recursos disponibles para mantener los paquetes SYN nuevamente de llegada.

En el caso de la mitad de las sesiones abiertas TCP solamente, el CBAC bloquea todos los paquetes SYN temporalmente para la duración configurada por el valor de umbral. Cuando el router bloquea un paquete SYN, la entrada en contacto de tres vías TCP nunca se inicia, que evita que el router usar la memoria y procese los recursos necesarios para las conexiones válidas.

La detección y la prevención DOS requiere que usted cree una regla de la inspección de CBAC y aplique esa regla en una interfaz. La regla del examen debe incluir los protocolos que usted quiere monitorear contra los ataques DOS. Por ejemplo, si usted tiene examen TCP habilitado en la regla del examen, después el CBAC puede seguir todas las conexiones TCP para mirar para los ataques DOS. Si la regla del examen incluye el examen del protocolo FTP pero no el examen TCP, el CBAC sigue solamente las conexiones FTP para los ataques DOS.

Para información detallada sobre el descanso y los valores de umbral de la configuración en el CBAC para detectar y para prevenir los ataques DOS, refiérase en “cómo configurar la sección del Context-Based Access Control”.

Una tabla de estado mantiene la información de estado de la sesión

Siempre que se examine un paquete, una tabla de estado se pone al día para incluir la información sobre el estado de la sesión.

El tráfico de retorno será permitido solamente detrás con el Firewall si la tabla de estado contiene la información que indica que el paquete pertenece a una sesión autorizada. El CBAC controla el tráfico que pertenece a una sesión válida. Cuando se examina el tráfico de retorno, la información de la tabla de estado se pone al día cuanto sea necesario.

Se aproxima el UDP “sesiones”

Con el UDP — un Servicio sin conexión — no hay sesiones reales, así que el software aproxima las sesiones examinando la información en el paquete y determinandola si el paquete es similar a otros paquetes UDP (por ejemplo, las mismas direcciones de origen/destino y números del puerto) y si el paquete fue detectado pronto después de otro paquete UDP similar. “Pronto” significa dentro del período de tiempo de inactividad configurable UDP.

Las entradas de lista de acceso se crean y se borran dinámicamente para permitir el tráfico de retorno y las conexiones de datos adicionales

El CBAC crea y borra dinámicamente las entradas de lista de acceso en las interfaces de escudo de protección, según la información mantenida en las tablas de estado. Estas entradas de lista de acceso se aplican a las interfaces para examinar el flujo de tráfico nuevamente dentro de la red interna. Estas entradas crean las aperturas temporales en el Firewall para permitir solamente el tráfico que es parte de a la sesión autorizada.

Las entradas temporarias de la lista de acceso nunca se guardan al NVRAM.

Cuándo y dónde Configurar CBAC

Configuración CBAC en los Firewall que protegen las redes internas. Tales Firewall deben ser routeres Cisco con el conjunto de funciones del Cisco IOS Firewall configurado según lo descrito previamente en la sección “Firewall Cisco IOS.”

Utilice el CBAC cuando el Firewall pasará el tráfico tal como el siguiente:

Aplicaciones de Internet estándar TCP y UDP

Aplicaciones multimedia

Soporte del Oracle

Utilice el CBAC para estas aplicaciones si usted quisiera que el tráfico de la aplicación fuera permitido con el Firewall solamente cuando la sesión del tráfico se inicia de un lado determinado del Firewall (generalmente de la red interna protegida).

En muchos casos, usted configurará el CBAC en una dirección solamente en una sola interfaz, que hace el tráfico ser permitida nuevamente dentro de la red interna solamente si el tráfico es parte de (válido, existiendo) a la sesión permitida. Esto es una configuración típica para proteger sus redes internas contra el tráfico que origina en Internet.

Usted puede también configurar el CBAC en dos direcciones en una o más interfaces. El CBAC se configura en dos direcciones cuando las redes a ambos lados del Firewall deben ser protegidas, por ejemplo con el extranet o las configuraciones del intranet, y proteger contra los ataques DOS. Por ejemplo, si el Firewall se sitúa entre dos redes de sociedades del partner, usted puede ser que desee restringir el tráfico en las aplicaciones de una dirección con certeza, y restringe el tráfico en la dirección opuesta para otras aplicaciones.

El Proceso CBAC

Esta sección describe una Secuencia de eventos de la muestra que ocurra cuando el CBAC se configura en una interfaz externa que conecte con una red externa tal como Internet.

En este ejemplo, un paquete TCP sale la red interna a través de la interfaz externa del Firewall. El paquete TCP es el primer paquete de una sesión telnet, y el TCP se configura para la inspección de CBAC.

1. El paquete alcanza la interfaz externa del Firewall.

2. El paquete se evalúa contra la lista del acceso de salida existente de la interfaz, y se permite el paquete. (A negó el paquete sería caída simplemente en este momento.)

3. El paquete es examinado por el CBAC para determinar y el registrar información sobre el estado de la conexión del paquete. Esta información se registra en una nueva entrada de tabla del estado creada para la nueva conexión.

(Si la aplicación del paquete — Telnet — no fue configurado para la inspección de CBAC, el paquete sería remitido simplemente hacia fuera la interfaz en este momento sin la inspección por el CBAC. Vea la sección el “definir de una regla del examen” más adelante en este capítulo para la información sobre configurar la inspección de CBAC.)

4.De acuerdo con la información del estado obtenida, el CBAC crea una entrada temporaria de la lista de acceso que se inserte al principio de la lista de acceso ampliada entrante de la interfaz externa. Esta entrada temporaria de la lista de acceso se diseña para permitir los paquetes de entrada que son parte de la misma conexión que el paquete saliente acaba de examinar.

5. El paquete saliente se remite hacia fuera la interfaz.

6. Más adelante, un paquete de entrada alcanza la interfaz. Este paquete es parte de la misma conexión Telnet establecida previamente con el paquete saliente. El paquete de entrada se evalúa contra la lista de acceso de entrada, y se permite debido a la entrada temporaria de la lista de acceso creada previamente.

7. El paquete de entrada permitido es examinado por el CBAC, y la entrada de tabla del estado de la conexión se pone al día cuanto sea necesario. De acuerdo con la información del estado actualizada, las entradas temporarias entrantes de la lista de acceso ampliada se pudieron modificar para permitir solamente los paquetes que son válidos para el estado actual de la conexión.

8. Cualquier entrante o paquete saliente adicional que pertenezcan a la conexión se examina para poner al día la entrada de tabla del estado y para modificar las entradas de lista de acceso de entrada temporales como sea necesario, y las se remite a través de la interfaz.

9. Cuando la conexión termina o mide el tiempo hacia fuera, se borra la entrada de tabla del estado de la conexión, y se borran las entradas de la lista de acceso de entrada temporales de la conexión.

En el proceso de la muestra apenas descrito, se configuran las Listas de acceso del Firewall como sigue:

Una lista de IP Access saliente (estándar o extendida) se aplica a la interfaz externa. Esta lista de acceso permite todos los paquetes que usted quiera permitir que salgan la red, incluyendo los paquetes que usted quiere ser examinado por el CBAC. En este caso, se permiten los paquetes Telnet.

Una lista de acceso IP ampliado entrante se aplica a la interfaz externa. Esta lista de acceso niega cualquier tráfico que se examinará por el CBAC — incluyendo los paquetes Telnet. Cuando el CBAC se acciona con un paquete saliente, el CBAC crea una apertura temporal en la lista de acceso de entrada para permitir solamente el tráfico que es parte de al válido, sesión existente.

Si la lista de acceso de entrada hubiera sido configurada para permitir todo el tráfico, el CBAC estaría creando las aperturas insustanciales en el Firewall para los paquetes que serían permitidos de todos modos.

Protocolos admitidos CBAC

Usted puede configurar el CBAC para examinar los siguientes tipos de sesiones:

Todas las sesiones TCP, sin importar el Application Layer Protocol (a veces llamado “examen monocanal” o “genérico” TCP)

Todas las Sesiones UDP, sin importar el Application Layer Protocol (a veces llamado “examen monocanal” o “genérico” UDP)

Usted puede también configurar el CBAC para examinar específicamente ciertos Application Layer Protocol. Los Application Layer Protocol siguientes se pueden todos configurar para el CBAC:

CU-SeeMe (solamente la versión de White Pine)

FTP

H.323 (tal como NetMeeting, ProShare)

HTTP (bloqueo de las Javas)

Microsoft NetShow

Comandos r de UNIX (tales como rlogin, rexec, y rsh)

Realaudio

RTSP (protocolo de flujo en tiempo real)

RPC (Sun RPC, no DCE RPC)

S TP (protocolo simple mail transport)


La notaCBAC se puede configurar para examinar S TP pero no ESMTP (protocolo simple mail transport extendido). El S TP se describe en el RFC 821. CBAC SMTP inspec no inspecciona la sesión ESMTP o la secuencia de comando. La configuración de la inspección SMTP no es útil para ESMTP y puede causar algunos problemas.

Para determinar si un mail server está haciendo el S TP o el ESMTP, entre en contacto su proveedor de software del mail server, o el telnet al puerto 25 del mail server y observe el banner para ver si señala el S TP o el ESMTP.


SQL*Net

Streamworks

TFTP

VDOLIVE

Cuando un protocolo se configura para el CBAC, se examina ese tráfico de protocolo, se mantiene la información del estado, y los paquetes se permiten generalmente detrás con el Firewall solamente si pertenecen a una sesión autorizada.

Soporte a protocolo RTSP y de H.323 para las aplicaciones multimedia

El CBAC soporta varios protocolos para las aplicaciones multimedia que requieren la salida de los datos con las propiedades en tiempo real tales como audio y videoconferencia. Este soporte incluye los protocolos siguientes de la aplicación multimedia:

Real-Time Streaming Protocol (RTSP)

H.323 versión 2 (H.323V2)

El examen RTSP y del H.323V2 permite que los clientes en una red protegida reciban los datos asociados a una sesión de las multimedias de un servidor en una red no protegida.

Soporte RTSP

El RTSP es el protocolo de estándares IETF (RFC 2326) para el control sobre la salida de los datos con las propiedades en tiempo real tales como audio y secuencias de video. Es útil para los broadcasts en grande y audio o Video on Demand que fluyen, y es soportado por una variedad de productos de proveedor de fluir las multimedias audios y video, incluyendo el software del Cisco IP/TV, del jugador, y de Apple QuickTime 4 de RealNetworks RealAudio G2.

El RFC 2326 permite que el RTSP ejecute encima el UDP o el TCP, aunque el CBAC soporta actualmente solamente el RTSP TCP basado. El RTSP establece un control de conexión TCP basado, o el canal, entre el cliente y servidor de las multimedias. El RTSP utiliza este canal a los comandos de control tales como “juego” y “pausa” entre el cliente y servidor. Estos comandos y respuestas de control son texto basado y son similares al HTTP.

El RTSP confía típicamente en un protocolo de transporte de datos basado en UDP tal como Real-Time Transport Protocol (RTP) estándar para abrir los canales diferentes para los datos y para los mensajes RTP Control Protocol (RTCP). Los canales RTP y RTCP ocurren en pares, con el RTP siendo un puerto y un RTCP pares que son el puerto consecutivo siguiente. La comprensión de la relación del RTP y del RTCP es importante para verificar la información de la sesión usando los comandos show CBAC.

El cliente RTSP utiliza el puerto TCP 554 o 8554 para abrir una Conexión multimedia con un servidor. El canal de control del canal de datos o de los datos (usando el RTCP) entre el cliente y el servidor se negocia dinámicamente entre el cliente y el servidor usando los altos puertos uces de los UDP (1024 a 65536).

CBAC utiliza esta información de puerto junto con información de conexión del cliente para crear entradas dinámicas de ACL (lista de control de acceso) en el firewall. Cuando se terminan las conexiones TCP o UDP, el CBAC remueve estas entradas dinámicas de los ACLs apropiados.

El soporte CBAC para el RTSP incluye los modos de transporte de datos siguientes:

Real-Time Transport Protocol (RTP) estándar

El RTP es una norma de IETF (RFC 1889) que soporta la salida de la información en tiempo real tal como audio y vídeo. El RTP utiliza el RTP Control Protocol (RTCP) para manejar la salida de la secuencia de los datos multimedia. Éste es el modo de operación normal para el software del Cisco IP/TV y de Apple QuickTime 4.

Transporte de datos reales de RealNetworks (RDT)

El RDT es un protocolo de propietario desarrollado por RealNetworks para el transporte de datos. Este modo utiliza el RTSP para el control de comunicación y utiliza el RDT para la conexión de datos y la retransmisión de los paquetes perdidos. Éste es el modo de operación normal para el RealServer G2 de RealNetworks.

Interpolado (modo túnel)

En este modo, el RTSP utiliza el canal de control para hacer un túnel el tráfico RTP o RDT.

Lenguaje sincronizado de la integración multimedia (SMIL)

SMIL es un lenguaje de la disposición que habilita la creación de las Presentaciones multimedia que consisten en los elementos múltiples de la música, de la Voz, de las imágenes, del texto, del vídeo y de los gráficos. Esto implica el control múltiple y las secuencias de datos RTSP entre el jugador y los servidores. Este modo está disponible solamente con el RTSP y el RDT. SMIL es una especificación propuesta del World Wide Web Consortium (W3C). El RealNetworks RealServer y RealServer G2 proporcionan el soporte para SMIL — el Cisco IP/TV y Apple QuickTime 4 no hacen.

Soporte de H.323

El soporte CBAC para el examen de H.323 incluye la versión 2 de H.323 y el H.323V2 de la versión 1. de H.323 proporciona la opción adcional sobre H.323 V1, incluyendo una opción del “comienzo rápido”. La opción de comienzo rápida minimiza el retardo entre el tiempo que un usuario inicia una conexión y el tiempo que el usuario consigue los datos (Voz, vídeo). El examen del H.323V2 es compatible con versiones anteriores con H.323 V1.

Con H.323 V1, después de que una conexión TCP se establezca entre el cliente y servidor (canal H.225), un canal diferente para el control de los media (canal H.245) se abre con el cual los canales de las multimedias para la auditoría y el vídeo se negocian más a fondo.

El cliente del H.323V2 abre una conexión al servidor que está escuchando en el puerto 1720. El canal de datos entre el cliente y el servidor se negocia dinámicamente usando los altos puertos uces de los UDP (1024 a 65536).

CBAC utiliza esta información de puerto junto con información de conexión del cliente para crear entradas dinámicas de ACL (lista de control de acceso) en el firewall. Cuando se terminan las conexiones TCP o UDP, el CBAC remueve estas entradas dinámicas de los ACLs apropiados.

Impacto en la Memoria y en el Rendimiento

Aplicaciones CBAC menos que aproximadamente 600 bytes de memoria por la conexión. Debido al uso de la memoria, usted debe utilizar el CBAC solamente cuando usted necesita. Hay también una pequeña cantidad de adicional procesando eso ocurre siempre que se examinen los paquetes.

El CBAC debe evaluar a veces las Listas de acceso largas, que pudieron haber presentado un impacto negativo al funcionamiento. Sin embargo, se evita este impacto, porque el CBAC evalúa las Listas de acceso usando un método acelerado (el CBAC desmenuza las Listas de acceso y evalúa el hash).

Selección de una Interfaz: Interno o Externo

Usted debe decidir si configurar el CBAC en un interno o una interfaz externa de su Firewall.

“Interno” refiere al lado donde las sesiones deben originar para que su tráfico sea permitido con el Firewall. El “externo” refiere al lado donde las sesiones no pueden originar (las sesiones que originan del lado del externo serán bloqueadas).

Si usted configura el CBAC en dos direcciones, usted debe configurar el CBAC en una dirección primero, usando “las designaciones internas” y “externas” apropiadas de la interfaz. Cuando usted configura el CBAC en la otra dirección, las designaciones de la interfaz serán intercambiadas. (el CBAC se puede configurar en dos direcciones en una o más interfaces. Configure el CBAC en dos direcciones cuando las redes a ambos lados del Firewall requieren la protección, por ejemplo con el extranet o las configuraciones del intranet, y para la protección contra los ataques DOS.)

El Firewall es el más de uso general con una de dos topologías de red básica. Determinar que de estas topologías es la mayoría como su los propio puede ayudarle a decidir a si configurar el CBAC en una interfaz interna o en una interfaz externa.

La primera topología se muestra en el cuadro 2. En esta topología simple, el CBAC se configura para el Serial1 de la interfaz externa. Esto evita que el tráfico del protocolo especificado ingrese el Firewall y la red interna, a menos que el tráfico sea parte de a la sesión inició dentro de la red interna.

Cuadro 2 topología simple — CBAC configurado en la interfaz externa

La segunda topología se muestra en el cuadro 3. En esta topología, el CBAC se configura para el ethernet0 de la interfaz interna. Esto permite el tráfico externo acceda los servicios en las zonas desmilitarizadas (DMZ), por ejemplo los servicios DNS, pero evita que el tráfico del protocolo especificado ingrese su red interna — a menos que el tráfico sea parte de que una sesión inició dentro de la red interna.

Cuadro 3 topología DMZ — CBAC configurado en la interfaz interna

Usando estas dos topologías de ejemplo, decida si configurar el CBAC en un interno o una interfaz externa.

Para ver los diversos escenarios de la configuración de escudo de protección, vea “la sección de los ejemplos de la configuración CBAC” en el final de este capítulo.

Configurar las listas de IP Access en la interfaz

Para que el CBAC trabaje correctamente, usted necesita aseegurarse que usted tenga listas de IP Access configuradas apropiadamente en la interfaz.

Siga estas tres reglas generales al evaluar sus listas de IP Access en el Firewall:

Comience con una configuración básica.

Si usted intenta configurar las Listas de acceso sin una buena comprensión de cómo las Listas de acceso trabajan, usted puede ser que introduzca inadvertidamente los riesgos de seguridad al Firewall y a la red protegida. Usted debe estar seguro que usted entiende lo que hacen las Listas de acceso antes de que usted configure su Firewall. Para más información sobre las listas de control de acceso, refiera a las “listas de control de acceso: Capítulo de la descripción y de las guías de consulta”.

Una configuración inicial básica permite que todo el tráfico de la red fluya de las redes protegidas a las redes no protegidas, mientras que bloquea el tráfico de la red de cualquier red no protegida.

Permita que el tráfico CBAC deje la red con el Firewall.

Todas las Listas de acceso que evalúan el tráfico que sale de la red protegida deben permitir el tráfico que será examinado por el CBAC. Por ejemplo, si Telnet es examinado por el CBAC, después el tráfico de Telnet se debe permitir en todas las Listas de acceso que se apliquen para traficar dejando la red.

Utilice las listas de acceso ampliadas para negar el tráfico de retorno CBAC que ingresa la red con el Firewall.

Para que las aperturas temporales sean creadas en una lista de acceso, la lista de acceso debe ser una lista de acceso ampliada. Tan dondequiera que usted tenga Listas de acceso que sean aplicadas al tráfico de vuelta, usted debe utilizar las listas de acceso ampliadas. Las Listas de acceso deben negar el tráfico de retorno CBAC porque el CBAC abrirá los agujeros temporales en las Listas de acceso. (Usted quisiera que el tráfico fuera bloqueado normalmente cuando ingresa su red.)


Observesi su Firewall tiene solamente dos conexiones, uno a la red interna y una a la red externa, usando todos los trabajos de las listas de acceso de entrada mana porque se paran los paquetes antes de que consigan una ocasión de afectar al router sí mismo.


Esta sección contiene las secciones siguientes:

Configuración Básica

Interfaz Externa

Interfaz Interna

Configuración Básica

La primera vez que usted configura el Firewall Cisco IOS, es útil comenzar con una configuración de la lista de acceso básica que haga la operación del Firewall fácil entender sin la Seguridad de compromiso. La configuración básica permite todo el tráfico de la red del acceso de redes protegidas a las redes no protegidas, mientras que bloquea todo el tráfico de la red (con algunas excepciones) de las redes no protegidas a las redes protegidas.

Cualquier configuración de escudo de protección depende de su política de seguridad del sitio. Si la configuración básica no cumple sus requerimientos de seguridad iniciales del sitio, configure el Firewall para resolver su directiva. Si usted es desconocido con esa directiva o necesita la ayuda con la configuración, entre en contacto a su grupo de la Administración de red para la ayuda. Para las directrices adicionales sobre configurar un Firewall, refiera “verificando a la sección CBAC” en este capítulo.

Utilice las guías de consulta siguientes para configurar las Listas de acceso iniciales del Firewall:

No configure una lista de acceso para el tráfico de las redes protegidas a las redes no protegidas, significando que todo el tráfico de las redes protegidas puede atravesar la interfaz.

Esto ayuda a simplificar la Administración de Firewall reduciendo el número de Listas de acceso aplicadas en las interfaces. Por supuesto esto asume un nivel elevado de confianza para los usuarios en las redes protegidas, y asume que no hay usuarios malintencionados en las redes protegidas que pudieron poner en marcha los ataques del “dentro.” Usted puede ajustar el acceso a la red para los usuarios en las redes protegidas mientras que usted gana la experiencia con la configuración de la lista de acceso y la operación del Firewall.

Configure una lista de acceso que incluya las entradas permitiendo cierto tráfico ICMP de las redes no protegidas.

Mientras que una lista de acceso que niega a toda la parte del tráfico IP no una conexión examinada por el CBAC parece la más segura, no es práctica para el funcionamiento normal del router. El router espera ver el tráfico ICMP del otro Routers en la red. Además, el tráfico ICMP no es examinado por el CBAC, significando que las entradas específicas están necesitadas en la lista de acceso para permitir el tráfico de retorno para los comandos icmp. Por ejemplo, un usuario en una red protegida utiliza ping el comando de conseguir el estatus de un host en una red no protegida; sin las entradas en la lista de acceso que permiten echo reply los mensajes, el usuario en la red protegida no consigue ninguna respuesta ping al comando.

Incluya las entradas de lista de acceso para permitir los mensajes ICMP siguientes:

Mensaje
Descripción

Respuesta de eco

Los comandos ping salientes requieren los mensajes de la respuesta de eco volverse.

time excedido

Los comandos traceroute salientes requieren los mensajes del time excedido volverse.

paquete-demasiado-grande

La detección de MTU de trayecto requiere los mensajes “demasiado-grandes” volverse.

traceroute

Permita un traceroute entrante.

inalcanzable

Permita que todos los mensajes “inalcanzables” se vuelvan. Si un router no puede remitir o entregar un datagrama, envía un mensaje inalcanzable de ICMP de nuevo a la fuente y cae el datagrama.


Agregue una entrada de lista de acceso que niega cualquier tráfico de la red de una dirección de origen que corresponde con un direccionamiento en la red protegida.

Esto se conoce como protección contra spoofing porque previene el tráfico de una red no protegida de si se asume que la identidad de un dispositivo en la red protegida.

Agregue una entrada que niega los mensajes de broadcast con una dirección de origen de 255.255.255.255.

Esta entrada ayuda a prevenir para transmitir los ataques.

Por abandono, la entrada más reciente de una lista de acceso ampliada es una negación implícita de todo el tráfico IP permitido no específicamente por otras entradas en la lista de acceso.

Aunque ésta sea la configuración predeterminada, este enunciado de negación final no se muestra por abandono en una lista de acceso. Opcionalmente, usted puede agregar una entrada a la lista de acceso que niega el tráfico IP con cualquier dirección de origen o de destino sin los efectos no deseados.

Para toda la información sobre cómo configurar las listas de IP Access, refiera “configurando al capítulo de los Servicios IP” del Cisco IOS IP Addressing Services Configuration Guide.

Para las extremidades en la aplicación de las Listas de acceso en un externo o una interfaz interna, revise las secciones “interfaz externa” y “interfaz interna” en este capítulo.

Interfaz Externa

Aquí están algunas guías de consulta para sus Listas de acceso cuando usted configurará el CBAC en una interfaz externa:

Si usted tiene una lista de IP Access saliente en la interfaz externa, la lista de acceso puede ser un estándar o una lista de acceso ampliada. Esta lista de acceso de salida debe permitir el tráfico que usted quiere ser examinado por el CBAC. Si el tráfico no se permite, no se inspeccionará por el CBAC, sino que simplemente se descartan.

La lista de IP Access entrante en la interfaz externa debe ser una lista de acceso ampliada. Esta lista de acceso de entrada debe negar el tráfico que usted quiere ser examinado por el CBAC. (el CBAC creará las aperturas temporales en esta lista de acceso de entrada como apropiada permitir solamente el tráfico de retorno que es parte de al válido, la sesión existente.)

Para toda la información sobre cómo configurar las listas de IP Access, refiera “configurando al capítulo de los Servicios IP” del Cisco IOS IP Addressing Services Configuration Guide.

Interfaz Interna

Aquí están algunas extremidades para sus Listas de acceso cuando usted configurará el CBAC en una interfaz interna:

Si usted tiene una lista de IP Access entrante en la interfaz interna o una lista de IP Access saliente en la interfaz externa, estas Listas de acceso pueden ser un estándar o lista de acceso ampliada. Estas Listas de acceso deben permitir el tráfico que usted quiere ser examinado por el CBAC. Si el tráfico no se permite, no se inspeccionará por el CBAC, sino que simplemente se descartan.

La lista de IP Access saliente en la interfaz interna y la lista de IP Access entrante en la interfaz externa deben ser listas de acceso ampliadas. Estas listas de acceso de salida deben negar el tráfico que usted quiere ser examinado por el CBAC. (el CBAC creará las aperturas temporales en estas listas de acceso de salida como apropiadas permitir solamente el tráfico de retorno que es parte de al válido, la sesión existente.) Usted no necesita necesariamente configurar una lista de acceso ampliada en la interfaz interna saliente y la interfaz externa entrante, pero por lo menos uno es necesario restringir el tráfico que atraviesa el Firewall en la red protegida interna.

Para toda la información sobre cómo configurar las listas de IP Access, refiera “configurando al capítulo de los Servicios IP” del Cisco IOS IP Addressing Services Configuration Guide.

Sesiones medio abiertas

Un número alto de sesiones medio abiertas (absoluto o medido como la velocidad de llegada) podría indicar inusualmente que está ocurriendo un establecimiento de rechazo del servicio. Para el TCP, “medio abierto” significa que la sesión no ha alcanzado al estado establecido — la entrada en contacto de tres vías TCP todavía no se ha completado. Para el UDP, “medio abierto” significa que el Firewall no ha detectado ningún tráfico de retorno.

El CBAC mide el número total de sesiones medio abiertas existentes y el índice de tentativas del establecimiento de sesión. Las sesiones medio abiertas TCP y UDP se cuentan en las medidas del número total y de la tarifa. Las medidas de la tarifa se hacen varias veces por el minuto.

Cuando el número de sesiones medio abiertas existentes sube sobre un umbral ( max-incomplete high el número), el software borrará las sesiones medio abiertas como sea necesario para acomodar las peticiones de nueva conexión. El software continuará borrando las peticiones medio abiertas cuanto sea necesario, hasta el número de descensos medio abiertos existentes de las sesiones debajo de otro umbral ( max-incomplete low el número).

Cuando el índice de nueva conexión intenta las subidas sobre un umbral ( one-minute high el número), el software borrará las sesiones medio abiertas como sea necesario para acomodar las tentativas de la nueva conexión. El software continuará borrando las sesiones medio abiertas cuanto sea necesario, hasta que el índice de nueva conexión intente los descensos debajo de otro umbral ( one-minute low el número). Se miden los umbrales de la tarifa como el número de nuevas tentativas de la conexión de la sesión detectadas en el período más pasado de la muestra de los minutos.

Examen de la fragmentación del paquete del IP

Las reglas de la inspección de CBAC pueden ayudar a proteger los hosts contra ciertos ataques DOS que implican los paquetes hechos fragmentos IP.

Usando el examen de la fragmentación, el Firewall mantiene un estado del interfragment (estructura) para el tráfico IP. Se desechan los fragmentos no iniciales a menos que el fragmento inicial correspondiente fuera permitido para pasar con el Firewall. Los fragmentos no iniciales recibidos antes de los fragmentos iniciales correspondientes se desechan.


El examende la fragmentación de la nota puede tener efectos indeseables en ciertos casos, porque puede dar lugar al Firewall que desecha cualquier paquete cuyos lleguen fragmentos fuera de servicio. Hay muchas circunstancias que pueden causar la salida fuera de servicio de los fragmentos legítimos. Aplicación del examen de la fragmentación en las situaciones donde los fragmentos legítimos, que son probables llegar fuera de servicio, pudieron tener un impacto del rendimiento severo.


Porque utilizan al Routers que funciona con el Cisco IOS Software en una gran variedad de redes, y porque la característica CBAC es de uso frecuente aislar las redes internas a partir de la una otras de las partes de, la característica del examen de la fragmentación se inhabilita por abandono. La detección de la fragmentación se debe habilitar explícitamente para una regla del examen usando ip inspect name el comando. El tráfico unfragmented nunca se desecha porque falta un estado del fragmento. Incluso cuando el sistema está bajo ataque pesado con los paquetes fragmentados, el tráfico fragmentado legítimo, eventualmente, consigue alguna fracción de los recursos estatales del fragmento del Firewall, y el tráfico legítimo, unfragmented puede atravesar el Firewall sin obstáculo.

Examen genérico TCP y UDP

Usted puede configurar el examen TCP y UDP para permitir que el TCP y los paquetes UDP ingresen la red interna con el Firewall, incluso si el Application Layer Protocol no se configura para ser examinado. Sin embargo, el examen TCP y UDP no reconoce los comandos específicos a la aplicación, y por lo tanto no pudo permitir todos los paquetes de devolución para una aplicación, determinado si los paquetes de devolución tienen un diverso número del puerto que el paquete de salida anterior.

Cualquier Application Layer Protocol se examine que tomará la precedencia sobre el examen TCP o del paquete UDP. Por ejemplo, si el examen se configura para el FTP, toda la información del canal de control será registrada en la tabla de estado, y todo el tráfico FTP será permitido detrás con el Firewall si la información del canal de control es válida para el estado de la sesión FTP. El hecho de que el examen TCP esté configurado es inútil a la información del estado FTP.

Con el examen TCP y UDP, los paquetes que ingresan la red deben corresponder con exactamente el paquete correspondiente que salió previamente la red. Los paquetes que ingresan deben tener las mismas direcciones de origen/destino y fuente/números de puerto de destino que el paquete de salida (pero invertido); si no, los paquetes que ingresan serán bloqueados en la interfaz. También, todos los paquetes TCP con un número de secuencia fuera de la ventana se caen.

Con el examen UDP configurado, las contestaciones serán permitidas solamente detrás adentro con el Firewall si se reciben dentro de un tiempo configurable después de que la petición más reciente fuera enviada. (Este vez se configura con ip inspect udp idle-time el comando.)

Guías de consulta para configurar un Firewall

Como ocurre con todos los dispositivos de networking, siempre se debe proteger el acceso al firewall configurando las contraseñas según lo descrito en el módulo "Configuración de la Seguridad con Contraseñas, Niveles de privilegio y Nombres de Usuario de Login para las Sesiones CLI en los Dispositivos de Networking". Debe considerar también la configuración de la autenticación, autorización y contabilización de usuarios según lo descrito en la parte "Autenticación, Autorización y Contabilización (AAA)" de esta guía.

También debe considerar las recomendaciones siguientes:

Al fijar las contraseñas para el acceso privilegiado al Firewall, utilice enable secret el comando bastante que enable password el comando, que no tiene como fuerte un algoritmo de encripción.

Ponga una contraseña en el puerto de la consola. En los entornos de autenticación, autorización y contabilización (AAA), utilice la misma autenticación para la consola que para el resto. En un entorno NON-AAA, en una configuración mínima login y password los comandos password.

Piensa en el control de acceso antes de conectar un puerto de consola a la red de cualquier manera, incluida la conexión de un módem al puerto. Tenga en cuenta que una rotura en el puerto de la consola podría dar el control total del firewall, incluso con el control de acceso configurado.

Aplique listas de acceso y protección por contraseña a todos los puertos de terminal virtual. Utilice listas de acceso para limitar quién puede acceder con Telnet al router.

No habilite ningún servicio local (como SNMP o NTP) que no utilice. Protocolo de detección de Cisco (CDP) y Network Time Protocol (NTP) están activados de forma predeterminada, y debería desactivarlos si no son necesarios.

Para apagar el CDP, ingrese no cdp run el comando global configuration. Para apagar el NTP, ingrese ntp disable el comando interface configuration en cada interfaz no usando el NTP.

Si debe ejecutar NTP, configure NTP solamente en las interfaces necesarias y configúrelo para que solamente escuche a determinados peers.

Cualquier servicio habilitado puede presentar un posible riesgo de seguridad. Un usuario decidido y malintencionado puede encontrar maneras creativas de hacer un mal uso de los servicios habilitados para acceder al firewall o a la red.

Para los servicios locales habilitados, protege contra el mal uso. Protege al configurar los servicios para comunicar solamente con peers específicos, y protege al configurar las listas de acceso para denegar los paquetes para los servicios en interfaces específicas.

Protéjase ante la suplantación: protege las redes a ambos lados del firewall de una simulación desde el otro lado. Puede establecer una protección contra los ataques de simulación configurando listas de acceso de entrada en todas las interfaces de modo que solamente pase el tráfico procedente de direcciones de origen esperadas, y deniegue todo el resto del tráfico.

También debe inhabilitar el ruteo de origen. Para el IP, ingrese no ip source-route el comando global configuration. La inhabilitación del ruteo de origen en todos los routers puede ayudar también a evitar la simulación.

También debe inhabilitar los servicios menores. Para el IP, ingrese no service tcp-small-servers y no service udp-small-servers los comandos global configuration. En el Cisco IOS Release 12.0 y Posterior, inhabilitan a estos servicios por abandono.

Evita que el firewall se utilice como relay configurando listas de acceso en cualquier puerto asíncrono Telnet.

Normalmente, debe inhabilitar los broadcasts dirigidos para todos los protocolos aplicables en el firewall y en todos los demás routers. Para el IP, utilice no ip directed-broadcast el comando. Raramente, algunas redes IP requieren broadcasts dirigidos; si se da este caso, no inhabilite los broadcasts dirigidos.

Los broadcasts dirigidos se pueden emplear indebidamente para multiplicar el poder de los ataques de negación de servicio porque cada paquete de negación de servicio enviado se transmite a todos los hosts de una subred. Además, algunos hosts tienen otros riesgos de seguridad intrínsecos al gestionar los broadcasts.

Configure no proxy-arp el comando de evitar que revelen a las direcciones internas. (Es importante llevarlo a cabo si no cuenta ya con NAT configurado para impedir que se revelen las direcciones internas.)

Mantenga el firewall en un cuarto seguro (cerrado).

Examen RTSP

En el caso del examen RTSP, la salida de la sesión puede variar basado en el protocolo de las multimedias y el modo de transporte. Esta sección utiliza los ejemplos de las sesiones RTSP y del H.323V2 para ilustrar los procedimientos de verificación y para ilustrar cómo la información de la sesión, y la interpretación de esa información de la sesión, varía basado en el protocolo que es examinado. Esta sección proporciona a la sesión de ejemplo siguiente hecha salir:

RTSP con el RDT

RTSP con TCP solamente (modo entrelazado)

RTSP con SMIL

RTSP con RTP (IP/TV)

H.323 V2

RTSP con el RDT

El siguiente ejemplo ilustra el resultado show ip inspect session del comando. Muestra que un canal de control (rtsp) y el canal de datos (RTSP-DATA) está abierto entre los hosts 192.168.155.2 y 192.168.35.1.

router# show ip inspect session 
Established Sessions
 Session 616B4F1C (192.168.155.2:7548)=>(192.168.35.1:6970) rtsp-data SIS_OPEN
 Session 611E2904 (192.168.35.1:1221)=>(192.168.155.2:554) rtsp SIS_OPEN

El siguiente ejemplo ilustra el resultado show ip access-list del comando. Muestra que dos entradas dinámicas (declaraciones del permiso) fueron agregadas al ACL 100 para la sesión de las multimedias. La entrada TCP crea una apertura dinámica con el Firewall entre el puerto 554 (puerto del protocolo RTSP) en el cliente y el puerto 1221 en el servidor. La entrada UDP crea una apertura dinámica entre el puerto 7548 de los datos en el cliente y el puerto 6970 de los datos en el servidor.

router# show ip access-list
Extended IP access list 100
 permit udp host 192.168.155.2 eq 7548 host 192.168.35.1 eq 6970 (31 matches)
 permit tcp host 192.168.155.2 eq 554 host 192.168.35.1 eq 1221 (27 matches)

Después de cerrar la sesión de las multimedias, revise la salida de la sesión usando show los comandos de verificar el software de escudo de protección ha quitado las entradas dinámicas de la configuración.

RTSP con TCP solamente (modo entrelazado)

El siguiente ejemplo ilustra el resultado show ip inspect session del comando. Muestra que solamente un solo canal de control (rtsp) está abierto entre los hosts 192.168.155.2 y 192.168.35.1. En este modo, los datos son tunneled con el Firewall usando la conexión TCP interpolar el RDT o los datos RTP.

router# show ip inspect session 
Established Sessions
 Session 611E2904 (192.168.35.1:1228)=>(192.168.155.2:554) rtsp SIS_OPEN

El siguiente ejemplo ilustra el resultado show ip access-list del comando. Muestra que una sola entrada dinámica (declaración del permiso) fue agregada al ACL 100 para la sesión de las multimedias. La entrada TCP crea una apertura dinámica con el Firewall entre el puerto 554 (puerto del protocolo RTSP) en el cliente y el puerto 1228 en el servidor.

router# show ip access-lists                                            
Extended IP access list 100
 permit tcp host 192.168.155.2 eq 554 host 192.168.35.1 eq 1228 (391 matches)

Después de cerrar la sesión de las multimedias, revise la salida de la sesión usando show los comandos de verificar el software de escudo de protección ha quitado las entradas dinámicas de la configuración.

RTSP con SMIL

El siguiente ejemplo ilustra el resultado show ip inspect session del comando para el RTSP usando el lenguaje sincronizado de la integración multimedia (SMIL). Muestra que un solo canal de control (rtsp) y los canales de datos múltiples (RTSP-DATA) están abiertos entre los hosts 192.168.155.2 y 192.168.35.1. Los canales de datos aparecen como medias sesiones abiertas porque los flujos de datos UDP en una dirección solamente, que es del servidor al cliente.

router# show ip inspect session 
Established Sessions
 Session 616CA914 (192.168.155.2:30616)=>(192.168.35.1:6974) rtsp-data SIS_OPEN
 Session 616B4E78 (192.168.35.1:1230)=>(192.168.155.2:554) rtsp SIS_OPEN
 Session 614AB61C (192.168.155.2:29704)=>(192.168.35.1:6976) rtsp-data SIS_OPEN
 Session 616CAA88 (192.168.155.2:26764)=>(192.168.35.1:6972) rtsp-data SIS_OPEN
Half-open Sessions
 Session 614AAEF0 (192.168.155.2:15520)=>(192.168.35.1:6970) rtsp-data SIS_OPENING

El siguiente ejemplo ilustra el resultado show ip access-lists del comando. Muestra que se añadieron entradas dinámicas múltiples (sentencias de permiso) a ACL 100 para la sesión multimedia. La entrada TCP crea una apertura dinámica a través del firewall entre el puerto 554 (puerto de protocolo RTSP) en el cliente y el puerto 1230 en el servidor. Las entradas UDP crean las aperturas dinámicas entre los puertos negociados de los datos en el cliente (192.168.155.2) y el servidor (192.168.35.1).

router# show ip access-list 
Extended IP access list 100
 permit udp host 192.168.155.2 eq 29704 host 192.168.35.1 eq 6976 (182 matches)
 permit udp host 192.168.155.2 eq 30616 host 192.168.35.1 eq 6974 (268 matches)
 permit udp host 192.168.155.2 eq 26764 host 192.168.35.1 eq 6972 (4 matches)
 permit udp host 192.168.155.2 eq 15520 host 192.168.35.1 eq 6970 (12 matches)
 permit tcp host 192.168.155.2 eq 554 host 192.168.35.1 eq 1230 (41 matches)

Después de cerrar la sesión de las multimedias, revise la salida de la sesión usando show los comandos de verificar el software de escudo de protección ha quitado las entradas dinámicas de la configuración.

RTSP con RTP (IP/TV)

El siguiente ejemplo ilustra el resultado show ip inspect session del comando para el RTSP con la aplicación del Cisco IP/TV. La salida muestra que un solo canal de control (rtsp) y los canales de datos múltiples (RTSP-DATA) están abiertos entre los hosts 192.168.2.15 y 192.168.102.23. Los canales de datos aparecen como sesiones medio abiertas porque los flujos de datos UDP en una dirección solamente, que es del servidor al cliente.

router# show ip inspect session 
Established Sessions
 Session 611493C0 (192.168.2.15:2571)=>(192.168.102.23:8554) rtsp SIS_OPEN
Half-open Sessions
 Session 6114A22C (192.168.102.23:2428)=>(192.168.2.15:20112) rtsp-data SIS_OPENING
 Session 61149F44 (192.168.102.23:2428)=>(192.168.2.15:20113) rtsp-data SIS_OPENING
 Session 6114A0B8 (192.168.102.23:2429)=>(192.168.2.15:20115) rtsp-data SIS_OPENING
 Session 6114A3A0 (192.168.102.23:2429)=>(192.168.2.15:20114) rtsp-data SIS_OPENING

El siguiente ejemplo ilustra el resultado show ip access-lists del comando. Muestra que se añadieron entradas dinámicas múltiples (sentencias de permiso) a ACL 100 para la sesión multimedia. La entrada TCP crea una apertura dinámica a través del firewall entre el puerto 554 (puerto de protocolo RTSP) en el cliente y el puerto 1230 en el servidor. Las entradas UDP crean las aperturas dinámicas entre los puertos negociados de los datos en el cliente (192.168.2.15) y el servidor (192.168.102.23).

router# show ip access-lists     
Extended IP access list 100
 permit udp host 192.168.102.23 eq 2428 host 192.168.2.15 eq 20113 (11 matches)
 permit udp host 192.168.102.23 eq 2428 host 192.168.2.15 eq 20112 (256 matches)
 permit udp host 192.168.102.23 eq 2429 host 192.168.2.15 eq 20115 (11 matches)
 permit udp host 192.168.102.23 eq 2429 host 192.168.2.15 eq 20114 (4598 matches)
 permit tcp host 192.168.102.23 eq 8554 host 192.168.2.15 eq 2571 (22 matches)

Después de cerrar la sesión de las multimedias, revise la salida de la sesión usando show los comandos de verificar que el software de escudo de protección ha quitado las entradas dinámicas de la configuración.

H.323 V2

El siguiente ejemplo ilustra el resultado show ip inspect session del comando para el H.323V2. Muestra un solo canal de control de H.323, un canal RTP Control Protocol para el audio y los datos de video, y un canal de datos RTP entre los hosts 192.168.155.2 y 192.168.35.1.

Session 615E2688 (192.168.35.1:49609)=>(192.168.155.1:49609) H323-RTCP-audio SIS_OPEN 
Session 615E2688 (192.168.35.1:49508)=>(192.168.155.1:49508) H323-RTP-audio SIS_OPEN 
Session 615E2688 (192.168.35.1:49410)=>(192.168.155.1:49410) H323-RTP-video SIS_OPEN 
Session 615E2688 (192.168.35.1:49611)=>(192.168.155.1:49611) H323-RTCP-video SIS_OPEN 
Session 615E1640 (192.168.35.1:4414)=>(192.168.155.1:1720) H323 SIS_OPEN

El siguiente ejemplo ilustra el resultado show ip access-lists del comando. Muestra que se añadieron entradas dinámicas múltiples (sentencias de permiso) a ACL 100 para la sesión multimedia. La entrada TCP crea una apertura dinámica con el Firewall entre el puerto 1720 (puerto del protocolo del H.323V2) en el cliente y el puerto 4414 en el servidor. Las entradas UDP crean las aperturas dinámicas entre los puertos negociados de los datos en el cliente (192.168.155.1) y el servidor (192.168.35.1).

Router# show ip access-lists 

Extended IP access list 100
 permit udp host 192.168.155.1 eq 49609 host 192.168.35.1 eq 49609 (11 matches)
 permit udp host 192.168.155.1 eq 49508 host 192.168.35.1 eq 49508 (256 matches)
 permit udp host 192.168.155.1 eq 49411 host 192.168.35.1 eq 49411 (11 matches)
 permit udp host 192.168.155.1 eq 49610 host 192.168.35.1 eq 49610 (4598 matches)
 permit tcp host 192.168.155.1 eq 1720 host 192.168.35.1 eq 4414 (22 matches)

Como Interpretar el Syslog y los Mensajes de la Consola Generados por CBAC

El CBAC proporciona los mensajes de Syslog, los mensajes de alerta de consola, y los mensajes del rastro de auditoría. Estos mensajes son útiles porque pueden alertarle a los ataques a la red y porque proporcionan un rastro de auditoría que proporcione los detalles sobre las sesiones examinados por el CBAC. Mientras que se refieren generalmente como mensajes de error, no todos los mensajes de error indican los problemas con su sistema.

El rastro de auditoría y la información de la alerta es configurables sobre una base de la por-aplicación usando las reglas de la inspección de CBAC.

Los siguientes tipos de mensajes se pueden generar por el CBAC:

Mensajes de error de la Detección de Ataques de Negación de Servicio

Mensajes de Error de Detección de Ataques SMTP

Mensajes de Error de Bloqueo Java

Mensajes de error de FTP

Mensajes del Rastro de Auditoría

Para las explicaciones y las acciones recomendadas relacionadas con los mensajes de error mencionados en esta sección, refiera a los mensajes de error del sistema del Cisco IOS.

Mensajes de error de la Detección de Ataques de Negación de Servicio

El CBAC detecta y bloquea los establecimientos de rechazo del servicio y le notifica cuando ocurren los establecimientos de rechazo del servicio. Los mensajes de error tales como el siguiente pueden indicar que han ocurrido los establecimientos de rechazo del servicio:

%FW-4-ALERT_ON: getting aggressive, count (550/500) current 1-min rate: 250
%FW-4-ALERT_OFF: calming down, count (0/400) current 1-min rate: 0

Cuando los mensajes de error %FW-4-ALERT_ON y %FW-4-ALERT_OFF aparecen juntos, el par “agresivo/que calma” cada uno de mensajes indica un ataque separado. Las demostraciones del ejemplo anterior un ataque separado.

Los mensajes de error tales como el siguiente pueden indicar que un establecimiento de rechazo del servicio ha ocurrido en un host TCP específico:

%FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 
172.21.127.242.
%FW-4-BLOCK_HOST: Blocking new TCP connections to host 172.21.127.242 for 2 minutes 
(half-open count 50 exceeded)
%FW-4-UNBLOCK_HOST: New TCP connections to host 172.21.127.242 no longer blocked

Mensajes de Error de Detección de Ataques SMTP

El CBAC detecta y bloquea los ataques S TP (comandos ilegales S TP) y le notifica cuando ocurren los ataques S TP. Los mensajes de error tales como el siguiente pueden indicar que ha ocurrido un ataque S TP:

%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator (192.168.12.3:52419)

El CBAC también detecta un número limitado de firmas del ataque S TP. Una firma en un mensaje de Syslog indica un ataque posible contra la red protegida, tal como la detección de comandos ilegales S TP en un paquete. Siempre que se detecte una firma, la conexión será reajustada.

El Firewall Cisco IOS soporta las firmas siguientes del ataque S TP:

Firma
Descripción

Correo: mún rcpt

Disparadores en cualquier mensaje de correo con una "canalización" ( | ) símbolo en el campo receptor.

Correo: malo de

Disparadores en cualquier mensaje de correo con una "canalización" ( | ) símbolo en “de: ” campo.

Correo: viejo ataque

Activadores cuando envían el “wiz” o los “comandos debug " al puerto S TP.

Correo: decodifique

Activadores en cualquier mensaje del correo con “: decode@” en la encabezado.

Majordomo

Un bug en el programa del Majordomo permitirá que los usuarios remotos ejecuten los comandos arbitrarios en el nivel de privilegio del servidor.


Lo que sigue es un mensaje de firma del ataque de la muestra S TP:

02:04:55: %FW-4-TCP_MAJORDOMO_EXEC_BUG: Sig:3107:Majordomo Execute Attack - from 
192.168.25.1 to 192.168.205.1:

Mensajes de Error de Bloqueo Java

El CBAC detecta y bloquea selectivamente los subprogramas java y le notifica cuando se han bloqueado los subprogramas java. Los mensajes de error tales como el siguiente pueden indicar que se han bloqueado los subprogramas java:

%FW-4-HTTP_JAVA_BLOCK: JAVA applet is blocked from (172.21.127.218:80) to
(172.16.57.30:44673).

Mensajes de error de FTP

El CBAC detecta y previene ciertos ataques FTP y le notifica cuando ocurre éste. Los mensajes de error tales como el siguiente pueden aparecer cuando el CBAC detecta estos ataques FTP:

%FW-3-FTP_PRIV_PORT: Privileged port 1000 used in PORT command -- FTP client 10.0.0.1  FTP 
server 10.1.0.1
%FW-3-FTP_SESSION_NOT_AUTHENTICATED: Command issued before the session is authenticated  
-- FTP client 10.0.0.1
%FW-3-FTP_NON_MATCHING_IP_ADDR: Non-matching address 172.19.148.154 used in PORT command 
-- FTP client 172.19.54.143  FTP server 172.16.127.242

Mensajes del Rastro de Auditoría

El CBAC proporciona los mensajes del rastro de auditoría para registrar los detalles sobre las sesiones examinadas. La información del rastro de auditoría es configurable sobre una base de la por-aplicación usando las reglas de la inspección de CBAC. Para determinar qué protocolo fue examinado, utilice el número del puerto del respondedor. El número del puerto sigue el direccionamiento del respondedor. Los siguientes son mensajes del rastro de auditoría de la muestra:

%FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.13:33192) sent 22 bytes -- 
responder (192.168.129.11:25) sent 208 bytes
%FW-6-SESS_AUDIT_TRAIL: http session initiator (172.16.57.30:44673) sent 1599 bytes -- 
responder (172.21.127.218:80) sent 93124 bytes

Desactivación de CBAC

Usted puede apagar el CBAC usando no ip inspect el comando global configuration.

no ip inspect El comando quita todas las entradas de la configuración CBAC y reajusta todo el tiempo de espera global agotado y los umbrales CBAC a los valores por defecto. Borran a todas las sesiones existentes y se quitan sus Listas de acceso asociadas.

En la mayoría de las situaciones, apagar el CBAC no tiene ningún impacto de Seguridad negativo porque el CBAC crea las Listas de acceso del “permiso”. Sin el CBAC configurado, se mantiene no las Listas de acceso del “permiso”. Por lo tanto, ningún tráfico derivado (tráfico de vuelta o tráfico de los canales de datos) puede pasar con el Firewall. La excepción es bloqueo S TP y de las Javas. Con el CBAC apagado, los comandos inaceptables o los subprogramas java S TP pueden pasar con el Firewall.

Cómo configurar el Context-Based Access Control

Configurando el tiempo de espera global agotado y los umbrales (requeridos)

Definiendo una regla del examen (requerida)

Aplicando la regla del examen a una interfaz (requerida)

Configurando el registro y el rastro de auditoría (requeridos)

Verificando el CBAC (requerido)

Haciendo el debug del Context-Based Access Control (requerido)

Configurar el tiempo de espera global agotado y los umbrales

El CBAC utiliza los descansos y los umbrales para determinar cuánto tiempo manejar la información del estado para una sesión, y determinar cuando caer las sesiones que no se establecen completamente. Estos descansos y umbrales se aplican global a todas las sesiones.

Usted puede utilizar el tiempo de espera predeterminado y los valores de umbral, o usted puede cambiar a los valores más convenientes a sus requerimientos de seguridad. Usted debe realizar cualquier cambio al descanso y a los valores de umbral antes de que usted continúe configurando el CBAC.

Para reajustar cualquier umbral o descanso al valor predeterminado, utilice no la forma del comando en el cuadro 1.


Observesi usted quiere habilitar la prevención host-específica más agresiva del servicio negado TCP que incluye el bloqueo del lanzamiento de conexión a un host, usted debe fijar block-time especificado en ip inspect tcp max-incomplete host el comando (véase la fila más reciente del cuadro 1).


Todos los descansos disponibles y los umbrales CBAC se enumeran en el cuadro 1, junto con el comando y el valor predeterminado correspondientes. Para cambiar un tiempo de espera global agotado o un umbral enumerado en el “descanso del valor de umbral para cambiar” la columna, utiliza el comando global configuration en la columna del “comando”:

Descanso y valores de umbral del cuadro 1 

Descanso o valor de umbral a cambiar
Comando
Predeterminado

La longitud del tiempo el software espera a una sesión TCP para alcanzar al estado establecido antes de caer la sesión.

ip inspect tcp synwait-time seconds

30 segundos

Inhabilite la comprobación para de la opción de la escala de la ventana un paquete TCP que tenga una opción inválida de la escala de la ventana bajo el Firewall del Control de acceso basado en el contexto (CBAC).

ip inspect tcp window-scale-enforcement loose

El control estricto de la opción de la escala de la ventana se habilita en el Firewall por abandono.

La longitud del tiempo que todavía manejarán a una sesión TCP después de que el Firewall detecte un FIN-intercambio.

ip inspect tcp finwait-time seconds

5 segundos

La longitud del tiempo que todavía manejarán a una sesión TCP después de ninguna actividad (el tiempo de inactividad TCP). 1

ip inspect tcp idle-time seconds

3600 segundos (1 hora)

La longitud del tiempo que todavía manejarán a una Sesión UDP después de ninguna actividad (el tiempo de inactividad UDP). 1

ip inspect udp idle-time seconds

30 segundos

La longitud del tiempo que una sesión de las operaciones de búsqueda del nombre DNS todavía será manejada después de ninguna actividad.

ip inspect dns-timeout seconds

5 segundos

El número de sesiones medio abiertas existentes que harán el software comenzar a borrar sessions.2 medio abierto

ip inspect max-incomplete high number

500 sesiones medio abiertas existentes

El número de sesiones medio abiertas existentes que harán el software parar el borrar de sessions.2 medio abierto

ip inspect max-incomplete low number

400 sesiones medio abiertas existentes

El índice de nuevas sesiones que harán el software comenzar a borrar sessions.2 medio abierto

ip inspect one-minute high number

500 sesiones medio abiertas por el minuto

El índice de nuevas sesiones que harán el software parar el borrar de sessions.2 medio abierto

ip inspect one-minute low number

400 sesiones medio abiertas por el minuto

El número de sesiones TCP medio abiertas existentes con la misma dirección de host del destino que hará el software comenzar a caer las sesiones medio abiertas a la misma dirección de host. 3 del destino

ip inspect tcp max-incomplete host number block-time minutes

50 sesiones TCP medio abiertas existentes; minutos 0

1 el tiempo de inactividad global TCP y UDP se puede reemplazar para las sesiones de los Application Layer Protocol especificados como descrito en ip inspect name el comando description (de la configuración global), encontró en el “Context-Based Access Control ordena” el capítulo de la referencia de comandos de la Seguridad de Cisco IOS.

2 vea la sección siguiente, las “sesiones medio abiertas,” para más información.

3 siempre que max-incomplete host se exceda el umbral, el software caerá las sesiones medio abiertas diferentemente dependiendo de si block-time el descanso es cero o un número no-cero positivo. Si block-time el descanso es cero, el software borrará la más vieja sesión medio abierta existente para el host para cada petición de nueva conexión al host y dejará el paquete SYN a través. Si block-time el descanso es mayor de cero, el software borrará todas las sesiones medio abiertas existentes para el host, y después bloquea todas las peticiones de nueva conexión al host. El software continuará bloqueando todas las peticiones de nueva conexión hasta que block-time expire.


Definición de una regla del examen

Después de que usted configure el tiempo de espera global agotado y los umbrales, usted debe definir una regla del examen. Esta regla especifica qué tráfico IP (que los Application Layer Protocol) será examinado por el CBAC en una interfaz.

Normalmente, usted define solamente una regla del examen. La única excepción podría ocurrir si quiere habilitar CBAC en dos direcciones según se describió anteriormente en la sección "Cuándo y Dónde Configurar CBAC". Para el CBAC configurado en las ambas direcciones en una sola interfaz de escudo de protección, usted debe configurar dos reglas, una para cada dirección.

Una regla del examen debe especificar cada Application Layer Protocol deseado así como UDP genérico TCP o genérico si está deseada. La regla del examen consiste en una serie de enunciados cada anuncio un protocolo y especificar el mismo nombre de la regla del examen.

Las reglas del examen incluyen las opciones para los mensajes de la alerta que controlan y del rastro de auditoría y para marcar la fragmentación del paquete del IP.

Para definir una regla del examen, siga las instrucciones en las secciones siguientes:

Configuración de la Inspección de Protocolo de la Capa de Aplicación

Configuración de la Inspección TCP y UDP Genérica

Configuración de la Inspección de Protocolo de la Capa de Aplicación

Esta sección proporciona las instrucciones para configurar el CBAC con la información siguiente del examen:

Configurar los Application Layer Protocol

Configurar el bloqueo de las Javas

Configurar el examen de la fragmentación del paquete del IP


Observepara que la inspección de CBAC trabaje con el tráfico del NetMeeting 2,0 (un Application Layer Protocol de H.323), usted debe también configurar el examen para el TCP, según lo descrito más adelante en el “configurar la sección del examen genérico TCP y UDP”. Este requisito existe porque el NetMeeting 2,0 utiliza un canal adicional TCP no definido en la especificación de H.323.


Configurar los Application Layer Protocol

Para configurar la inspección de CBAC para un Application Layer Protocol, utilice uno o ambos siguientes comandos en el modo de configuración global:

Comando
Propósito

Router(config)# ip inspect name inspection-name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Inspección de CBAC de las configuraciones para un Application Layer Protocol (a excepción del RPC y de las Javas). Utilice una de las palabras claves de protocolo definidas en el cuadro 2.

Relance este comando para cada protocolo deseado. Utilice el mismo valor inspection-name para crear una única regla de inspección.

Router(config)# ip inspect name inspection-name rpc program-number number [wait-time minutes] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Inspección de CBAC de los permisos para el Application Layer Protocol RPC.

Usted puede especificar los números múltiples del programa RPC relanzando este comando para cada número del programa.

Utilice el mismo valor inspection-name para crear una única regla de inspección.


Configurar el bloqueo de las Javas

La filtración de los subprogramas java distingue entre los applet confiados en y untrusted confiando en una lista de sitios externos que usted señale como “cómodo.” Si un applet es de un sitio cómodo, el Firewall permite el applet a través. Si el applet no es de un sitio cómodo, el applet será bloqueado. (Alternativamente, usted podría permitir los applet de todos los sitios externos a excepción de ésos que usted señala específicamente como hostil.)


Observelas fuerzas de bloqueo de las Javas una orden estricta en los paquetes TCP. Para verificar correctamente que los subprogramas java no estén en la respuesta, un Firewall caerá cualquier paquete TCP que esté fuera de servicio. Porque la red — no el Firewall — determina cómo se rutean los paquetes, el Firewall no puede controlar la pedido de los paquetes; el Firewall puede caer y retransmitir solamente todos los paquetes TCP que no estén en la orden.



La precauciónCBAC no detecta ni bloquea los subprogramas java encapsulados. Por lo tanto, los subprogramas java se envuelven que o encapsulado, por ejemplo los applet en el .zip o el formato del .jar, no se bloquean en el Firewall. El CBAC también no detecta ni bloquea los applet cargados del FTP, Gopher, HTTP en un puerto no estándar, y así sucesivamente.

Para bloquear todos los subprogramas java a excepción de los applet de las ubicaciones cómodas, utilice los siguientes comandos en el modo de configuración global:

 
Comando
Propósito

Paso 1 

Router(config)# ip access-list standard name
  permit ...
  deny ... (Use permit and deny statements as appropriate.)


o

Router(config)# access-list access-list-number {deny | permit} protocol source [source-wildcard]eq www destination [destination-wildcard]

Crea una lista de acceso estándar que permita el tráfico solamente de los sitios cómodos, y niega el tráfico de los sitios hostiles.

Utilice any la palabra clave para el destino como apropiado — pero tenga cuidado de no emplear mal any la palabra clave para permitir inadvertidamente todos los applet a través.

Paso 2 

Router(config)# ip inspect name inspection-name http [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Bloquea todos los subprogramas java a excepción de los applet de los sitios cómodos definidos previamente en la lista de acceso. Javas que bloquean solamente los trabajos con las listas de acceso estándar numeradas.

Para crear una sola regla de inspección, utilice el mismo valor de inspection-name que cuando especificó otros protocolos.

Configuración de la Inspección TCP y UDP Genérica

Para configurar la inspección de CBAC para el TCP o los paquetes UDP, utilice uno o ambos siguientes comandos en el modo de configuración global:

Comando
Propósito

Router(config)# ip inspect name inspection-name tcp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Inspección de CBAC de los permisos para los paquetes TCP.

Para crear una sola regla de inspección, utilice el mismo valor de inspection-name que cuando especificó otros protocolos.

Router(config)# ip inspect name inspection-name udp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Inspección de CBAC de los permisos para los paquetes UDP.

Para crear una sola regla de inspección, utilice el mismo valor de inspection-name que cuando especificó otros protocolos.


Aplicación de la regla del examen a una interfaz

Después de que usted defina una regla del examen, usted aplica esta regla a una interfaz.

Normalmente, usted aplica solamente una regla del examen a una interfaz. La única excepción podría ocurrir si quiere habilitar CBAC en dos direcciones según se describió anteriormente en la sección "Cuándo y Dónde Configurar CBAC". Para el CBAC configurado en las ambas direcciones en una sola interfaz de escudo de protección, usted debe aplicar dos reglas, una para cada dirección.

Si usted está configurando el CBAC en una interfaz externa, aplique la regla al tráfico saliente.

Si usted está configurando el CBAC en una interfaz interna, aplique la regla al tráfico entrante.

Para aplicar una regla del examen a una interfaz, utilice el siguiente comando en el modo de configuración de la interfaz:

Comando
Propósito

Router(config-if)# ip inspect inspection-name

{in | out}

Aplica una regla del examen a una interfaz.


Configurar el registro y el rastro de auditoría

Dé vuelta encendido a registración y al rastro de auditoría para proporcionar un expediente del acceso a la red con el Firewall, incluyendo los intentos de acceso ilegítimos, y entrante y los servicios salientes. Para configurar las funciones de la registración y del rastro de auditoría, ingrese los siguientes comandos en el modo de configuración global:

 
Comando
Propósito

Paso 1 

Router(config)# service timestamps log datetime

Agrega la fecha y hora a los mensajes del Syslog y del rastro de auditoría.

Paso 2 

Router(config)# logging host

Especifica el nombre del host o la dirección IP del host donde usted quiere enviar los mensajes de Syslog.

Paso 3 

Router(config)# logging facility facility-type

Configura el recurso del Syslog en el cual se envían los mensajes de error.

Paso 4 

Router(config)# logging trap level

(Opcional) utiliza este comando de limitar los mensajes registrados a los servidores de Syslog basados en la gravedad. El valor por defecto es el nivel 7 (informativo).

Paso 5 

Router(config)# ip inspect audit-trail

Activa los mensajes del registro de auditoría CBAC.

Verificar el CBAC

En la mayoría de los casos, usted puede decir si el CBAC está examinando el tráfico de la red correctamente porque las aplicaciones de red están trabajando como se esperaba. En algunos casos, sin embargo, usted puede ser que quiera verificar la operación CBAC. Por ejemplo, para verificar el examen RTSP o de H.323, inicie una aplicación RTSP- o basado en H.323 con el Firewall. Utilice show ip inspect session y show ip access lists los comandos verificar la operación CBAC. Estos comandos display las entradas ACL dinámicas y las conexiones establecidas para una sesión de las multimedias.

Usted puede ver y verificar la configuración CBAC, el estatus, las estadísticas, y la información de la sesión usando uno o más de los siguientes comandos en el modo EXEC:

Comando
Propósito

Router# show ip access-lists

Muestra el contenido de todas las listas de acceso IP actuales.

Router# show ip inspect name inspection-name

Muestra una regla configurada detalle del examen.

Router# show ip inspect config

Muestra la configuración completa de la inspección de CBAC.

Router# show ip inspect interfaces

Configuración de la interfaz de las demostraciones en lo que respecta a las reglas y a las Listas de acceso aplicadas del examen.

Router# show ip inspect session [detail]

Muestra a las sesiones existentes que están siendo seguidas y examinadas actualmente por el CBAC.

Router# show ip inspect all

Muestra toda la configuración CBAC y a todas las sesiones existentes que estén siendo seguidas y examinadas actualmente por el CBAC.


Monitoreo y Mantenimiento de CBAC

Usted puede mirar para los ataques a la red e investigar los problemas de red usando los comandos debug y los mensajes del sistema. Esta sección contiene las siguientes secciones:

Debugging del Control de Acceso Basado en Contexto

Ejemplos de la configuración CBAC

Desactivación de CBAC

Debugging del Control de Acceso Basado en Contexto

Para ayudar al debugging CBAC, usted puede girar los mensajes del rastro de auditoría que serán visualizados en la consola después de que cada sesión CBAC se cierre. La información del rastro de auditoría es también configurable sobre una base de la por-aplicación usando las reglas de la inspección de CBAC.


Observeeficaz con el Cisco IOS Release 12.4(20)T, debug ip inspect el comando es substituido por el comando del directiva-Firewall del debug. Vea la referencia del comando Debug del Cisco IOS para más información.


Para girar los mensajes del rastro de auditoría, utilice el siguiente comando en el modo de configuración global:

Comando
Propósito

Router(config)# ip inspect audit-trail

Activa los mensajes del registro de auditoría CBAC.


Comandos Genéricos de Debug

Usted puede utilizar los comandos generic siguientes debug , ingresados en el modo EXEC privilegiado:

Comando
Propósito

Router# debug ip inspect function-trace

Visualiza los mensajes sobre las funciones del software llamadas por el CBAC.

Router# debug ip inspect object-creation

Visualiza los mensajes sobre los objetos del software que son creados por el CBAC. La creación del objeto corresponde al principio de las sesiones inspeccionado por CBAC.

Router# debug ip inspect object-deletion

Visualiza los mensajes sobre los objetos del software que son borrados por el CBAC. La cancelacíon del objeto corresponde al closing de las sesiones inspeccionado por CBAC.

Router# debug ip inspect events

Visualiza los mensajes sobre los eventos del software CBAC, incluyendo la información sobre el proceso del paquete CBAC.

Router# debug ip inspect timers

Visualiza los mensajes sobre los eventos de temporización CBAC por ejemplo cuando se alcanza un tiempo de inactividad CBAC.

Router# debug ip inspect detail

Habilita la opción detallada, que se puede utilizar conjuntamente con la otra opción de conseguir la información adicional.


Comandos de Debug del Nivel de Transporte

Usted puede utilizar los comandos siguientes debug del transporte-nivel, ingresados en el modo EXEC privilegiado:

Comando
Propósito

Router# debug ip inspect tcp

Visualiza los mensajes sobre los eventos TCP inspeccionado por CBAC, incluyendo los detalles sobre los paquetes TCP.

Router# debug ip inspect udp

Visualiza los mensajes sobre los eventos inspeccionado por CBAC UDP, incluyendo los detalles sobre los paquetes UDP.


Comandos de Debug del Application Protocol

Usted puede utilizar el comando siguiente debug del Application Protocol, ingresado en el modo EXEC privilegiado:

Comando
Propósito

Router# debug ip inspect protocol

Visualiza los mensajes sobre los eventos inspeccionado por CBAC del protocolo, incluyendo los detalles sobre los paquetes del protocolo.

Refiera al cuadro 3 para determinar la palabra clave de protocolo.


Ejemplos de la configuración CBAC

Las secciones siguientes proporcionan los ejemplos de la configuración CBAC:

Ejemplo de Configuración de Interfaz Ethernet

Ejemplo de Configuración de la Interfaz ATM

Ejemplo de Configuración de Oficina Remota a ISP

Ejemplo de Configuración de Oficina Remota a Sucursal

Ejemplo de Configuración de Sucursal de Dos Interfaces

Ejemplo de Configuración de Sucursal de Interfaz Múltiple

El primer ejemplo desarrolla una regla de la inspección de CBAC para los protocolos específicos y un Access Control List que soporta (ACL). Este ejemplo se enfoca cómo configurar el CBAC; no proporciona una configuración del router completa y no describe otros elementos de la configuración.

El próximo ejemplo desarrolla una regla de la inspección de CBAC para los sitios que pudieron tener tráfico alejado a través de una interfaz ATM. Este ejemplo más futuro ilustra en cómo configurar el CBAC y acentúa la aplicación de la regla de la configuración en la interfaz, sea cual sea esa interfaz pudo ser. Este ejemplo no proporciona una configuración del router completa y no describe otros elementos de la configuración.

Los ejemplos de la oficina remota también se centran en la configuración de escudo de protección pero no proporcionan las descripciones detalladas de otros elementos de configuración, tales como el Basic Rate Interface (BRI) y las configuraciones de la interfaz del dialer.

Otros ejemplos proporcionan configuraciones de escudo de protección más completas, otras maneras de ilustración de las cuales aplicar el CBAC.

En cada ejemplo, configurar el examen del protocolo usando el CBAC tiene cuatro componentes:

Definición de una lista de acceso con los permisos adecuados.

Aplicación del ACL en una interfaz donde usted quiere controlar el acceso.

Definiendo una regla del examen que incluye el protocolo que usted quiere examinar.

Aplicación de la regla del examen en una interfaz donde usted quiere examinar el tráfico.

Ejemplo de Configuración de Interfaz Ethernet

Este ejemplo mira cada uno de estos cuatro componentes. Por este ejemplo, el CBAC se está configurando para examinar el tráfico de protocolo RTSP y de H.323 entrante de la red protegida en un router con dos interfaces de Ethernet. La interfaz Ethernet1/0 es la red protegida y la interfaz Ethernet1/1 es la red no protegida. La política de seguridad para el sitio protegido utiliza el Listas de control de acceso (ACL) para restringir el tráfico entrante en la interfaz no protegida al tráfico específico del protocolo ICMP, negando el acceso entrante para el TCP y el tráfico del protocolo UDP. El acceso entrante para el tráfico de protocolo específico se proporciona a través de las listas de acceso dinámicas, que se generan según las reglas de la inspección de CBAC.

El ACL 100 niega el tráfico TCP y UDP de cualquier fuente o destino mientras que permite el tráfico específico del protocolo ICMP. El enunciado de negación final no se requiere, sino es incluido para la explicidad — la imputación definitiva en cualquier ACL es una negación implícita de todos protocolo IP trafica.

Router(config)# access-list 100 deny tcp any any 
Router(config)# access-list 100 deny udp any any 
Router(config)# access-list 100 permit icmp any any echo-reply 
Router(config)# access-list 100 permit icmp any any time-exceeded 
Router(config)# access-list 100 permit icmp any any packet-too-big 
Router(config)# access-list 100 permit icmp any any traceroute 
Router(config)# access-list 100 permit icmp any any unreachable 
Router(config)# access-list 100 deny ip any any 

El ACL 100 es entrante aplicado en la interfaz Ethernet1/1 para bloquear todo el acceso de la red no protegida a la red protegida.

Router(config)# interface Ethernet1/1 
Router(config-if)# ip access-group 100 in 

Una regla del examen se crea para los “hqusers” esos las cubiertas dos protocolos: RTSP y H.323.

Router(config)# ip inspect name hqusers rtsp 
Router(config)# ip inspect name hqusers h323 

La regla del examen es entrante aplicado en la interfaz Ethernet1/0 para examinar el tráfico de los usuarios en la red protegida. Cuando el CBAC detecta el tráfico de las multimedias de la red protegida, el CBAC crea las entradas dinámicas en la lista de acceso 100 para permitir el tráfico de retorno para las sesiones de las multimedias.

Router(config)# interface Ethernet1/0 
Router(config-if)# ip inspect hqusers in 

Ejemplo de Configuración de la Interfaz ATM

En este ejemplo, la inspección de CBAC (protección mediante firewall) se requiere contra el tráfico entrante en una interfaz ATM. Este ejemplo pudo aplicarse a los sitios en donde los host locales requieren el acceso a los hosts o a los servicios en una red remota. La política de seguridad para este sitio utiliza el Listas de control de acceso (ACL) para restringir el tráfico entrante en la interfaz ATM al tráfico específico del protocolo ICMP, negando el acceso entrante para el TCP y el tráfico del protocolo UDP. El acceso entrante para el tráfico específico TCP y del protocolo UDP se proporciona a través de las listas de acceso dinámicas, que se generan según las reglas de la inspección de CBAC.

Para la información sobre cómo seleccionar la interfaz en la cual aplicar el CBAC, refiera “configurando las listas de IP Access en a la sección de la interfaz”.


Observepara el Frame Relay o las interfaces ATM, usted puede aplicar las reglas de la inspección de CBAC por separado en cada sub-interfaz, aunque las subinterfaces están conectadas físicamente a través de una interfaz.


! -------------------------
! Create the Inspection Rule
! -------------------------
!
! Create the CBAC inspection rule "test", allowing inspection of the protocol traffic
! specified by the rule. This inspection rule sets the timeout value to 30 seconds for
! each protocol (except for RPC). The timeout value defines the maximum time that a
! connection for a given protocol can remain active without any traffic passing through
! the router. When these timeouts are reached, the dynamic ACLs that are inserted to
! permit the returning traffic are removed, and subsequent packets (possibly even valid
! ones) are not permitted. 
ip inspect name test cuseeme timeout 30
ip inspect name test ftp timeout 30
ip inspect name test h323 timeout 30
ip inspect name test realaudio timeout 30
ip inspect name test rpc program-number 100000
ip inspect name test streamworks timeout 30
ip inspect name test vdolive timeout 30
! 
! ------------------------------
! Create the Access Control List
! ------------------------------
! 
! In this example, ACL 105 denies all TCP and UDP protocol traffic. ICMP traffic from
! subnet 192.168.1.0 is permitted to allow access for routing and control traffic.
! ACL 105 specifies that only the return traffic for protocols defined in the 
! inspection rule is allow access through the interface where this rule is applied. The
! final deny statement is added for explicitness.
access-list 105 deny TCP any any
access-list 105 deny UDP any any
access-list 105 permit icmp any any echo-reply
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 time-exceeded
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 packet-too-big
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 traceroute
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 unreachable
access-list 105 deny ip any any
! 
! ---------------------------------
! Apply the Inspection Rule and ACL
! ---------------------------------
! 
! In this example, the inspection rule "test" is applied to traffic at interface ATM3/0
! for connections initiated in the outbound direction; that is, from hosts that are
! located on a local network. CBAC creates dynamic access list entries for traffic
! initiated by local hosts. These dynamic entries allow inbound (returning) traffic for
! that connection. ACL 105 is applied at interface ATM3/0 in the inbound direction to
! block traffic initiated from hosts on a remote network that is not part of an 
! existing connection.
interface ATM3/0
ip address 10.1.10.1 255.0.0.0
ip access-group 105 in
no ip directed-broadcast
ip inspect test out
no shutdown
atm clock INTERNAL
atm pvc 7 7 7 aal5snap
map-group atm

Ejemplo de Configuración de Oficina Remota a ISP

Este ejemplo describe una configuración posible del Firewall Cisco IOS para un router de oficina remota conectado con un Proveedor de servicios de Internet (ISP). En esta configuración, la política de seguridad del sitio permite que los hosts en la red local inicien el tráfico al ISP mientras que el tráfico entrante al router del ISP se bloquea en la interfaz de ISDN. El tráfico de mensajes de control ICMP específico se permite a través del firewall. No hay correo o servicios web disponible desde la red local. El cuadro 4 ilustra este ejemplo.

Cuadro 4 oficina remota a la configuración de muestra ISP

El firewall tiene dos interfaces:

Una interfaz de Ethernet se conecta a la red protegida interna.

El interface ethernet0 no tiene ningún ACL aplicado a él, significando que todo el tráfico iniciado en el LAN no está prohibido el acceso al ISP. En este ejemplo de configuración, el Network Address Translation (NAT) no se gira, y los direccionamientos en el interface ethernet0 son IP Addresses reservados. En un entorno de producción, los direccionamientos en el ethernet0 o deben ser direcciones de red registradoas, o usted debe girar el NAT para ocultar a estas direcciones internas de ser visible en Internet.

Un Basic Rate Interface (BRI) ISDN conecta al router con el ISP. En este ejemplo, se utiliza un perfil de marcador para controlar la interfaz BRI. Esto significa que las reglas ACL y de la inspección de CBAC son aplicadas en la interfaz del dialer, no no directamente en la interfaz física ISDN (BRI) usando un mapa de marcador.

! --------------------------------------
! General Cisco IOS Firewall Guidelines
! --------------------------------------
! The following global configuration entries illustrate good security practices. 
enable secret 5 <elided>
no ip source-route
no cdp run
! 
! --------------------------------
! Create the CBAC inspection rule
! -------------------------------
! Create the CBAC inspection rule STOP to allow inspection of the protocol traffic
! specified by the rule. 
ip inspect name STOP tcp
ip inspect name STOP ftp
ip inspect name STOP smtp
ip inspect name STOP h323
ip inspect name STOP rcmd
! 
! ---------------------------------
! Create Access Control List 105 
! ---------------------------------
! ACL 105 denies all IP protocol traffic except for specific ICMP control traffic. 
! This means that only the return traffic for protocols defined in the 
! inspection rule and the specified ICMP traffic is allowed access through the 
! interface where this rule is applied.
! 
! Deny broadcast messages with a source address of 255.255.255.255; this helps to
! prevent broadcast attacks.
access-list 105 deny ip host 255.255.255.255 any
!
! Add anti-spoofing protection by denying traffic with a source address matching a host
! on the Ethernet interface.
acl 105 deny ip 192.168.1.0 0.0.0.255 any 
! 
! ICMP traffic is not inspected by CBAC. To control the type of ICMP traffic at the
! interface, add static access list entries. This example has the following ICMP
! requirements: outgoing ping commands require echo-reply messages to come back,
! outgoing traceroute commands require time-exceeded messages to come back, path MTU
! discovery requires "too-big" messages to come back, and incoming traceroute
! messages must be allowed. Additionally, permit all "unreachable" messages to come
! back; that is, if a router cannot forward or deliver a datagram, it sends an ICMP
! unreachable message back to the source and drops the datagram.
access-list 105 permit icmp any any echo-reply
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 time-exceeded
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 packet-too-big
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 traceroute
access-list 105 permit icmp any 192.168.1.0 0.0.0.255 unreachable
! 
! Final deny for explicitness. This entry is not required but helps complete the access
! list picture. By default, the final entry in any access list is an implicit deny of 
! IP protocol traffic. This ensures that the firewall blocks any traffic not explicitly
! permitted by the access list.
access-list 105 deny ip any any
! 
! ----------------------------------------------------------
! Configure the interface
! ----------------------------------------------------------
! In this example, no ACLs or inspection rules are applied at interface Ethernet0, 
! meaning that all traffic on the local network is allowed to go out. This assumes a
! high-level of trust for the users on the local network.
interface Ethernet0
ip address 192.168.1.104 255.255.255.0
! 
no ip directed-broadcast
! 
! This example uses a dialer profile, so the ACL and CBAC inspection rules are applied
! at the dialer interface, not the physical BRI interface. The dialer pool-member
! command is used to associate the physical interface with a dialer profile. 
interface BRI0
no ip address
no ip directed-broadcast
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-5ess
! 
! -------------------------------------------------------------------
! Create the dialer profile.
! -------------------------------------------------------------------
! Through the dialer profile, the ACL and CBAC inspection rules are
! applied to every pool member. In this example, the ACL is applied in, meaning that it
! applies to traffic inbound from the ISP. The CBAC inspection rule STOP is applied 
! out, meaning that CBAC monitors the traffic through the interface and controls return
! traffic to the router for an existing connection. 
interface Dialer0
ip address negotiated
ip access-group 105 in
no ip directed-broadcast
ip inspect STOP out
encapsulation ppp
dialer remote-name <ISP router>
dialer idle-timeout 500
dialer string <elided>
dialer pool 1
dialer-group 1
ppp authentication callin
! 
! ---------------------------------------------------------
! Additional entries 
! ---------------------------------------------------------
! Configure the router to forward packets destined for an unrecognized subnet of
! a directly connected network.
ip classless
! Route traffic to the dialer interface.
ip route 0.0.0.0 0.0.0.0 Dialer0
! Include a dialer list protocol entry to specify the protocol that triggers dialing.
dialer-list 1 protocol ip permit
! Add a user name (name of the router your are configuring) and password for caller
! identification and password authentication with the ISP router.
username <router host name> password 5 <elided>

Ejemplo de Configuración de Oficina Remota a Sucursal

Este ejemplo describe una configuración posible del Firewall Cisco IOS para un router de oficina remota conectado con una sucursal. En esta configuración, la política de seguridad del sitio permite que los hosts en la red local inicien el tráfico a la sucursal. El correo o los servicios web es disponible desde un servidor en la red local, y el acceso a estos servicios es disponible desde la sucursal. Trafique de la sucursal, a excepción del correo y el tráfico de la Web, se bloquea en la interfaz exterior. El tráfico de mensajes de control ICMP específico se permite a través del firewall. El cuadro 5 ilustra este ejemplo.

Cuadro 5 oficina remota a la configuración de muestra de la sucursal

El firewall tiene dos interfaces:

Una interfaz de Ethernet se conecta a la red protegida interna.

El interface ethernet0 no tiene ningún ACL aplicado a él, significando que todo el tráfico iniciado del LAN no está prohibido el acceso con el Firewall.

Un Basic Rate Interface (BRI) ISDN conecta al router con la sucursal. En este ejemplo, se utiliza un perfil de marcador para controlar la interfaz BRI. Esto significa que las reglas ACL y de la inspección de CBAC son aplicadas en la interfaz del dialer, no no directamente en la interfaz física ISDN (BRI).

! -------------------------------------------
! General firewall configuration guidelines
! -------------------------------------------
! The following global configuration entries illustrate good security practices. 
enable secret 5 <elided>
no ip source-route
no cdp run
! 
! ---------------------------
! Create the Inspection Rule
! ---------------------------
! Create the CBAC inspection rule STOP to allow inspection of the specified protocol
! traffic. Create the inspection rule GO to allow inspection of SMTP traffic. 
ip inspect name STOP tcp
ip inspect name STOP ftp
ip inspect name STOP smtp
ip inspect name STOP h323
ip inspect name GO smtp
! 
! --------------------------------------------------------------
! Create Access Control Lists 106 and 51
! --------------------------------------------------------------
! ACL 106 permits mail and Web traffic from any host to the specified server. ACL 106
! denies all other ip protocol traffic except for specific ICMP control traffic. 
! This means that only the return traffic for protocols defined in the 
! inspection rule and the specified ICMP traffic is allowed access through the 
! interface where this rule is applied.
! 
! Deny broadcast messages with a source address of 255.255.255.255; this helps to 
! prevent broadcast attacks.
access-list 106 deny ip host 255.255.255.255 any
! 
! Add anti-spoofing protection by denying traffic with a source address matching a host
! on the Ethernet interface.
access-list 106 deny ip 192.168.1.0 0.0.0.255 any 
! 
! ICMP traffic is not inspected by CBAC. To control the type of ICMP traffic at the
! interface, add static access list entries. This example has the following ICMP
! requirements: outgoing ping commands require echo-reply messages to come back,
! outgoing traceroute commands require time-exceeded messages to come back, path MTU
! discovery requires "too-big" messages to come back, and incoming traceroute must be
! allowed. Additionally, permit all "unreachable" messages to come back; that is, if a
! router cannot forward or deliver a datagram, it sends an ICMP unreachable message 
! back to the source and drops the datagram.
access-list 106 permit icmp any any echo-reply
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 time-exceeded
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 packet-too-big
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 traceroute
access-list 106 permit icmp any 192.168.1.0 0.0.0.255 unreachable
! 
! Permit mail and Web access to a specific server.
access-list 106 permit tcp any host 192.168.1.20 eq smtp
access-list 106 permit tcp any host 192.168.1.20 eq www
! 
! Final deny for explicitness. This entry is not required but helps complete the access
! list picture. By default, the final entry in any access list is an implicit deny of 
! IP protocol traffic. This ensures that the firewall blocks any traffic not explicitly
! permitted by the access list.
access-list 106 deny ip any any
! 
! ----------------------------------------------------------
! Configure the interface.
! ----------------------------------------------------------
! In this example, no ACLs or inspection rules are applied at interface Ethernet0, 
! meaning that all traffic on the local network is allowed to go out. This assumes a
! high-level of trust for the users on the local network.
interface Ethernet0
ip address 192.168.1.104 255.255.255.0
no ip directed-broadcast
! 
! This example uses a dialer profile, so the ACL and CBAC inspection rules are applied
! at the dialer interface, not the physical BRI interface. The dialer pool-member
! command is used to associate the physical interface with a dialer profile. 
interface BRI0
no ip address
no ip directed-broadcast
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-5ess
! 
! ------------------------------------------------------------------
! Apply the ACL and CBAC inspection rules at the dialer interface.
! ------------------------------------------------------------------
! Through the dialer profile, the ACL and CBAC inspection rules are 
! applied to every pool member. In this example, the ACL is applied in, meaning that it 
! applies to traffic inbound from the branch office. The CBAC inspection rule STOP is
! applied out, meaning that CBAC monitors the traffic and controls return traffic to 
! the router for an existing connection. The CBAC inspection rule GO is applied in,
! protecting against certain types of DoS attacks as described in this document. Note
! that the GO inspection rule does not control return traffic because there is no ACL
! blocking traffic in that direction; however, it does monitor the connections.
interface Dialer0
ip address <ISDN interface address>
ip access-group 106 in
no ip directed-broadcast
ip inspect STOP out
ip inspect GO in
encapsulation ppp
dialer remote-name <branch office router>
dialer idle-timeout 500
dialer string <elided>
dialer pool 1
dialer-group 1
ppp authentication
! 
! ---------------------------------------------------------
! Additional entries 
! ---------------------------------------------------------
! Configure the router to forward packets destined for an unrecognized subnet of
! a directly connected network.
ip classless
! Route traffic to the dialer interface.
ip route 0.0.0.0 0.0.0.0 Dialer0
! Include a dialer list protocol entry to specify the protocol that triggers dialing.
dialer-list 1 protocol ip permit
! Add a user name (name of the router your are configuring) and password for caller
! identification and password authentication with the ISP router.
username <router host name> password 5 <elided>

Ejemplo de Configuración de Sucursal de Dos Interfaces

Este ejemplo de archivo de configuración describe un Firewall configurado con el CBAC. El Firewall se coloca entre la red interna de una oficina de campo protegida y una conexión WAN a las oficinas principales de la compañía. El CBAC se configura en el Firewall para proteger la red interna contra las amenazas de la red potencial que vienen del lado de WAN.

El Firewall tiene dos interfaces configuradas:

El interface ethernet0 conecta con la red protegida interna

El serial0 de la interfaz conecta con WAN con el Frame Relay

! ----------------------------------------------------------------------
! This first section contains some configuration that is not required for CBAC,
! but illustrates good security practices. Note that there are no 
! services on the Ethernet side. Email is picked up via POP from a server on the
! corporate side.
! ----------------------------------------------------------------------
! 
hostname user1-examplecorp-fr
! 
boot system flash c1600-fw1600-l
enable secret 5 <elided>
! 
username user1 password <elided>
ip subnet-zero
no ip source-route
ip domain-name example.com
ip name-server 172.19.2.132
ip name-server 198.92.30.32
! 
! 
! -----------------------------------------------------------------------
! The next section includes configuration required specifically for CBAC.
! -----------------------------------------------------------------------
! 
! The following commands define the inspection rule "myfw", allowing
! the specified protocols to be inspected. Note that Java applets will be permitted
! according to access list 51, defined later in this configuration.
ip inspect name myfw cuseeme timeout 3600
ip inspect name myfw ftp timeout 3600
ip inspect name myfw http java-list 51 timeout 30
ip inspect name myfw rcmd timeout 3600
ip inspect name myfw realaudio timeout 3600
ip inspect name myfw smtp timeout 3600
ip inspect name myfw tftp timeout 30
ip inspect name myfw udp timeout 15
ip inspect name myfw tcp timeout 3600
! 
! The following interface configuration applies the "myfw" inspection rule to
! inbound traffic at Ethernet 0. Since this interface is on the internal network 
! side of the firewall, traffic entering Ethernet 0 is actually 
! exiting the internal network. Applying the inspection rule to this interface causes
! inbound traffic (which is exiting the network) to be inspected; return traffic will
! only be permitted back through the firewall if part of a session which began from
! within the network.
! Also note that access list 101 is applied to inbound traffic at Ethernet 0.
! (Traffic blocked by the access list will not be inspected.)
interface Ethernet0
description ExampleCorp Ethernet chez user1
ip address 172.19.139.1 255.255.255.248
ip broadcast-address 172.19.131.7
no ip directed-broadcast
no ip proxy-arp
ip inspect myfw in
ip access-group 101 in
no cdp enable
! 
interface Serial0
description Frame Relay (Telco ID 22RTQQ062438-001) to ExampleCorp HQ
no ip address
ip broadcast-address 0.0.0.0
encapsulation frame-relay IETF
no arp frame-relay
bandwidth 56
service-module 56k clock source line
service-module 56k network-type dds
frame-relay lmi-type ansi
! 
! Note that the following interface configuration applies access list 111 to
! inbound traffic at the external serial interface. (Inbound traffic is
! entering the network.) When CBAC inspection occurs on traffic exiting the 
! network, temporary openings will be added to access list 111 to allow returning
! traffic that is part of existing sessions.
! 
interface Serial0.1 point-to-point
ip unnumbered Ethernet0
ip access-group 111 in
bandwidth 56
no cdp enable
frame-relay interface-dlci 16   
! 
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0.1
! 
! The following access list defines "friendly" and "hostile" sites for Java 
! applet blocking. Because Java applet blocking is defined in the inspection 
! rule "myfw" and references access list 51, applets will be actively denied
! if they are from any of the "deny" addresses and allowed only if they are from 
! either of the two "permit" networks.
! 
access-list 51 deny   172.19.1.203
access-list 51 deny   172.19.2.147
access-list 51 permit 172.18.0.0 0.1.255.255
access-list 51 permit 192.168.1.0 0.0.0.255
access-list 51 deny   any
! 
! The following access list 101 is applied to interface Ethernet 0 above.
! This access list permits all traffic that should be CBAC inspected, and also 
! provides anti-spoofing. The access list is deliberately set up to deny unknown
! IP protocols, because no such unknown protocols will be in legitimate use.
! 
access-list 101 permit tcp 172.19.139.0 0.0.0.7 any
access-list 101 permit udp 172.19.139.0 0.0.0.7 any
access-list 101 permit icmp 172.19.139.0 0.0.0.7 any
access-list 101 deny   ip any any
! 
! The following access list 111 is applied to interface Serial 0.1 above.
! This access list filters traffic coming in from the external side. When
! CBAC inspection occurs, temporary openings will be added to the beginning of
! this access list to allow return traffic back into the internal network.
! This access list should restrict traffic that will be inspected by
! CBAC. (Remember that CBAC will open holes as necessary to permit returning traffic.)
! Comments precede each access list entry. These entries are not all specifically
! related to CBAC, but are created to provide general good security.
! 
! Anti-spoofing.
access-list 111 deny   ip 172.19.139.0 0.0.0.7 any
! Sometimes EIGRP is run on the Frame Relay link. When you use an
! input access list, you have to explicitly allow even control traffic.
! This could be more restrictive, but there would have to be entries
! for the EIGRP multicast as well as for the office's own unicast address.
access-list 111 permit igrp any any
! 
! These are the ICMP types actually used...
! administratively-prohibited is useful when you are trying to figure out why
! you cannot reach something you think you should be able to reach.
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 administratively-prohibited
! 
! This allows network admins at headquarters to ping hosts at the field office:
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 echo
! 
! This allows the field office to do outgoing pings
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 echo-reply
! 
! Path MTU discovery requires too-big messages
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 packet-too-big
! 
! Outgoing traceroute requires time-exceeded messages to come back
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 time-exceeded
! 
! Incoming traceroute
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 traceroute
! 
! Permits all unreachables because if you are trying to debug
! things from the remote office, you want to see them. If nobody ever did 
! any debugging from the network, it would be more appropriate to permit only 
! port unreachables or no unreachables at all.
access-list 111 permit icmp any 172.19.139.0 0.0.0.7 unreachable
! 
! 
! These next two entries permit users on most ExampleCorp networks to Telnet to
! a host in the field office. This is for remote administration by the network admins.
access-list 111 permit tcp 172.18.0.0 0.1.255.255 host 172.19.139.1 eq telnet
access-list 111 permit tcp 192.168.1.0 0.0.0.255 host 172.19.139.1 eq telnet
! 
! Final deny for explicitness
access-list 111 deny ip any any
! 
no cdp run
snmp-server community <elided> RO
! 
line con 0
exec-timeout 0 0
password <elided>
login local
line vty 0
exec-timeout 0 0
password <elided>
login local
length 35
line vty 1
exec-timeout 0 0
password 7 <elided>
login local
line vty 2
exec-timeout 0 0
password 7 <elided>
login local
line vty 3
exec-timeout 0 0
password 7 <elided>
login local
line vty 4
exec-timeout 0 0
password 7 <elided>
login local
! 
scheduler interval 500
end

Ejemplo de Configuración de Sucursal de Interfaz Múltiple

En este ejemplo de configuración, un solo router de escudo de protección de las Cisco 3600 Series se coloca en una sucursal. Tiene cuatro redes internas y dos conexiones WAN a las oficinas principales de la compañía. El CBAC se configura en el Firewall para proteger dos de las redes internas contra las amenazas de la red potencial que vienen del lado de WAN y de menos asegura las redes internas. La protección contra spoofing se agrega en cada interfaz con los sistemas del cliente. El cuadro 6 ilustra esta configuración.


Observeeste ejemplo muestra un moderado de alto nivel de la confianza de los administradores hacia los usuarios previstos. La protección adicional se podía agregar a esta configuración para una situación en un nivel inferior de la confianza. Que la configuración incluiría las declaraciones del filtrado de ICMP, significantly more protocolo y control de direccionamiento con el uso de listas de control de acceso más restrictivas, y contra spoofing aplicado por todas partes. Esta configuración no contiene esas restricciones adicionales porque ésa detraería del ejemplo CBAC.


Cuadro 6 entorno de la aplicación del Firewall Cisco IOS de la muestra

La sucursal tiene esta configuración de red de muestra:

La interfaz de Ethernet 0/0 soporta los servidores del departamento de los Recursos Humanos. Esta red incluye un host del correo electrónico (S TP y POP3) y un servidor Windows NT. El servidor Windows NT es el controlador de dominio primario (PDC) para el dominio de los Recursos Humanos y tiene una relación de confianza con el resto de la compañía; sin embargo, contiene las aplicaciones y las bases de datos que no se deben acceder por el resto de la compañía o los otros grupos en la sucursal. Los dispositivos en este LAN son accesibles solamente por los usuarios en el departamento de los Recursos Humanos en la interfaz de Ethernet 0/1. El mail server debe poder enviar y recibir el correo electrónico (a través de las sesiones de SMTP) con todos los otros dispositivos. Las máquinas de Windows 95 pueden utilizar esta máquina mientras que su servidor de correo electrónico (para enviar el correo electrónico a través de las sesiones de SMTP) y como repositorio para acumular el correo electrónico que pueden entonces descargar con las sesiones POP3. Nadie más en la compañía se permite formar las sesiones POP3 a cualquier máquina en este LAN.

La interfaz de Ethernet 0/1 soporta los ordenadores de Windows 95 en el departamento de los Recursos Humanos. Estos usuarios deben tener el acceso a los servidores del correo de los Recursos Humanos situados en la interfaz de Ethernet 0/0 así como acceso al resto de la compañía. El acceso a los recursos del servidor de Windows NT es controlado con los permisos de Windows NT asignados a cada usuario en el dominio de Windows NT.

La interfaz de Ethernet 1/0 soporta los servidores Web de la sucursal, que se pueden acceder por todo el mundo en la compañía. Estos servidores utilizan los puertos TCP 80 (HTTP) y 443 (SHTTP) para el Acceso Web entrante. Esta red también incluye un controlador de dominio de backup (BCD) para el dominio total que también se utiliza como el archivo, la impresión, y servidor del servicio.

La interfaz de Ethernet 1/1 apoya a todos los usuarios que no estén en el departamento de los Recursos Humanos. Estos usuarios no tienen ningún acceso a los servidores del departamento de los Recursos Humanos, sino que pueden acceder las otras interfaces de la red y las interfaces seriales para la conectividad WAN. La interfaz serial 0/0 y 0/1 conecta con WAN con los links T1 (links a las oficinas principales de la compañía). En esta configuración de muestra, los servidores del Domain Name System (DNS) están situados en alguna parte dentro del resto de la compañía.

Además, limitan el (SNMP) de la Administración de redes y a las sesiones telnets a la red de administración (192.168.55.0), que está situada en alguna parte dentro del resto de la compañía a través de la interfaz serial.

! ------------------------------------------------------------------
! This first section contains some configuration that is not required
! for CBAC, but illustrates good security practices.
! ------------------------------------------------------------------
! Add this line to get timestamps on the syslog messages.
service timestamps log datetime localtime show-timezone
! 
hostname Router1
! 
boot system flash c3600-fw3600-l
! 
! Configure AAA user authentication.
aaa new-model
aaa authentication login lista group tacacs+ enable
! 
enable secret 5 <elided>
ip subnet-zero
! 
! Disable source routing to help prevent spoofing.
no ip source-route
! 
! Set up the domain name and server IP addresses.
ip domain-name example.com
ip name-server 192.168.55.132
ip name-server 192.168.27.32
! 
! The audit-trail command enables the delivery of specific CBAC messages 
! through the syslog notification process.
ip inspect audit-trail 
! 
! Establish the time-out values for DNS queries. When this idle-timer expires,
! the dynamic ACL entries that were created to permit the reply to a DNS request 
! will be removed and any subsequent packets will be denied.
ip inspect dns-timeout 10
!
! ----------------------------------------------------------------------------------
! The next section includes configuration statements required specifically for CBAC.
! ----------------------------------------------------------------------------------
! Define the CBAC inspection rule "inspect1", allowing the specified protocols to be
! inspected. The first rule enables SMTP specific inspection. SMTP inspection causes
! the exchange of the SMTP session to be inspected for illegal commands. Any packets
! with illegal commands are dropped, and the SMTP session will hang and eventually
! time out.
ip inspect name inspect1 smtp timeout 30
!
! In the next two lines of inspect1, define the maximum time that each of the UDP and 
! TCP sessions are allowed to continue without any traffic passing 
! through the router. When these timeouts are reached, the dynamic ACLs that 
! are inserted to permit the returning traffic are removed and subsequent packets
! (possibly even valid ones) will not be permitted.
ip inspect name inspect1 udp timeout 30
ip inspect name inspect1 tcp timeout 30
!
! Define the CBAC inspection rule "inspect2", allowing the specified protocols to be
! inspected. These rules are similar to those used in the inspection rule "inspect1,"
! except that on the interfaces where this rule is applied, SMTP sessions are not 
! expected to go through; therefore, the SMTP rule element is not applied here.
ip inspect name inspect2 udp timeout 30
ip inspect name inspect2 tcp timeout 30
!
! ----------------------------------------------------------------------
! The next section shows the Ethernet interface configuration statements for each 
! interface, including access lists and inspections rules. 
! ----------------------------------------------------------------------
! Apply the "inspect1" inspection rule to sessions that are initiated in the outbound 
! direction (toward the LAN) at Ethernet interface 0/0. All packets in these sessions
! will be inspected by CBAC. Provided that network traffic passes the Access Control
! List (ACL) restrictions, traffic is then inspected by CBAC for access through the
! Cisco Secure Integrated Software. Traffic blocked by the access list is not inspected
! by CBAC. Access list 110 is applied to outbound traffic on this interface. 
interface Ethernet0/0
description HR_Server Ethernet
ip address 172.16.110.1 255.255.255.0
ip access-group 110 out
no ip directed-broadcast
no ip proxy-arp
ip inspect inspect1 out
no cdp enable
!
! Apply access list 120 to inbound traffic on Ethernet interface 0/1.
! Applying access list 120 to inbound traffic provides anti-spoofing on this interface
! by dropping traffic with a source address matching the IP address on a network other
! than Ethernet 0/1. The IP helper address lists the IP address of the DHCP server on
! Ethernet interface 1/0. 
interface Ethernet0/1
description HR_client Ethernet
ip address 172.16.120.1 255.255.255.0
ip access-group 120 in
ip helper-address 172.16.130.66
no ip directed-broadcast
no ip proxy-arp
no cdp enable
!
! Apply the "inspect2" inspection rule to sessions that are initiated in the outbound
! direction (toward the LAN) at Ethernet interface 1/0. Provided that network traffic
! passes the Access Control List (ACL) restrictions, traffic is then inspected by CBAC
! through the Cisco Secure Integrated Software. Traffic blocked by the access list is
! not inspected
! by CBAC. Access list 130 is applied to outbound traffic on this interface. 
interface Ethernet1/0
description Web_server Ethernet
ip address 172.16.130.1 255.255.255.0
ip access-group 130 out
no ip directed-broadcast
no ip proxy-arp
ip inspect inspect2 out
no cdp enable
!
! Apply access list 140 to inbound traffic at Ethernet interface 1/1. This
! provides anti-spoofing on the interface by dropping traffic with a source address
! matching the IP address of a network other than Ethernet 1/1. The IP helper address
! lists the IP address of the DHCP server on Ethernet interface 1/0. 
interface Ethernet1/1
description Everyone_else Ethernet
ip address 172.16.140.1 255.255.255.0
ip access-group 140 in
ip helper-address 172.16.130.66
no ip directed-broadcast

no ip proxy-arp
no cdp enable
!
! --------------------------------------------------------------------------
! The next section configures the serial interfaces, including access lists.
! --------------------------------------------------------------------------
! Apply access list 150 to Serial interfaces 0/0. This provides anti-spoofing on the
! serial interface by dropping traffic with a source address matching the IP address
! of a host on Ethernet interface 0/0, 0/1, 1/0, or 1/1.
interface Serial0/0
description T1 to HQ
ip address 192.168.150.1 255.255.255.0
ip access-group 150 in
bandwidth 1544
!
interface Serial1/1
description T1 to HQ
ip address 192.168.160.1 255.255.255.0
ip access-group 150 in
bandwidth 1544
!
! ------------------------------
! Configure routing information.
! ------------------------------
router igrp 109
network 172.16.0.0
network 192.168.150.0
network 192.168.160.0
!
! Define protocol forwarding on the firewall. When you turn on a related command, 
! ip helper-address, you forward every IP broadcast in the ip forward protocol
! command list, including several which are on by default: TFTP (port 69), 
! DNS (port 53), Time service (port 37), NetBIOS Name Server (port 137), 
! NetBIOS Datagram Server (port 138), BOOTP client and server datagrams 
! (ports 67 and 68), and TACACS service (port 49). One common
! application that requires helper addresses is Dynamic Host Configuration
! Protocol (DHCP). DHCP information is carried inside of BOOTP packets. The
! "no ip forward protocol" statements turn off forwarding for the specified protocols.
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs 
no ip forward-protocol udp tftp 
ip forward-protocol udp bootpc
!
! Add this line to establish where router SYSLOG messages are sent. This includes the 
! CBAC messages. 
logging 192.168.55.131 
!
! ---------------------------------------------------------------
! Define the configuration of each access list. 
! ---------------------------------------------------------------
! Defines Telnet controls in access list 12.
access-list 12 permit 192.168.55.0 0.0.0.255
!
! Defines SNMP controls in access list 13. 
access-list 13 permit 192.168.55.12
access-list 13 permit 192.168.55.19
!
! Access list 110 permits TCP and UDP protocol traffic for specific ports and with a  
! source address on Ethernet interface 0/1. The access list denies IP protocol traffic  
! with any other source and destination address. The access list permits ICMP access  
! for any source and destination address. Access list 110 is deliberately set up to  
! deny unknown IP protocols because no such unknown protocols will be in legitimate  
! use. Access list 110 is applied to outbound traffic at Ethernet interface 0/0. In ACL  
! 110, network traffic is being allowed access to the ports on any server on the HR  
! server network. In less trusted environments, this can be a security problem;  
! however, you can limit access more severely by specifying specific destination  
! addresses in the ACL statements.
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq smtp
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq pop3
access-list 110 permit tcp 172.16.120.0 0.0.0.255 any eq 110
access-list 110 permit udp any any eq 137
access-list 110 permit udp any any eq 138
access-list 110 permit udp any any eq 139
access-list 110 permit icmp any any 
access-list 110 deny ip any any!
!
! Access-list 120 permits TCP, UDP, and ICMP protocol traffic with a source address 
! on Ethernet interface 0/1, but denies all other IP protocol traffic. Access list
! 120 is applied to inbound traffic on Ethernet interface 0/1.
access-list 120 permit tcp 172.16.120.0 0.0.0.255 any
access-list 120 permit udp 172.16.120.0 0.0.0.255 any
access-list 120 permit icmp 172.16.120.0 0.0.0.255 any
access-list 120 deny ip any any
!
! Access list 130 permits TCP, UDP, and ICMP protocol traffic for specific ports and
! with any source and destination address. It opens access to the web server and to
! all NBT services to the rest of the company, which can be controlled through the
! trust relations on the Windows NT servers. The bootpc entry permits access to the
! DHCP server. Access list 130 denies all other IP protocol traffic. Access list 130 is
! applied to outbound traffic at Ethernet interface 1/0.
access-list 130 permit tcp any any eq www
access-list 130 permit tcp any any eq 443
access-list 130 permit tcp any any eq 110
access-list 130 permit udp any any eq 137
access-list 130 permit udp any any eq 138
access-list 130 permit udp any any eq 139
access-list 130 permit udp any any eq bootpc 
access-list 130 permit icmp any any 
access-list 130 deny ip any any
!
! Access list 140 permits TCP, UDP, and ICMP protocol traffic with a source address on
! Ethernet interface 1/1, and it denies all other IP protocol traffic. Access list 140
! is applied to inbound traffic at Ethernet interface 1/1.
access-list 140 permit tcp 172.16.140.0 0.0.0.255 any
access-list 140 permit udp 172.16.140.0 0.0.0.255 any
access-list 140 permit icmp 172.16.140.0 0.0.0.255 any
access-list 140 deny ip any any
!
! Access list 150 denies IP protocol traffic with a source address on Ethernet 
! interfaces 0/0, 0/1, 1/0, and 1/1, and it permits IP protocol traffic with any other
! source and destination address. Access list 150 is applied to inbound traffic
! on each of the serial interfaces.
access-list 150 deny ip 172.16.110.0 0.0.0.255 any
access-list 150 deny ip 172.16.120.0 0.0.0.255 any
access-list 150 deny ip 172.16.130.0 0.0.0.255 any
access-list 150 deny ip 172.16.140.0 0.0.0.255 any
access-list 150 permit ip any any
!
! Disable Cisco Discovery Protocol.
no cdp run 
!
snmp-server community <elided> ro 13
tacacs-server host 192.168.55.2
tacacs-server key <elided>
!
! -----------------------------------------------------------------------------------
! Configures the router console port and the virtual terminal line interfaces,
! including AAA authentication at login. Authentication is required for users defined
! in "lista." Access-class 12 is applied on each line, restricting Telnet access to
! connections with a source address on the network management network.
! -----------------------------------------------------------------------------------
line console 0
exec-timeout 3 00
login authentication lista
line aux 0
exec-timeout 3 00
login authentication lista
line vty 0
exec-timeout 1 30
login authentication lista
access-class 12 in
line vty 1
exec-timeout 1 30
login authentication lista
access-class 12 in
line vty 2
exec-timeout 1 30
login authentication lista
access-class 12 in
line vty 3
exec-timeout 1 30
login authentication lista
access-class 12 in
line vty 4
exec-timeout 1 30
login authentication lista
access-class 12 in
!
end


Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any 
examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes 
only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. 
 
© 2007 Cisco Systems, Inc. All rights reserved.