CCNA SECURITY

Capítulo 4: Implementing Firewall Technologies

 CCNA SECURITY

Introducción
• Estudiar ACLs nombradas, estandares y extendidas.
• Configurar ACLs con CLI y SDM
• Describir la funcionalidad TCP established
• Estudiar ACLs reflexivas.
• Estudiar ACLs dinámicas.
• Estudiar ACLs basadas en tiempo.
• Mitigación de ataques mediante ACLs
• Estudiar los tipos de Firewalls.
• Estudiar las CBACs.
• Estudiar la generación de politica basadas en zonas en los Firewalls mediante CLI y SDM.
 CCNA SECURITY

Listas de control de acceso (ACLs)

 CCNA SECURITY

Configurar ACLs estándares y extendidas con CLI

• Las ACLs se emplean como mecanismo de seguridad de red para la mitigación de
ataques y como sistema de control de tráfico de red.
• En una ACL es posible especificar el tipo de tráfico exactamente.
• Las ACLS numeradas se categorizan según su número y las familias de protocolos
que son capaces de filtrar.

• Por ejemplo, una ACL numerada 700-799 podría ser usado para bloquear un cliente
con una dirección MAC específica.
 CCNA SECURITY

Configurar ACLs estándares y extendidas con CLI (y II)

• ACLs estándares:
– Las ACL estándares emplean numeraciones de 1-99 y 1300-1399 para IPv4 e IPv6.
– Filtran tráfico examinando la IP origen del paquete y en consecuencia lo permiten
o lo deniegan.
– El comando es: “access-list {1-99} {permit | deny} source-addr [source-wildcard]”
– El último parámetro “source-wildcard” especifica el rango de direcciones que se
filtrarán.
• ACLs extendidas:
– Las ACL estándares emplean numeraciones de 100-199 y 2000-2699 para IPv4 e
IPv6.
– Filtran tráfico basandose en informacion de la capa 3 direccion IP origen y
destino y 4 puesto que incluyen informacion de puertos TCP y UDP origen y
destino y también basandose en informacion acerca del tipo o numero de
protocolo: TCP, UDP, IP o subprotocolos de IP.
– El comando es: “access-list {100-199} {permit | deny} protocol source-addr
[source-wildcard] [operator operand] destination-addr [destination-wildcard]
[operator operand] [established]”
 CCNA SECURITY

Configurar ACLs estándares y extendidas con CLI (y III)

• ACLs extendidas:
– Todas las ACLs tienen una denegación implícita.
– La verificación de las condiciones de las ACLs es secuencial.
– Una vez que se crea una ACL hay que asociarla al interfaz correspondiente para
tráfico de entrada o de salida.
– El comando para asociar una ACL a un interfaz es: “ip access-group access-list-
number {in | out}”
– El comando para asociar una ACL por ejemplo a una linea VTY es: “access-class
access-list-number {in | out}”
• ACLs nombradas:
– Las ACL nombradas se crean mediante el comando “ip access-list [standard |
extended] name_of_ACL” a continuación entramos en un modo de
subconfiguracion e introducimos las clausulas permit o deny correspondientes.
– Se pueden hacer ACL nombradas estandar o extendidas.
– Las clausulas permit y deny de una ACL nombrada tienen la siguiente sintaxis.
• Router(config-std-nacl)# deny {source [source-wildcard] | any}
• Router(config-std-nacl)# permit {source [source-wildcard] | any}
 CCNA SECURITY

Configurar ACLs estándares y extendidas con CLI (y IV)

• ACLs nombradas:
– La sintaxis completa de las clausulas de una ACL nombrada es:
– Router(config-ext-nacl)# {permit | deny} protocol source-addr [source-wildcard]
[operator operand] destination-addr [destination-wildcard] [operator operand]
[established]
– Una ventaja de las ACLs nombradas es que en el modo de configuracion es
posible eliminar una clausula especifica y añadir una clausula en una
determinada posición mientras que en las numeradas solo se pueden añadir
condiciones al final.
– En modo de configuracion de interfaz se asocia la ACL a trafico entrante o
saliente mediante el comando: “ip access-group access-list-name {in | out}”
– También es posible emplear una ACL para permitir o negar determinadas direcciones
IP desde un acceso virtual VTY. Para lo cual la ACL debe aplicarse al puerto VTY
mediante el siguiente comando.
– Router(config-line)# access-class access-list-name {in | out}
 CCNA SECURITY

Configurar ACLs estándares y extendidas con CLI (y V)

• ACLs nombradas:
 CCNA SECURITY

Configurar ACLs estándares y extendidas con CLI (y VI)

• Al final de las ACLs hay un parámetro denominado LOG que permite loguear informacion en el
supuesto de que se cumpla la clausula de la ACL correspondiente.
• Se puede loguear al buffer interno, a la consola, o a un servidor de syslog.
• Las informaciones que se loguean son:
– Acción: permitir o denegar
– Protocolo: TCP, UDP, ICMP
– Direcciones de Origen y destino
– Números de puerto origen y destino TCP y UDP
– Para ICMP: tipos de mensaje
• Los mensajes de log se generan para la primera coincidencia y después a intervalos de 5 minutos
tras la primera coincidencia.
• El empleo de LOG puede reducir el rendimiento del equipo.
• Si se utiliza Cisco IOS versión 12.3 y posterior, los números de secuencia se puede utilizar para
garantizar que una nueva declaración se agrega a la ACL en la ubicación correcta.
• La ACL se procesan de arriba hacia abajo sobre la base de los números de secuencia de las
declaraciones (de menor a mayor).
• El tráfico de enrutamiento de un router (actualizaciones) no es filtrado en el tráfico de salida de un
interfaz.
 CCNA SECURITY

Usando ACLs IP estandares y extendidas

• Ejemplo de ACL estándar que bloquea el tráfico de la red 172.16.4.0/24 y permite el
resto del tráfico.

• R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255

• R1(config)# access-list 1 permit any
• R1(config)# interface FastEthernet 0/0
• R1(config-if)# ip access-group 1 out

• El parámetro 0.0.0.255 es la wildcard. Los ceros indican las posiciones que deben
coincidir en el proceso de AND y los 1 indican las posiciones que serán ignoradas.
• El parámetro any es una abreviatura de una dirección 0.0.0.0 y una wildcard de
255.255.255.255.
• La clausula “access-list 1 permit any” se pone debido a la denegación implícita del
final de toda ACLS en cuyo caso se denegaria todo el tráfico, de este modo se
permite el resto del tráfico.
 CCNA SECURITY

Usando ACLs IP estandares y extendidas (y II)

• Ejemplo de ACL extendida que bloquea el tráfico FTP de la red 172.16.4.0/24 y
permite el resto del tráfico.
• R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21
• R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20
• R1(config)# access-list 101 permit ip any any
• El puerto 21 es para comandos de
FTP y el 20 para transferencia de
datos de FTP.
• La clausula “access-list 1 permit
any any” se ponde por la misma
razón que antes.
• En este ejemplo, la mejor ubicación
de la ACL es entrante en FA0 / 1. De
este modo se consumen menos
recursos en el router.
 CCNA SECURITY

Topología y diagrama de flujo de una ACL

• Hablamos de tráfico:
– Inbound: cuando entra en un interfaz de un router.
– Outbound: cuando sale de un interfza de un router.
• Las ACL extendidas se colocan en los routers lo más cerca posible
de la fuente que está siendo filtrada para ser más eficientes.
• Las ACL estándar se colocan lo más cerca posible del destino
como sea posible.
• Los comandos que nos permiten saber que ACLs tenemos creadas
son:
– “show ip access-list “: Cone ste comando vemos el tráfico que
coincide con una Entrada de Control de Acceso (ACE)
– “show running-config”: Permite ver las ACL creadas y su
asignación a los interfaces.
 CCNA SECURITY

