Reforzar los dispositivos IOS

Introducción

Este documento describe cómo proteger sus dispositivos del sistema Cisco IOS^® y aumentar la seguridad general de su red.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Background

Al proteger los dispositivos del sistema Cisco IOS, aumenta la seguridad general de la red.

La seguridad general de la red se estructura en torno a los tres planos en los que se pueden categorizar las funciones de un dispositivo de red. Los tres planos funcionales de una red son: el plano de gestión, el plano de control y el plano de datos. Cada plano proporciona una funcionalidad diferente que debe protegerse. Este documento proporciona una descripción general de cada función incluida y referencias a la documentación relacionada.

• Plano de administración: El plano de administración administra el tráfico enviado al dispositivo Cisco IOS y se compone de aplicaciones y protocolos, como Secure Shell (SSH) y el protocolo simple de administración de red (SNMP).
  
  
• Plano de control: El plano de control de un dispositivo de red procesa el tráfico que es crucial para mantener en funcionamiento la infraestructura de la red. El plano de control consta de aplicaciones y protocolos entre dispositivos de red, como el protocolo de gateway fronterizo (BGP), así como los protocolos de gateway interior (IGP). También se incluyen el protocolo de routing de gateway interior mejorado (EIGRP) y la ruta de acceso más corta primero (OSPF).
  
  
• Plano de datos: Reenvía datos mediante un dispositivo de red. El plano de datos no incluye el tráfico enviado al dispositivo Cisco IOS local.

Las funciones de seguridad que se tratan en este documento suelen proporcionar suficientes detalles para configurar la función descrita. Sin embargo, cuando no hay detalles disponibles, la función se explica de tal manera que se puede evaluar si se requiere atención adicional a la función. Siempre que sea posible y apropiado, este documento contiene recomendaciones que, si se implementan, ayudan a proteger una red.

Operaciones de Seguridad

Las operaciones de seguridad de la red constituyen un tema primordial. Aunque la mayor parte de este documento trate sobre la configuración segura de un dispositivo Cisco IOS, las configuraciones solas no aseguran totalmente una red. Los procedimientos operativos que se utilizan en la red contribuyen tanto a la seguridad como a la configuración de los dispositivos subyacentes.

Estos temas contienen las recomendaciones operativas que se le aconseja implementar. Estos temas resaltan áreas fundamentales específicas de las operaciones de la red y no son exhaustivos.

Monitoreo de Boletines y Respuestas de Seguridad de Cisco

El Equipo de Respuesta a Incidentes de Seguridad en Productos Cisco (PSIRT) crea y mantiene publicaciones, comúnmente conocidas como boletines de PSIRT, para los problemas relacionados con la seguridad en productos Cisco. El método usado para la comunicación de problemas de menor gravedad es Respuesta de Seguridad de Cisco. Las respuestas y los consejos de seguridad están disponibles en Cisco Security Advisories.

Hay información adicional sobre estos medios de comunicación disponible en la Política de Vulnerabilidad de Seguridad de Cisco.

Para mantener una red segura, tenga en cuenta las respuestas y los consejos de seguridad de Cisco que se han publicado. Debe tener conocimiento de una vulnerabilidad para que se pueda evaluar la amenaza que representa para una red. Consulte Clasificación de riesgos para los anuncios de vulnerabilidades de seguridad para obtener ayuda en este proceso de evaluación.

Aprovechamiento de Autenticación, Autorización y Contabilización

El marco de trabajo de autenticación, autorización y auditoría (AAA) es vital para proteger los dispositivos de redes. El protocolo AAA proporciona autenticación de las sesiones de administración y puede también limitar a los usuarios a comandos específicos definidos por el administrador y registrar todos los comandos ingresados por cada usuario. En la sección Autenticación, autorización y auditoría de este documento, hallará más información sobre cómo aprovechar el AAA.

Centralización del proceso de recopilación y supervisión de registros

Para obtener información sobre los eventos actuales, emergentes e históricos relacionados con los incidentes de seguridad, su organización debe tener una estrategia unificada para los registros de eventos y la correlación. Esta estrategia unificada debe aprovechar los registros de todos los dispositivos de red y utilizar capacidades de correlación preempaquetadas y personalizables.

Una vez implementados los registros centralizados, debe desarrollar un enfoque estructurado para el análisis de registros y el seguimiento de incidentes. De acuerdo con las necesidades de su organización, este método puede ser una simple revisión minuciosa de datos de registro e, incluso, un análisis avanzado basado en reglas.

Vea la sección Prácticas Recomendadas de Registro de este documento para obtener más información sobre cómo implementar registros en los dispositivos de red de Cisco IOS.

Uso de Protocolos de Seguridad Siempre Que Sea Posible

Se utilizan varios protocolos para transportar datos confidenciales de administración de redes. Utilice protocolos seguros siempre que sea posible. Una opción de protocolo seguro incluye el uso de SSH, en lugar de Telnet, para que los datos de autenticación y la información de administración se cifren. Además, utilice protocolos de transferencia de archivos seguros al copiar datos de configuración. Un ejemplo es el uso del protocolo Secure Copy Protocol (SCP) en lugar de FTP o de TFTP. 

Consulte la sección Proteja las sesiones de administración interactiva de este documento para ver más información sobre la administración segura de los dispositivos Cisco IOS.

Netflow para Visibilidad del Tráfico

NetFlow le permite supervisar los flujos de tráfico en la red. NetFlow se diseñó originalmente para exportar información de tráfico a aplicaciones de administración de redes y también se puede utilizar para mostrar información de flujo en un router. Gracias a esta capacidad, usted puede ver el momento en que el tráfico cruza la red en tiempo real. Independientemente de si la información de flujo se exporta o no a un colector remoto, se recomienda configurar los dispositivos de red para NetFlow de modo que se puedan utilizar de forma reactiva si es necesario.

Puede encontrar más información sobre esta función en la sección Identificación y Seguimiento del Tráfico de este documento y en Cisco IOS NetFlow.

Nota: Solo los usuarios registrados de Cisco tienen acceso a la información y las herramientas internas.

Administración de la Configuración

La administración de la configuración es un proceso mediante el cual se proponen, revisan, aprueban e implementan cambios de configuración. En el contexto de la configuración de un dispositivo Cisco IOS, dos aspectos adicionales de la administración de la configuración son críticos: el archivado de la configuración y la seguridad.

Utilice los archivos de configuración para revertir los cambios realizados en los dispositivos de red. En un contexto de seguridad, los archivos de configuración también se pueden utilizar para determinar qué cambios de seguridad se realizaron y cuándo se produjeron. Junto con los datos de registro AAA, esta información puede ayudar en la auditoría de seguridad de los dispositivos de red.

La configuración de un dispositivo Cisco IOS contiene muchos detalles confidenciales. Los nombres de usuario, las contraseñas y el contenido de las listas de control de acceso son ejemplos de esta información confidencial. Es necesario proteger el repositorio utilizado para archivar las configuraciones de dispositivos de Cisco IOS. El acceso inseguro a esta información puede disminuir la seguridad de toda la red.

Plano de Administración

El plano de administración consiste en funciones que permiten alcanzar las metas de administración de la red. Esto incluye las sesiones de administración interactiva que emplean SSH y también recopilación de estadísticas con SNMP o NetFlow. Cuando se tiene en cuenta la seguridad de un dispositivo de red, es fundamental que el plano de gestión esté protegido. Si un incidente de seguridad puede socavar las funciones del plano de gestión, puede ser imposible recuperar o estabilizar la red.

Estas secciones del documento abordan en detalle las funciones y las configuraciones de seguridad disponibles en Cisco IOS Software que ayudan a fortalecer el plano de administración.

Consolidación del Plano de Administración General

El plano de gestión se utiliza para acceder, configurar y gestionar un dispositivo, así como para supervisar sus operaciones y la red en la que está implementado. El plano de administración recibe y envía tráfico para las operaciones de estas funciones. Proteja tanto el plano de gestión como el plano de control de un dispositivo, ya que las operaciones del plano de control afectan directamente a las operaciones del plano de gestión. Estos protocolos utilizados por el plano de administración incluyen:

• Simple Network Management Protocol
• TELNET
• Secure Shell Protocol
• File Transfer Protocol
• Protocolo de transferencia de hipertexto / Protocolo de transferencia de hipertexto seguro

• Trivial File Transfer Protocol
• Secure Copy Protocol
• TACACS+
• RADIUS
• Netflow
• Network Time Protocol
• Syslog

Se deben tomar medidas para garantizar la supervivencia de los planos de administración y de control durante incidentes de seguridad. Si alguno de estos planos se explota con éxito, todos los planos pueden verse comprometidos.

Administración de Contraseña

Las contraseñas controlan el acceso a recursos o a dispositivos. Esto se logra a través de la contraseña utilizada para autenticar las solicitudes. Cuando se recibe una solicitud de acceso a un recurso o dispositivo, se desafía a la solicitud para que verifique la contraseña y la identidad, y el acceso se puede conceder, denegar o limitar según el resultado. Como práctica recomendada de seguridad, las contraseñas se deben administrar con un servidor de autenticación TACACS+ o RADIUS. Sin embargo, aún se necesita una contraseña configurada localmente para el acceso privilegiado en caso de falla de los servicios TACACS+ o RADIUS. Un dispositivo puede también tener otra información de contraseña presente dentro de su configuración, como un clave NTP, una comunidad SNMP o una clave de Protocolo de Ruteo.

El enable secret comando se utiliza para establecer la contraseña que otorga acceso administrativo privilegiado al sistema Cisco IOS. Se debe utilizar elenable secretcomando, en lugar delenable passwordcomando anterior. enable passwordutiliza un algoritmo de cifrado débil.

Si no enable secret se establece ninguna contraseña y se configura una contraseña para la línea tty de la consola, la contraseña de la consola se puede utilizar para recibir acceso privilegiado, incluso desde una sesión tty virtual (vty) remota. Esta acción es casi seguro indeseada y es otro motivo por el cual se debe asegurar la configuración de un comando enable secret.

El comando de configuración service password-encryption global indica al software Cisco IOS que cifre las contraseñas, los secretos del Protocolo de autenticación por desafío mutuo (CHAP) y datos similares que se guardan en su archivo de configuración. Este cifrado es útil para evitar que los observadores ocasionales observen las contraseñas, como cuando miran la pantalla sobre el hombro de un administrador. Sin embargo, el algoritmo utilizado por el service password-encryption comando es un simple cifrado Vigen re. El algoritmo no ha sido diseñado para proteger los archivos de configuración contra el grave análisis de, incluso, atacantes poco sofisticados y no debe ser utilizado con este fin. Cualquier archivo de configuración de Cisco IOS que contenga contraseñas cifradas debe tratarse con el mismo cuidado que se utiliza para una lista de texto sin formato de esas mismas contraseñas.

Aunque este algoritmo de cifrado débil no es utilizado por el enable secret comando, lo utiliza el comando de configuración enable password global, así como el comando de configuración de password línea. Este tipo de contraseñas debe eliminarse y se debe utilizar el enable secret comando o la función Enhanced Password Security.

Elenable secretcomando y la función Enhanced Password Security utilizan Message Digest 5 (MD5) para el hash de contraseñas. Este algoritmo ha tenido considerable revisión pública y no es reversible. Sin embargo, el algoritmo está sujeto a ataques de diccionario. En un ataque de diccionario, un atacante intenta cada palabra de un diccionario u otra lista de contraseñas candidatas para encontrar una coincidencia. Por lo tanto, los archivos de configuración se deben guardar con seguridad y compartir solamente con individuos de confianza.

Enhanced Password Security

La función Enhanced Password Security, introducida en Cisco IOS Software Release 12.2(8)T, permite a un administrador configurar el hash MD5 de contraseñas para elusernamecomando. Antes de esta función, había dos tipos de contraseñas: Tipo 0, que es una contraseña de texto sin cifrar, y Tipo 7, que utiliza el algoritmo del cifrado Vigen re. La función Enhanced Password Security no se puede utilizar con protocolos que exigen que la contraseña de texto sin formato sea recuperable, como CHAP.

Para cifrar una contraseña de usuario con hash MD5, ejecute el comando de configuración username secret global.

!

username <name> secret <password>

!

Login Password Retry Lockout

La función de bloqueo tras intentos fallidos de inicio de sesión agregada en la versión del software Cisco IOS 12.3(14)T le permite bloquear las cuentas de usuarios locales tras una cantidad configurable de intentos fallidos de inicio de sesión. Una vez que un usuario ha sido bloqueado, su cuenta queda bloqueada hasta que la desbloquee. Un usuario autorizado configurado con el nivel de privilegio 15 no se puede bloquear con esta función. Mantenga el número de usuarios con el nivel de privilegio 15 al mínimo.

Tenga en cuenta que los usuarios autorizados pueden bloquear su propio acceso a un dispositivo si alcanza el número configurado de intentos de inicio de sesión fallidos. Además, un usuario malicioso puede crear una condición de negación de servicio con intentos repetidos de autenticación con un nombre de usuario válido.

Este ejemplo muestra cómo habilitar la función Login Password Retry Lockout:

!

aaa new-model
aaa local authentication attempts max-fail <max-attempts>
aaa authentication login default local

!

username <name> secret <password>

!

Esta función también se aplica a los métodos de autenticación, como CHAP y el protocolo de autenticación de contraseña (PAP).

No Service Password-Recovery

En Cisco IOS Software Release 12.3(14)T y en versiones posteriores, la función No Service Password-Recovery no permite que ningún usuario con acceso a la consola acceda de manera insegura a la configuración del dispositivo y borre la contraseña. Tampoco permite que usuarios maliciosos cambien el valor del registro de configuración y accedan a NVRAM.

!

no service password-recovery

!

El software Cisco IOS proporciona un procedimiento de recuperación de contraseña que se basa en el acceso al modo de supervisión de ROM (ROMMON) que utiliza la tecla de interrupción durante el inicio del sistema. En ROMMON, el software del dispositivo se puede recargar para solicitar una nueva configuración del sistema que incluya una nueva contraseña.

El procedimiento de recuperación de la contraseña actual permite que cualquier usuario con acceso a la consola acceda al dispositivo y a su red. La función de no recuperación de contraseña de servicio impide el empleo de la secuencia de la tecla Interrumpir y el ingreso a ROMMON durante la fase de inicio.

Si no service password-recovery está habilitado en un dispositivo, se recomienda guardar una copia sin conexión de la configuración del dispositivo e implementar una solución de archivado de la configuración. Si es necesario recuperar la contraseña de un dispositivo Cisco IOS una vez que se habilita esta función, se elimina la configuración completa.

Consulte Ejemplo de configuración de ROMMON segura para ver más información sobre esta función.

Inhabilitación de Servicios No Utilizados

Como práctica recomendada de seguridad, desactive cualquier servicio innecesario. Los servicios innecesarios, especialmente aquellos que utilizan el protocolo UDP (User Datagram Protocol), no se utilizan con frecuencia para fines legítimos, pero se pueden utilizar para iniciar DoS y otros ataques que, de lo contrario, se evitarían mediante el filtrado de paquetes.

Desactive los servicios pequeños TCP y UDP. Estos servicios incluyen:

• echo (número del puerto 7)
  
  
• discard (número de puerto 9)
  
  
• daytime (número de puerto 13)
  
  
• chargen (número de puerto 19)

Aunque el abuso de los servicios pequeños puede evitarse o hacerse menos peligroso mediante listas de acceso antisimulación, desactive los servicios en cualquier dispositivo accesible dentro de la red. De forma predeterminada, los servicios pequeños están inhabilitados en Cisco IOS Software Releases 12.0 y versiones posteriores. En el software anterior, se pueden ejecutar los comandos de configuración no service tcp-small-servers y no service udp-small-servers global para desactivarlos.

Los servicios adicionales que se deben inhabilitar, si no se usan, incluyen:

• Ejecute elno ip fingercomando de configuración global para inhabilitar el servicio Finger. De forma predeterminada, las versiones del software del IOS de Cisco posteriores a las 12.1(5) y 12.1(5)T desactivan este servicio.
• Ejecute elno ip bootp servercomando de configuración global para inhabilitar el Protocolo de Bootstrap (BOOTP).
• En Cisco IOS Software Release 12.2(8)T y posteriores, ejecute el comando ip dhcp bootp ignore en el modo de configuración global para inhabilitar BOOTP. De esta manera, quedan habilitados los servicios de Dynamic Host Configuration Protocol (DHCP).
• Los servicios de DHCP pueden ser inhabilitados si no se necesitan los servicios de retransmisión de DHCP. Ejecute el comando no service dhcp en modo de configuración global.
• Ejecute el comando no mop enabled en el modo de configuración de la interfaz para deshabilitar el servicio de protocolo de operación de mantenimiento (MOP).
• Ejecute el comando de configuración global no ip domain-lookup para inhabilitar los servicios de resolución del Sistema de nombres de dominio (DNS).
• Ejecute el comando no service pad en el modo de configuración global para inhabilitar el servicio Packet Assembler/Disassembler (PAD), que se utiliza para las redes X.25.
  El servidor HTTP puede desactivarse con el comando no ip http server en el modo de configuración global, mientras que el servidor HTTP seguro (HTTPS) puede desactivarse con el comando de configuración global no ip http secure-server.
  A menos que los dispositivos Cisco IOS recuperen las configuraciones de la red durante el inicio, se debe utilizar el comando de configuración no service config. Esto impide que el dispositivo Cisco IOS intente hallar un archivo de configuración en la red con TFTP.
  Cisco Discovery Protocol (CDP) es un protocolo de red que se utiliza para detectar otros dispositivos con CDP activado para la adyacencia de vecinos y la topología de red. CDP puede ser utilizado por Network Management Systems (NMS) o mientras se produce el aislamiento de problemas. El CDP debe estar inhabilitado en todas las interfaces conectadas a redes no confiables. Para ello, ejecute el comando de interfaz no cdp enable. De manera alternativa, el CDP se puede inhabilitar globalmente con el comando de configuración global no cdp run. Tenga en cuenta que un usuario malintencionado puede utilizar CDP para el reconocimiento y la asignación de una red.
• El protocolo LLDP (Link Layer Discovery Protocol) es un protocolo IEEE definido en 802.1AB y es similar al CDP. Sin embargo, este protocolo permite la interoperabilidad entre los otros dispositivos que no admiten CDP. LLDP debe recibir el mismo tratamiento que CDP y se debe inhabilitar en todas las interfaces que se conecten con redes no confiables. Para lograr esto, ejecute los comandos de configuración de interfaz no lldp transmit y no lldp receive. Ejecute el comando de configuración global no lldp run para inhabilitar LLDP globalmente. Un usuario malintencionado también puede utilizar LLDP para el reconocimiento y la asignación de una red.

• Para los switches que admiten el inicio desde sdflash, la seguridad se puede mejorar para arrancar desde flash y deshabilitar sdflash con el comando de configuración "no sdflash".

Tiempo de Espera de EXEC

Para establecer el intervalo, el intérprete de comandos EXEC espera la entrada del usuario antes de terminar una sesión, ejecute el comando de configuración de línea exec-timeout. Utilice el comando exec-timeout para cerrar las sesiones en las líneas vty o tty que se dejan inactivas. De manera predeterminada, las sesiones se desconectan tras diez minutos de inactividad.

!

line con 0
 exec-timeout <minutes> [seconds]
line vty 0 4
 exec-timeout <minutes> [seconds]
!

Keepalives para Sesiones TCP

Los comandos de configuración global service tcp-keepalives-in y service tcp-keepalives-out permiten que un dispositivo envíe keepalives de TCP para sesiones de TCP. Utilice esta configuración para habilitar señales de mantenimiento TCP en las conexiones entrantes al dispositivo y las conexiones salientes del dispositivo. Esto garantiza que el dispositivo en el extremo remoto de la conexión siga siendo accesible y que las conexiones semiabiertas o huérfanas se eliminen del dispositivo Cisco IOS local.

!

service tcp-keepalives-in
service tcp-keepalives-out
!

