1. RESOLUCION DE
PROBLEMAS DE CBAC

2. • La inspección CBAC soporta dos tipos de funciones de
registro: alertas y auditorías
• Las alertas muestran mensajes relacionados con la
operación de CBAC, como :
• Recursos insuficientes del router,
• ataques de DoS
• y otras amenazas.
• Las alertas están habilitadas por defecto y se muestran
automáticamente en la consola del router.
• El administrador puede deshabilitar las alertas
globalmente, aunque es altamente recomendable que
las alertas permanezcan habilitadas.
• Router(config)# ip inspect alert-off

3. • El administrador puede deshabilitar y habilitar las
alertas por regla de inspección; sin embargo, es
altamente recomendable que las alertas
permanezcan habilitadas.
• Ejemplo de una alerta que informa que alguien
está intentando enviar un comando SMTP no
aprobado a un servidor de correo electrónico:
%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP
command from initiator (209.165.201.5:49387)

4. • CBAC puede detectar otros tipos de ataques SMTP:
• Envío de un pipe (|) en los campos To o From de un
mensaje de correo electrónico
• Envío de :decode@ en el encabezado del mensaje de
correo electrónico
• Uso de los viejos comandos SMTP wiz y debug en el puerto
SMTP
• Ejecución de comandos arbitrarios para explotar una falla
en el programa de correo electrónico Majordomo.

5. • Este es un ejemplo de una alerta generada
cuando un hacker trata de explotar la falla SMTP
de Majordomo:
• 02:04:55: %FW-4-TCP_MAJORDOMO_EXEC_BUG:
Sig:3107:
• Majordomo Execute Attack - from 209.165.201.5 to
192.168.1.1:

6. AUDITORÍAS
• Las auditorías monitorean las conexiones que el
CBAC inspecciona, incluyendo intentos de acceso
válidos y no válidos.
• Por ejemplo, muestra cuando CBAC agrega o
elimina una entrada de la tabla de estados.
• El registro de auditoría proporciona información
estadística básica sobre la conexión.
• La auditoría está deshabilitada por defecto, pero
puede ser habilitada con el siguiente comando:
• Router(config)# ip inspect audit-trail

7. • Por ejemplo, este mensaje de auditoría se crea
para una conexión telnet iniciada por 192.1.1.2:
• %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
• Por defecto, las alertas y auditorías se muestran en
la línea de consola.
• Esta información puede ser registrada en otros
lugares, incluyendo el buffer interno del router o un
servidor syslog externo.

9. • CBAC soporta muchos comandos show que pueden ser
usados para ver las entradas temporales creadas en
una ACL, la tabla de estados y la operación de CBAC.
• Para ver información sobre las inspecciones CBAC, use
el comando show ip inspect.
• Router# show ip inspect [parameter]
• La siguiente salida del comando muestra las reglas de
inspección configuradas para la regla de inspección
inspect_outbound.
• Esta regla inspecciona tráfico TCP y UDP, ambos con sus
tiempos de vencimiento por inactividad en los valores
por defecto.

10. Router# show ip inspect name inspect_outbound
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

11. • En el siguiente ejemplo, la tabla de estados tiene
dos entradas: 192.168.1.2 es dentro de la red y
209.165.201.1 es fuera de ella.
• La segunda entrada muestra al dispositivo interno
abrir una conexión a un servidor FTP externo.
• La primera conexión muestra la conexión de datos
que el servidor FTP abrió con el cliente interno.
• Así se muestra la creación dinámica de entradas
ACL en la ACL extendida de entrada.
• El comando show ip access-list muestra las
entradas ACL creadas dinámicamente por la ACL
extendida de entrada

12. Router# show ip inspect sessions
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
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)
<output omitted>

13. • Hay dos entradas ACL dinámicas que permiten el
tráfico de retorno del servidor FTP, 209.165.201.1, al
cliente FTP, 192.168.1.1.

14. • Para una resolución de problemas de CBAC
detallada, el administrador puede usar los
comandos debug, que le permiten ver en tiempo
real cómo opera CBAC en el router.
• El comando debug ip inspect puede inspeccionar
varias aplicaciones y otros detalles de operación.
• Router# debug ip inspect protocol parameter

15. • Los nombres de aplicaciones que deben usarse
para la inspección son cuseeme, dns, ftpcmd, ftp-
token, h323, http, netshow, rcmd, realaudio, rpc,
rtsp, sip, skinny, smtp, sqlnet, streamworks, tftp y
vdolive.
• Esta salida del comando debug ip inspect timers
permite al administrador determinar, entre otras
cosas, cuándo se alcanzan los vencimientos por
inactividad.

16. C A R A C T E R I S T I C A S D E L F I R E W A L L D E P O L I T I C A
B A S A D A E N Z O N A S
FIREWALL DE POLITICA
BASADA EN ZONAS

17. • Las interfaces son asignadas a zonas y luego se
aplica una política de inspección al tráfico que se
mueve entre las zonas.
• El firewall basado en zonas permite la aplicación
de diferentes políticas de inspección a múltiples
grupos de hosts conectados a la misma interfaz del
router.
• Asimismo, tiene la habilidad de prohibir tráfico por
medio de una política de deny-all por defecto
entre las zonas del firewall.