Topología y diagrama de flujo de una ACL (y II)

• En el siguiente caso pretendemos
acceder al servidor POP desde la LAN
pero no queremos que se acceda
desde el exterior.
• El programa Nmap puede utilizarse
para determinar qué puertos están
abiertos en un dispositivo
determinado. Y podemos observar
como nmap muestra que el puerto 110
esta abierto desde PC1 pero una ACL
no permitira dicho tráfico desde el
exterior de la red.
 CCNA SECURITY

Configurar ACL estándares y extendidas con SDM

• En SDM: Pulsamos el botón
Configure y a continuación
pulsamos el botón Additional
Tasks.
• Cisco SDM proporciona reglas
predeterminadas que un
administrador puede utilizar al crear
reglas de acceso.
• Se denominan reglas externas a
aquellas que no fueron creadas
con SDM pero si son visibles
desde SDM, inclusive es posible
ver reglas con sintaxis no
soportadas por SDM denominadas
reglas no soportadas.
• Para crear, edita o borrar ACLs:
Menú Configure -> Additional
Tasks -> ACL Editor
 CCNA SECURITY

Configurar ACL estándares y extendidas con SDM (y II)

• SDM soporta los siguientes tipos de reglas:
– Reglas de Acceso: Son las ACL que conocemos se aplican a inetrfaces y lineas
VTY.
– Reglas de NAT: Determinan que direcciones IP privadas se traducen a
direcciones IP publicas.
– Reglas IPsec : Determinan que el tráfico se cifra en conexiones seguras.
– Reglas NAC: Especifican las direcciones IP que son admitidas a la red o
bloqueadas desde la red..
– Las reglas de firewall: Especificar las direcciones origen y destino y si se
permite el tráfico o se deniega.
– Reglas de QoS: Especifica el tráfico que pertenece a la calidad de servicio (QoS)
y que clase se asocia a la regla.
– Reglas no soportadas por SDM, solo se pueden ver en SDM son de solo lectura.
– Reglas definidas Externamente: reglas creadas fuera de SDM, pero si son
soportadas por SDM y asociables a cualquier interfaz
– SDM reglas por defecto: Reglas predefinidas que son utilizados por los
asistentes de Cisco SDM.
 CCNA SECURITY

Configurar ACL estándares y extendidas con SDM (y III)

• En SDM: Configure > Additional Tasks > ACL Editor >
Access Rules. Y pulsamos en añadir una regla. Le
pondremos un nombre a la regla, elegiremos el tipo de
regla de la lista desplegable por ejemplo “standard rule” y
pulsaremos en Añadir una entrada “Add”.
• Ac ontinuación creamos las entradas individuales de la
regla, seleccionamos una accion, permitir o denegary a
continuación en la seleccion de host/red elegimos entre:
una red, un host o una IP o cualquier direccion IP.
• En funcion de nuestra seleccion podremos elegir datos de
red, de host o de wildcards.
• A continuación seleccionaremos la opción de LOG si nos
interese e incluso podriamos asociarle comentarios a la
entrada.
• Por ultimo repetiriamos el proceso tantas veces como sea
necesario para generar todas las entardas de nuestra
regla. Podemos incluso cambiar el orden de las mismas.
 CCNA SECURITY

Configurar ACL estándares y extendidas con SDM (y IV)

• A continuación es necesario asociar la regla creada a un
interfaz.
• En la ventana de creación de la regla pulsamos el botón
“Associate” y seleccionamos el interfaz y si deseamos
filtrar tráfico inbound o outbound.
• Si ya hubiera una regla asociada con dicho interfaz se nos
proponen las siguientes opciones:
– Cancelar la operación.
– Continuar con la operación y añadir las entradas de la
nueva regla a la regla que ya estaba asociada a dicho
interfaz.
– Disociar la regla que estaba asociada al interfaz y
asociar la nueva regla en su lugar
• A continuación desde SDM podemos ver el fichero
running-config generado con las ACLs correspondientes.
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas

• Un FW por definición prohíbe el trafico OUT- IN si no fue generado interiormente.
• Muchas aplicaciones comunes se basan en TCP, que construye un circuito virtual entre los dos
extremos.
• La primera solucion de filtrado de tráfico mediante IOS que soporta la naturaleza de dos vias
(bidireccional) de los circuitos virtuales TCP fue TCP Established palabra clave que se emplea en las
ACL extendidas.
• De este modo se bloquea todo el tráfico procedente de Internet, excepto el tráfico TCP asociado con una
respuesta al tráfico TCP established iniciado desde el interior de la red.
• La segunda generación de soluciones de filtrado IOS fueron las ACLs Reflexivas introducidas en el IOS
en 1996.
• Las ACLs reflexivas filtran el tráfico basandose en direcciones de origen y destino, números de puerto, y
realizan un seguimiento de las sesiones. Las ACLs reflexivas empelan filtros temporales que se quitan
cuando una sesión ha terminado.
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas (y II)

• La sintaxis para una ACL extendida numerada con la opción established es la siguiente:
• Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard]
[operator operand] destination-addr [destination-wildcard] [operator operand] [established]
• La palabra clave established fuerza al router a comprobar si se establece TCP ACK o un
indicador de control de RST. Si se establece el indicador ACK, al tráfico TCP se le permite
entrar, en otro caso se supone que el tráfico se asocia con una nueva conexión iniciada
desde el exterior y no se permite.
• Esto no significa que el router realice funciones de filtrado con estado. El router no hace un
seguimiento de las conversaciones para determinar si el tráfico es el tráfico de retorno
asociado a una conexión iniciada desde el interior de la red.
• Esto crea un “agujero” en el router, los hackers pueden aprovecharse de este agujero
utilizando un generador de paquetes, como Nmap, de este modo los paquetes TCP se
hacen pasar como paquete de devolución de tráfico. De este modo los Hackers generan
tráfico con el bit apropiado o bits en el campo de control de TCP.
• “Established” no se aplica a UDP ni ICMP.
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas (y III)

• Ejemplo de una ACL con
Established habilitado
– R1(config)# access-list 100
permit tcp any eq 443
192.168.1.0 0.0.0.255
established
– R1(config)# access-list 100
permit tcp any 192.168.1.3
0.0.0.0 eq 22
– R1(config)# access-list 100
deny ip any any
– R1(config)# interface
s0/0/0
– R1(config-if)# ip access-
group 100 in
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas (y IV)

• Las ACLs reflexivas aparecieron en Cisco IOS en 1996, un año después de que la
opción TCP Established estuviera disponible.
• Las ACL Reflexivas proporcionan una forma más correcta de filtrado de sesiones que
la que se realiza con TCP established.
• Las ACL reflexivas son mucho más difíciles de engañar porque los criterios de filtrado
son más exigentes. Por ejemplo, se comprueban direcciones de origen y destino,
números de puerto y los bits ACK y RST.
• Se emplean filtros temporales que se quitan cuando una sesión ha terminado. Esto
añade un límite de tiempo en oportunidad de ataque de un hacker.
• Las ACL reflexivas emplean registros de control temporal de acceso (ACE) que se
insertan en una AC
• El funcionamiento de las ACLs reflexivas es el siguiente: Una ACL extendida examina
el tráfico a medida que sale de la red. La ACL se puede aplicar de entrada en una
interfaz interna o saliente en la interfaz externa. Las ACE examinan el tráfico asociado
a las nuevas sesiones utilizando el parámetro reflect. Sobre la base de estas
declaraciones (utilizando reflect), el ACE de conexión construye dinámicamente una
ACL para permitir el tráfico de retorno.
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas (y V)