Uso de la interfaz de administración

Al plano de administración de un dispositivo se accede en banda o fuera de banda en una interfaz de administración física o lógica. Idealmente, existe acceso de administración tanto en banda como fuera de banda para cada dispositivo de red, de modo que se pueda acceder al plano de administración durante las interrupciones de la red.

Una de las interfaces más comunes utilizadas para el acceso en banda a un dispositivo es la interfaz lógica de loopback. Las interfaces Loopback nunca dejan de funcionar, mientras que las interfaces físicas pueden cambiar de estado y quizá no se pueda acceder a la interfaz. Se recomienda agregar una interfaz de loopback a cada dispositivo como interfaz de administración y utilizarla exclusivamente para el plano de administración. Esto permite que el administrador aplique las políticas en toda la red para el plano de administración. Una vez configurada la interfaz de loopback en un dispositivo, los protocolos del plano de administración, como SSH, SNMP y syslog, pueden utilizarla para enviar y recibir tráfico.

!
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!

Notificaciones de Umbrales de Memoria

La función Memory Threshold Notification, agregada en Cisco IOS Software Release 12.3(4)T, le permite mitigar las condiciones de memoria baja en un dispositivo. Esta función utiliza dos métodos para lograr esto: Memory Threshold Notification y Memory Reservation.

Memory Threshold Notification genera un mensaje de registro para indicar que la memoria libre de un dispositivo ha caído por debajo del umbral configurado. Este ejemplo de configuración muestra cómo habilitar esta función con el comando de configuración global memory free low-watermark. Este comando habilita a un dispositivo para que genere una notificación cuando la memoria libre disponible se reduce por debajo del umbral especificado y para que vuelva a generar una notificación cuando la memoria libre disponible aumenta en un cinco por ciento más que el umbral especificado.

!

memory free low-watermark processor <threshold>
memory free low-watermark io <threshold>
!

La reserva de memoria se utiliza para que haya suficiente memoria disponible para las notificaciones críticas. En este ejemplo de configuración se muestra cómo habilitar esta característica para garantizar que los procesos de administración continúen funcionando cuando se agota la memoria del dispositivo.

!

memory reserve critical <value>
!

Consulte Memory Threshold Notifications para obtener más información sobre esta función.

Notificación de Umbrales de CPU

Introducida en Cisco IOS Software Release 12.3(4)T, la función CPU Thresholding Notification le permite detectar y recibir notificaciones cuando la carga de la CPU en un dispositivo cruza un umbral configurado. Cuando se supera el umbral, el dispositivo genera y envía un mensaje de trampa SNMP. El software Cisco IOS admite dos métodos de umbral de uso de CPU: Umbral ascendente y Umbral descendente.

Este ejemplo de configuración muestra cómo habilitar los umbrales ascendente y descendente para activar un mensaje de notificación de umbral de CPU:

!

snmp-server enable traps cpu threshold
!

snmp-server host <host-address> <community-string> cpu 
!

process cpu threshold type <type> rising <percentage> interval <seconds> 
     [falling <percentage> interval <seconds>]
process cpu statistics limit entry-percentage <number> [size <seconds>]
!

Consulte CPU Thresholding Notification para obtener más información sobre esta función.

Memoria de Reserva para Acceso a a Consola

En Cisco IOS Software Release 12.4(15)T y posteriores, la función Reserve Memory for Console Access se puede utilizar para reservar suficiente memoria para asegurar el acceso de la consola a un dispositivo Cisco IOS con fines administrativos y de aislamiento de problemas. Esta función es especialmente útil cuando el dispositivo se queda sin memoria. Puede ejecutar el comando de configuración global memory reserve console para habilitar esta función. En este ejemplo se configura un dispositivo Cisco IOS para reservar 4096 kilobytes con este fin.

!
memory reserve console 4096
!

Detector de Fugas de memoria

Introducida en Cisco IOS Software Release 12.3(8)T1, la función Memory Leak Detector le permite detectar agotamiento de memoria en un dispositivo. Memory Leak Detector puede encontrar fugas en todos los agrupamientos de memoria, buffers de paquetes y fragmentos. El agotamiento de memoria es la asignación estática o dinámica de la memoria que no responde a ningún propósito útil. Esta función se centra en las asignaciones de memoria que son dinámicas. Puede utilizar el comando EXEC show memory debug leaks para detectar si existe una pérdida de memoria.

Desbordamiento de búfer: detección y corrección de la corrupción en las zonas rojas

En Cisco IOS Software Release 12.3(7)T y posteriores, la función Buffer Overflow: Detection and Correction of Redzone Corruption se puede habilitar en un dispositivo para detectar y corregir un desbordamiento de bloque de memoria y continuar con las operaciones.

Los comandos de configuración global se pueden utilizar para habilitar esta función. Una vez configurado, el comando show memory overflow se puede utilizar para mostrar las estadísticas de detección y corrección del desbordamiento del búfer.

!
exception memory ignore overflow io
exception memory ignore overflow processor
!

Enhanced Crashinfo File Collection

La función Enhanced Crashinfo File Collection elimina automáticamente los viejos archivos crashinfo. Esta función, agregada en Cisco IOS Software Release 12.3(11)T, permite que un dispositivo recupere espacio para crear nuevos archivos crashinfo cuando el dispositivo colapsa. Esta función también permite configurar el número de archivos crashinfo que se van a guardar.

!
exception crashinfo maximum files <number-of-files>
!

Network Time Protocol

El protocolo de tiempo de la red (NTP) no es un servicio peligroso, pero cualquier servicio innecesario puede representar un vector de ataque. Si se utiliza el protocolo NTP, es importante configurar explícitamente un origen de hora confiable y utilizar la autenticación adecuada. Se requiere un tiempo preciso y confiable para fines de syslog, como durante las investigaciones forenses de ataques potenciales, así como para la conectividad VPN exitosa cuando depende de certificados para la autenticación de la Fase 1.

• Zona horaria NTP: Al configurar NTP, es necesario configurar la zona horaria para que las marcas de tiempo se puedan correlacionar con precisión. Existen dos métodos típicos para configurar la zona horaria de los dispositivos en una red con presencia global. Un método es configurar todos los dispositivos de red con el Tiempo Universal Coordinado (UTC), previamente conocido como Tiempo Medio de Greenwich (GMT). El otro método es configurar los dispositivos de red con la zona horaria local. Podrá encontrar más información sobre esta función en "huso horario del reloj" en la documentación del producto de Cisco.
  
  
• Autenticación de NTP: Si configura la autenticación de NTP, se garantiza que los mensajes de NTP se intercambien entre pares de NTP confiables.

Ésta es una configuración de ejemplo que utiliza autenticación NTP:

Cliente:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5
(config)#ntp server 172.16.1.5 key 5

Servidor:

(config)#ntp authenticate
(config)#ntp authentication-key 5 md5 ciscotime
(config)#ntp trusted-key 5

Desactive Smart Install

Las prácticas recomendadas de seguridad en torno a la función Cisco Smart Install (SMI) dependen de cómo se utilice la función en un entorno de usuario específico. Cisco distingue entre estos casos de uso:

• Usuarios que no utilizan la función SMI.
• Usuarios que aprovechan la función SMI solo para la implementación sin intervención del usuario.
• Usuarios que aprovechan la función Smart InstallSMI para una implementación que no requiere la intervención del usuario (configuración y gestión de imágenes).

En estas secciones se describen en detalle los escenarios:

• Usuarios que no utilizan la función SMI.
• Los usuarios que no utilizan la función SMI y ejecutan una versión del software Cisco IOS y Cisco IOS XE donde el comando está disponible, pueden inhabilitar la función SMI con el comando no vstack.

Nota: El comando vstack se introdujo en Cisco IOS Release 12.2(55)SE03.

Este es un ejemplo de salida del comando show vstack en un Cisco Catalyst Switch con la función de cliente SMI inhabilitada:

switch# show vstack 
config Role: Client (SmartInstall disabled) 
Vstack Director IP address: 0.0.0.0

Clientes que aprovechan la función SMI solo para la implementación sin intervención del usuario

Inhabilite la funcionalidad del cliente SMI después de que se complete la instalación sin intervención del usuario o utilice el comando no vstack.

Para propagar el comando no vstack en la red, utilice uno de estos métodos:

• Ingrese el comando no vstack en todos los switches de cliente, ya sea manualmente o con un script.
• Agregue el comando no vstack como parte de la configuración de Cisco IOS que se inserta en cada cliente SMI como parte de la instalación sin intervención del usuario.
• En las versiones que no admiten el comando vstack (Cisco IOS Release 12.2(55)SE02 y versiones anteriores), aplique una lista de control de acceso (ACL) en los switches cliente para bloquear el tráfico en el puerto TCP 4786.

Para habilitar la funcionalidad de cliente SMI más adelante, ingrese el comando vstack en todos los switches de cliente, ya sea manualmente o con un script.

Clientes que aprovechan la función SMI para una implementación sin intervención del usuario

En el diseño de una arquitectura SMI, tenga cuidado para que el espacio de la dirección IP de la infraestructura no sea accesible para las partes no confiables. En las versiones que no admiten el comando vstack, asegúrese de que sólo el director SMI tenga conectividad TCP con todos los clientes SMI en el puerto 4786.

Los administradores pueden utilizar estas prácticas recomendadas de seguridad para las implementaciones de SMI en los dispositivos afectados:

• ACL de interfaz
• Políticas del plano de control (CoPP). Esta función no está disponible en todas las versiones del software Cisco IOS.

Este ejemplo muestra una ACL de interfaz con la dirección IP del director SMI como 10.10.10.1 y la dirección IP del cliente SMI como 10.10.10.200:

ip access-list extended SMI_HARDENING_LIST
Permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786
deny tcp any any eq 4786
permit ip any any

Esta ACL debe implementarse en todas las interfaces IP de todos los clientes. También puede ser empujado por el director cuando los switches se implementan por primera vez.

Para restringir aún más el acceso a todos los clientes de la infraestructura, los administradores pueden utilizar estas prácticas recomendadas de seguridad en otros dispositivos de la red:

• Listas de control de acceso a la infraestructura (iACL)
• Listas de control de acceso a la VLAN (VACL)

Acceso limitado a la red mediante ACL de infraestructura

Las iACL, diseñadas para evitar la comunicación directa no autorizada a dispositivos de red, son uno de los controles de seguridad más importantes que se implementan en las redes. Una iACL aprovecha la idea de que casi todo el tráfico de red atraviesa la red y no está destinado a la propia red.

Una iACL se construye y se aplica para especificar las conexiones de los hosts o de las redes que necesitan ser permitidas para los dispositivos de red. Ejemplos comunes de estos tipos de conexión son eBGP, SSH y SNMP. Después de que se hayan permitido las conexiones necesarias, el resto del tráfico a la infraestructura se niega explícitamente. Todo el tráfico de tránsito que cruza la red y no se dirige a los dispositivos de la infraestructura se permite explícitamente.

Las iACL ofrecen protecciones que son relevantes tanto para el plano de administración como para el plano de control. La implementación de iACL se puede facilitar mediante el uso de direcciones distintas para los dispositivos de infraestructura de red. Consulte Enfoque Orientado a la Seguridad para el Direccionamiento IP para obtener más información sobre las implicaciones de seguridad de las direcciones IP.

Este ejemplo de configuración de iACL ilustra la estructura que se debe utilizar como punto de inicio al iniciar el proceso de implementación de iACL:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit required connections for routing protocols and
!--- network management
!

 permit tcp host <trusted-ebgp-peer> host <local-ebgp-address> eq 179
 permit tcp host <trusted-ebgp-peer> eq 179 host <local-ebgp-address>
 permit tcp host <trusted-management-stations> any eq 22
 permit udp host <trusted-netmgmt-servers> any eq 161
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Una vez creada, la iACL se debe aplicar a todas las interfaces que se encuentran con dispositivos que no forman parte de la infraestructura, que incluyen las interfaces que se conectan con otras organizaciones, segmentos de acceso remoto, segmentos de usuario y segmentos en centros de datos.

Consulte Protección del Núcleo: Listas de Control de Acceso para Protección de Infraestructura para obtener más información sobre las ACL de Infraestructura.

Filtrado de Paquetes ICMP

Internet Control Message Protocol (ICMP) ha sido diseñado como protocolo de control de IP. Como tal, los mensajes que transmite pueden tener una interacción significativa con los protocolos TCP e IP en general. Mientras que las herramientas de red, ping y traceroute, para resolver problemas utilizan ICMP, rara vez se necesita conectividad ICMP externa para el funcionamiento correcto de la red.

Cisco IOS Software proporciona una función para filtrar mensajes ICMP específicamente por nombre o tipo y código. Esta ACL de ejemplo, que se debe utilizar con las entradas de control de acceso (ACE) de los ejemplos anteriores, permite pings de estaciones de administración y de servidores NMS confiables y bloquea el resto de los paquetes ICMP:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Permit ICMP Echo (ping) from trusted management stations and servers
!

 permit icmp host <trusted-management-stations> any echo
 permit icmp host <trusted-netmgmt-servers> any echo
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Filtrar fragmentos IP

El proceso de filtrado para paquetes IP fragmentados puede ser un desafío para los dispositivos de seguridad. Esto se debe a que la información de la Capa 4 utilizada para filtrar los paquetes TCP y UDP sólo está presente en el fragmento inicial. Cisco IOS Software utiliza un método específico para revisar los fragmentos no iniciales en relación con las listas de acceso configuradas. El software Cisco IOS evalúa estos fragmentos no iniciales contra la ACL e ignora cualquier información filtrada de la Capa 4. Esto hace que los fragmentos no iniciales sean evaluados solamente en la parte de la Capa 3 de cualquier ACE configurada. 

En esta configuración de ejemplo, si un paquete TCP destinado a 192.168.1.1 en el puerto 22 se fragmenta en tránsito, el fragmento inicial se descarta según lo esperado por la segunda ACE, según la información de la Capa 4 dentro del paquete. Sin embargo, todos los fragmentos (no iniciales) que quedan son permitidos por la primera ACE, basada completamente en la información de la Capa 3 en el paquete y la ACE. Este escenario se muestra en esta configuración:

!

ip access-list extended ACL-FRAGMENT-EXAMPLE
 permit tcp any host 192.168.1.1 eq 80
 deny tcp any host 192.168.1.1 eq 22
!

Debido a la naturaleza no intuitiva del manejo de fragmentos, las ACL suelen permitir fragmentos IP inadvertidamente. La fragmentación se utiliza a menudo para intentar eludir la detección por parte de los sistemas de detección de intrusiones. Por estas razones, los fragmentos IP se utilizan a menudo en ataques y por qué deben filtrarse explícitamente en la parte superior de cualquier iACL configurada. Esta ACL de ejemplo incluye la filtración completa de fragmentos IP. La funcionalidad de este ejemplo debe utilizarse con la funcionalidad de los ejemplos anteriores.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Consulte Listas de control acceso y fragmentos de IP para ver más información sobre cómo actúan las ACL ante los paquetes de IP fragmentados.

Soporte ACL para Filtrar las Opciones IP

La versión 12.3(4)T del software del IOS de Cisco agregó soporte para el uso de ACL para filtrar paquetes IP, según las opciones IP contenidas en el paquete. Las opciones IP representan un desafío de seguridad para los dispositivos de red porque se deben procesar como paquetes de excepción. Esto requiere un nivel de esfuerzo de CPU no necesario para los paquetes típicos que atraviesan la red. La presencia de opciones IP dentro de un paquete también puede indicar un intento de subvertir los controles de seguridad en la red o alterar de alguna otra manera las características de tránsito de un paquete. Por estas razones, los paquetes con opciones IP deben filtrarse en el borde de la red.

Este ejemplo se debe utilizar con las ACE de los ejemplos anteriores para incluir el filtrado completo de paquetes IP que contienen opciones IP:

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Filtrado en ACL por el valor de TTL

Cisco IOS Software Release 12.4(2)T agregó un filtro de soporte ACL de paquetes IP, basado en el valor de Tiempo de vida (TTL). Los dispositivos de red reducen el valor TTL de un datagrama IP a medida que un paquete fluye del origen al destino. Aunque los valores iniciales varían según el sistema operativo, cuando el TTL de un paquete llega a cero, el paquete debe ser descartado. El dispositivo que reduce el valor TTL a cero y que por lo tanto descarta el paquete debe generar y enviar un mensaje de tiempo de vida superado ICMP al origen del paquete.

La generación y la transmisión de estos mensajes es un proceso de excepción. Los routers pueden realizar esta función cuando el número de paquetes IP que van a caducar es bajo, pero si el número de paquetes que van a caducar es alto, la generación y transmisión de estos mensajes puede consumir todos los recursos de CPU disponibles. Esto genera un vector de ataque de negación de servicio. Por esta razón, los dispositivos deben ser reforzados contra los ataques de DoS que utilizan una alta tasa de paquetes IP, que están a punto de caducar.

Se recomienda que las organizaciones filtren los paquetes IP con valores TTL bajos en el borde de la red. La filtración completa de paquetes con valores TTL insuficientes para atravesar la red mitiga la amenaza de ataques basados en TTL.

En este ejemplo, ACL filtra paquetes con valores TTL inferiores a seis. De esta manera se protege a las redes de hasta cinco saltos de ancho contra los ataques basados en el vencimiento de TTL.

!

ip access-list extended ACL-INFRASTRUCTURE-IN
!
!--- Deny IP packets with TTL values insufficient to traverse the network
!

 deny ip any any ttl lt 6
!
!--- Deny all other IP traffic to any network device
!

 deny ip any <infrastructure-address-space> <mask>
!
!--- Permit transit traffic
!

 permit ip any any
!

Nota: Algunos protocolos hacen un uso legítimo de paquetes con valores TTL bajos. eBGP es uno de esos protocolos. Consulte Identificación y Mitigación de Ataques por Vencimiento de TTL para obtener más información para mitigar los ataques basados en el vencimiento de TTL.

Proteja las sesiones de administración interactiva

Las sesiones de administración de los dispositivos permiten ver y recopilar información sobre un dispositivo y sus operaciones. Si esta información se revela a un usuario malintencionado, el dispositivo puede convertirse en el objetivo de un ataque, ponerse en peligro y utilizarse para realizar ataques adicionales. Cualquier persona con acceso privilegiado a un dispositivo tiene la capacidad para el control administrativo completo de ese dispositivo. Es imprescindible proteger las sesiones de gestión para evitar la divulgación de información y el acceso no autorizado.

Management Plane Protection

En Cisco IOS Software Release 12.4(6)T y versiones posteriores, la función Management Plane Protection (MPP) permite a un administrador imponer restricciones en las diferentes interfaces del tráfico de administración que recibe un dispositivo. De esta manera, el administrador tiene control adicional sobre un dispositivo y el modo de acceso a él.

Este ejemplo muestra cómo habilitar la función MPP para permitir solamente SSH y HTTPS en la interfaz GigabitEthernet0/1:

!

control-plane host
  management-interface GigabitEthernet 0/1 allow ssh https
!

Consulte Management Plane Protection para más información sobre esta función.

Nota: MPP no admite IPv6 y está restringido a la ruta de entrada IPv4. Dado que IPv6 no se filtra, utilice CoPP en entornos IPv4/IPv6 mixtos.

Función Control Plane Protection

La protección del plano de control (CPPr) se basa en la funcionalidad de la política del plano de control para restringir y controlar el tráfico del plano de control que se dirige al procesador de rutas del dispositivo Cisco IOS. Agregado en Cisco IOS Software Release 12.4(4)T, CPPr divide el plano de control en categorías de plano de control separadas, conocidas como subinterfaces. Existen tres subinterfaces de plano de control: Host, Transit y CEF-Exception. Además, CPPr incluye estas funciones de protección del plano de control:

• Función de filtrado de puertos: permite al administrador controlar o descartar paquetes que van a puertos UDP y TCP cerrados o sin escucha.
  
  
• Función de política de umbral de cola: Limita el número de paquetes para un protocolo especificado permitido en la cola de entrada IP del plano de control.