18. • El firewall de inspección de política basada en
zonas (ZPF o ZBF o ZFW) soporta las funciones de
firewalls anteriores, incluyendo inspección de
paquetes con estados, inspección de aplicaciones,
filtrado de URL y mitigación de ataques de DoS.
• Las políticas de firewall se configuran usando el
Cisco Common Classification Policy Language
(C3PL), que utiliza una estructura jerárquica para
definir la inspección del protocolo de red y permite
a los hosts agruparse bajo una sola política de
inspección

20. • El enfoque estructurado es útil para documentación y
comunicación.
• La facilidad de uso hace que las implementaciones de
seguridad en redes sean más accesibles a una
comunidad más grande de profesionales de la
seguridad.
• Implementar CBAC es complejo y puede ser
abrumador.
• A diferencia de ZPF, CBAC no utiliza ninguna estructura
de datos jerárquica para modularizar la
implementación.
• CBAC tiene las siguientes limitaciones:
• Las múltiples políticas de inspección y ACLs en varias interfaces
del router dificultan la correlación de las políticas del tráfico
entre múltiples interfaces.
• Las políticas no pueden asociarse a un grupo de hosts o
subred con una ACL.
• Todo el tráfico que pasa por una interfaz dada está sujeto a la
misma inspección.
• El proceso depende demasiado de las ACLs.

21. • Las zonas establecen las fronteras de seguridad en una
red.
• La zona en sí define una frontera en la que el tráfico
está sujeto a restricciones de políticas cuando cruza a
otra región de la red.
• La política por defecto entre las zonas es de denegar
todo.
• Si no se configura una política explícitamente, todo el
tráfico que intente moverse entre las zonas será
bloqueado.
• Esta es una desviación importante del modelo CBAC en
el que el tráfico estaba permitido implícitamente hasta
que fuera explícitamente bloqueado con una ACL.

22. • Aunque muchos comandos ZPF aparentan ser
similares a los comandos CBAC, no son iguales.
• Otro cambio significativo es la introducción del
Cisco Common Classification Policy Language
(C3PL).
• Este nuevo lenguaje de configuración de políticas
facilita un enfoque modular sobre la
implementación de firewalls.

23. • Algunos de los beneficios de ZPF incluyen los
siguientes:
• No depende de ACLs.
• La postura de seguridad del router es de bloquear salvo
que sea explícitamente permitido.
• Las políticas son de fácil lectura y resolución de problemas
con C3PL.
• Una política afecta cualquier tráfico dado, en lugar de
necesitar múltiples ACLs y acciones de inspección.

24. • Al decidir si implementar CBAC o zonas, debe
tomarse en cuenta que ambos modelos de
configuración pueden ser habilitados
concurrentemente en el router.
• Sin embargo, los modelos no pueden ser
combinados en la misma interfaz: una interfaz no
puede ser configurada para inspección IP y como
un miembro de una zona de seguridad al mismo
tiempo.

26. EL DISEÑO DE FIREWALLS BASADOS EN
ZONAS INVOLUCRA ALGUNOS PASOS:
PASO1
• Determinar las zonas –
• La infraestructura de internetworking en cuestión debe
ser dividida en zonas con diferentes niveles de
seguridad.
• El administrador no considera la implementación física
del firewall (número de dispositivos, profundidad de la
defensa, redundancia, etc), sino que se concentra en la
separación de la infraestructura en zonas.
• Por ejemplo, la red pública a la que la red interna se
conecta es una zona.

27. PASO 2
• Establecimiento de políticas entre las zonas –
• Para cada par de zonas "origen destino« (por ejemplo, desde
la red interna hacia Internet), defina la sesión que los clientes
en las zonas de origen pueden solicitar de los servidores en las
zonas de destino.
• Estas sesiones son generalmente sesiones TCP y UDP, pero
también pueden ser sesiones ICMP como un eco ICMP.
• Para el tráfico que no está basado en el concepto de
sesiones, como IPsec Encapsulating Security Payload [ESP], el
administrador debe definir flujos de tráfico unidireccionales
del origen al destino y viceversa.
• Como en el paso 1, este paso se ocupa de los requerimientos
de tráfico entre las zonas, no de la configuración física.

28. PASO 3
• Diseño de la infraestructura física –
• Luego de identificar las zonas y documentar los
requerimientos de tráfico, el administrador debe
diseñar la infraestructura física tomando en cuenta
los requerimientos de seguridad y disponibilidad.
• Esto incluye la estimación del número de
dispositivos entre las zonas más seguras y las menos
seguras y la determinación de dispositivos
redundantes.

29. PASO 4
• Identificación de subconjuntos en las zonas y fusión
de requerimientos de tráfico –
• En cada dispositivo firewall del diseño, el
administrador debe identificar subconjuntos en las
zonas conectadas a sus interfaces y unir los
requerimientos de tráfico en esas zonas.
• Por ejemplo, múltiples zonas pueden estar
asociadas indirectamente con una sola interfaz en
el router, resultando en una política interzona
específica del dispositivo.

30. • Algunos diseños ZPF comunes son un firewall LAN-a-
Internet, un firewall con servidores públicos, firewalls
redundantes y firewalls complejos