• Las ACLs reflexivas aparecieron en Cisco IOS en 1996, un año después de que la opción TCP
Established estuviera disponible.
• Las ACL Reflexivas proporcionan una forma más correcta de filtrado de sesiones que la que se
realiza con TCP established.
• Las ACL reflexivas son mucho más difíciles de engañar porque los criterios de filtrado son más
exigentes. Por ejemplo, se comprueban direcciones de origen y destino, números de puerto y los
bits ACK y RST.
• Se emplean filtros temporales que se quitan cuando una sesión ha terminado. Esto añade un límite
de tiempo en oportunidad de ataque de un hacker.
• Las ACL reflexivas emplean registros de control temporal de acceso (ACE) que se insertan en una
AC
• El funcionamiento de las ACLs reflexivas es el siguiente: Una ACL extendida examina el tráfico a
medida que sale de la red. La ACL se puede aplicar de entrada en una interfaz interna o saliente
en la interfaz externa. Las ACE examinan el tráfico asociado a las nuevas sesiones utilizando el
parámetro reflect. Sobre la base de estas declaraciones (utilizando reflect), el ACE de conexión
construye dinámicamente una ACL para permitir el tráfico de retorno.
• Para cada declaración reflect , el router crea una ACL reflexiva independiente.
• Cualquier ACE temporal reflexiva que se crean contener la acción de permiso para permitir el
tráfico de retorno para esta sesión.
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas (y VI)

• Paso 1. Creamos una ACL interna que observe las nuevas sesiones salientes y crea ACEs
temporales reflexivas.
• Paso 2. Crear una ACL externa que utiliza la ACL reflexiva para examinar el tráfico de retorno.
• Paso 3. Activar la ACL nombrada en las interfaces adecuadas.
• La sintaxis de la ACL interna es:
– Router(config)# ip access-list extended internal_ACL_name
– Router(config-ext-nacl)# permit protocol source-addr [source-mask] [operator operand]
destination-addr [destination-mask] [operator operand] [established] reflect
reflexive_ACL_name [timeout seconds]
• Un ejemplo de dicha ACL interna es:
– R1(config)# ip access-list extended internal_ACL
– R1(config-ext-nacl)# permit tcp any any eq 80 reflect web-only-reflexive-ACL
– R1(config-ext-nacl)# permit udp any any eq 53 reflect dns-only-reflexive-ACL timeout 10
• Cisco IOS crea dos ACEs reflexivas que mantienen la información de sesión para las conexiones
web de salida (web-only-reflexive-ACL) y las consultas DNS (dns-only-reflexive-ACL).
Establecemos un tiempo de espera para las consultas DNS de 10 segundos.
• A continuación es necesario crear una nueva ACL extendida nombrada que haga referencia a las
entradas temporales ACEs reflexivas emplearemos para ello la keyword “evaluate”.
 CCNA SECURITY

Configurar TCP Established y ACLs Reflexivas (y VII)

• La sintaxis para crear dicha ACL extendida nombrada
externa es la siguiente:
– Router(config)# ip access-list extended
external_ACL_name
– Router(config-ext-nacl)# evaluate
reflexive_ACL_name
• Y para nuestro ejemplo dicha ACL será:
– R1(config)# ip access-list extended external_ACL
– R1(config-ext-nacl)# evaluate web-only-reflexive-
ACL
– R1(config-ext-nacl)# evaluate dns-only-reflexive-
ACL
– R1(config-ext-nacl)# deny ip any any
• Por último aplicaremos las ACLs a los interfaces
correspondientes:
– R1(config)# interface s0/0/0
– R1(config-if)# description connection to the ISP.
– R1(config-if)# ip access-group internal_ACL out
– R1(config-if)# ip access-group external_ACL in
 CCNA SECURITY

Configurando ACLs dinámicas

• Añadidas a Cisco IOS en 1996.
• Las ACLs dinámicas están disponibles para tráfico IP.
• Las ACLs dinámicas dependen de la conexión Telnet,
autenticación (local o remota), y de las ACLs extendidas.
• Para configurar una ACL dinámica es necesario crear una
ACL Extendida que bloquee el tráfico a través del router, a
continuación los usuarios que quieren atravesar el router
son bloqueados hasta que el usuario cree una sesión Telnet
o SSH para conectarse al router y se autentique. Una vez
autenticado el usuario se cierra la sesión de telnet y se crea
una entrada de ACL dinámica que se agrega a la ACL
extendida existente.
• El router autentica la conexión TELNET o SSH utilizando la
base de datos local de nombre de usuarios o mediante un
servidor AAA usando RADIUS o TACACS +.
• No es posible establecer políticas de acceso de usuario
individuales. En cambio, el administrador define una política
para todos los usuarios de la ACL dinámica, de modo que
esta política solo se aplica a todos los usuarios
autenticados.
• Esta ACL permite el tráfico durante un periodo de tiempo
determinado, es posible controla los tiempos de inactividad y
tiempos absolutos de conexión.
 CCNA SECURITY

Configurando ACLs dinámicas (y II)

• Paso 1: Creación de una ACL extendida (nombrada o numerada). Esta ACL debe permitir
el acceso Telnet o SSH al router. Como mínimo es necesario crear una entrada de
marcador de posición en la ACL.
• Paso 2: Definimos el procedimiento de autenticación (BD local, AAA externa…)
• Paso 3: Habilitación del método de autenticación dinámica que se realiza en las lineas
VTY del router.
• El comando para crear la ACL dinámica es el siguiente:
– Router(config)# access-list {100-199} dynamic dynamic_ACL_name [timeout minutes]
{permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-
addr [destination-wildcard] [operator operand] [established]
• El keyword dynamic permite a un administrador especificar el nombre de la ACL dinámica
que se va a utilizar.
• El timeout (tiempo de espera absoluto) es opcional y puede variar desde 1 hasta 9999
minutos y mide el tiempo absoluto de duración de la sesión autenticada.
• Hay otro temporizador que mide el tiempo de inactividad de la sesión y se controla con el
comando “autocommand” que habilita la autenticación “lock and key” en las lineas VTY.
 CCNA SECURITY

Configurando ACLs dinámicas (y III)

• Si no se especifican temporizadores no hay limites en los tiempos de espera absolutos ni
de inactividad.
• La sintaxis mediante la cual especificamos el temporizador de inactividad es:
– Router(config)# line vty 0 4
– Router(config-line)# autocommand access-enable host [timeout minutes]
• El comando autocommand es el que permite la autenticación lock-and-key, a continuación
se crea la entrada dinámica que se coloca en la posición en que se definió el parámetro
“dynamic” en la ACL extendida. Con ello se crea la ACL dinámica en tiempo real. Sin el
comando “autocommand access-enable” no se crearian las entradas temporales.
• El parámetro host es opcional. Al especificar este parámetro, el IOS de Cisco sustituye la
entrada “any” de la ACL con la dirección IP del usuario.
• El parámetro de tiempo de espera opcional se utiliza para establecer el tiempo de espera
de inactividad del usuario.
 CCNA SECURITY

Configurando ACLs dinámicas (y IV)

 CCNA SECURITY

ACLs basadas en tiempo

• Aparecieron en Cisco IOS en 1998.
• Básicamente son ACLs extendidas (nombradas o numeradas) que permiten un control de
acceso basado en tiempo.
• Permiten o deniegan tráfico en función de la fecha y hora.
• Un administrador crea entradas basadas en tiempo y utiliza un parámetro de intervalo de
tiempo “time-range” para especificar el período de tiempo en que las sentencias de la ACL
son válidas.
• Cuando se crea un rango de tiempo con el comando “time-range” este debe tener un
nombre único y dicho nombre debe comenzar con una letra y no puede contener un
espacio, posteriormente se asociará una ACL específica con este rango.
• La sintaxis del comando es la siguiente:
– Router(config)# time-range time_range_name
– Router(config-time-range)# absolute [start_time start_date] [end_time end_date]
– Router(config-time-range)# periodic day_of_the_week hh:mm to [day_of_the_week]
hh:mm
 CCNA SECURITY

ACLs basadas en tiempo (y II)

• Se pueden especificar intervalos de tiempo
absolutos o periodicos.
• Se puede especificar hora de comienzo, de
finalización o ambas (La sintaxis es un poco
engorrosa).
• Dentro del mismo rango se pueden especificar
multiples comandos periodicos.
• Después de crear rangos de tiempo, el
administrador debe activarlos. Esto se hace
añadiendo el parámetro de intervalo de tiempo a la
declaración de ACL.
•La sintaxis de configuración de una ACL numerada es la siguiente:
•Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-mask] [operator
operand] destination-addr [destination-mask] [operator operand] [established][log | log-
input][established][time-range name_of_time_range]
 CCNA SECURITY