CPPr permite a un administrador clasificar, controlar y restringir el tráfico enviado a un dispositivo con fines de administración con la subinterfaz del host. Algunos ejemplos de paquetes clasificados para la categoría de subinterfaz de host son el tráfico de administración, como SSH o Telnet y los protocolos de ruteo.

Nota: CPPr no admite IPv6 y está restringido a la ruta de entrada IPv4.

Consulte Guía para la Función Control Plane Protection - 12.4T y Comprensión de Control Plane Protection para obtener más información sobre la función CPPr de Cisco.

Encripte las sesiones de administración

Dado que la información se puede divulgar en una sesión de gestión interactiva, este tráfico debe cifrarse para que un usuario malintencionado no pueda acceder a los datos transmitidos. La encriptación del tráfico permite conexiones de acceso remoto seguras con dispositivos. Si el tráfico para una sesión de administración se envía por la red en texto sin formato, un atacante puede obtener información confidencial sobre el dispositivo y la red.

Los administradores pueden establecer conexiones de administración de acceso remoto seguras y encriptadas con dispositivos mediante las funciones SSH o HTTPS (Secure Hypertext Transfer Protocol). Cisco IOS Software es compatible con SSH versión 1.0 (SSHv1), con SSH versión 2.0 (SSHv2) y con HTTPS que utiliza Secure Sockets Layer (SSL) y Transport Layer Security (TLS) para la autenticación y el cifrado de datos. SSHv1 y SSHv2 no son compatibles. SSHv1 no es seguro ni está estandarizado, por lo que no se recomienda su uso si SSHv2 es una opción.

El software Cisco IOS también es compatible con el protocolo de copia segura (SCP), que permite una conexión cifrada y segura para copiar configuraciones de dispositivos o imágenes de software. El protocolo SCP depende de SSH. Este ejemplo de configuración habilita el protocolo SSH en un dispositivo Cisco IOS:

!

ip domain-name example.com
!

crypto key generate rsa modulus 2048
!

ip ssh time-out 60
ip ssh authentication-retries 3
ip ssh source-interface GigabitEthernet 0/1
!

line vty 0 4
 transport input ssh
!

Este ejemplo de configuración habilita los servicios de SCP:

!

ip scp server enable
!

Este ejemplo de configuración es para servicios HTTPS:

!

crypto key generate rsa modulus 2048
!

ip http secure-server
!

Consulte Configuración de Secure Shell en Routers y Switches que ejecutan Cisco IOS y Preguntas Frecuentes sobre Secure Shell (SSH) para obtener más información sobre la función SSH de Cisco IOS Software.

SSHv2

La función SSHv2, introducida en Cisco IOS Software Release 12.3(4)T, permite al usuario configurar SSHv2. (La compatibilidad con SSHv1 se implementó en una versión anterior del software Cisco IOS.) SSH se ejecuta encima de una capa de transporte confiable y proporciona capacidades de autenticación y encripción potentes. El único transporte confiable definido para SSH es TCP. SSH proporciona una manera de acceder y ejecutar comandos de forma segura en otro ordenador o dispositivo a través de una red. La función Secure Copy Protocol (SCP) tunelizada sobre SSH permite la transferencia segura de archivos.

Si el comando ip ssh version 2 no se configura explícitamente, Cisco IOS habilita la versión 1.99 de SSH. La versión 1.99 de SSH permite conexiones de SSHv1 y SSHv2. SSHv1 se considera inseguro y puede tener efectos adversos en el sistema. Si SSH está habilitado, se recomienda inhabilitar SSHv1 mediante el comando ip ssh version 2.

En este ejemplo de configuración se activa SSHv2 (con SSHv1 desactivado) en un dispositivo Cisco IOS:

!
    
hostname router

!

ip domain-name example.com    

!
    
crypto key generate rsa modulus 2048

!

ip ssh time-out 60  
ip ssh authentication-retries 3  
ip ssh source-interface GigabitEthernet 0/1    

!
    
ip ssh version 2

!

line vty 0 4   
transport input ssh    

!
 

Consulte Soporte Secure Shell Version 2 para obtener más información sobre el uso de SSHv2.

SSHv2 Enhancements for RSA Keys

La función SSHv2 de Cisco IOS admite los métodos de autenticación interactiva mediante teclado y basada en contraseña. Las función SSHv2 Enhancements for RSA Keys también admite la autenticación mediante clave pública RSA para el cliente y el servidor.

Para la autenticación de usuario, la autenticación de usuario basada en RSA utiliza una pareja de claves privada/pública asociadas con cada usuario para la autenticación. El usuario debe generar una pareja de claves privada/pública en el cliente y configurar un clave pública en el servidor SSH de Cisco IOS para completar la autenticación.

El usuario de SSH que intenta establecer las credenciales introduce una firma encriptada con la clave privada. La firma cifrada y la clave pública del usuario se envían al servidor SSH para la autenticación. El servidor SSH calcula un hash de la clave pública proporcionada por el usuario. El hash se utiliza para determinar si el servidor tiene una entrada que coincida. Si se halla una coincidencia, se efectúa la verificación de mensaje RSA con la clave pública. Por lo tanto, se autentica o se niega el acceso al usuario de acuerdo con la firma cifrada.

Para la autenticación de servidor, el cliente SSH de Cisco IOS debe asignar una clave de host para cada servidor. Cuando el cliente intenta establecer una sesión SSH con un servidor, recibe la firma del servidor como parte del mensaje de intercambio de claves. Si el indicador de verificación estricta de clave de host está habilitado en el cliente, éste comprueba si tiene la entrada de clave de host que corresponde al servidor preconfigurado. Si se halla una coincidencia, el cliente intenta validar la firma con la clave de organizador del servidor. Si el servidor se autentica correctamente, el establecimiento de sesión continúa; de lo contrario, se termina y muestra el mensaje Error de autenticación del servidor.

En este ejemplo de configuración se activa el uso de claves RSA con SSHv2 en un dispositivo Cisco IOS:

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Specify the name of the RSA key pair (in this case, "sshkeys") to use for SSH
!

 ip ssh rsa keypair-name sshkeys
!
! Enable the SSH server for local and remote authentication on the router using 
! the "crypto key generate" command
! For SSH version 2, the modulus size must be at least 768 bits 
!

 crypto key generate rsa usage-keys label sshkeys modulus 2048
!
! Configure an ssh timeout (in seconds) 
!
! The following enables a timeout of 120 seconds for SSH connections
!

ip ssh time-out 120
!
! Configure a limit of five (5) authentication retries
!

ip ssh authentication-retries 5
!
! Configure SSH version 2
!

ip ssh version 2 
!

  

Consulte Secure Shell Version 2 Enhancements for RSA Keys para obtener más información sobre el uso de claves RSA con SSHv2.

En este ejemplo de configuración se permite que el servidor de SSH de Cisco IOS realice la autenticación de usuario RSA. La autenticación de usuario es exitosa si la clave pública RSA guardada en el servidor se verifica con la clave pública o la clave privada guardadas en el cliente.

!
! Configure a hostname for the device
!

hostname router
!
! Configure a domain name
!

ip domain-name cisco.com
!
! Generate RSA key pairs using a modulus of 2048 bits
!

crypto key generate rsa modulus 2048
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Configure the SSH username
!

        username ssh-user
!
! Specify the RSA public key of the remote peer
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash command (followed by the SSH key type and version.)
!

Consulte Configuración del Servidor SSH de Cisco IOS para Realizar la Autenticación de Usuario Basada en RSA a fin de obtener más información sobre el uso de claves RSA con SSHv2.

En este ejemplo de configuración se permite que el cliente de SSH de Cisco IOS realice la autenticación de servidor RSA.

!
!

hostname router
!
ip domain-name cisco.c
!
! Generate RSA key pairs
!

crypto key generate rsa
!
! Configure SSH-RSA keys for user and server authentication on the SSH server
!

ip ssh pubkey-chain
!
! Enable the SSH server for public-key authentication on the router 
!

        server SSH-server-name
!
! Specify the RSA public-key of the remote peer 
!
! You must then configure either the key-string command
! (followed by the RSA public key of the remote peer) or the 
! key-hash <key-type> <key-name> command (followed by the SSH key 
! type and version.)
!
! Ensure that server authentication takes place - The connection will be 
! terminated on a failure
!

ip ssh stricthostkeycheck 
!

Consulte Configuración del Cliente SSH de Cisco IOS para Realizar la Autenticación de Servidor Basada en RSA a fin de obtener más información sobre el uso de claves RSA con SSHv2.

Puertos de Consola y Auxiliar

En los dispositivos Cisco IOS, los puertos de consola y auxiliar (AUX) son líneas asincrónicas que se pueden utilizar para el acceso local o remoto a un dispositivo. Tenga en cuenta que los puertos de la consola en los dispositivos Cisco IOS tienen privilegios especiales. Particularmente, estos privilegios permiten que un administrador realice el procedimiento de recuperación de contraseña. Para realizar la recuperación de contraseña, un atacante no autenticado necesitaría acceso al puerto de la consola y la capacidad de interrumpir la alimentación del dispositivo o hacer que el dispositivo se bloquee.

Cualquier método utilizado para acceder al puerto de la consola de un dispositivo debe estar protegido de una manera que sea igual a la seguridad aplicada para el acceso privilegiado a un dispositivo. Los métodos utilizados para proteger el acceso deben incluir el uso de AAA, exec-timeout y contraseñas de módem (si hay un módem conectado a la consola).

Si la recuperación de contraseña no es necesaria, un administrador puede quitar la capacidad de realizar el procedimiento de recuperación de contraseña mediante el comando de configuración global no service password-recovery; sin embargo, una vez que se ha habilitado el comando no service password-recovery, un administrador no puede realizar la recuperación de contraseña en un dispositivo.

En la mayoría de las situaciones, el puerto AUX del dispositivo debe estar deshabilitado para evitar el acceso no autorizado. Los puertos AUX pueden desactivarse mediante estos comandos:

!

line aux 0
 transport input none
 transport output none
 no exec
 exec-timeout 0 1
 no password
!

Control de Líneas vty y tty

Las sesiones de administración interactivas en Cisco IOS Software utilizan una línea tty o una línea tty virtual (vty). Una línea tty es una línea asíncrona local a la cual se puede conectar un terminal para el acceso local al dispositivo o a un módem para el acceso por marcación a un dispositivo. Tenga en cuenta que las líneas tty se pueden utilizar para conexiones a los puertos de consola de otros dispositivos. Esta función permite que un dispositivo con líneas tty funcione como servidor de consola donde se pueden establecer conexiones a través de la red a los puertos de consola de dispositivos conectados con las líneas tty. Las líneas tty para estas conexiones inversas a través de la red también deben ser controladas.

Una línea vty se utiliza para el resto de las conexiones de red remotas admitidas por el dispositivo, independientemente del protocolo (SSH, SCP o Telnet, por ejemplo). Para garantizar que se pueda acceder a un dispositivo mediante una sesión de administración local o remota, se deben aplicar los controles adecuados en las líneas vty y tty. Los dispositivos Cisco IOS tienen un número limitado de líneas vty; el número de líneas disponibles se puede determinar con el comando EXEC show line. Cuando todas las líneas vty están en uso, no se pueden establecer nuevas sesiones de administración, lo que puede crear una condición DoS para el acceso al dispositivo.

El control de acceso más sencillo a una vty o tty de un dispositivo es mediante el uso de autenticación en todas las líneas, independientemente de la ubicación del dispositivo en la red. Esto es fundamental para las líneas vty, ya que la red puede acceder a ellas. La red también puede acceder a una línea tty conectada a un módem que se utiliza para el acceso remoto al dispositivo o a una línea tty conectada al puerto de consola de otros dispositivos. Se pueden aplicar otras formas de controles de acceso a vty y tty mediante los comandos de configuración transport input o access-class, mediante las funciones CoPP y CPPr, o aplicando listas de acceso en interfaces de dispositivos.

La autenticación se puede aplicar mediante AAA, que es el método recomendado de acceso autenticado a dispositivos, mediante la base de datos de usuarios locales, o mediante la autenticación de contraseña simple configurada directamente en las líneas de vty o tty.

El comando exec-timeout se debe utilizar para cerrar sesiones en líneas vty o tty que se dejan inactivas. El comando service tcp-keepalives-in también se debe utilizar para habilitar los keepalives TCP en las conexiones entrantes al dispositivo. Esto garantiza que el dispositivo en el extremo remoto de la conexión siga siendo accesible y que las conexiones semiabiertas o huérfanas se eliminen del dispositivo Cisco IOS local.

Control del Transporte para Líneas vty y tty

Configure un vty y tty para aceptar solamente conexiones de administración de acceso remoto cifradas y seguras al dispositivo o a través del dispositivo si se utiliza como servidor de consola. Esta sección trata sobre las tty porque tales líneas se pueden conectar con los puertos de consola en otros dispositivos y, de esta manera, se puede acceder a ellas a través de la red. Para evitar la divulgación de información o el acceso no autorizado a los datos transmitidos entre el administrador y el dispositivo, utilice transport input ssh en lugar de protocolos de texto sin formato, como Telnet y rlogin. La configuración transport input none se puede habilitar en una tty, lo que inhabilita el uso de la línea tty para las conexiones de consola inversa.

Las líneas vty y las líneas tty permiten que un administrador se conecte con otros dispositivos. Para limitar el tipo de transporte que un administrador puede utilizar para las conexiones salientes, utilice el comando de configuración de línea transport output. Si las conexiones salientes no son necesarias, utilice transport output none. Sin embargo, si se permiten las conexiones salientes, aplique un método de acceso remoto cifrado y seguro para la conexión mediante el uso de transport output ssh.

Nota: IPSec se puede utilizar para conexiones de acceso remoto seguras y cifradas a un dispositivo, si se admite. Si usted utiliza IPSec, este conjunto también agrega la sobrecarga del CPU adicional al dispositivo. Sin embargo, SSH se debe seguir aplicando como transporte, incluso cuando se utiliza IPSec.

Banners de Advertencia

En algunas jurisdicciones legales, puede ser imposible procesar e ilegal monitorear a los usuarios maliciosos, a menos que se les haya notificado que no se les permite utilizar el sistema. Un método para proporcionar esta notificación es colocar esta información en un mensaje de banner que se configura con el comando banner login del software del IOS de Cisco.

Los requisitos de notificación legal son complejos, varían según la jurisdicción y la situación, y requieren un debate con un asesor legal. Incluso dentro de las jurisdicciones, las opiniones legales pueden variar. En cooperación con el abogado, un banner puede proporcionar parte o toda esta información:

• Notificación de que solamente el personal específicamente autorizado puede iniciar sesión o utilizar el sistema y quizás notificación de la información sobre quién puede autorizar el uso.
  
  
• Notificación de que cualquier uso no autorizado del sistema es ilegal y de que puede estar sujeto a sanciones penales y civiles.
  
  
• Tenga en cuenta que cualquier uso del sistema puede registrarse o supervisarse sin previo aviso y que los registros resultantes pueden utilizarse como prueba en los tribunales.
  
  
• Notificaciones específicas que exigen las leyes locales.

Desde el punto de vista de la seguridad, en lugar de ser legal, un banner de inicio de sesión no debe contener ninguna información específica sobre el nombre del router, el modelo, el software o la propiedad. Los usuarios maliciosos pueden darle un uso indebido a esta información.

Autenticación, autorización y contabilidad

El marco de autenticación, autorización y contabilidad (AAA) es fundamental para proteger el acceso interactivo a los dispositivos de red. El marco AAA proporciona un entorno altamente configurable que se puede adaptar en función de las necesidades de la red.

autenticación TACACS+

TACACS+ es un protocolo de autenticación que los dispositivos Cisco IOS pueden utilizar para la autenticación de usuarios de administración contra un servidor AAA remoto. Estos usuarios de administración pueden acceder al dispositivo Cisco IOS mediante SSH, HTTPS, telnet o HTTP.

La autenticación TACACS+, más comúnmente conocida como autenticación AAA, le da a cada administrador de red la posibilidad de utilizar cuentas de usuarios individuales. Al no dependerse de una contraseña compartida, se mejora la seguridad de la red y se refuerza la responsabilidad individual.

RADIUS es un protocolo similar en su propósito a TACACS+; sin embargo, sólo cifra la contraseña enviada a través de la red. En cambio, TACACS+ encripta toda la carga útil de TCP, que incluye el nombre de usuario y la contraseña. Por esta razón, utilice TACACS+ en lugar de RADIUS cuando TACACS+ es soportado por el servidor AAA. Consulte Comparación entre TACACS+ y RADIUS para obtener una comparación más detallada de estos dos protocolos.

La autenticación de TACACS+ se puede activar en los dispositivos Cisco IOS con una configuración similar a este ejemplo:

!

aaa new-model
aaa authentication login default group tacacs+
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

La configuración anterior se puede utilizar como punto de inicio para una plantilla de autenticación AAA específica de la organización. 

Una lista de métodos es una lista secuencial que describe los métodos de autenticación que se consultarán para autenticar a un usuario. Las listas de métodos le permiten designar uno o más protocolos de seguridad que se utilizarán para la autenticación y, por lo tanto, garantizar un sistema de copia de seguridad para la autenticación si el método inicial falla. El software Cisco IOS emplea el primer método de la lista que logre aceptar o rechazar al usuario. Los métodos subsiguientes sólo se intentan si los métodos anteriores fallan debido a la indisponibilidad del servidor o a una configuración incorrecta.

Autenticación Alternativa

Si todos los servidores TACACS+ configurados carecen de disponibilidad, un dispositivo Cisco IOS puede utilizar protocolos de autenticación secundarios. Las configuraciones típicas incluyen el uso de las opciones de autenticación local o enable si todos los servidores TACACS+ configurados carecen de disponibilidad.

La lista completa de opciones para la autenticación en el dispositivo incluye enable, local y line. Cada opción tiene ventajas. Se prefiere el uso de enable secret porque el secreto se trocea con un algoritmo unidireccional que es inherentemente más seguro que el algoritmo de cifrado utilizado con las contraseñas Tipo 7 para la autenticación local o de línea.

Sin embargo, en las versiones de Cisco IOS Software que admiten el uso de contraseñas secretas para los usuarios localmente definidos, puede ser deseable recurrir a la autenticación local. Esto permite crear un usuario definido localmente para uno o más administradores de red. Si TACACS+ no estaba completamente disponible, cada administrador puede utilizar su nombre de usuario y contraseña locales. Si bien esta acción amplía la responsabilidad individual de los administradores de redes en las interrupciones de TACACS+, aumenta significativamente la carga administrativa porque deben mantenerse las cuentas de usuarios locales en todos los dispositivos de redes.

Este ejemplo de configuración se basa en el ejemplo de autenticación TACACS+ anterior para incluir la autenticación alternativa a la contraseña configurada localmente con el enable secret comando:

!

enable secret <password>
!

aaa new-model
aaa authentication login default group tacacs+ enable
!

tacacs-server host <ip-address-of-tacacs-server>
tacacs-server key <key>
!

Uso de Contraseñas Tipo 7

En un principio diseñadas para permitir el descifrado rápido de las contraseñas guardadas, las contraseñas Tipo 7 no constituyen una forma segura de almacenamiento de contraseña. Hay muchas herramientas disponibles para descifrar fácilmente estas contraseñas. Evite el uso de contraseñas Tipo 7 a menos que lo requiera una función en uso en el dispositivo Cisco IOS.

Siempre que sea posible, utilice el tipo 9 (cifrado):

username <username> privilege 15 algorithm-type scrypt secret <secret>

La eliminación de contraseñas de este tipo se puede realizar mediante la autenticación AAA y el uso de la función Enhanced Password Security, que permite utilizar contraseñas secretas con usuarios definidos localmente por el comando de configuración username global. Si usted no puede evitar completamente el uso de contraseñas Tipo 7, tenga en cuenta que estas contraseñas son ofuscadas pero no cifradas.