ACLs basadas en tiempo (y III)

• Ejemplo de una ACL basad en tiempo
– R1(config)# time-range employee-time
– R1(config-time-range)# periodic weekdays 12:00 to 13:00
– R1(config-time-range)# periodic weekdays 17:00 to 19:00
– R1(config-time-range)# exit
– R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any time-range employee-time
– R1(config)# access-list 100 deny ip any any
– R1(config)# interface FastEthernet 0/1
– R1(config-if)# ip access-group 100 in
– R1(config-if)# exit
 CCNA SECURITY

Troubleshooting ACLs
• Uno de los comandos de verificación de ACLs es el siguiente:
– Router# show access-lists [access-list-number | access-list-name]
– Este comando informa de los paquetes que han coincidido con las condiciones de la ACL
• Otro comando muy importante es “debug ip packet”
– Router# debug ip packet [access-list-number] [detail]
– Es un comando muy util para analizar el flujo de trafico entre hosts locales y remotos, con el
keyword detail obtenemos informacion adicional.
 CCNA SECURITY

Mitigar ataques con ACLs

• Las ACLs pueden mitigar ataques como por ejemplo:
– IP address spoofing, inbound y outbound
– Ataques DoS TCP SYN
– Ataques DoS smurf
• Los administradores suelen hacer ACLs que deniegan todo trafico que contiene las siguientes
direcciones origen (En tráfico proveniente del exterior de la LAN).
– Direcciones de host (127.0.0.0/8)
– Cualquier direccion privada (RFC 1918, Address Allocation for Private Internets)
– Cualquier direccion de multicast (224.0.0.0/4)
• Los hackers utilizan varios tipos de mensajes ICMP para atacar las redes.
– Pueden utilizar paquetes de eco ICMP para descubrir las subredes y los hosts en una red protegida
y para generar ataques de inundación DoS.
– Pueden utilizar mensajes de redirección ICMP para modificar las tablas de enrutamiento de host.
Tanto el eco ICMP y mensajes de redirección de entrada debe ser bloqueado por el router.
 CCNA SECURITY

Mitigar ataques con ACLs (y II)

• Tipo de tráfico (inbound) ICMP que se puede
permitir
– Echo reply - Permite a los usuarios hacer
ping a los hosts externos.
– Source quench - Pide al remitente
disminuir la tasa de tráfico de mensajes.
– Unreachable - Mensajes inalcanzable que
se generan debido a los paquetes
negados por una ACL.
• Tipo de tráfico (outbound) ICMP que se puede
permitir
– Echo - Permite a los usuarios hacer ping
a los hosts externos.
– Parameter Problem - Informa al host de
problemas de cabecera del paquete.
– Packet too big - Necesario para decubrir
el máximo de la unidad de transmisión de
paquetes (MTU).
– Source quench – Corta (Throttles down)
el tráfico cuando sea necesario.
• El resto del trafico ICMP podriamos denegarlo
 CCNA SECURITY

Tecnologías de Firewall
 CCNA SECURITY

Asegurar redes con Firewalls

• Un firewall es un sistema o grupo de sistemas que impone una política de
control de acceso entre redes.
• Características comunes a los Firewalls:
– Resistentes a los ataques
– Suponen el punto de tránsito entre las redes (todo el tráfico entre redes fluye
a través del firewall)
– Aplican una política de control de acceso
• En 1988 aparece el primer FW de filtrado de paquetes. Se filtra cada paquete
independientemente. Similar al filtrado de una ACL.
• El 1989 AT&T implementa el primer FW con filtrado con estado. El “stateful
firewall” es capaz de determinar si un paquete pertenece a un flujo de datos
existentes.
 CCNA SECURITY

Asegurar redes con Firewalls (y II)

• Ventajas de emplear FW:
– Se pueden bloquear datos y tráfico maliciosos entre de servidores y clientes.
– La aplicación de políticas de seguridad pueden ser simple, escalable y
robusta con un cortafuegos correctamente configurado.
– Se reduce la complejidad de la gestión de la seguridad.
• Inconvenientes de emplear FW:
– Supone un único punto de fallo.
– El rendimiento de la red se puede reducir.
 CCNA SECURITY

Tipos de Firewalls
• FW de filtrado de paquetes - Normalmente es un router con la capacidad de filtrar algún
contenido del paquete, como de nivel 3 y a veces de nivel 4.
• Stateful firewall - Monitoriza el estado de las conexiones, si la conexión está en la fase de
inicio, de transferencia de datos, o en la fase de terminación. (Opera en las capas 3, 4 y 5)
• Application Gateway cortafuegos (firewall proxy) - Un cortafuegos que filtra la información
a las capas 3, 4, 5 y 7 del modelo de referencia OSI. Se suele hacer por software.
• Adress Translation FW - Un servidor de seguridad que amplía el número de direcciones IP
disponibles y oculta el diseño del direccionamiento de la red interna.(Opera en las capas 3
y 4)
• FW Basado en host (servidor y personal) - Un software de FW que se ejecuta en un PC o
servidor.
• Firewall transparente - Un firewall que filtra el tráfico IP entre un par de interfaces de
puente.
• Firewall Hibrido - Un servidor de seguridad que es una combinación de los distintos tipos
de firewalls. Por ejemplo, un firewall de inspección de aplicación combina un cortafuegos
de estado con un firewall de aplicación.
 CCNA SECURITY

Tipos de Firewalls (y II)

• FW de filtrado de paquetes
– Primariamente trabajan en la capa 3 pero también pueden permitir o denegar tráfico
en función de información de capa 4 como números de puerto y protocolo (numero de
protocolo) y tipo de paquete. Suelen estar implementados dentro de Routers.
– Implementan sistemas de filtrado estáticos.
– Pueden emplear como criterio: Synchronize/start (SYN) packet receipt.
– Son susceptibles de sufrir IP spoofing.
– No son capaces de filtrar paquetes fragmentados los cuales llevan la cabecera TCP
en el primer fragmento , como consecuencia todos los fragmentos tras el primero
pasan los filtros incondicionalmente.
– Los servicios en los cuales al inicio de la sesión hay negociaciones dinámicas de
puertos no es posible filtrarlos con este tipo de FW.
– No implementan filtrado con estado.
 CCNA SECURITY

Tipos de Firewalls (y III)