Para obtener más información sobre la eliminación de contraseñas de tipo 7, consulte la sección Consolidación del Plano de Administración General.

Autorización de Comandos con TACACS+

La autorización de comandos con TACACS+ y con AAA proporciona un mecanismo que permite o niega los comandos que ingresa un usuario administrativo. Cuando el usuario ingresa comandos EXEC, Cisco IOS envía cada comando al servidor AAA configurado, El servidor AAA utiliza sus políticas configuradas para permitir o denegar el comando para ese usuario en particular.

Esta configuración se puede agregar al ejemplo de autenticación AAA anterior para implementar la autorización de comandos:

!

aaa authorization exec default group tacacs none
aaa authorization commands 0 default group tacacs none
aaa authorization commands 1 default group tacacs none 
aaa authorization commands 15 default group tacacs none
!

Contabilización de Comandos TACACS+

Cuando se configura, la contabilización de comandos AAA envía información sobre cada comando EXEC ingresado a los servidores TACACS+ configurados. La información enviada al servidor TACACS+ incluye el comando ejecutado, la fecha en que se ejecutó y el nombre de usuario de quien ingresó el comando. Con RADIUS no se ofrece auditoría de comandos.

Este ejemplo de configuración habilita la contabilización de comandos AAA para los comandos EXEC ingresados en los niveles de privilegio cero, uno y 15. Esta configuración se basa en ejemplos anteriores que incluyen la configuración de los servidores TACACS.

!

aaa accounting exec default start-stop group tacacs 
aaa accounting commands 0 default start-stop group tacacs
aaa accounting commands 1 default start-stop group tacacs
aaa accounting commands 15 default start-stop group tacacs
!

Servidores AAA Redundantes

Los servidores AAA que se aprovechan en un entorno pueden ser redundantes e implementarse de forma tolerante a fallos. Esto permite garantizar que el acceso de administración interactivo, como SSH, sea posible si un servidor AAA no está disponible.

Al designar o implementar una solución de servidor AAA redundante, recuerde lo siguiente:

• Disponibilidad de servidores AAA en el momento de posibles fallos de red
  
  
• colocación geográficamente distribuida de los servidores de AAA;
  
  
• Cargue en servidores AAA individuales de condiciones estables de falla y estado
  
  
• latencia de red entre los servidores de acceso a la red y los servidores AAA;
  
  
• sincronización de las bases de datos del servidor AAA.

Consulte Implementación de Servidores de Control de Acceso para obtener más información.

Fortalezca el protocolo simple de administración de redes

Esta sección resalta varios métodos que se pueden utilizar para asegurar la implementación de SNMP en dispositivos Cisco IOS. Es fundamental que SNMP esté protegido correctamente para proteger la confidencialidad, la integridad y la disponibilidad de los datos de red y de los dispositivos de red por los que pasan los datos. SNMP proporciona una gran cantidad de información sobre el estado de los dispositivos de red. Proteja esta información de los usuarios malintencionados que deseen aprovechar estos datos para realizar ataques contra la red.

Identificaciones de comunidad SNMP

Las cadenas de comunidad son contraseñas que se aplican a un dispositivo Cisco IOS para restringir el acceso, tanto de solo lectura como de lectura-escritura, a los datos SNMP del dispositivo. Estas cadenas de comunidad, como todas las contraseñas, se eligen cuidadosamente para asegurarse de que no sean triviales. Cambie las cadenas de comunidad a intervalos regulares y de acuerdo con las políticas de seguridad de la red. Por ejemplo, cambie las cadenas cuando un administrador de red cambie de función o abandone la empresa.

Estas líneas de configuración configuran una comunidad de solo lectura de READONLY y una cadena de comunidad de lectura y escritura de READWRITE:

!

snmp-server community READONLY RO
snmp-server community READWRITE RW  
!

Nota: Los ejemplos de cadenas de comunidad anteriores se eligieron para explicar claramente el uso de estas cadenas. Para entornos de producción, elija las cadenas de comunidad con precaución e incluya una serie de símbolos alfabéticos, numéricos y no alfanuméricos. 

Consulte Referencia de Comandos SNMP de Cisco IOS para obtener más información sobre esta función.

Comunidades SNMP con ACL

Además de la cadena de comunidad, aplique una ACL que restrinja aún más el acceso SNMP a un grupo seleccionado de direcciones IP de origen. Esta configuración restringe el acceso de solo lectura de SNMP a los dispositivos host extremo que residen en el espacio de la dirección 192.168.100.0/24 y restringe el acceso de lectura y escritura de SNMP a solamente el dispositivo host extremo en 192.168.100.1.

Nota: Los dispositivos permitidos por estas ACL requieren la cadena de comunidad adecuada para acceder a la información SNMP solicitada.

!

access-list 98 permit 192.168.100.0 0.0.0.255
access-list 99 permit 192.168.100.1
!

snmp-server community READONLY RO 98
snmp-server community READWRITE RW 99
!

Para obtener más información sobre esta función, consulte Comunidad de servidores de snmp en la Guía de referencia de comandos de administración de redes de Cisco ISO.

ACL de Infraestructura

Las ACL de infraestructura (iACL) se pueden implementar para garantizar que solo los hosts finales con direcciones IP fiables puedan enviar tráfico SNMP a un dispositivo Cisco IOS. Idealmente, una iACL contiene una política que niega los paquetes SNMP no autorizados en el puerto UDP 161.

Consulte la sección Limitación del Acceso a la Red con Listas de Control de Acceso a la Infraestructura de este documento para obtener más información sobre el uso de iACL.

Vistas SNMP

Vistas SNMP son una función de seguridad que pueden permitir o negar el acceso a ciertas bases de información de administración (MIB) SNMP. Una vez que una vista se crea y se aplica a una comunidad con los comandos de configuración global snmp-server community y community-string view, si usted accede a los datos de MIB, estará restringido a los permisos definidos por la vista. Cuando sea apropiado, utilice las vistas para limitar a los usuarios de SNMP a los datos que necesitan.

Este ejemplo de configuración restringe el acceso SNMP con la comunidad LIMITED a los datos de MIB situados en el grupo del sistema:

!

snmp-server view VIEW-SYSTEM-ONLY system include
!

snmp-server community LIMITED view VIEW-SYSTEM-ONLY RO
!

Consulte Configuración de Soporte SNMP para obtener más información.

Versión 3 de SNMP

La versión 3 de SNMP (SNMPv3) se encuentra definida en RFC3410 , RFC3411 , RFC3412 , RFC3413 , RFC3414 y RFC3415 , además es un protocolo de interoperabilidad basado en estándares para la administración de red. SNMPv3 ofrece acceso seguro a dispositivos porque autentica y brinda la opción de encriptar paquetes en las redes. Cuando se admite, SNMPv3 se puede utilizar para agregar otra capa de seguridad al implementar SNMP. SNMPv3 consiste en tres opciones de configuración primaria:

• no auth - Este modo no requiere ninguna autenticación ni cifrado de paquetes SNMP
  
  
• auth: Este modo exige la autenticación de los paquetes de SNMP sin encriptación
  
  
• priv: Este modo exige autenticación y encriptación (privacidad) de todos los paquetes de SNMP

Debe existir un ID de motor autorizado para utilizar los mecanismos de seguridad SNMPv3 (autenticación o autenticación y cifrado) para gestionar paquetes SNMP; de forma predeterminada, el ID de motor se genera localmente. El ID del motor se puede mostrar con el show snmp engineID comando como se muestra en este ejemplo:

router#show snmp engineID 
   Local SNMP engineID: 80000009030000152BD35496
   Remote Engine ID          IP-addr    Port

Nota: Si se cambia el engineID, se deben reconfigurar todas las cuentas de usuario SNMP.

El siguiente paso es configurar un grupo SNMPv3. Este comando configura los dispositivos Cisco IOS para SNMPv3 con un grupo de servidores SNMP AUTHGROUP y permite solo autenticación para este grupo con la palabra clave auth:

!
snmp-server group AUTHGROUP v3 auth
!

Este comando configura los dispositivos Cisco IOS para SNMPv3 con un grupo de servidores SNMP PRIVGROUP, y permite autenticación y encriptación para este grupo con la palabra clave priv:

!
snmp-server group PRIVGROUP v3 priv
!

Este comando configura un usuario SNMPv3 snmpv3user con una contraseña de autenticación MD5 de authpassword y una contraseña de cifrado 3DES de privpassword:

!

snmp-server user snmpv3user PRIVGROUP v3 auth md5 authpassword priv 3des 
     privpassword
!

Tenga en cuenta que los comandos de snmp-server user configuración no se muestran en la salida de configuración del dispositivo como lo requiere RFC 3414. Por lo tanto, la contraseña del usuario no se puede ver en la configuración. Para ver los usuarios configurados, ingrese el show snmp user comando, como se muestra en este ejemplo:

router#show snmp user 
User name: snmpv3user
Engine ID: 80000009030000152BD35496
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: PRIVGROUP

Consulte Configuración de Soporte SNMP para obtener más información sobre esta función.

Management Plane Protection

La función Management Plane Protection (MPP) del software Cisco IOS se puede utilizar para ayudar a proteger SNMP porque restringe las interfaces a través de las cuales el tráfico SNMP puede terminar en el dispositivo. La función MPP permite que un administrador designe una o más interfaces como interfaces de administración. El tráfico de administración puede ingresar a un dispositivo solamente a través de estas interfaces de administración. Después de que se habilita la función MPP, ninguna interfaz, salvo las interfaces de administración designadas, acepta el tráfico de administración de red que se dirige al dispositivo.

El MPP es un subconjunto de la función CPPr y requiere una versión de Cisco IOS que admita CPPr. Consulte Comprensión de Control Plane Protection para obtener más información sobre la función CPPr.

En este ejemplo, MPP se utiliza para restringir el acceso SNMP y SSH sólo a la interfaz FastEthernet 0/0:

!
control-plane host
 management-interface FastEthernet0/0 allow ssh snmp 
!

Consulte Guía para la Función Management Plane Protection para obtener más información.

Prácticas Recomendadas de Registro

Los registros de eventos proporcionan visibilidad de las operaciones de un dispositivo Cisco IOS y de la red en la que está implementado. El software Cisco IOS proporciona varias opciones de configuración de registro flexibles que pueden ayudar a alcanzar los objetivos de visibilidad y gestión de red de una organización.

Estas secciones proporcionan algunas prácticas recomendadas básicas de las funciones de registro que pueden ayudar a un administrador a aprovechar las funciones de registro con éxito, con un impacto mínimo en la función de registro en un dispositivo Cisco IOS.

Envío de Registros a una Ubicación Central

Se recomienda enviar la información de registro a un servidor syslog remoto. Esto hace posible correlacionar y auditar con más eficiencia los eventos de seguridad y redes en los dispositivos de redes. Tenga en cuenta que los mensajes syslog son transmitidos de manera poco fiable por el protocolo UDP y en texto sin formato. Por lo tanto, cualquier protección que una red ofrezca al tráfico de administración (por ejemplo, cifrado o acceso fuera de banda) se puede ampliar para incluir el tráfico de syslog.

Este ejemplo configura un dispositivo Cisco IOS para enviar información de registro a un servidor syslog remoto:

!
logging host <ip-address>
!

Consulte Identificación de Incidentes Usando Firewall y Eventos Syslog del Router Cisco IOS para obtener más información sobre la correlación de registros.

Integrada en Cisco IOS 12.4(15)T y originalmente introducida en 12.0(26)S, la función Logging to Local Nonvolatile Storage (ATA Disk) permite que los mensajes de registro del sistema se guarden en un disco flash de conexión de tecnología avanzada (ATA). Los mensajes guardados en una unidad ATA persisten después de que se reinicie un router.

Estas líneas de configuración configuran 134,217,728 bytes (128 MB) de mensajes de registro al directorio syslog de la memoria flash ATA (disk0), con un tamaño de archivo especificado de 16,384 bytes:

logging buffered
logging persistent url disk0:/syslog size 134217728 filesize 16384

Antes de que los mensajes de registro se escriban en un archivo en el disco ATA, el software Cisco IOS verifica si hay suficiente espacio en disco. Si no es así, se elimina el mensaje del archivo de registro más antiguo (por marca de tiempo) y se guarda el archivo actual. El formato del nombre de archivo es log_month:day:year::time.

Nota: Una unidad flash ATA tiene un espacio en disco limitado y, por lo tanto, debe mantenerse para evitar la posibilidad de sobrescribir los datos almacenados.

Este ejemplo muestra cómo copiar los mensajes de registro del disco flash ATA del router a un disco externo en el servidor FTP 192.168.1.129 como parte de los procedimientos de mantenimiento:

copy disk0:/syslog ftp://myuser/mypass@192.168.1.129/syslog

Consulte Registro en Almacenamiento No Volátil Local (disco ATA) para obtener más información sobre esta función.

Nivel de Registro

A cada mensaje de registro generado por un dispositivo Cisco IOS se le asigna una de las ocho severidades que van desde el nivel 0, Emergencias, hasta el nivel 7, Depuración. A menos que se requiera específicamente, se le aconseja evitar los registros en el nivel 7. Los registros del nivel 7 producen una carga de CPU elevada en el dispositivo, lo que puede provocar inestabilidad en el dispositivo y en la red.

El logging trap nivel de comando de configuración global se utiliza para especificar qué mensajes de registro se envían a los servidores syslog remotos. El nivel especificado indica el mensaje de nivel más bajo de gravedad que se envía. Para los registros almacenados en búfer, se utiliza el comando logging buffered level.

Este ejemplo de configuración limita los mensajes de registro enviados a servidores syslog remotos y al buffer de registro local a las gravedades 6 (Informativo) a 0 (Emergencias):

!

logging trap 6
logging buffered 6
!

Consulte Troubleshooting, Administración de Fallas y Registro para obtener más información.

Inhabilitación de Registro en la Consola o en las Sesiones de Monitoreo

Con el software Cisco IOS, es posible enviar mensajes de registro para monitorear las sesiones, que son sesiones de administración interactivas en las que se terminal monitor ha ejecutado el comando EXEC, y a la consola. Sin embargo, esto puede elevar la carga de CPU de un dispositivo Cisco IOS y, por lo tanto, no se recomienda. En su lugar, envíe la información de registro al búfer de registro local que se puede ver con el show logging comando.

Utilice los comandos de configuración global no logging console y no logging monitor para inhabilitar los registros en la consola y en las sesiones de supervisión. Este ejemplo de configuración muestra el uso de estos comandos:

!

no logging console
no logging monitor
!

Consulte Referencia de Comandos de Administración de Red de Cisco IOS para obtener más información sobre los comandos de configuración global.

Utilizar registros almacenados en búfer

El software Cisco IOS admite el uso de un búfer de registro local para que un administrador pueda ver los mensajes de registro generados localmente. Se recomienda utilizar registros almacenados en búfer en lugar de registros en la consola o en sesiones de supervisión.

Existen dos opciones de configuración relevantes al configurar los logs almacenados en buffer: el tamaño del buffer de log y la gravedad de los mensajes almacenados en el buffer. El tamaño del logging buffer búfer se configura con el comando de configuración global logging buffered size. La gravedad más baja incluida en el búfer se configura con el comando log buffered severity. Un administrador puede ver el contenido del búfer de registro mediante el comando show logging EXEC.

Este ejemplo de configuración incluye la configuración de un búfer de registro de 16.384 bytes, así como una gravedad de 6, Informativo, que indica que se almacenan los mensajes de los niveles 0 (Emergencias) a 6 (Informativo):

!

logging buffered 16384 6
!

Consulte Referencia de Comandos de Administración de Redes de Cisco IOS para obtener más información sobre los registros almacenados en buffer.

Configuración de la Interfaz de Origen de Registro

Para proporcionar un mayor nivel de coherencia al recopilar y revisar mensajes de registro, se recomienda configurar estáticamente una interfaz de origen de registro. Esto se logra mediante el comando logging source-interface interface. Una interfaz de origen de registro configurada estáticamente garantiza que la misma dirección IP aparezca en todos los mensajes de registro enviados desde un dispositivo Cisco IOS individual. Para mayor estabilidad, utilice una interfaz de loopback como origen del registro.

Este ejemplo de configuración ilustra el uso del comando de configuración global logging source-interface interface para especificar la dirección IP de la interfaz loopback 0 que se utilizará para todos los mensajes de registro:

!
logging source-interface Loopback 0
!

Consulte Referencia de Comando de Cisco IOS para obtener más información.

Configurar marcas de tiempo de registro

La configuración de las marcas de tiempo del registro ayuda a correlacionar los eventos en los dispositivos de red. Es importante implementar una configuración de registro de fecha y hora correcta y coherente para garantizar que pueda correlacionar los datos de registro. Configure las marcas de tiempo del registro para incluir la fecha y la hora, con precisión de milisegundos, y para incluir la zona horaria en uso en el dispositivo.

Este ejemplo incluye la configuración de marcas de tiempo de registro, con precisión de milisegundos, dentro de la zona de Tiempo universal coordinado (UTC):

!
service timestamps log datetime msec show-timezone
!

Si usted prefiere usar un estándar diferente al UTC para registrar la hora, usted puede configurar un huso horario local específico y configurar esa información para que esté presente en los mensajes de registro generados. Este ejemplo muestra la configuración de un dispositivo para la zona Tiempo Estándar del Pacífico (PST):

!

clock timezone PST -8
service timestamps log datetime msec localtime show-timezone
!

Administración de la Configuración de Cisco IOS Software

El software Cisco IOS incluye varias funciones para habilitar una forma de administración de la configuración en un dispositivo Cisco IOS. Estas funciones incluyen la funcionalidad de archivar configuraciones y revertir la configuración a una versión anterior, así como crear un registro de cambios de configuración detallado.

Configuration Replace y Configuration Rollback

En la versión del software Cisco IOS 12.3(7)T y las posteriores, las funciones de reemplazo de configuración y reversión de configuración le permiten archivar la configuración de dispositivos Cisco IOS en los dispositivos. Almacenadas manual o automáticamente, las configuraciones de este archivo se pueden utilizar para reemplazar la configuración actual en ejecución con el comando configure replace filename. Esto contrasta con el comando copy filename running-config . El configure replace comando filename reemplaza la configuración en ejecución, a diferencia de la combinación realizada por el copy comando.

Se recomienda activar esta función en todos los dispositivos Cisco IOS de la red. Una vez habilitada, un administrador puede hacer que la configuración en ejecución actual se agregue al contenedor con el archive config EXEC comando. Las configuraciones archivadas se pueden ver con el show archive EXEC comando.

Este ejemplo ilustra la configuración para el archivo de configuración automática. En este ejemplo se indica al dispositivo Cisco IOS que almacene las configuraciones archivadas como archivos con el nombre archive-config-N en el sistema de archivos disk0:, que mantenga un máximo de 14 copias de seguridad y que archive una vez al día (140 minutos) cuando un administrador ejecute el write memory EXEC comando.

!

archive
 path disk0:archived-config
 maximum 14
 time-period 1440
 write-memory
!

Aunque la función de archivo de configuración puede almacenar hasta 14 configuraciones de copia de seguridad, se recomienda considerar los requisitos de espacio antes de utilizar el maximum comando.

Función Exclusive Configuration Change Access

Añadida a Cisco IOS Software Release 12.3(14)T, la función Exclusive Configuration Change Access garantiza que solo un administrador realice cambios de configuración en un dispositivo Cisco IOS a la vez. Esta función ayuda a eliminar el impacto no deseable de cambios simultáneos realizados a componentes de la configuración relacionados. Esta función se configura con el configuration mode exclusive modo de comando de configuración global y opera en uno de los dos modos: automático o manual. En el modo automático, la configuración se bloquea automáticamente cuando un administrador ejecuta el configure terminal EXEC comando. En el modo manual, el administrador utiliza el configure terminal lock comando para bloquear la configuración cuando entra en el modo de configuración.

Este ejemplo ilustra la configuración de esta función para el bloqueo automático de la configuración:

!
configuration mode exclusive auto
!

Cisco IOS Software Resilient Configuration

Añadida en Cisco IOS Software Release 12.3(8)T, la función Resilient Configuration permite almacenar de forma segura una copia de la imagen de Cisco IOS Software y la configuración del dispositivo que actualmente utiliza un dispositivo Cisco IOS. Cuando se habilita esta función, no es posible alterar o quitar estos archivos de respaldo. Se le aconseja que habilite esta función para evitar intentos tanto inadvertidos como maliciosos de borrar estos archivos.

!
secure boot-image
secure boot-config!

Una vez que se habilita esta función, es posible restaurar una configuración eliminada o una imagen de Cisco IOS Software eliminada. El estado actual de esta función se puede mostrar con el show secure boot EXEC comando.

Digitally Signed Cisco Software

La función Digitally Signed Cisco Software, agregada en Cisco IOS Software Release 15.0(1)M para los Cisco 1900, 2900 y 3900 Series Routers, facilita el uso de Cisco IOS Software firmado digitalmente y, por lo tanto, de confianza, con el uso de criptografía asimétrica segura (clave pública).

Una imagen con firma digital tiene un hash cifrado (con una clave privada). Tras la comprobación, el dispositivo descifra el hash con la clave pública asociada de las claves que tiene en su almacén de claves y también calcula su propio hash de la imagen. Si el hash descifrado coincide con el hash calculado de la imagen, la imagen no se ha alterado y es confiable.

Los claves de Digitally Signed Cisco Software son identificadas por tipo y versión. Los tipos de clave puede ser especial, producción o renovación. Los tipos de clave de producción y especial tienen asociada una versión de clave que aumenta alfabéticamente cuando se revoca y reemplaza la clave. Las imágenes de Cisco IOS regular y de ROMMON se firman con una clave de producción o especial al emplear la función de software Cisco de firma digital. La imagen de ROMMON se puede actualizar y debe firmarse con la misma clave que la imagen de producción especial cargada.

Este comando verifica la integridad de la imagen c3900-universalk9-mz.SSA en flash a partir de las claves almacenadas en el dispositivo:

show software authenticity file flash0:c3900-universalk9-mz.SSA

La función Digitally Signed Cisco Software también fue integrada en Cisco IOS XE Release 3.1.0.SG para Cisco Catalyst 4500 E-Series Switches.

Consulte Digitally Signed Cisco Software para obtener más información sobre esta función.

En la versión del software Cisco IOS 15.1(1)T y las posteriores, se introdujo el reemplazo de claves para esta función de firma digital. La sustitución y revocación de claves reemplaza y elimina una clave que se utiliza para una comprobación de software de Cisco firmado digitalmente del almacenamiento de claves de la plataforma. Solamente las claves de tipo especial y de producción se pueden revocar en caso de que sea vean comprometidas.

Una nueva clave (especial o de producción) para una imagen (especial o de producción) se encuentra incluida en una imagen (producción o revocación) que se utiliza para revocar la clave especial o de producción anterior. La integridad de la imagen de revocación se verifica mediante una clave sustituta que viene prealmacenada en la plataforma. Las claves de renovación no cambian. Cuando revoca una clave de producción, después de cargar la imagen de revocación, la nueva clave que lleva se agrega al almacén de claves y la clave antigua asociada se puede revocar, siempre y cuando se actualice la imagen ROMMON y se arranque la nueva imagen de producción. Al revocar una clave especial, se carga una imagen de producción. Esta imagen agrega la nueva clave especial y puede revocar la clave especial anterior. Tras actualizar ROMMON, se puede arrancar con la nueva imagen especial.

En este ejemplo se presenta la revocación de una clave especial. Estos comandos agregan la nueva clave especial al almacén de claves de la imagen de producción actual, copian una nueva imagen ROMMON (C3900_rom-monitor.srec.SSB) en el área de almacenamiento (usbflash0:), actualizan el archivo ROMMON y revocan la clave especial anterior:

software authenticity key add special
copy tftp://192.168.1.129/C3900_rom-monitor.srec.SSB usbflash0:
upgrade rom-monitor file usbflash0:C3900_PRIV_RM2.srec.SSB
software authenticity key revoke special

Luego se puede copiar una nueva imagen especial (c3900-universalk9-mz.SSB) en flash para cargarla, y la firma de la imagen se verifica mediante la clave especial recién agregada (.SSB):

copy /verify tftp://192.168.1.129/c3900-universalk9-mz.SSB flash:

La revocación y el reemplazo de claves no se ofrecen en los switches de la serie Catalyst 4500 E que emplean el software Cisco IOS XE, pero estos switches sí ofrecen la función de software Cisco de firma digital.

Consulte la sección Digitally Signed Cisco Software Key Revocation and Replacement de la guía Digitally Signed Cisco Software para obtener más información sobre esta función.

Configuration Change Notification and Logging

La función Configuration Change Notification and Logging, agregada en Cisco IOS Software Release 12.3(4)T, permite registrar los cambios realizados en la configuración de un dispositivo Cisco IOS. El registro se mantiene en el dispositivo Cisco IOS y contiene la información del usuario de la persona que realizó el cambio, el comando de configuración ingresado y la hora en que se realizó el cambio. Esta funcionalidad se habilita con el comando logging enable configuration change logger configuration mode. Los comandos hidekeys y logging size entradas opcionales se utilizan para mejorar la configuración predeterminada, ya que impiden los registros de datos de contraseñas y aumentan la longitud del registro de cambios.

Se recomienda que habilite esta funcionalidad para que el historial de cambios de configuración de un dispositivo Cisco IOS se pueda entender más fácilmente. Además, se recomienda utilizar el comando de notify syslog configuración para habilitar la generación de mensajes syslog cuando se realiza un cambio de configuración.

!

archive
 log config
  logging enable
  logging size 200
  hidekeys
  notify syslog
!

Una vez habilitada la función Configuration Change Notification and Logging, se show archive log config all puede utilizar el comando EXEC privilegiado para ver el registro de la configuración.

Plano de Control

Las funciones del plano de control consisten en los protocolos y los procesos que se comunican entre los dispositivos de red para trasladar los datos desde el origen hasta el destino. Esto incluye protocolos de routing, como el protocolo de gateway fronterizo, así como protocolos como ICMP y el protocolo de reserva de recursos (RSVP).

Es importante que los eventos en los planos de datos y de administración no afecten negativamente al plano de control. Si un evento del plano de datos, como un ataque DoS, afecta al plano de control, toda la red puede volverse inestable. La siguiente información sobre las configuraciones y las funciones de Cisco IOS Software puede ayudar a asegurar la resistencia del plano control.

Consolidación del Plano de Control General

La protección del plano de control de un dispositivo de red es fundamental porque el plano de control garantiza que los planos de gestión y de datos se mantienen y funcionan. Si el plano de control se vuelve inestable durante un incidente de seguridad, puede ser imposible recuperar la estabilidad de la red.

En muchos casos, puede inhabilitar la recepción y la transmisión de ciertos tipos de mensajes en una interfaz para minimizar la cantidad de carga de la CPU necesaria para procesar paquetes innecesarios.

Mensajes de Redirección ICMP IP

Un mensaje de redirección ICMP puede ser generado por un router cuando un paquete se recibe y se transmite en la misma interfaz. En esta situación, el router reenvía el paquete y envía un mensaje de redirección ICMP al remitente del paquete original. Este comportamiento le permite al remitente saltear el router y reenviar los futuros paquetes directamente al destino (o a un router más cercano al destino). En una red IP que funciona sin inconvenientes, un router envía mensajes de redirección solamente a hosts en sus propias subredes locales. En otras palabras, las redirecciones ICMP normalmente nunca van más allá de un límite de Capa 3.

Existen dos tipos de mensajes de redirección ICMP: redirección para una dirección de host y redirección para una subred completa. Un usuario malintencionado puede aprovechar la capacidad del router para enviar redirecciones ICMP mediante la transmisión continua de paquetes al router, lo que obliga al router a responder con mensajes de redirección ICMP y tiene como resultado un impacto adverso en la CPU y el rendimiento del router. Para evitar que el router transmita redirecciones ICMP, utilice el comando de configuración de la no ip redirects interfaz.

Mensajes ICMP de Destino Inalcanzable

La filtración con una lista de acceso a la interfaz provoca la transmisión de mensajes ICMP inalcanzables de vuelta al origen del tráfico filtrado. La generación de estos mensajes puede aumentar el uso de la CPU en el dispositivo. De forma predeterminada, en Cisco IOS Software, la generación de ICMP inalcanzable está limitada a un paquete cada 500 milisegundos. La generación de mensajes de ICMP inalcanzable se puede inhabilitar con el comando de configuración de la interfaz no ip unreachables. El límite de velocidad de ICMP inalcanzable se puede cambiar del valor predeterminado con el comando de configuración global ip icmp rate-limit unreachable interval-in-ms.

Proxy ARP

Proxy ARP es la técnica mediante la cual un dispositivo, normalmente un router, responde a las solicitudes ARP destinadas a otro dispositivo. Al falsificar su identidad, el router acepta la responsabilidad de rutear los paquetes al destino real. El ARP proxy puede ayudar a las máquinas en una subred a alcanzar subredes remotas sin configuración de ruta o un gateway predeterminado. El ARP proxy se define en el RFC 1027.

El uso de ARP proxy tiene sus desventajas. Puede generar un incremento del tráfico de ARP en el segmento de red, agotar los recursos y permitir ataques de intermediarios. Proxy ARP presenta un vector de ataque de agotamiento de recursos porque cada solicitud a la que se aplicó la técnica Proxy ARP consume un poco de memoria. Un atacante puede agotar toda la memoria disponible si envía una gran cantidad de solicitudes ARP.

Los ataques de intrusos permiten a un host de la red suplantar la dirección MAC del router, lo que da lugar a que los hosts transmitan tráfico de forma inadvertida al atacante. El ARP proxy se puede inhabilitar con el comando de configuración de la interfaz no ip proxy-arp.

Limite el impacto del tráfico del plano de control sobre la CPU

La protección del plano de control es crucial. Dado que el rendimiento de las aplicaciones y la experiencia del usuario final pueden verse afectados si no hay tráfico de datos y de gestión, la supervivencia del plano de control garantiza que los otros dos planos se mantengan y estén operativos.

Comprenda el tráfico del plano de control

Para proteger correctamente el plano de control del dispositivo Cisco IOS, es esencial entender los tipos de tráfico que son conmutados por proceso por la CPU. El tráfico conmutado de proceso normalmente consta de dos tipos de tráfico diferentes. El primer tipo de tráfico se dirige al dispositivo Cisco IOS y debe ser manejado directamente por la CPU del dispositivo Cisco IOS. Este tráfico consiste en la categoría de tráfico de adyacencia de recepción. Este tráfico contiene una entrada en la tabla Cisco Express Forwarding (CEF), por la cual el siguiente salto del router es el propio dispositivo, lo que se indica mediante el término receive en la salida de la show ip cef CLI. Esta indicación es la misma para cualquier dirección IP que requiere el manejo directo de parte del CPU del dispositivo Cisco IOS, que incluye direcciones IP de la interfaz, espacio de dirección de multicast y espacio de dirección de broadcast.

El segundo tipo de tráfico manejado por la CPU es el tráfico del plano de datos: tráfico con un destino más allá del propio dispositivo Cisco IOS, que requiere un procesamiento especial de la CPU. Aunque no es una lista exhaustiva de los impactos de la CPU del tráfico del plano de datos, estos tipos de tráfico son conmutados por proceso y, por lo tanto, pueden afectar al funcionamiento del plano de control:

• Registro de lista de control de acceso: el tráfico de registro de ACL consiste en cualquier paquete generado debido a una coincidencia (permiso o denegación) de una ACE en la que se utiliza la palabra clave log.
  
  
• Unicast Reverse Path Forwarding (Unicast RPF): El RPF unidifusión, utilizado con una ACL, puede dar lugar a la conmutación del proceso de ciertos paquetes.
  
  
• Opciones de IP: La CPU debe procesar todos los paquetes de IP que incluyan opciones.
  
  
• Fragmentación - Cualquier paquete IP que requiera fragmentación debe ser pasado a la CPU para ser procesado.
  
  
• Vencimiento del tiempo de vida (TTL): Los paquetes con un valor TTL inferior o igual a uno requieren que se envíen mensajes de Internet Control Message Protocol Time Exceeded (ICMP tipo 11, código 0), lo que se traduce en el procesamiento de la CPU.
  
  
• ICMP de destino inalcanzable: la CPU procesa los paquetes que resultan en mensajes de ICMP de destino inalcanzable debido a su ruta, MTU o filtrado.
  
  
• Tráfico que Requiere una Solicitud ARP - La CPU procesa los destinos para los cuales no existe una entrada ARP.
  
  
• Tráfico que no es de IP: La CPU procesa todo el tráfico que no es de IP.

Esta lista detalla varios métodos para determinar qué tipos de tráfico debe procesar la CPU del dispositivo Cisco IOS:

• El show ip cef comando proporciona la información de siguiente salto para cada prefijo IP contenido en la tabla CEF. Tal como se indicó previamente, las entradas que contienen el término receive como "Salto Siguiente" son consideradas receive adjacencies e indican que el tráfico se debe enviar directamente al CPU.
  
  
• El show interface switching comando proporciona información sobre el número de paquetes que son conmutados por proceso por un dispositivo.
  
  
• El show ip traffic comando proporciona información sobre el número de paquetes IP:
  
  
  • con un destino local (es decir, tráfico del tipo receive adjacency)
  • con opciones
  • que requieren fragmentación
  • que se envían al espacio de dirección de broadcast
  • que se envían al espacio de dirección de multicast
    
    
• El tráfico del tipo receive adjacency puede ser identificado con el uso del comando show ip cache flow. Cualquier flujo destinado al dispositivo Cisco IOS tiene una interfaz de destino (DstIf) de local.
  
  
• Control Plane Policing se puede utilizar para identificar el tipo y la velocidad del tráfico que alcanza el plano de control del dispositivo Cisco IOS. La regulación del plano de control se puede realizar mediante el uso de ACL de clasificación granular, registros y el show policy-map control-plane comando.

ACL de Infraestructura

Las ACL de infraestructura (iACLs) limitan la comunicación externa con los dispositivos de la red. Las iACL se tratan ampliamente en la sección Acceso Limitado a la Red con ACL de Infraestructura de este documento.

Se recomienda implementar iACL para proteger el plano de control de todos los dispositivos de red.

ACL de recepción

En el caso de plataformas distribuidas, las listas de control de acceso de recepción (rACL) pueden ser una opción para Cisco IOS Software Releases 12.0(21)S2 para 12000 (GSR), 12.0(24)S para 7500 y 12.0(31)S para 10720. Una rACL protege el dispositivo contra el tráfico dañino antes de que este afecte al procesador de ruta. Las rACL están diseñadas para proteger solamente el dispositivo en el que está configurado y el tráfico de tránsito no se ve afectado por una rACL. Como resultado, la dirección IP de destino "any" utilizada en las entradas de ACL de ejemplo que se muestran, sólo hace referencia a las direcciones IP físicas o virtuales del router. Las rACL también se consideran una práctica recomendada de seguridad de la red y pueden considerarse como una adición a largo plazo a una buena seguridad de la red.

Esta es la ACL de trayectoria de recepción que se escribe para permitir el tráfico SSH (TCP puerto 22) de hosts confiables en la red 192.168.100.0/24:

!
!--- Permit SSH from trusted hosts allowed to the device.
!

access-list 151 permit tcp 192.168.100.0 0.0.0.255 any eq 22
!
!--- Deny SSH from all other sources to the RP.
!

access-list 151 deny tcp any any eq 22
!
!--- Permit all other traffic to the device.
!--- according to security policy and configurations.
!

access-list 151 permit ip any any
!
!--- Apply this access list to the receive path.
!

ip receive access-list 151
!

Consulte GSR: Listas de Control de Acceso de Recepción para ayudar a identificar y permitir el tráfico legítimo a un dispositivo y denegar todos los paquetes no deseados.

CoPP

La función CoPP también se puede utilizar para restringir los paquetes IP destinados al dispositivo de infraestructura. En este ejemplo, solamente el tráfico SSH de hosts confiables está permitido para alcanzar el CPU del dispositivo Cisco IOS. 

Nota: El tráfico descartado de direcciones IP desconocidas o no confiables puede evitar que los hosts con direcciones IP asignadas dinámicamente establezcan una conexión con el dispositivo Cisco IOS.

!

access-list 152 deny tcp <trusted-addresses> <mask> any eq 22
access-list 152 permit tcp any any eq 22
access-list 152 deny ip any any
!

class-map match-all COPP-KNOWN-UNDESIRABLE
 match access-group 152
!

policy-map COPP-INPUT-POLICY
 class COPP-KNOWN-UNDESIRABLE
  drop
!

control-plane
 service-policy input COPP-INPUT-POLICY
!

En el ejemplo anterior de CoPP, en las entradas de ACL, los paquetes no autorizados que coincidían con la acción de permitir se desechaban mediante la función de rechazo de mapa de políticas, mientras que los paquetes que coincidían con la acción de rechazar no se veían afectados por dicha función.

La función CoPP está disponible en las versiones 12.0S, 12.2SX, 12.2S, 12.3T, 12.4 y 12.4T de Cisco IOS Software.

Función Control Plane Protection

La protección del plano de control (CPPr), introducida en Cisco IOS Software Release 12.4(4)T, se puede utilizar para restringir o controlar el tráfico del plano de control destinado a la CPU del dispositivo Cisco IOS. Si bien es similar a CoPP, CPPr puede restringir el tráfico con mayor granularidad. La CPPr divide el plano de control agregado en tres categorías de plano de control independientes conocidas como subinterfaces. Las subinterfaces existen para las categorías de tráfico Host, Transit y CEF-Exception. Además, CPPr incluye estas funciones de protección del plano de control:

• Función de filtrado de puertos: esta función permite controlar y descartar los paquetes enviados a puertos UDP o TCP cerrados o sin escucha.
  
  
• Función de umbral de cola: Esta función limita el número de paquetes para un protocolo especificado permitido en la cola de entrada IP del plano de control.

Consulte Comprensión de la Protección del Plano de Control (CPPr) para obtener más información sobre el uso de la función CPPr.

Limitadores de Velocidad Basados en Hardware

Cisco Catalyst 6500 Series Supervisor Engine 32 y Supervisor Engine 720 admiten limitadores de velocidad basados en hardware (HWRL) específicos de la plataforma para escenarios de red especiales. Estos limitadores de la velocidad del hardware son conocidos como limitadores de velocidad para casos especiales porque abarcan un conjunto predefinido específico de escenarios de negación de servicio de IPv4, IPv6, unicast y multicast. Los HWRL pueden proteger el dispositivo Cisco IOS de una variedad de ataques que requieren que los paquetes sean procesados por la CPU.

Hay varios HWRL habilitados de forma predeterminada. Consulte Configuraciones Predeterminadas del Limitador de Velocidad Basado en Hardware PFC3 para obtener más información sobre los HWRL.

Consulte Configuraciones Predeterminadas de Limitador de Velocidad Basado en Hardware PFC3 para obtener más información sobre HWRL.

Proteja el protocolo BGP

El protocolo Border Gateway Protocol (BGP) es la base de ruteo de Internet. Las organizaciones con requisitos no modestos de conectividad suelen emplear BGP. El BGP es a menudo el objetivo de los atacantes debido a su ubicuidad y a la naturaleza de set and Forget de las configuraciones BGP en las organizaciones más pequeñas. Sin embargo, hay muchas funciones de seguridad específicas de BGP que se pueden aprovechar para aumentar la seguridad de una configuración BGP.

Esto proporciona una descripción general de las funciones de seguridad de BGP más importantes y, cuando corresponde, se hacen recomendaciones de configuración.

Protecciones de Seguridad Basadas en TTL