• Stateful FW
– Son muy versátiles.
– Mantienen información de las conexiones en una tabla de estados.
– Se clasifica como de capa de red pero opera también en las capas 4 y 5.
– Analiza las conexiones al atravesar los interfaces del FW, para ello analiza las cabeceras de los paquetes y de los
segmentos de capa 4.
– Analiza la cabecera TCP y de paquetes de nivel 3 para ver el estado de la conexión
• Examina el encabezado TCP de sincronización (SYN)
• Reset (RST)
• Confirmación (ACK)
• Final (FIN), y otros códigos de control mediante los cuales es capaz de determinar el estado de la conexión.
– Cuando se accede a un servicio externo, el FW conserva ciertos detalles de la petición guardando el estado de la
solicitud en la tabla de estado. Cuando desde el exterior del sistema se responde a una solicitud, en el FW se
comparan los paquetes recibidos con el estado guardado para permitir o denegar el acceso a la red.
 CCNA SECURITY

Tipos de Firewalls (y III)

• Soluciones de seguridad
– Firewall de Cisco IOS (IOS con funciones de FW)
– PIX Security Appliance (fin de ciclo de vida)
– ASA (Adaptative Security Appliances – Dispositivos de Seguridad Adaptable)
• ASA forma parte de Cisco Self Defending Network protege redes de todos los tamaños e implementa funciones
de:
– Firewall
– Comunicaciones unificadas de voz y video de seguridad.
– SSL, IPSec, VPN, IPS y servicios de seguridad de contenido.
 CCNA SECURITY

Firewalls en el diseño de red

• Se define DMZ como una parte de una red limitada por un firewall o un conjunto de servidores de seguridad.
• Una DMZ define las partes de una red que son de confianza y las partes que no son de confianza.
• Un diseño sencillo es aquel en que hay una red externa (insegura y publica) y una red interna (segura y privada) , estas
redes están determinadas por dos interfaces en un servidor de seguridad (FW). En este caso, el tráfico desde el interior por
lo general permite atravesar el firewall hacia el exterior con poca o ninguna restricción y el tráfico que se origina desde el
exterior, normalmente se bloquea por completo o se permite de modo muy selectivo. El tráfico que regresa desde el exterior y
que está asociado con tráfico procedente de la parte interior se le permite atravesar el FW.
• Hay diseños más elaborados con tres zonas delimitadas: un interfaz “outside”, otro “inside”, y un tercer interfaz DMZ.
• En este caso el tráfico DMZ -> Outside este no se permite libremente.Está permitido tráfico de Outside a DMZ siempre y
cuando sean tráficos específicos como por ejemplo correo electrónico, DNS, HTTP, o tráfico HTTPS.
 CCNA SECURITY

Firewalls en el diseño de red (y II)

• En un escenario de defensa en capas, los firewalls proporcionar seguridad en el perímetro de toda la red y en los segmentos
de red interna en el núcleo.
• Un administrador debe tener en cuenta los siguientes factores a la hora de asegurar su sistema por ejemplo:
– Los cortafuegos a menudo hacen poco para proteger contra los virus que se descargan a través de correo electrónico.
– Los cortafuegos no sustituyen a los mecanismos de copia de seguridad y recuperación de desastres resultantes de un
ataque o fallo de hardware.
– En una defensa en profundidad se incluye el almacenamiento “offsite” y topologías de hardware redundantes.
 CCNA SECURITY

Control de Acceso Basado en el Contexto (CBAC)

 CCNA SECURITY

Características CBAC
• Opción disponible en Cisco IOS Firewall.
• Las CBAC filtran de manera inteligente paquetes TCP y UDP basándose en información de las sesiones de
protocolos de la capa de aplicación.
• Proporciona filtrado con estado de capa de aplicacion.
• Están especificamente diseñadas para filtrar tráfico así de aplicaciones multimedia y protocolos que
requieren de múltiples canales de comunicación tales como FTP y H.323.
• Las CBAC pueden bloquear aplicaciones de mensajería instantanea y aplicaciones P2P.
• Las CBACs ofrecen cuatro funciones principales: filtrado de tráfico, control de tráfico, detección de intrusos,
y generación de las auditorías y alertas.
• Filtrado de tráfico
– Una CBAC puede ser configurada para permitir tráfico TCP y UDP de retorno a través de un servidor
de seguridad cuando la conexión se inicia desde dentro de la red. Esto se logra mediante la creación
de aberturas temporales en una ACL que de lo contrario negaría el tráfico.
– Examinan información de la capa de transporte y de la capa de aplicación para conocer el estado de
la sesión. Como consecuencia se da soporte a protocolos que involucran múltiples canales creados
como resultado de las negociaciones en el canal de control.
– La mayoría de los protocolos de multimedia, así como algunos otros protocolos (como FTP, RPC, y
SQL) se refieren a múltiples canales.
 CCNA SECURITY

Características CBAC (y II)

• Inspección de tráfico:
– Al inspeccionar los paquetes de la capa de aplicación y mantener información de sesiones TCP y UDP se pueden
prevenir ataques de inundación SYN.
– Inspeccionando las numeraciones de secuencia en los paquetes TCP se protege ante ataques DOS.
• Detección de intrusos
– Protección frente a ataques específicos SMTP
– Detección de ataques mediante firmas o patrones
– Envía información a SYSLOG
• Alertas y generación de auditorias
– Se generan alertas en tiempo real.
– Seguimiento de las transacciones de red (puertos, direcciones, bytes tx y rx ...)
– Administración central de las consolas.
• Las CBACS aparecen en 1997 en Cisco IOS
• Mejoran las prestaciones de las ACL reflexivas y TCP established debido a varios aspectos.
– Monitorea el establecimiento de la conexión TCP
– Examina los números de secuencia TCP
– Inspecciona las consultas DNS y las respuestas
– Inspecciona los tipos de mensajes ICMP más comunes.
– Soporta aplicaciones que se basan en varios canales como FTP y multimedia.
– Inspecciona las direcciones incrustadas
– Inspecciona la información de la capa de aplicación
 CCNA SECURITY

Funcionamiento de las CBACs

• La tabla de estado hace un seguimiento de las sesiones e inspecciona todos los paquetes
que pasan por el firewall de filtrado de paquetes.
• A continuación la CBAC, utiliza la tabla de estado para construir entradas dinámicas ACL que
duran un tiempo específico y que permiten el retorno del tráfico a través del router o firewall
perímetral.
• El tráfico es de retorno está permitido sólo si es parte de la misma sesión y tiene las
propiedades se espera que el tráfico inicial que desencadenó CBAC al salir a través del
firewall.
• La tabla de estado cambia y se adapta dinámicamente con el flujo de tráfico.
 CCNA SECURITY

Funcionamiento de las CBACs (y II)

• En el paso 3: la información de conexión se compara con las entradas en la tabla de estado.

Si la conexión no existe actualmente, se añade la entrada. Si existe, el temporizador de
inactividad para la conexión se restablece.
• En el paso 4: La apertura temporal sólo se activa durante el tiempo que la sesión está abierta.
Estas entradas dinámicas ACL no se guardan en la memoria NVRAM.
 CCNA SECURITY

Funcionamiento de las CBACs (y III)

• Las entradas temporales de las ACLs se crean como al inspeccionar el tráfico que sale de la
red y se eliminan cuando termina la conexión o el tiempo de espera de inactividad de la
conexión se ha alcanzado.
• Como en el caso de las ACL reflexivas, el administrador puede especificar qué protocolos se
inspeccionan, así como el interfaz y en qué dirección se produce la inspección.
• Las CBACs son flexibles en la elección de la dirección en la que se inspecciona el tráfico.
– En una configuración típica las CBAC se utilizan en el router perimetral o firewall para
permitir el retorno de tráfico en la red.
– Las CBACs también pueden ser configuradas para inspeccionar el tráfico en dos
direcciones - dentro y fuera. Esto es útil cuando interesa la protección de redes en
ambos lados puesto que hosts en ambas redes pueden iniciar ciertas conexiones y
permitir que el tráfico vuelva a las fuentes correspondientes.
 CCNA SECURITY