Cada paquete IP contiene un campo de 1 byte conocido como Tiempo de Vida (TTL). Cada dispositivo que un paquete del IP cruza reduce este valor en uno. El valor inicial de TTL varía según el sistema operativo y normalmente oscila entre 64 y 255. Un paquete se descarta cuando su valor TTL alcanza cero.

Conocida como Generalized TTL-based Security Mechanism (GTSM) y como BGP TTL Security Hack (BTSH), una protección de seguridad basada en TTL aprovecha el valor TTL de los paquetes IP para garantizar que los paquetes BGP recibidos proceden de un peer conectado directamente. Esta función a menudo requiere coordinación de los routers pares; sin embargo, una vez habilitada, puede derrotar completamente muchos ataques basados en TCP contra BGP.

GTSM para BGP se habilita con la ttl-security opción para el comando de configuración del router neighbor BGP. Este ejemplo ilustra la configuración de esta función:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> ttl-security hops <hop-count>
!

A medida que se reciben paquetes BGP, se verifica el valor TTL y debe ser mayor o igual a 255, menos el conteo de saltos especificado.

Autenticación de Peer BGP con MD5

La autenticación de pares con MD5 genera un resumen de MD5 para cada paquete enviado en sesiones de BGP. Específicamente, partes de los encabezados IP y TCP, la carga TCP y una clave secreta se utilizan para generar el resumen.

El resumen creado se guarda en la opción Kind 19 de TCP, creada específicamente para este fin por RFC 2385. El altavoz BGP del destinatario utiliza el mismo algoritmo y la misma clave secreta para regenerar el resumen del mensaje. Si los resúmenes recibidos y computados no son idénticos, se descarta el paquete.

La autenticación de par con MD5 se configura con la password opción del comando de configuración del router neighbor BGP. El uso de este comando se ilustra aquí:

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> password <secret>
!

Consulte Autenticación de Router Vecino para obtener más información sobre la autenticación de peer BGP con MD5.

Configure el máximo de prefijos

Los prefijos BGP son guardados por un router en la memoria. Cuantos más prefijos debe contener un router, más memoria consume BGP. En algunas configuraciones, se puede almacenar un subconjunto de todos los prefijos de Internet, como en configuraciones que aprovechan sólo una ruta o rutas predeterminadas para las redes de usuarios del proveedor.

Para evitar el agotamiento de la memoria, configure el número máximo de prefijos aceptados por par. Se recomienda que se configure un límite para cada peer BGP.

Cuando configura esta función con el comando de configuración del router neighbor maximum-prefix BGP, se requiere un argumento: el número máximo de prefijos aceptados antes de que se cierre un par. Opcionalmente, se puede ingresar un número del 1 al 100. Este número representa el porcentaje del valor máximo de prefijos en cuanto al momento en que se envía un mensaje de registro.

!

router bgp <asn>
 neighbor <ip-address> remote-as <remote-asn>
 neighbor <ip-address> maximum-prefix <shutdown-threshold> <log-percent>
!

Consulte Configuración de la Función de Número Máximo de Prefijos BGP para obtener más información sobre los prefijos máximos por peer.

Filtre los prefijos de BGP mediante listas de prefijos

Las listas de prefijos permiten que un administrador de red permita o deniegue prefijos específicos enviados o recibidos por BGP. Utilice listas de prefijos, siempre que sea posible, para asegurarse de que el tráfico de red se envía por las rutas deseadas. Aplique listas de prefijos a cada par eBGP en las direcciones entrante y saliente.

Las listas de prefijos configuradas limitan los prefijos enviados o recibidos a aquellos específicamente permitidos por la política de ruta de una red. Si esto no es factible debido al gran número de prefijos recibidos, configure una lista de prefijos para bloquear específicamente los prefijos malos conocidos. Estos prefijos malintencionados conocidos incluyen el espacio de direcciones IP no asignadas y las redes reservadas para fines internos o de prueba por RFC 3330. Configure las listas de prefijos salientes para permitir específicamente sólo los prefijos que una organización pretende anunciar.

Este ejemplo de configuración utiliza listas de prefijos para limitar las rutas que se aprenden y publican. Específicamente, la lista de prefijos BGP-PL-INBOUND permite el ingreso de solamente una ruta predeterminada, y el prefijo 192.168.2.0/24 es la única ruta permitida para ser publicada por BGP-PL-OUTBOUND.

!

ip prefix-list BGP-PL-INBOUND seq 5 permit 0.0.0.0/0
ip prefix-list BGP-PL-OUTBOUND seq 5 permit 192.168.2.0/24
!

router bgp <asn>
 neighbor <ip-address> prefix-list BGP-PL-INBOUND in
 neighbor <ip-address> prefix-list BGP-PL-OUTBOUND out
!

Consulte Conexión a un Proveedor de Servicios Usando BGP Externo para obtener una cobertura completa de la información de filtro de prefijo BGP.

Filtre los prefijos de BGP mediante listas de acceso a la ruta del sistema autónomo

Las listas de acceso de trayectoria del sistema autónomo (AS) BGP permiten al usuario filtrar los prefijos recibidos y anunciados en función del atributo AS-path de un prefijo. Esto se puede utilizar con listas de prefijos para establecer un sólido conjunto de filtros.

Este ejemplo de configuración utiliza listas de acceso de trayectoria del sistema autónomo para restringir los prefijos entrantes a aquellos originados por el sistema autónomo remoto y los prefijos salientes a aquellos originados por el sistema autónomo local. Los prefijos originados en todos los otros sistemas autónomos se filtran y no se instalan en la tabla de ruteo.

!

ip as-path access-list 1 permit ^65501$
ip as-path access-list 2 permit ^$
!

router bgp <asn>
 neighbor <ip-address> remote-as 65501
 neighbor <ip-address> filter-list 1 in
 neighbor <ip-address> filter-list 2 out
!

Proteja los protocolos de gateway interior

La capacidad de una red para reenviar correctamente el tráfico y recuperarse de cambios o fallos de topología depende de una vista precisa de la topología. A menudo, puede ejecutar un protocolo de gateway interior (IGP) para proporcionar esta vista. De forma predeterminada, los protocolos IGP son dinámicos y descubren los routers adicionales que se comunican con el IGP en particular que se encuentra funcionando. Los IGP también detectan rutas que se pueden utilizar cuando falla un link de red.

Las siguientes subsecciones describen en términos generales las funciones de seguridad de IGP más importantes. Cuando corresponda, se incluyen recomendaciones y ejemplos que abarcan Routing Information Protocol Version 2 (RIPv2), Enhanced Interior Gateway Routing Protocol (EIGRP) y Open Shortest Path First (OSPF).

Autenticación y Verificación de Protocolo de Ruteo con Message Digest 5

Si no se logra asegurar el intercambio de información de ruteo, un atacante puede introducir información de ruteo falsa en la red. Utilice la autenticación de contraseña con protocolos de ruteo entre routers para ayudar a la seguridad de la red. Sin embargo, puesto que esta autenticación se envía como texto sin formato, un atacante puede destruir este control de seguridad sin inconvenientes.

Cuando se agregan capacidades de hash MD5 al proceso de autenticación, las actualizaciones de ruteo ya no contienen contraseñas de texto sin formato, y todo el contenido de la actualización de ruteo es más resistente a las manipulaciones. Sin embargo, la autenticación MD5 sigue siendo susceptible a la fuerza bruta y a los ataques de diccionario si se utilizan contraseñas débiles. Se recomienda el uso de contraseñas con suficiente distribución al azar. Puesto que la autenticación MD5 es mucho más segura en comparación con la autenticación de contraseña, estos ejemplos son específicos para la autenticación MD5. IPSec también se puede utilizar para validar y proteger protocolos de routing, pero estos ejemplos no detallan su uso.

Tanto EIGRP como RIPv2 utilizan Key Chains como parte de la configuración. Consulte clave para obtener más información sobre la configuración y el uso de Key Chains.

Este es un ejemplo de configuración para la autenticación del router EIGRP que utiliza MD5:

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip authentication mode eigrp <as-number> md5
 ip authentication key-chain eigrp <as-number> <key-name>
!

Esto es un ejemplo de configuración de la autenticación de router MD5 para RIPv2. RIPv1 no admite la autenticación.

!

key chain <key-name>
 key <key-identifier>
 key-string <password> 
!

interface <interface>
 ip rip authentication mode md5
 ip rip authentication key-chain <key-name>
!

Este es un ejemplo de configuración para la autenticación de router OSPF con MD5. OSPF no utiliza Key Chains.

!

interface <interface>
 ip ospf message-digest-key <key-id> md5 <password>
!

router ospf <process-id>
 network 10.0.0.0 0.255.255.255 area 0
 area 0 authentication message-digest
!

Consulte Configuración de OSPF para obtener más información.

Comando Passive-Interface

Las filtraciones de información, o la introducción de información falsa en un IGP, se pueden mitigar mediante el uso del passive-interface comando que ayuda con el control del anuncio de la información de ruteo. Se le aconseja no anunciar ninguna información a las redes fuera de su control administrativo.

Este ejemplo demuestra el uso de esta función:

!

router eigrp <as-number> 
 passive-interface default
 no passive-interface <interface>
!

Filtrado de Rutas

Para reducir la posibilidad de que introduzca información de ruta falsa en la red, utilice el filtrado de rutas. A diferencia del comando de configuración del passive-interface router, el ruteo ocurre en las interfaces una vez que se habilita el filtrado de rutas, pero la información que se anuncia o procesa es limitada.

Para EIGRP y RIP, el uso del distribute-list comando con la palabra out clave limita la información anunciada, mientras que el uso de la palabra in clave limita las actualizaciones procesadas. El distribute-list comando está disponible para OSPF, pero no impide que un router propague las rutas filtradas. En su lugar, se puede utilizar el area filter-list comando.

Este ejemplo de EIGRP filtra los anuncios salientes con el distribute-list comando y una lista de prefijos:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> out <interface>
!

Este ejemplo de EIGRP filtra las actualizaciones entrantes con una lista de prefijos:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router eigrp <as-number>
 passive-interface default
 no passive-interface <interface>
 distribute-list prefix <list-name> in <interface>
!

Este ejemplo de OSPF utiliza una lista de prefijos con el OSPF específico area filter-list command:

!

ip prefix-list <list-name> seq 10 permit <prefix> 
!

router ospf <process-id>
 area <area-id> filter-list prefix <list-name> in 
!

Consumo de Recursos del Proceso de Ruteo

Los prefijos del Routing Protocol son almacenados por un router en la memoria, y el consumo de recursos aumenta con los prefijos adicionales que un router debe contener. Para evitar el agotamiento de los recursos, configure el protocolo de ruteo para limitar el consumo de recursos. Esto es posible con OSPF si se emplea la función de protección de sobrecarga de base de datos de estado de enlaces.

Este ejemplo demuestra la configuración de la función de protección contra sobrecarga de base de datos de estado de link de OSPF:

!

router ospf <process-id>
 max-lsa <maximum-number> 
!

Proteja los protocolos de redundancia de primer salto

Estos protocolos FHRP ofrecen recuperabilidad y redundancia para dispositivos que actúan como gateways predeterminados. Esta situación y estos protocolos son corrientes en entornos en los que un par de dispositivos de la Capa 3 funciona como gateway predeterminado para un segmento de red o un conjunto de VLAN que contengan servidores o estaciones de trabajo.

Los protocolos Gateway Load-Balancing Protocol (GLBP), Hot Standby Router Protocol (HSRP) y Virtual Router Redundancy Protocol son FHRP. De forma predeterminada, estos protocolos se comunican con mensajes no autenticados. Este tipo de comunicación puede permitir que un atacante se haga pasar por un dispositivo compatible con FHRP para asumir la función de gateway predeterminada en la red. Esta adquisición permite a un atacante realizar un ataque de intrusos e interceptar todo el tráfico de usuarios que sale de la red.

Para evitar este tipo de ataque, todos los FHRPs soportados por el software del IOS de Cisco incluyen una capacidad de autenticación con MD5 o cadenas de texto. Debido a la amenaza planteada por los FHRP no autenticados, se recomienda que las instancias de estos protocolos utilicen autenticación MD5. Este ejemplo de configuración demuestra el uso de autenticación MD5 para GLBP, HSRP y VRRP:

!

interface FastEthernet 1
 description *** GLBP Authentication ***
 glbp 1 authentication md5 key-string <glbp-secret>
 glbp 1 ip 10.1.1.1
!

interface FastEthernet 2
 description *** HSRP Authentication ***
 standby 1 authentication md5 key-string <hsrp-secret>
 standby 1 ip 10.2.2.1
!

interface FastEthernet 3
 description *** VRRP Authentication ***
 vrrp 1 authentication md5 key-string <vrrp-secret> 
 vrrp 1 ip 10.3.3.1
!

Plano de Datos

Aunque el plano de datos es responsable de mover datos del origen al destino, en el contexto de la seguridad, el plano de datos es el menos importante de los tres planos. Por esta razón, es importante proteger los planos de administración y control con preferencia sobre el plano de datos cuando se protege un dispositivo de red .

Sin embargo, dentro del plano de datos, hay muchas funciones y opciones de configuración que pueden ayudar a asegurar el tráfico. En estas secciones se detallan las funciones y opciones para que pueda proteger su red con mayor facilidad.

Consolidación del Plano de Datos General

La gran mayoría del tráfico del plano de datos fluye a través de la red según lo determinado por la configuración de ruteo de la red. Sin embargo, existen funciones de red IP que permiten alterar la trayectoria de los paquetes a través de la red. Las funciones, como las opciones IP, en concreto la opción de routing de origen, suponen un reto para la seguridad de las redes actuales.

El uso de ACL de tránsito también es relevante para fortalecer el plano de datos.

Para obtener más información, vea la sección Filtrado de Tráfico de Tránsito con ACL de Tránsito.

IP Options Selective Drop

Las opciones IP plantean dos problemas de seguridad. El tráfico que contiene opciones IP debe ser conmutado por proceso por los dispositivos Cisco IOS, lo que puede conducir a una carga de CPU elevada. Las opciones IP también incluyen la funcionalidad de alterar la ruta que el tráfico toma a través de la red, lo que potencialmente le permite subvertir los controles de seguridad.

Debido a estos problemas, el comando de configuración global se ip options {drop | ignore} ha agregado a las versiones 12.3(4)T, 12.0(22)S y 12.2(25)S del software del IOS de Cisco. En la primera forma de este comando, ip options dropse descartan todos los paquetes IP que contienen opciones IP recibidos por el dispositivo Cisco IOS. De esta manera se evita una carga elevada del CPU y la posible destrucción de los controles de seguridad que las opciones IP pueden habilitar.

La segunda forma de este comando, ip options ignore, configura el dispositivo Cisco IOS para ignorar las opciones IP contenidas en los paquetes recibidos. Aunque esto mitiga las amenazas relacionadas con las opciones IP para el dispositivo local, es posible que los dispositivos de flujo descendente se vean afectados por la presencia de opciones IP. Por esta razón, se recomienda encarecidamente la drop forma de este comando. Como se muestra en este ejemplo de configuración:

!
ip options drop
!

Algunos protocolos, por ejemplo el RSVP, hacen un uso legítimo de las opciones IP. El funcionamiento de estos protocolos se ve afectado por este comando.

Una vez que se ha habilitado IP Options Selective Drop, el show ip traffic EXEC comando se puede utilizar para determinar el número de paquetes que se descartan debido a la presencia de opciones IP. Esta información está presente en el contador de forced drop.

Inhabilitación de Ruteo de Origen de IP

El ruteo de origen IP aprovecha las opciones Loose Source Route y Record Route, en tándem; o Strict Source Route, junto con la opción Record Route para habilitar el origen de datagrama IP para especificar la trayectoria de red que toma un paquete. Esta funcionalidad se puede utilizar para intentar enrutar el tráfico alrededor de los controles de seguridad de la red.

Si las opciones IP no han sido completamente inhabilitadas por la función IP Options Selective Drop, es importante que el ruteo de origen IP esté inhabilitado. El ruteo de IP de origen, que está habilitado de forma predeterminada en todas las versiones de Cisco IOS Software, se inhabilita mediante el comando de configuración no ip source-route global. Este ejemplo de configuración ilustra el uso de este comando:

!
no ip source-route
!

Inhabilitación de Mensajes de Redirección ICMP

Las redirecciones ICMP se utilizan para informar a un dispositivo de red de una mejor trayectoria a un destino IP. De forma predeterminada, Cisco IOS Software envía un mensaje de redirección si recibe un paquete que se debe rutear a través de la interfaz por la cual fue recibido.

En algunas situaciones, puede ser posible que un atacante haga que el dispositivo Cisco IOS envíe muchos mensajes de redirección ICMP, lo que resulta en una carga de CPU elevada. Por esta razón, se recomienda desactivar la transmisión de redirecciones ICMP. Las redirecciones ICMP están inhabilitadas con el no ip redirects comando de configuración de interfaz, como se muestra en este ejemplo de configuración:

!

interface FastEthernet 0
 no ip redirects
!

Inhabilitación o Limitación de Broadcasts Dirigidos a IP

Los Broadcasts Dirigidos a IP permiten enviar un paquete de broadcast IP a una subred IP remota. Una vez que el paquete llega a la red remota, el dispositivo IP de reenvío envía el paquete como una difusión de Capa 2 a todas las estaciones de la subred. Esta función de difusión dirigida se ha aprovechado como ayuda de amplificación y reflexión en varios ataques, entre los que se incluye el ataque smurf.

De forma predeterminada, las versiones actuales del software del IOS de Cisco tienen esta funcionalidad inhabilitada; sin embargo, se puede habilitar mediante el comando de configuración de la ip directed-broadcast interfaz. De forma predeterminada, las versiones de Cisco IOS Software anteriores a la 12.0 tienen esta funcionalidad habilitada.

Si una red requiere absolutamente la funcionalidad de broadcast dirigido, controle su uso. Esto es posible con el uso de una ACL como opción para el ip directed-broadcast comando. Este ejemplo de configuración limita las difusiones dirigidas a los paquetes UDP que se originan en una red de confianza, 192.168.1.0/24:

!

access-list 100 permit udp 192.168.1.0 0.0.0.255 any
!

interface FastEthernet 0
 ip directed-broadcast 100
!

Filtre el tráfico en tránsito con ACL de tránsito

Mediante las ACL de tránsito (tACL) se puede controlar qué tráfico transita por las redes. Esto contrasta con las iACL que buscan filtrar el tráfico destinado a la propia red. El filtro proporcionado por las tACL es beneficioso cuando el objetivo es filtrar el tráfico a un grupo particular de dispositivos o el tráfico que transita por la red.

Tradicionalmente, los firewalls realizan este tipo de filtro. Sin embargo, hay casos en los que puede ser beneficioso realizar este filtro en un dispositivo Cisco IOS en la red. Por ejemplo, donde debe realizarse el filtrado pero no hay firewall presente.

Las tACL también son un lugar adecuado para implementar protecciones estáticas contra la suplantación.

Para obtener más información, consulte la sección Protecciones contra la suplantación de identidad.

Consulte Listas de Control de Acceso de Tránsito: Filtrado en el Borde para obtener más información sobre las tACL.

Filtrado de Paquetes ICMP

El protocolo Internet Control Message Protocol (ICMP) fue diseñado como protocolo de control para IP. Como tal, los mensajes que transmite pueden tener ramificaciones significativas en los protocolos TCP e IP en general. El ICMP es utilizado por las herramientas ping y traceroute, para resolver problemas de la red, así como por Path MTU Discovery. Sin embargo, la conectividad ICMP externa rara vez es necesaria para el funcionamiento correcto de la red.

Cisco IOS Software proporciona una función para filtrar mensajes ICMP específicamente por nombre o tipo y código. Esta ACL de ejemplo permite el ICMP de redes confiables, mientras que bloquea todos los paquetes ICMP de otras fuentes:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Permit ICMP packets from trusted networks only
!

 permit icmp host <trusted-networks> any 