Funcionamiento de las CBACs (y III)

• CBAC TCP Handling
– TCP usa un saludo a tres vías.
– Como determina una CBAC que un paquete pertenece a una sesión ya establecida: Lo hace puesto
que cuando se transmite el paquete TCP SYN el segundo paquete contiene un numero de secuencia
de confirmación y un numero de secuencia aleatorio que ha generado la maquina destino. El tercer
paquete reconoce el paquete recibido (por el incremento en la confirmación).
 CCNA SECURITY

Funcionamiento de las CBACs (y IV)

• En las CBAC la inspección se especifica mediante reglas de inspección.
• Una regla de inspección se aplica a un interfaz en una dirección.
• Los PKTs que coincidan con la regla de inspección generan una entarda de ACL dinámica
que permitirá al trñafico retornar, y si por el contrario un PKT es negado por la ACL de
inspección el PKT es descartado.
• El Cisco IOS FW puede detectar ciertos tipos de ataques a nivel de aplicación y en
cosnecuencia realizar ciertas accciones:
– Generacion de mensajes de alerta.
– Proteger los recursos del sistema para que no decaiga el rendimiento.
– Bloquear los PKTs de los resuntos atacantes.
• Los valores “timeout” y “treshold” permiten controlar el tiempo que duran las sesiones tras un
tiempo de espera o en el caso de que no hayan sido plenamente establecidas.
• Para controlar ataques DOS se pueden controlar los siguientes parámetros:
– Numero de sesiones semiabiertas TCP
– Numero de sesiones semiabiertas en un intervalo de tiempo
– Numero de sesiones semiabiertas por maquina
 CCNA SECURITY

Funcionamiento de las CBACs (y V)

• Si se superan los umbrales anteriores el FW toma alguna de las siguientes medidas:
– Envia un mensaje de RESET a los extremo de las conexiones en las que las sesiones semiabiertas son mas viejas.
Haciendo de este modo que esos recursos queden libres para atender nuevas conexiones.
– Bloqueo de todos los paquetes SYN temporalmente en consecuencia no se incian saludos a tres vias.
 CCNA SECURITY

Configuración de las CBACs

• Para crear una CBAC son necesarios los siguientes pasos:
– Elegir un interface interno o externo.
– Configurar una ACL IP en dicho interfaz.
– Definir las normas o reglas de inspección.
– Aplicar una regla de inspección al interfaz.
 CCNA SECURITY

Configuración de las CBACs (y II)

• Elegir un interface interno o externo.
– La interfaz en la que se inician las sesiones se denomina interfaz interna. En
consecuencia el concepto de interna/externa se refiere a la dirección la
conversación.
– Por ejemplo en un escenario con tres interfaces
• Interfaz 1: red externa
• Interfaz 2: DMZ
• Interfaz 3: red interna
• Puede interesar permitir solo el acceso a servicios WEB y FTP en DMZ.
– CBAC puede ser configurado en dos direcciones y en uno o varios interfaces.
– Si buscamos proteger las redes de ambos lados las CBAC se aplicaran en
ambas direcciones.
 CCNA SECURITY

Configuración de las CBACs (y III)

• Configurar de la ACL IP en el interfaz seleccionado
– Las ACL se pueden configurar en un interfaz para tráfico entrante, saliente o
ambos.
– El administrador debe definir una ACL para controlar el tráfico de los protocolos
que le interese inspeccionar, asimismo deberá crear ACLs que explícitamente
no permitan el tráfico que el administrador decida.
– Si se desea inspeccionar un determinado tipo de tráfico dicho tráfico debe
permitirse en todas las ACLs que se aplican al flujo de dicho tráfico.
– Para implementar protecciones antispoofing es recomendable denegar
cualquier tráfico entrante (en una interfaz externa) de una dirección de origen
que coincida con una dirección de la red protegida.
– También es una buena política prohibir mensajes de difusión con dirección de
origen 255.255.255.255.
 CCNA SECURITY

Configuración de las CBACs (y IV)

• Definición de las reglas de inspección
– El administrador debe definir las reglas de inspección para especificar los
protocolos de capa de aplicación a inspeccionar en una interfaz. Normalmente,
sólo es necesario definir una regla de inspección. Pero en ocasiones se
establecen dos reglas de inspección una en cada dirección en un interfaz.
– Una regla de inspección debe especificar el protocolo de capa de aplicación
que se desea inspeccionar.
– Las reglas de inspección incluyen opciones para el control de alertas y
mensajes de auditoría.
– La sintaxis del comando es:
• Router(config)# ip inspect name inspection_name protocol [alert {on | off}]
[audit-trail {on | off}] [timeout seconds]
– Ejemplo de una regla de inspección que inspecciona el tráfico de SMTP y FTP
y que genera mensajes de alerta e informacion de auditoria.
• ip inspect name FWRULE smtp alert on audit-trail on timeout 300
• ip inspect name FWRULE ftp alert on audit-trail on timeout 300
 CCNA SECURITY

Configuración de las CBACs (y V)

• Si no se emplea el keyword “alert {on | off}” en la regla de inspección la generación
de mensajes de alerta se hace o no en función del comando “ip inspect alert-off”.
• Del mismo modo si no se selecciona ninguna opción con el keyword “audit-trail
{on|off}” los mensajes de auditoria se generan o no se generan en función del
comando “ip inspect audit-trail”.
• El keyword “timeout” de una regla de inspección permite especificar un timeout de
inactividad que sobrescribe los timeouts especificados para los protocolos TCP y
UDP pero no lo hace para el timeout de DNS.
• Otro ejemplo de reglas de inspección:
– La regla PERMIT_JAVA permite a todos los usuarios que son permitidos por la
ACL standard 10 descargar Java applets.
• ip inspect name PERMIT_JAVA http java-list 10
• access-list 10 permit 10.224.10.0 0.0.0.255
 CCNA SECURITY

Configuración de las CBACs (y VI)

• Aplicación de una regla de inspección a un interfaz.
• La sintaxis es la siguiente:
– Router(config-if)# ip inspect inspection_name {in | out}
• Hay dos principios fundamentales para la aplicación de normas de inspección y
ACL en el router:
– En la interfaz donde se inicia el tráfico, aplicar una ACL en dirección IN que
permita solo el tráfico buscado y aplicar la regla en dirección IN que
inspeccione el tráfico buscado.
– En otras interfaces, aplicar una ACL en dirección IN que deniegue todo el
tráfico, excepto el tráfico que no ha sido inspeccionado por el firewall.
 CCNA SECURITY

Configuración de las CBACs (y VII)

• Ejemplo:
– Creamos una ACL que permite sesiones TCP,
UDP, e ICMP y deniega el resto.
• R1(config)# access-list 101 permit tcp
10.10.10.0 0.0.0.255 any
• R1(config)# access-list 101 permit udp
10.10.10.0 0.0.0.255 any
• R1(config)# access-list 101 permit icmp
10.10.10.0 0.0.0.255 any
• R1(config)# access-list 101 deny ip any
any
– La asociamos al interfaz Inside fa0/0
• R1(config)# interface Fa0/0
• R1(config-if)# ip access-group 101 in
 CCNA SECURITY

Configuración de las CBACs (y VIII)

• Continuación del Ejemplo:
– Creamos una ACL extendida en la que se permite el tráfico SMTP y HTTP
desde Outside a DMZ y el resto del tráfico se deniega.
• R1(config)# access-list 102 permit tcp any 209.165.201.1 0.0.0.0 eq 80
• R1(config)# access-list 102 permit tcp any 209.165.201.2 0.0.0.0 eq smtp
• R1(config)# access-list 102 permit icmp any any echo-reply
• R1(config)# access-list 102 permit icmp any any unreachable
• R1(config)# access-list 102 permit icmp any any administratively-prohibited
• R1(config)# access-list 102 permit icmp any any packet-too-big
• R1(config)# access-list 102 permit icmp any any echo
• R1(config)# access-list 102 permit icmp any any time-exceeded
• R1(config)# access-list 102 deny ip any any
– La asociamos al interfaz Outside en direccion IN
• R1(config)# interface S0/0/0
• R1(config-if)# ip access-group 102 in
 CCNA SECURITY

Configuración de las CBACs (y VIII)

• Continuación del Ejemplo:
– Creamos las reglas de inspección para el tráfico TCP y UDP.
• R1(config)# ip inspect name MYSITE tcp
• R1(config)# ip inspect name MYSITE udp
– Estas reglas de inspección se aplican al interfaz INSIDE en direccion IN.
• R1(config)# interface Fa0/0
• R1(config-if)# ip inspect MYSITE in
– Las reglas de inspección crean automaticamente sentencias ACL temporales en la ACL
aplicada al interfaz externo para trafico IN y conexiones TCP y UDP. De este modo se
permite el tráfico TCP y UDP de respuesta a las peticiones generadas en el interior.
– Para desactivar las CBACs del router podemos empelar el comando “no ip inspect “ que
elimina todas las CBAC, la tabla de estados y todas las entradas de ACL creadas por la
CBAC. También resetea todos los timeouts y threshold a sus valores por defecto.
– Al eliminar las CBACs los procesos de inspeccion ya no estan disponibles y las ACLs se
emplean solo para filtrar.
 CCNA SECURITY

Troubleshooting CBACs
• Las CBACs generan dos tipos de loggings: alertas y auditorias.
• Alertas
– Las alertas muestran informacion acerca de insuficiencia de recursos en el router,
ataques DOS y otras amenazas.
– Las alertas están habilitadas por defecto, para deshabilitarlas tenemos el comando “ip
inspect alert-off”.
– Tambien es posible habilitar o deshabilitar alertas por regla de inspeccion.
– Ejemplo de alerta:
• %FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator
• (209.165.201.5:49387)
• Auditorias
– Las funciones de auditoría realizan un seguimiento de las conexiones que inspecciona la
CBAC, incluidos los intentos de acceso válidos y no válidos.
– Por ejemplo, muestra mensajes cuando una CBAC agrega o quita una entrada de la
tabla de estado.
– La auditoría está desactivada por defecto, pero puede ser activado con el comando “ip
inspect audit-trail”
 CCNA SECURITY

Troubleshooting CBACs (y II)

• Auditorias (Continuación)
– Un ejemplo de auditoria como consecuencia de una conexion de telnet iniciada desde
192.1.1.2 es:
• %FW-6-SESS_AUDIT_TRAIL: tcp session
• initiator (192.168.1.2:32782) sent 22 bytes
• responder (209.165.201.1:23) sent 200 bytes
– Si quisieramso enviar los logs de auditoria a un syslog emplearíamos los siguientes
comandos.
 CCNA SECURITY

Troubleshooting CBACs (y III)

• Existen comandos que permiten ver las entradas temporales creadas por una CBAC, la tabla
de estadosy el fucnionamiento de al propia CBAC.
• Para ver la información acerca de inspecciones CBAC, utilice el comando
– “Router# show ip inspect [parameter]
 CCNA SECURITY

Troubleshooting CBACs (y IV)

• Ejemplos:
– El comando “Router# show ip inspect name inspect_outbound” muestra las siguiente
información
• Inspection name inspect_outbound
• cuseeme alert is on audit-trail is on timeout 3600
• ftp alert is on audit-trail is on timeout 3600
• http alert is on audit-trail is on timeout 3600
• rcmd alert is on audit-trail is on timeout 3600
• realaudio alert is on audit-trail is on timeout 3600
• smtp max-data 20000000 alert is on audit-trail is on timeout 3600
• tftp alert is on audit-trail is on timeout 30
• udp alert is on audit-trail is on timeout 15
• tcp alert is on audit-trail is on timeout 3600
 CCNA SECURITY

Troubleshooting CBACs (y V)
• Ejemplos:
– El comando “Router# show ip inspect sessions” muestra las siguiente información
• Established Sessions
• Session 25A3378 (209.165.201.1:20)=>(192.168.1.2:32704) ftp-data SIS_OPEN
• Session 25A5AC2 (192.168.1.2:32703)=>(209.165.201.1:21) ftp SIS_OPEN
• El comando “show ip access-list” muestra las entradas dinamicas creadas por la ACL
extendida entrante
– Router# show ip access-list
• Extended IP access list 100
• permit tcp host 209.165.201.1 eq 21 host 192.168.1.2 eq 32703 (24 matches)
• permit tcp host 209.165.201.1 eq 20 host 192.168.1.2 eq 32704 (88 matches)
 CCNA SECURITY

Troubleshooting CBACs (y VI)

• Cuando buscamos información mucho mas detallada pordemos emplear el comando “debug
ip inspect”
 CCNA SECURITY

Zone-Based Policy Firewall

 CCNA SECURITY

Características Zone-Based Policy Firewall (ZPF)

• En 2006, Cisco Systems presentó el modelo de configuración de FW con politica

basada en zonas con Cisco IOS Release 12.4 (6) T.
• Con este modelo, las interfaces se asignan a zonas y una política de inspección se
aplica al tráfico que se desplaza entre las zonas.
• Se pueden aplicar diferentes políticas de inspección a grupos de host conectados
al mismo interfaz del router.
• La configuration de las politicas de FW se realiza mediante el lenguaje Cisco
Common Classification Policy Language (C3PL) que emplea una estructura
jerárquica para definir la inspección de protocolo de red y permite el agrupamiento
de hosts bajo una política de inspección.
• Aparentemente hay similitudes entre las CBAC y ZPF pero la diferencia
fundamental está en el hecho de que las CBAC tienen una configuracion y
documentacion compleja y engorrosa mientras que la configuracion de ZPF es facil
de realizar.
 CCNA SECURITY

Características Zone-Based Policy Firewall (ZPF) (y II)

• Ventajas de ZPF :
– No dependen de la ACL.
– La postura de seguridad del router es bloquear a menos que un tráfico esté
explícitamente permitido.
– Las políticas son fáciles de leer y resolver problemas con C3PL.
– Una política afecta a todo el tráfico dado, en lugar de necesitar múltiples ACL y
las acciones de inspección.
• En el mismo router podemos emplear CBACs y ZPF pero no al mismo tiempo en el
mismo interfaz.
 CCNA SECURITY

Características Zone-Based Policy Firewall (ZPF) (y III)

• Diseño de ZPF
– Paso 1: El administrador se centra en la separación de la infraestructura en
zonas.
– Paso 2. Establecer políticas entre las zonas. Para cada Pareja de zonas
“origen-destino" se definen los períodos de sesiones que los clientes en las
zonas de origen, puede solicitar de los servidores en las zonas de destino. El
administrador debe definir los flujos de tráfico unidireccional desde el origen al
destino y viceversa.
– Paso 3: Diseño de la infraestructura física - Después de las zonas han sido
identificadas y los requisitos de tráfico entre ellos documentados, el
administrador debe diseñar la infraestructura física, teniendo en cuenta la
seguridad y disponibilidad.
– Paso 4. Identificar subgrupo dentro de las zonas y combinar las necesidades
del tráfico.
 CCNA SECURITY