!
!--- Deny all other IP traffic to any network device
!

 deny icmp any any
!

Filtrar fragmentos IP

Como se detalló anteriormente en la sección Limitar el Acceso a la Red con ACL de Infraestructura de este documento, el filtro de paquetes IP fragmentados puede plantear un desafío para los dispositivos de seguridad.

Debido a la naturaleza no intuitiva del control de fragmentos, las ACL a menudo permiten inadvertidamente los fragmentos IP. La fragmentación también se usa con frecuencia para intentar evadir la detección mediante sistemas de detección de intrusión. Por estas razones, los fragmentos IP se utilizan a menudo en ataques y se pueden filtrar explícitamente en la parte superior de cualquier tACL configurada. El ejemplo de ACL que se muestra incluye un filtro completo de fragmentos IP. La funcionalidad ilustrada en este ejemplo se debe utilizar con la funcionalidad de los ejemplos anteriores:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP fragments using protocol-specific ACEs to aid in 
!--- classification of attack traffic
!

 deny tcp any any fragments
 deny udp any any fragments
 deny icmp any any fragments
 deny ip any any fragments
!

Consulte Listas de control acceso y fragmentos de IP para ver más información sobre cómo actúan las ACL ante los paquetes de IP fragmentados.

Soporte ACL para Filtrar las Opciones IP

En Cisco IOS Software Release 12.3(4)T y posteriores, Cisco IOS Software soporta el uso de ACL para filtrar paquetes IP, según las opciones IP contenidas en el paquete. La presencia de opciones IP dentro de un paquete puede indicar un intento de subvertir los controles de seguridad en la red o alterar de alguna otra manera las características de tránsito de un paquete. Por estas razones, se recomienda filtrar los paquetes con opciones IP en el borde de la red.

Utilice este ejemplo, junto con el contenido de los ejemplos anteriores, para incluir un filtro completo para los paquetes IP que contienen opciones IP:

!

ip access-list extended ACL-TRANSIT-IN
!
!--- Deny IP packets containing IP options
!

 deny ip any any option any-options
!

Protecciones Contra Suplantación

En muchos ataques, se falsifica la dirección IP de origen para ganar eficacia u ocultar el origen verdadero y así entorpecer el rastreo. Cisco IOS Software proporciona Unicast RPF e IP Source Guard (IPSG) para disuadir los ataques que se basan en la suplantación de dirección IP de origen. Además, las ACL y el ruteo nulo suelen implementarse como métodos manuales de prevención de la suplantación.

El IPSG trabaja para minimizar la suplantación de identidad para las redes bajo control administrativo directo mediante el rendimiento del puerto del switch, la dirección MAC y la verificación de la dirección de origen. Unicast RPF proporciona verificación de la red de origen y puede reducir los ataques simulados de redes que no están bajo control administrativo directo. Port Security se puede utilizar para validar direcciones MAC en la capa de acceso. La inspección del protocolo de resolución de direcciones (ARP) dinámica (DAI) mitiga los vectores de ataque que contaminan ARP en los segmentos locales.

Unicast RPF

Unicast RPF permite que un dispositivo verifique que la dirección de origen de un paquete reenviado puede ser alcanzada a través de la interfaz que recibió el paquete. No confíe en Unicast RPF como la única protección contra la suplantación. Los paquetes suplantados podrían ingresar a la red a través de una interfaz habilitada para Unicast RPF si existe una ruta de regreso a la dirección IP de origen apropiada. Con RPF unicast, usted debe activar Cisco Express Forwarding en cada dispositivo, y la configuración se hace en cada interfaz.

RPF unidifusión se puede configurar en uno de dos modos: amplio o estricto. Si el ruteo es asimétrico, se prefiere el modo flexible porque se sabe que el modo estricto descarta paquetes en estas situaciones. Durante la configuración del comando ip verify interface configuration, la palabra clave any configura el modo flexible mientras que la palabra clave rx configura el modo estricto.

Este ejemplo ilustra la configuración de esta función:

!

ip cef
!

interface <interface>
  ip verify unicast source reachable-via <mode>
!

Consulte Comprensión de Unicast Reverse Path Forwarding para obtener más información sobre la configuración y el uso de Unicast RPF.

IP Source Guard

IP Source Guard es una función eficaz para la prevención de la suplantación que se puede utilizar si usted tiene control de las interfaces de la Capa 2. IP Source Guard utiliza información de DHCP snooping para configurar dinámicamente una lista de control de acceso a puertos (PACL) en la interfaz de Capa 2, negando cualquier tráfico de direcciones IP que no estén asociadas en la tabla de enlace de IP de origen.

IP Source Guard se puede aplicar a las interfaces de Capa 2 que pertenecen a las VLAN habilitadas para snooping DHCP. Estos comandos habilitan la función DHCP snooping:

!

ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Después de que se habilite la función DHCP snooping, estos comandos habilitan IPSG:

!
interface <interface-id>
   ip verify source 
!

La seguridad de puertos se puede habilitar con el comando de configuración de la Tip verify source port security interfaz. Esto requiere el comando de configuración global ip dhcp snooping information option; además, el servidor DHCP debe soportar la opción DHCP 82.

Consulte Configuración de funciones de DHCP y de IP Source Guard para obtener más información sobre esta función.

Seguridad de Puertos

Port Security se utiliza para mitigar la suplantación de direcciones MAC en la interfaz de acceso. Port Security puede utilizar direcciones MAC (sticky) aprendidas dinámicamente para facilitar la configuración inicial. Una vez que la seguridad de puertos determina una infracción de MAC, puede usar uno de los cuatro modos de infracción. Estos modos son: proteger, restringir, apagar y apagar la VLAN. En los casos en que un puerto sólo proporciona acceso a una estación de trabajo con el uso de protocolos estándar, puede ser suficiente un número máximo de uno. Los protocolos que aprovechan las direcciones MAC virtuales, como HSRP, no funcionan cuando el número máximo se establece en uno.

!

interface <interface> 
  switchport
  switchport mode access 
  switchport port-security
  switchport port-security mac-address sticky
  switchport port-security maximum <number>
  switchport port-security violation <violation-mode>
!

Consulte Configuración de la seguridad de puertos para ver más información.

Dynamic ARP Inspection

Dynamic ARP Inspection (DAI) se puede utilizar para mitigar los ataques de envenenamiento ARP en segmentos locales. Un ataque mediante envenenamiento ARP es un método en el cual un atacante envía información sobre ARP falsificada a un segmento local. Esta información tiene como finalidad corromper la memoria caché ARP de otros dispositivos. A menudo, un atacante utiliza el envenenamiento ARP para realizar un ataque de intrusos.

La función DAI intercepta y valida la relación de dirección de IP a MAC de todos los paquetes ARP en los puertos no confiables. En los entornos de DHCP, DAI emplea los datos generados por la función de detección DHCP. Los paquetes ARP que se reciben en las interfaces confiables no se validan y los paquetes no válidos en las interfaces no confiables se descartan. En entornos no DHCP, se necesita usar ACL ARP.

Estos comandos habilitan la función DHCP snooping:

!
ip dhcp snooping
ip dhcp snooping vlan <vlan-range>
!

Una vez habilitada la función DHCP snooping, estos comandos habilitan la función DAI:

!
ip arp inspection vlan <vlan-range> 
!

En entornos no DHCP, se requieren ACL ARP para habilitar DAI. Este ejemplo demuestra la configuración básica de DAI con ACL ARP:

!

arp access-list <acl-name>
 permit ip host <sender-ip> mac host <sender-mac>
!

ip arp inspection filter <arp-acl-name> vlan <vlan-range>
!

DAI también se puede habilitar por interfaz siempre que se admita.

ip arp inspection limit rate <rate_value> burst interval <interval_value>

Consulte Configuración de Dynamic ARP Inspection para obtener más información sobre cómo configurar DAI.

ACL Contra Suplantación

Las ACL de configuración manual pueden brindar protección estática contra la suplantación de identidad para los ataques que emplean espacios conocidos de direcciones no utilizadas y no confiables. Comúnmente, estas ACL de protección contra suplantación se aplican al tráfico de ingreso en los límites de red como componente de una ACL más grande. Las ACL contra la suplantación requieren intervalos de monitoreo regulares porque pueden cambiar con frecuencia. Estos ataques pueden reducirse en el tráfico que se origina en la red local si se aplican ACL salientes que limiten el tráfico hacia direcciones locales válidas.

En este ejemplo se muestra cómo utilizar las ACL para limitar la suplantación de IP. Esta ACL se aplica al tráfico entrante en la interfaz deseada. Las ACE que componen esta ACL no son exhaustivas. Si configura estos tipos de ACL, busque una referencia actualizada que sea concluyente.

!

ip access-list extended ACL-ANTISPOOF-IN
 deny	ip 10.0.0.0 0.255.255.255 any
 deny	ip 192.168.0.0 0.0.255.255 any
!

interface <interface>
 ip access-group ACL-ANTISPOOF-IN in
!

Consulte Configuración de ACL IP de Uso Frecuente para obtener más información sobre cómo configurar Listas de Control de Acceso.

Team Cymru se encarga de mantener la lista oficial de direcciones de Internet. Puede encontrar información adicional sobre cómo filtrar las direcciones no utilizadas en la Página de Referencia de Bogon .

Limite el impacto del tráfico del plano de datos sobre la CPU

La función principal que desempeñan los routers y los switches es reenviar paquetes y tramas a través del dispositivo a los destinos finales. Estos paquetes, que transitan los dispositivos implementados en la red, pueden afectar el funcionamiento del CPU de un dispositivo. Proteja el plano de datos, que consiste en el tráfico que transita por el dispositivo de red, para garantizar el funcionamiento de los planos de gestión y control. Si el tráfico de tránsito puede hacer que un dispositivo procese el tráfico del switch, el plano de control de un dispositivo puede verse afectado, lo que provoca una interrupción operativa.

Funciones y Tipos de Tráfico que Afectan el CPU

Aunque no es exhaustiva, esta lista incluye los tipos de tráfico del plano de datos que requieren un procesamiento de CPU especial y que la CPU conmuta por proceso:

• Registro de ACL: El tráfico de registro de ACL consiste en cualquier paquete generado debido a una coincidencia (permiso o denegación) de una ACE en la que se utiliza la palabra clave log.
  
  
• RPF unidifusión: El RPF unidifusión utilizado con una ACL puede dar lugar a la conmutación del proceso de ciertos paquetes.
  
  
• Opciones de IP: La CPU debe procesar todos los paquetes de IP que incluyan opciones.
  
  
• Fragmentación: La CPU debe recibir y procesar todos los paquetes de IP que exijan fragmentación.
  
  
• Tiempo de vida (TTL) agotado: Los paquetes con un valor de TTL inferior o igual a 1 exigen el envío del mensaje Internet Control Message Protocol Time Exceeded (ICMP Type 11, Code 0) (Se agotó el tiempo del protocolo de mensajería de control de Internet, Tipo de ICMP 11, Código 0), lo cual genera el procesamiento por parte de la CPU.
  
  
• ICMP de destino inalcanzable: la CPU procesa los paquetes que resultan en mensajes de ICMP de destino inalcanzable debido a su ruta, MTU o filtrado.
  
  
• Tráfico que requiere una Solicitud ARP - La CPU procesa los destinos para los cuales no existe una entrada ARP.
  
  
• Tráfico que no es de IP: La CPU procesa todo el tráfico que no es de IP.

Para obtener más información sobre la consolidación del plano de datos, consulte la sección Consolidación del plano de datos general.

Filtre por el valor de TTL

Puede utilizar la función ACL Support for Filtering on TTL Value, introducida en Cisco IOS Software Release 12.4(2)T, en una lista de acceso IP ampliada para filtrar paquetes según el valor TTL. Esta función puede proteger un dispositivo que recibe tráfico de tránsito en el que el valor TTL es cero o uno. El filtro de paquetes basado en valores TTL también se puede utilizar para garantizar que el valor TTL no sea inferior al diámetro de la red, esto protege el plano de control de los dispositivos de infraestructura descendentes de ataques de vencimiento TTL.

Algunas aplicaciones y herramientas, como traceroute utilizar paquetes de vencimiento TTL para fines de prueba y diagnóstico. Algunos protocolos, como IGMP, hacen un uso legítimo de un valor TTL de uno.

Este ejemplo de ACL crea una política que filtra paquetes IP si el valor TTL es inferior a 6.

!
!--- Create ACL policy that filters IP packets with a TTL value
!--- less than 6
!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any ttl lt 6
 permit ip any any
!
!--- Apply access-list to interface in the ingress direction
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Consulte Identificación y Mitigación de Ataques de Vencimiento de TTL para obtener más información sobre cómo filtrar paquetes según el valor de TTL.

Consulte ACL Support for Filtering on TTL Value para obtener más información sobre esta función.

En la versión del software Cisco IOS 12.4(4)T y las posteriores, la concordancia flexible de paquetes (FPM) permite que el administrador compare bits de los paquetes de manera arbitraria. Esta política FPM descarta paquetes con un valor TTL menor que 6.

!

load protocol flash:ip.phdf
!

class-map type access-control match-all FPM-TTL-LT-6-CLASS
 match field IP ttl lt 6
!

policy-map type access-control FPM-TTL-LT-6-DROP-POLICY
 class  FPM-TTL-LT-6-CLASS
  drop
!

interface FastEthernet0
 service-policy type access-control input FPM-TTL-LT-6-DROP-POLICY
!

Filtre por la presencia de opciones de IP

En Cisco IOS Software Release 12.3(4)T y en versiones posteriores, usted puede utilizar la función ACL Support for the Filtering IP Options en una lista de acceso IP ampliada y con nombre para filtrar los paquetes IP que tengan opciones IP presentes. El filtro de paquetes IP basado en la presencia de opciones IP también se puede utilizar para evitar que el plano de control de los dispositivos de infraestructura necesite procesar estos paquetes en el nivel de CPU.

La función ACL Support for Filtering IP Options sólo se puede utilizar con ACL ampliadas y con nombre. RSVP, Multiprotocol Label Switching Traffic Engineering, IGMP Versiones 2 y 3, y otros protocolos que utilizan paquetes de opciones IP no pueden funcionar correctamente si se descartan los paquetes para estos protocolos. Si estos protocolos están en uso en la red, se puede utilizar ACL Support for Filtering IP Options . Sin embargo, la función ACL IP Options Selective Drop puede descartar este tráfico y estos protocolos no pueden funcionar correctamente. Si no se usan protocolos que exijan opciones de IP, el método preferido para rechazar estos paquetes es el del rechazo selectivo de opciones de IP de ACL.

Este ejemplo de ACL crea una política que filtra los paquetes IP que contienen cualquier opción IP:

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option any-options
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Este ejemplo ACL demuestra una política esa los paquetes del IP de los filtros con cinco opciones IP específicas. Se niegan los paquetes que contienen estas opciones:

• 0 End of Options List (eool)
  
  
• 7 Record Route (record-route)
  
  
• 68 Time Stamp (timestamp)
  
  
• 131 - Source ruta flexible (lsr)
  
  
• 137 - Source ruta estricta (ssr)

!

ip access-list extended ACL-TRANSIT-IN
 deny ip any any option eool
 deny ip any any option record-route
 deny ip any any option timestamp
 deny ip any any option lsr
 deny ip any any option ssr
 permit ip any any
!

interface GigabitEthernet 0/0
 ip access-group ACL-TRANSIT-IN in 
!

Consulte la sección Consolidación del Plano de Datos General de este documento para obtener más información sobre ACL IP Options Selective Drop.

Consulte Listas de Control de Acceso de Tránsito: Filtrado en su Borde para obtener más información sobre cómo filtrar el tráfico de tránsito y de borde.

Otra función del software Cisco IOS que se puede utilizar para filtrar paquetes con opciones IP es CoPP. En la versión del software Cisco IOS 12.3(4)T y las posteriores, con CoPP el administrador puede filtrar el flujo de tráfico de los paquetes del plano de control. Un dispositivo compatible con CoPP y ACL Support for Filtering IP Options, introducido en Cisco IOS Software Release 12.3(4)T, puede utilizar una política de lista de acceso para filtrar paquetes que contengan opciones IP.

Esta política de CoPP descarta los paquetes de tránsito recibidos por un dispositivo cuando hay alguna opción IP presente:

!

ip access-list extended ACL-IP-OPTIONS-ANY
 permit ip any any option any-options
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS-ANY
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

Esta política de CoPP descarta los paquetes de tránsito recibidos por un dispositivo cuando estas opciones IP están presentes:

• 0 End of Options List (eool)
  
  
• 7 Record Route (record-route)
  
  
• 68 Time Stamp (timestamp)
  
  
• 131 Loose Source Route (lsr)
  
  
• 137 Strict Source Route (ssr)

!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map COPP-POLICY
 class ACL-IP-OPTIONS-CLASS
  drop
!

control-plane
 service-policy input COPP-POLICY
!

En las políticas CoPP anteriores, las entradas de la lista de control de acceso (ACE) que coinciden con los paquetes con la acción permit producen el descarte de estos paquetes mediante la función drop de policy-map, mientras que los paquetes que coinciden con la acción deny (no se muestran) no se ven afectados por la función drop de policy-map.

Función Control Plane Protection

En Cisco IOS Software Release 12.4(4)T y posteriores, la Protección del plano de control (CPPr) se puede utilizar para restringir o controlar el tráfico del plano de control por parte de la CPU de un dispositivo Cisco IOS. Si bien es similar a CoPP, CPPr puede restringir o supervisar el tráfico con una granularidad más fina que CoPP. CPPr divide el plano de control agregado en tres categorías de plano de control independientes conocidas como subinterfaces: existen subinterfaces Host, Transit y CEF-Exception.

Esta política de CPPr descarta los paquetes de tránsito recibidos por un dispositivo si el valor TTL es inferior a 6 y los paquetes de tránsito o no tránsito recibidos por un dispositivo si el valor TTL es cero o uno. La política de CPPr también descarta los paquetes con opciones IP seleccionadas recibidos por el dispositivo.

!

ip access-list extended ACL-IP-TTL-0/1
 permit ip any any ttl eq 0 1
!

class-map ACL-IP-TTL-0/1-CLASS
 match access-group name ACL-IP-TTL-0/1
!

ip access-list extended ACL-IP-TTL-LOW
 permit ip any any ttl lt 6
!

class-map ACL-IP-TTL-LOW-CLASS
 match access-group name ACL-IP-TTL-LOW
!

ip access-list extended ACL-IP-OPTIONS
 permit ip any any option eool
 permit ip any any option record-route
 permit ip any any option timestamp
 permit ip any any option lsr
 permit ip any any option ssr
!

class-map ACL-IP-OPTIONS-CLASS
 match access-group name ACL-IP-OPTIONS
!

policy-map CPPR-CEF-EXCEPTION-POLICY
 class ACL-IP-TTL-0/1-CLASS
  drop
 class ACL-IP-OPTIONS-CLASS
  drop
!

!-- Apply CPPr CEF-Exception policy CPPR-CEF-EXCEPTION-POLICY to
!-- the CEF-Exception CPPr sub-interface of the device

!

control-plane cef-exception
 service-policy input CPPR-CEF-EXCEPTION-POLICY
!

policy-map CPPR-TRANSIT-POLICY
 class ACL-IP-TTL-LOW-CLASS
  drop
!

control-plane transit
 service-policy input CPPR-TRANSIT-POLICY
!

En la política CPPr anterior, las entradas de la lista de control de acceso que coinciden con los paquetes con el resultado de la acción permit era que esos paquetes fueron descartados por la función drop de policy-map, mientras que los paquetes que coincidieron con la acción deny (no mostrada) no fueron afectados por la función drop de policy-map.

Consulte Comprensión de la Protección del Plano de Control y Protección del Plano de Control para obtener más información sobre la función CPPr.

Identificación y Determinación del Origen del Tráfico