Características Zone-Based Policy Firewall (ZPF) (y IV)

• Ejemplos de Diseño ZPF
 CCNA SECURITY

Funcionamiento de Zone-Based Policy Firewall (ZPF)

• Las acciones que puede realizar ZPF son las siguientes:
– Inspect- Configura la inspección de paquetes con estado Cisco IOS. Lo cual es
equivalente a ejecutar el comando CBAC “ip inspect” el cual permitirá el tráfico
de retorno. En el caso de los protocolos que empelan varios canales el
comando también se encarga de inspeccionar el establecimiento adecuado de
las sesiones de datos.
– Drop - similar a una declaración de negación en una ACL. Podemos empelar la
opción LOG para registrar los paquetes rechazados.
– Pass - análogo a una clausula “permit” en una ACL. En este caso no se realiza
el seguimiento del estado de las conexiones. En este caso se permite el tráfico
en la dirección de ida para permitir el trafico de vuelta habrá que aplicar una
política de retorno de trafico.
 CCNA SECURITY

Funcionamiento de Zone-Based Policy Firewall (ZPF) (y II)

• Reglas de asignación de interfaces a zonas
– Hay que configurar la zona antes de asignar interfaces a dicha zona.
– Si hay flujo de trafico entre todos los interfaces de un router cada interfaz debe
ser miembro de una zona.
– Un interfaz solo puede ser miembro de una zona
– Por defecto el trafico entre interfaces de la misma zona esta permitido
– Para permitir el tráfico hacia y desde un interfaz miembro de una zona,
debemos configurar una política que permita la inspección del tráfico entre esa
zona y cualquier otra zona.
– No puede fluir trafico entre un interfaz miembro de una zona y cualquier
interfaz que no sea miembro de una zona.
– A los interfaces que no son miembros de una zona les podemos aplicar CBACs
– Si un administrador no desea que un interfaz del router sea parte de una zona
pero aun asi tiene que incluirlos en una zona puede configurar una politica
“pass-all” (también conocido como política ficticia) entre a esa zona y cualquier
otra zona a la que se desea realizar flujo de tráfico.
 CCNA SECURITY

Funcionamiento de Zone-Based Policy Firewall (ZPF) (y III)

• Las reglas para ZPF son diferentes cuando el router está involucrado en el flujo de tráfico.
Mas concretamente las normas dependerán de si el router es la fuente o el destino del tráfico.
• Cuando una interfaz está configurado para ser un miembro de la zona, los hosts que están
conectados a dicho interfaz se incluyen en la zona, pero el tráfico que fluye hacia y desde las
interfaces del router no está controlado por las políticas de la zona.
• Todas las interfaces IP en el router automáticamente forman parte de la propia zona (self
zone).
• Las políticas pueden ser configuradas para bloquear, permitir o inspeccionar el tráfico entre la
zona y la zona propia zona del router, y viceversa.
• Todo el tráfico hacia y desde un interfaz dada está implícitamente bloqueado cuando el
interfaz está asignado a una zona, excepto el tráfico hacia o desde otras interfaces de la
misma zona y el tráfico a cualquier interfaz en el router.
• La única excepción al enfoque de negar por defecto es el tráfico hacia y desde el router. Este
tráfico es permitido por defecto. Se puede definir una política explícita que permita restringir
ese tráfico.
 CCNA SECURITY

Configurar Zone-Based Policy Firewall (ZPF) con CLI

• Paso 1: Crear las zonas con el comando “zone security”.
• Paso 2: Definir las clases de tráfico con el comando “class-map type inspect”.
• Paso 3: Especificar politicas de Firewall con el comando “policy-map type inspect”.
• Paso 4. Aplicar politicas de FW a parejas de zonas origen y destino usando el comando “zone-pair
security”.
• Paso 5. Asignar interfaces del router a zonas mediante el comando “zone-member security interface”.
• Limitaciones
– Con el comando “zone-pair security” solo se pueden usar mapas creados con “type inspect”
– No puede haber superposicion de nombres entre los class maps y los policy maps
– Para emplear “zone member security” previamente debe estar creada con “zone secutity”
– Un interfaz no puede pertenecer a multiples zonas.
– Si ZPF reemplaza a CBAC es necesario eliminar la CBAC con “ip inspect” antes de aplicar “zone-
member security”
– Si queremos coexistencia de CBAC y ZPF el interfaz al que se aplica “ip inspect” no puede formar
parte de zonas de seguridad.
• Las CBAC crean dinámicamente entradas de ACL, ZPF no cambia ACLs
 CCNA SECURITY

Configurar Zone-Based Policy Firewall (ZPF) con CLI (y II)

• Crear zonas: Lo ideal es agrupar interfaces similares bajo la optica de la seguridad, con
necesidades de seguridad similares.
– Router(config)# zone security zone-name
– Router(config-sec-zone)# description line-of-description
 CCNA SECURITY

Configurar Zone-Based Policy Firewall (ZPF) con CLI (y III)

• Definir clases de tráfico:
– Router(config)# class-map type inspect [match-any | match-all] class-map-name
– Cuando se especifican clases de trafico a nivel de las capas 3 y 4 la clausula “match-any”
es el comportamiento predeterminado y en este caso la sintaxis del comando es:
• Router(config)# class-map type inspect protocol-name [match-any | match-all] class-
map-name
– La sintaxis para referenciar ACLs desde un Class Map es:
• Router(config-cmap)# match access-group {access-group | name access-group-
name}
– Para especificar protocolos en el Map Class empleamos:
• Router(config-cmap)# match protocol protocol-name
– Incluso es posible anidar Map Class a través de la siguiente sintaxis.
• Router(config-cmap)# match class-map class-map-name
– De este modo es posible crear jerarquías en las clases de tráfico
 CCNA SECURITY

Configurar Zone-Based Policy Firewall (ZPF) con CLI (y IV)

• Especificar políticas del FW
– Una vez que el tráfico coincide con una clase de trafico es necesario decidir que hacer:
pass, inspect, drop y police.
– La sintaxis para crear Policy MAPS es:
• Router(config)# policy-map type inspect policy-map-name
– Mediante Policy Maps se especifica la accion a realizar cuando un tráfico coincide con
una clase de tráfico.
• Router(config-pmap)# class type inspect class-name
– La clase predeterminada (con la que coincide el resto del trafico) se especifica:
• Router(config-pmap)# class class-default
– Al final es necesario especificar la accion que se le aplica al trafico mediante el comando:
• Router(config-pmap-c)# pass | inspect | drop [log] | police
 CCNA SECURITY

Configurar Zone-Based Policy Firewall (ZPF) con CLI (y V)

• Aplicar politicas de FW
– Una vez que la politica ha sido configurada se aplica a parejas de zonas mediante el comando: “zone
pair security”
– Antes hay que crear la politica y especificar la zona origen, la zona destino y la politica de gestion de
trafico entre ellas.
• Router(config)# zone-pair security zone-pair-name [source source-zone-name | self] destination
[self | destination-zone-name]
– Podemos usar el comando “service-policy type inspect policy-map-name” para asociar una Policy
MAP y las acciones asociadas a una pareja de zonasmediante el comando “zone-pair security”.
• Asignar interfaces:
– Para asignar un interfaz a una zona emplearemos el comando
• Router(config-if)# zone-member security zone-name
• Para permitir trafico a traves de este interfaz es encesario aplicar una politica.
 CCNA SECURITY

Fin de la Presentación del Capítulo 4