A veces, usted puede necesitar identificar y determinar rápidamente el origen del tráfico de la red, especialmente durante una respuesta a un incidente o un rendimiento deficiente de la red. Las ACL de clasificación y NetFlow son dos métodos principales para lograr esto con el software Cisco IOS. Netflow permite ver todo el tráfico en la red. Además, Netflow se puede implementar con colectores que pueden proporcionar tendencia a largo plazo y análisis automatizado. Las ACL de clasificación son un componente de las ACL y requieren planificación previa para identificar tráfico específico e intervención manual durante el análisis. Las siguientes secciones proporcionan una breve descripción de cada función.

Netflow

NetFlow identifica la actividad de red anómala y relacionada con la seguridad mediante el seguimiento de los flujos de red. Los datos de NetFlow se pueden visualizar y analizar mediante la CLI, o bien se pueden exportar a un recopilador NetFlow comercial o gratuito para su agregación y análisis. Los recopiladores de NetFlow, a través de tendencias a largo plazo, pueden proporcionar análisis del comportamiento y el uso de la red. NetFlow realiza análisis de atributos específicos dentro de los paquetes IP y crea flujos. La versión 5 es la versión de NetFlow más utilizada; sin embargo, la versión 9 es más extensible. Se puede crear flujos de NetFlow con muestras de datos de tráfico en entornos de gran volumen.

CEF, o CEF distribuido, es un requisito previo para habilitar NetFlow. Netflow se puede configurar en routers y switches.

Este ejemplo ilustra la configuración básica de NetFlow. En las versiones anteriores del software Cisco IOS, el comando para habilitar NetFlow en una interfaz es ip route-cache flow en lugar de ip flow {ingress | egress}.

!

ip flow-export destination <ip-address> <udp-port>
ip flow-export version <version>
!

interface <interface> 
 ip flow <ingess|egress> 
!

Este es un ejemplo del resultado de Netflow en la CLI. El atributo SrcIf puede ayudar en la determinación del origen del tráfico.

router#show ip cache flow
IP packet size distribution (26662860 total packets):
   1-32   64   96  128	160  192  224  256  288  320  352  384	416  448  480
   .741 .124 .047 .006 .005 .005 .002 .008 .000 .000 .003 .000 .001 .000 .000

    512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
   .000 .000 .001 .007 .039 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
  55 active, 65481 inactive, 1014683 added
  41000680 ager polls, 0 flow alloc failures
  Active flows timeout in 2 minutes
  Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
  110 active, 16274 inactive, 2029366 added, 1014683 added to flow
  0 alloc failures, 0 force free
  1 chunk, 15 chunks added
  last clearing of statistics never
Protocol	 Total	  Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
--------	 Flows	   /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
TCP-Telnet	 11512	    0.0        15    42      0.2      33.8      44.8
TCP-FTP 	  5606	    0.0 	3    45      0.0      59.5      47.1
TCP-FTPD	  1075	    0.0        13    52      0.0       1.2      61.1
TCP-WWW 	 77155	    0.0        11   530      1.0      13.9      31.5
TCP-SMTP	  8913	    0.0 	2    43      0.0      74.2      44.4
TCP-X		   351	    0.0 	2    40      0.0       0.0      60.8
TCP-BGP 	   114	    0.0 	1    40      0.0       0.0      62.4
TCP-NNTP	   120	    0.0 	1    42      0.0       0.7      61.4
TCP-other	556070	    0.6 	8   318      6.0       8.2      38.3
UDP-DNS 	130909	    0.1 	2    55      0.3      24.0      53.1
UDP-NTP 	116213	    0.1 	1    75      0.1       5.0      58.6
UDP-TFTP	   169	    0.0 	3    51      0.0      15.3      64.2
UDP-Frag	     1	    0.0 	1  1405      0.0       0.0      86.8
UDP-other	 86247	    0.1       226    29     24.0      31.4      54.3
ICMP		 19989	    0.0        37    33      0.9      26.0      53.9
IP-other	   193	    0.0 	1    22      0.0       3.0      78.2
Total:	       1014637	    1.2        26    99     32.8      13.8      43.9

SrcIf	      SrcIPaddress    DstIf	    DstIPaddress    Pr SrcP DstP Pkts
Gi0/1	      192.168.128.21  Local	    192.168.128.20  11 CB2B 07AF   3
Gi0/1	      192.168.150.60  Gi0/0	    10.89.17.146    06 0016 101F  55
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 101F 0016   9
Gi0/1	      192.168.150.60  Local	    192.168.206.20  01 0000 0303  11
Gi0/0	      10.89.17.146    Gi0/1	    192.168.150.60  06 07F1 0016   1

Consulte Netflow de Cisco IOS para obtener más información sobre las capacidades de Netflow.

Consulte Introducción a Netflow de Cisco IOS: Una descripción Técnica General para obtener una descripción técnica general de Netflow.

ACL de Clasificación

Las ACL de clasificación permiten ver el tráfico que cruza una interfaz. Las ACL de clasificación no alteran la política de seguridad de una red y normalmente se construyen para clasificar protocolos, direcciones de origen o destinos individuales. Por ejemplo, una ACE que permite todo el tráfico se podría separar en protocolos o puertos específicos. Esta clasificación más granular del tráfico en ACE específicas puede ayudar a proporcionar visibilidad del tráfico de red, ya que cada categoría de tráfico tiene su propio contador de visitas. Un administrador también puede separar la negación implícita al final de una ACL en ACE granulares para ayudar a identificar los tipos de tráfico denegado.

Un administrador puede agilizar una respuesta a incidentes mediante el uso de ACL de clasificación con los comandos show access-list y clear ip access-list counters EXEC.

Este ejemplo muestra la configuración de una ACL de clasificación para identificar el tráfico SMB antes de una negación predeterminada:

!

ip access-list extended ACL-SMB-CLASSIFY
 remark Existing contents of ACL
 remark Classification of SMB specific TCP traffic 
 deny	tcp any any eq 139
 deny	tcp any any eq 445
 deny	ip any any 
!

Para identificar el tráfico que utiliza una ACL de clasificación, utilice el show access-list EXEC comando. Los contadores de ACL se pueden borrar con el clear ip access-list counters EXEC comando.

router#show access-list ACL-SMB-CLASSIFY 
Extended IP access list ACL-SMB-CLASSIFY
    10 deny tcp any any eq 139 (10 matches)
    20 deny tcp any any eq 445 (9 matches)
    30 deny ip any any (184 matches) 

Consulte Comprensión del Registro de Listas de Control de Acceso para obtener más información sobre cómo habilitar las capacidades de registro dentro de las ACL.

Control de Acceso con VLAN Maps y Listas de Control de Acceso de Puerto

Las Listas de Control de Acceso a VLAN (VACL), o VLAN maps y ACL de puerto (PACL), proporcionan la capacidad de implementar control de acceso en tráfico no ruteado que está más cercano a los dispositivos extremos que las listas de control de acceso que se aplican a las interfaces ruteadas.

Estas secciones proporcionan una descripción general de las características, ventajas y escenarios de uso potencial de las VACL y las PACL.

Control de Acceso con VLAN Maps

Las VACL, o VLAN maps que se aplican a todos los paquetes, que ingresan a la VLAN, proporcionan la capacidad de aplicar el control de acceso en el tráfico intra-VLAN. Esto no es posible con las ACL de interfaces con routing. Por ejemplo, se puede utilizar un mapa de VLAN para evitar que los hosts contenidos en la misma VLAN se comuniquen entre sí, lo que reduce las oportunidades de que los atacantes locales o los gusanos exploten un host en el mismo segmento de red. Para denegar a los paquetes el uso de un mapa de VLAN, cree una lista de control de acceso (ACL) que coincida con el tráfico y, en el mapa de VLAN, establezca la acción en descartar. Una vez que se configura una lista de acceso VLAN map, todos los paquetes que ingresan a la LAN se evalúan secuencialmente en relación con VLAN map configurada. Los mapas de acceso VLAN admiten listas de acceso IPv4 y MAC; sin embargo, no admiten registros ni ACL IPv6.

En este ejemplo se emplea una lista de acceso ampliada determinada que ilustra la configuración de esta función:

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address>
     <destination-port>
!

vlan access-map <name> <number>
 match ip address <acl-name>
 action <drop|forward>
!

Este ejemplo demuestra el uso de un mapa VLAN para denegar los puertos TCP 139 y 445, así como el protocolo vines-ip:

!

ip access-list extended VACL-MATCH-ANY
 permit ip any any
!

ip access-list extended VACL-MATCH-PORTS
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 445
 permit tcp 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 139
!

mac access-list extended VACL-MATCH-VINES
 permit any any vines-ip
!

vlan access-map VACL 10
 match ip address VACL-MATCH-VINES 
 action drop
!

vlan access-map VACL 20 
 match ip address VACL-MATCH-PORTS
 action drop
!

vlan access-map VACL 30
 match ip address VACL-MATCH-ANY
 action forward
!

vlan filter VACL vlan 100 
!

Consulte Configuración de la Seguridad de la Red con ACL para obtener más información sobre la configuración de VLAN maps.

Control de Acceso con PACL

Las PACL se pueden aplicar solamente a la dirección entrante en las interfaces físicas de la Capa 2 de un switch. Similar a las VLAN maps, las PACL proporcionan control de acceso en tráfico no ruteado o de la Capa 2. La sintaxis para la creación de las PACL, que tienen precedencia sobre los mapas de VLAN y las ACL de routers, es la misma que para estas últimas. Si una ACL se aplica a un interfaz de Capa 2, se denomina PACL. La configuración supone la creación de una ACL de MAC, IPv4 o IPv6 y su aplicación en la interfaz de capa 2.

Este ejemplo utiliza una lista de acceso con nombre ampliada para ilustrar la configuración de esta función:

!

ip access-list extended <acl-name>
 permit <protocol> <source-address> <source-port> <destination-address> 
     <destination-port>
!

interface <type> <slot/port>
 switchport mode access
 switchport access vlan <vlan_number>
 ip access-group <acl-name> in 
!

Consulte la sección ACL de puerto de Configuración de Seguridad de la Red con ACL para obtener más información sobre la configuración de PACL.

Control de Acceso con MAC

Las listas de control de acceso MAC o las listas extendidas se pueden aplicar en una red IP con el uso de este comando en el modo de configuración de la interfaz:

Cat6K-IOS(config-if)#mac packet-classify

Nota: Las listas de control de acceso MAC clasifican los paquetes de Capa 3 como paquetes de Capa 2. El comando es compatible con Cisco IOS Software Release 12.2(18)SXD (para Sup 720) y Cisco IOS Software Release 12.2(33)SRA o versiones posteriores.

Este comando de interfaz debe aplicarse en la interfaz de ingreso e indica al motor de reenvío que no inspeccione el encabezado IP. El resultado es que puede utilizar una lista de acceso MAC en el entorno IP.

Uso de VLAN privadas

Las VLAN privadas (PVLAN) son una función de seguridad de capa 2 que limita la conectividad entre estaciones de trabajo o servidores en una VLAN. Sin las PVLAN, todos los dispositivos de las VLAN de la capa 2 pueden comunicarse libremente. Existen situaciones de red en las que la seguridad puede verse favorecida por la limitación de la comunicación entre dispositivos en una única VLAN. Por ejemplo, las PVLAN se utilizan a menudo para prohibir la comunicación entre servidores en una subred de acceso público. Si un solo servidor se ve comprometido, la falta de conectividad con otros servidores debido a la aplicación de PVLAN puede ayudar a limitar el riesgo a un solo servidor.

Existen tres tipos de VLAN privadas: VLAN aisladas, VLAN de comunidad y VLAN principales. Para configurar PVLAN, se utiliza VLAN primarias y secundarias. La VLAN primaria contiene todos los puertos promiscuos, que se describen más adelante, e incluye una o más VLAN secundarias, que pueden ser VLAN aisladas o comunitarias.

VLAN aisladas

La configuración de una VLAN secundaria como una VLAN aislada impide completamente la comunicación entre los dispositivos en la VLAN secundaria. Solo puede haber una VLAN aislada por VLAN principal, y solo los puertos promiscuos pueden comunicarse con los puertos en una VLAN aislada. Las VLAN aisladas se pueden utilizar en redes no fiables, como las redes que admiten invitados.

Este ejemplo de configuración configura la red VLAN 11 como VLAN aislada y la asocia con la VLAN primaria (VLAN20). Este ejemplo también configura la interfaz FastEthernet 1/1 como puerto aislado en la VLAN 11:

!

vlan 11
 private-vlan isolated
!

vlan 20
 private-vlan primary
 private-vlan association 11
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

VLAN Comunitarias

Una VLAN secundaria configurada como VLAN de comunidad permite la comunicación entre los miembros de la VLAN y con cualquier puerto promiscuo en la VLAN principal. Sin embargo, no hay comunicación posible entre dos VLAN comunitarias cualquiera o entre una VLAN comunitaria y una VLAN aislada. Las VLAN comunitarias se deben utilizar para agrupar servidores que necesitan conectividad entre sí, pero donde no se requiere conectividad con todos los demás dispositivos en la VLAN. Este escenario es común en una red de acceso público o en cualquier lugar en el que los servidores proporcionan contenido a clientes no fiables.

Este ejemplo configura una sola VLAN comunitaria y configura el puerto FastEthernet 1/2 del switch como miembro de esa VLAN. La VLAN comunitaria, VLAN 12, es una VLAN secundaria a la VLAN 20 primaria.

!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 12
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

Puertos Promiscuos

Los puertos de switch ubicados en la VLAN principal se conocen como puertos promiscuos. Los puertos promiscuos pueden comunicarse con todos los otros puertos en las VLAN primarias y secundarias. Las interfaces de router o firewall son los dispositivos que se encuentran más comúnmente en estas VLAN.

Este ejemplo de configuración combina los ejemplos de VLAN aislada y comunitaria anteriores y agrega la configuración de la interfaz FastEthernet 1/12 como puerto promiscuo:

!

vlan 11
 private-vlan isolated
!

vlan 12
 private-vlan community
!

vlan 20
 private-vlan primary
 private-vlan association 11-12
!

interface FastEthernet 1/1
 description *** Port in Isolated VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 11
!

interface FastEthernet 1/2
 description *** Port in Community VLAN ***
 switchport mode private-vlan host 
 switchport private-vlan host-association 20 12
!

interface FastEthernet 1/12
 description *** Promiscuous Port ***
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 20 add 11-12
!

Al implementar las PVLAN, es importante asegurarse de que la configuración de la capa 3 en su lugar admita las restricciones impuestas por las PVLAN y no permita que se subvierta la configuración de la PVLAN. Un filtro de capa 3 con una ACL de router o firewall puede evitar la subversión de la configuración PVLAN.

Consulte VLAN Privadas (PVLAN): Puertos Promiscuos, VLAN Aislada y VLAN Comunitaria, en la página de inicio de Seguridad de LAN, para obtener más información sobre el uso y la configuración de VLAN Privadas.

Conclusión

Este documento le brinda una descripción general de los métodos que se pueden utilizar para asegurar un dispositivo del sistema Cisco IOS. Si protege los dispositivos, aumenta la seguridad general de las redes que administra. En esta descripción general, se trata la protección de los planos de administración, de control y de datos; además se incluyen recomendaciones para la configuración. En la medida de lo posible, se brinda suficiente información detallada para la configuración de cada función asociada. Sin embargo, en todos los casos, se mencionan las referencias completas para brindarle la información necesaria para una evaluación adicional.

Reconocimientos

Algunas descripciones de funciones en este documento fueron escritas por los equipos de desarrollo de información de Cisco.

Apéndice: Lista de comprobación de Cisco IOS Device Hardening

Esta lista de comprobación es una recopilación de todos los pasos para fortalecer los dispositivos que se presentan en esta guía. Los administradores pueden utilizarla como recordatorio de todas las funciones de consolidación utilizadas y consideradas para un dispositivo Cisco IOS, incluso si una función no fue implementada porque no correspondió. Se recomienda a los administradores evaluar los riesgos de cada opción antes de implementarla.

Plano de Administración

• Contraseñas
  
  
  • Habilitar hash MD5 (opción de secreto) para contraseñas de usuario local y de habilitación
  • Configurar el bloqueo de nuevo intento de contraseña
  • Inhabilitar la recuperación de contraseña (considerar el riesgo)
    
    
• Inhabilitación de servicios no utilizados
  
  
• Configurar keepalives TCP para las sesiones de administración
  
  
• Configurar notificaciones del umbral de CPU y de memoria
  
  
• Configurar
  
  
  • Notificaciones de umbral de CPU y de memoria
  • Memoria de reserva para acceso a la consola
  • Detector de fugas de memoria
  • Detección del desbordamiento de buffer
  • Recolección de archivos crashinfo mejorada
    
    
• Utilizar iACL para restringir el acceso de administración
  
  
• Filtrar (considerar el riesgo)
  
  
  • Paquetes ICMP
  • Fragmentos IP
  • Opciones IP
  • Valor TTL en los paquetes
    
    
• Función Control Plane Protection
  
  
  • Configurar filtrado de puertos
  • Configurar umbrales de cola
    
    
• Acceso de administración
  
  
  • Utilizar la función Management Plane Protection para restringir las interfaces de administración
  • Configurar el tiempo de espera de exec
  • Utilizar un protocolo de transporte cifrado (como SSH) para el acceso de CLI
  • Controlar el transporte para las líneas vty y tty (opción de clase de acceso)
  • Advertir con el uso de banners
    
    
• AAA
  
  
  • Utilizar AAA para autenticación y autenticación alternativa
  • Utilizar AAA (TACACS+) para autorización de comandos
  • Utilizar AAA para fines de cuentas
  • Utilizar servidores AAA redundantes
    
    
• SNMP (Protocolo de administración de red simple)
  
  
  • Configurar comunidades SNMPv2 y aplicar ACL
  • Configurar SNMPv3
    
    
• Registro
  
  
  • Configurar registros centralizados
  • Establecer niveles de registro para todos los componentes relevantes
  • Set log source-interface
  • Configurar granularidad de registro de marca de tiempo
    
    
• Administración de la Configuración
  
  
  • Reemplazo y restauración
  • Función Exclusive Configuration Change Access
  • Configuración de resistencia del software
  • Notificaciones de cambios en la configuración

Plano de Control

• Inhabilitar (considerar el riesgo)
  
  
  • Mensajes de redirección ICMP
  • Mensajes ICMP de Destino Inalcanzable
  • Proxy ARP
    
    
• Configurar la autenticación NTP si se va a utilizar NTP
  
  
• Configuración de políticas/protección del plano de control (filtros de puertos, umbrales de cola)
  
  
• Asegurar los protocolos de seguridad
  
  
  • BGP (TTL, MD5, prefijos máximos, listas de prefijos, ACL de trayectoria del sistema)
  • IGP (MD5, interfaz pasiva, filtros de ruta, consumo de recursos)
    
    
• Configurar limitadores de velocidad basados en hardware
  
  
• Asegurar los Protocolos de Redundancia de Primer Salto (GLBP, HSRP, VRRP)

Plano de Datos

• Configurar la función IP Options Selective Drop
  
  
• Inhabilitar (considerar el riesgo)
  
  
  • Rutas de origen IP
  • Broadcasts dirigidos a IP
  • Mensajes de redirección ICMP
    
    
• Limitar broadcasts dirigidos a IP
  
  
• Configurar TACL (considerar el riesgo)
  
  
  • Filtrar ICMP
  • Filtrar fragmentos IP
  • Filtrar opciones IP
  • Filtrar valores TTL
    
    
• Configurar las protecciones contra suplantación requeridas
  
  
  • Listas de control de acceso (ACL)
  • IP Source Guard
  • Dynamic ARP Inspection
  • Unicast RPF
  • Seguridad del puerto
    
    
• Función Control Plane Protection (cef-exception del plano de control)
  
  
• Configurar Netflow y ACL de clasificación para la identificación del tráfico
  
  
• Configurar ACL de control de acceso requeridas (VLAN maps, PACL, MAC)
  
  
• Configurar VLAN privadas