Cisco 200-301: Seguridad de Red y Control de Acceso — Guía de estudio

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Forma parte de la Cisco CCNA 200-301 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Cisco, o realiza tests cronometrados en ExamRoll.io.

Resumen

La seguridad de red y el control de acceso garantizan que solo las entidades autorizadas utilicen los recursos de red de la manera prevista, mientras se protegen los datos y servicios contra la alteración o interrupción. Los diseños eficaces alinean los controles técnicos con los principios fundamentales de confidencialidad, integridad, disponibilidad y mínimo privilegio. Los controles deben abarcar el plano de gestión (cómo se administran los dispositivos), el plano de control (cómo los dispositivos forman adyacencias e intercambian enrutamiento) y el plano de datos (cómo se reenvía el tráfico de usuario), con defensas en capas en la Capa 2, Capa 3 y superiores. Esta sección resume mecanismos prácticos —AAA, ACLs, protecciones de Capa 2, VPNs, firewalls/IPS, fortalecimiento (hardening) y monitorización operativa— junto con el razonamiento de diseño, los modos de fallo comunes y ejemplos de configuración concisos.

Principios de Seguridad y Fundamentos del Control de Acceso

Confidencialidad: Prevenir la divulgación no autorizada. Se aplica con cifrado en tránsito (SSH, IPsec), cifrado en reposo y políticas de acceso delimitadas.
Integridad: Prevenir la alteración no autorizada. Se logra mediante comprobaciones criptográficas (HMACs, firmas digitales), controles de configuración e inmutabilidad de los registros de auditoría.
Disponibilidad: Mantener los servicios accesibles a pesar de fallos o ataques. Se consigue con redundancia, limitación de velocidad (rate-limiting), vigilancia (policing) y arquitecturas resilientes que mantienen la conectividad continua durante las fallas.
Mínimo privilegio: Otorgar los derechos mínimos necesarios, delimitados por rol, dispositivo, protocolo, tiempo y ubicación. Se implementa mediante el control de acceso basado en roles (RBAC), la segmentación y la autorización por comando.

Razonamiento de diseño:

Derivar las políticas de acceso a partir de los roles de negocio. El RBAC en la infraestructura (p. ej., network-operator frente a network-admin) reduce el radio de impacto (blast radius) del uso indebido de credenciales y de los errores operativos.
Separar funciones (p. ej., operaciones de seguridad frente a operaciones de red). Se aplica mediante grupos AAA distintos y autorización de comandos.
Preferir posturas de denegación por defecto. Permitir explícitamente los flujos previstos y las fuentes de gestión, con registro de las excepciones.

Errores comunes:

Privilegios excesivos por conveniencia (p. ej., un privilege 15 generalizado). Esto invita al movimiento lateral y a errores irreversibles.
Redes planas sin segmentación. Los dominios de difusión (broadcast) y los límites de políticas no diferenciados amplifican los ataques (p. ej., ARP spoofing).
Controles demasiado estrictos sin telemetría. La falta de contadores/registros dificulta la resolución de problemas y puede prolongar las interrupciones.

AAA y Gestión Segura de Dispositivos

Resumen de AAA:

Autenticación (Authentication) verifica la identidad. Autorización (Authorization) determina lo que una identidad puede hacer. Contabilidad (Accounting) registra qué se hizo y cuándo.
Autenticación local: El dispositivo almacena usuarios y contraseñas. Útil para acceso de emergencia (break-glass); no escala ni centraliza la política.
TACACS+: TCP/49, cifra la carga útil completa, admite autorización granular por comando; preferido para la administración de dispositivos.
RADIUS: UDP/1812 (authn/author), UDP/1813 (acct), cifra solo el campo de la contraseña; se integra bien con 802.1X y el acceso a la red, autorización menos granular para la CLI.

Configuración AAA típica con TACACS+ y respaldo local:

undefined

Acceso basado en roles:

Asignar atributos de TACACS+/RADIUS a niveles de privilegio del dispositivo o conjuntos de comandos. Usar la autorización por comando para restringir acciones de riesgo (p. ej., reload, write, ediciones de policy-map).
Validar el RBAC con cuentas de prueba; asegurar que la cuenta local de emergencia (break-glass) esté documentada, protegida y monitorizada.

Aseguramiento del plano de gestión:

Preferir SSHv2 para la CLI. Deshabilitar Telnet y los servidores no utilizados.

undefined

Restringir la gestión a VLANs/VRFs de gestión dedicadas o fuera de banda (out-of-band). Aplicar ACLs en la SVI o en la interfaz de gestión física para permitir solo las fuentes autorizadas.
Control-plane policing (CoPP) para proteger los protocolos de enrutamiento, gestión y control contra inundaciones de tráfico:

undefined

Razonamiento y precauciones: Aplique policing, no descarte (drop) indiscriminadamente el tráfico de class-default; una clasificación errónea puede romper las adyacencias de enrutamiento o BFD y causar interrupciones. Comience con tasas generosas, observe los contadores y luego ajústelas.

Fortalecimiento de contraseñas e integridad del dispositivo:

Usar enable secret (con hash) en lugar de enable password.
Forzar una longitud mínima y limitar los ataques de inicio de sesión:

undefined

Preferir secretos de usuario local (secrets) (PBKDF2/scrypt en plataformas compatibles). Entender que service password-encryption solo ofusca las contraseñas heredadas de tipo 7.
Arranque y configuración seguros:

undefined

Proteger y versionar las configuraciones; considere archivarlas periódicamente en el almacenamiento local y en un repositorio remoto seguro. Use SCP o SFTP para las transferencias de archivos; evite TFTP en texto plano para archivos sensibles.

Filtrado de Tráfico con ACLs de IPv4/IPv6

Conceptos básicos de ACLs de IPv4:

Las ACLs estándar (1–99, 1300–1999) solo coinciden con la dirección IPv4 de origen. Las ACLs extendidas (100–199, 2000–2699) coinciden con origen/destino, protocolo y puertos de L4.
Máscaras wildcard: el bit 0 debe coincidir; el bit 1 es “no importa”. Se calcula como la inversa de la máscara de subred (p. ej., /24 => 0.0.0.255). Atajos: host 192.0.2.5 equivale a 192.0.2.5 0.0.0.0; any equivale a 0.0.0.0 255.255.255.255.
Dirección: inbound (entrante) se procesa antes del enrutamiento en el ingreso; outbound (saliente) se procesa después del enrutamiento en la salida. Los paquetes se revisan de arriba hacia abajo hasta la primera coincidencia; un deny any implícito finaliza la ACL.
Directrices de ubicación: coloque las ACLs extendidas cerca del origen para descartar el tráfico no deseado tempranamente; coloque las ACLs estándar cerca del destino para evitar un bloqueo excesivo. Las plataformas modernas usan TCAM; aun así, prefiera la precisión cerca del origen.

Ejemplos:

undefined

Mejoras útiles: use remark para documentación; use established para una permisión rudimentaria de la ruta de retorno en TCP (valor de seguridad limitado); habilite el logging en los deny con moderación para evitar picos de CPU.

Principios de ACLs de IPv6:

La lógica es similar, pero las ACLs de IPv6 solo tienen nombre y se aplican con ipv6 traffic-filter. El deny por defecto también es implícito.
Siempre tenga en cuenta los tipos esenciales de ICMPv6 (neighbor solicitation/advertisement, router solicitation/advertisement, PMTU). Las ACLs demasiado estrictas que descartan ICMPv6 rompen el protocolo ND y causan agujeros negros (black holes).

undefined

Verificación y operaciones:

show access-lists APP-POLICY y show ipv6 access-lists V6-EDGE-IN para ver los contadores de aciertos (hit counters) y los números de secuencia.
show ip interface o show ipv6 interface para confirmar la asignación y la dirección.
Pruebe de forma limitada antes de un despliegue amplio; un deny ip any any mal ubicado puede causar interrupciones generalizadas.

Modos de fallo comunes:

Cálculos erróneos de la máscara wildcard que coinciden involuntariamente de forma demasiado amplia.
Aplicar ACLs en la dirección incorrecta o en la interfaz/SVI equivocada.
Omitir permisos críticos de ICMPv6, lo que lleva a fallos en el descubrimiento de vecinos (neighbor discovery).

Protecciones de Capa 2, VPNs y Defensas Perimetrales

Controles de amenazas de Capa 2:

DHCP snooping: Construye una tabla de enlaces (binding table) de IP–MAC–VLAN–puerto para direcciones aprendidas por DHCP; descarta respuestas de servidores no autorizados (rogue) en puertos no confiables; limita la tasa (rate-limits) de ofertas/solicitudes.

undefined

Modos de fallo: Olvidar declarar como confiables (trust) los enlaces ascendentes (uplinks) a los relays/servidores DHCP reales interrumpe la asignación de direcciones; no guardar la tabla de enlaces entre reinicios puede afectar a DAI/IPSG hasta que las concesiones (leases) se renueven.

Dynamic ARP Inspection (DAI): Valida los paquetes ARP contra la tabla de enlaces de DHCP snooping (o enlaces estáticos). Descarta ARP falsificado (spoofed).

undefined

Advertencia: Los hosts con direccionamiento estático requieren enlaces estáticos; de lo contrario, el ARP legítimo podría ser descartado.

IP Source Guard (IPSG): Utiliza los enlaces para permitir solo la IP de origen válida (y opcionalmente la MAC) por puerto.

undefined

Ejemplo de enlace estático para un dispositivo con IP fija:

undefined

Fundamentos de VPN y conceptos de IPsec:

Las VPNs de sitio a sitio (site-to-site) suelen usar IPsec en modo túnel para cifrar y autenticar subredes privadas a través de redes no confiables. Elementos centrales: IKE Fase 1 (p. ej., IKEv2) para establecer una SA de ISAKMP; Fase 2 para construir SAs de IPsec con transformaciones (p. ej., AES-GCM para modo combinado o AES-CBC con HMAC-SHA2); PFS para garantizar la confidencialidad directa (forward secrecy); tiempos de vida (lifetimes) para renovar claves; NAT-T sobre UDP/4500 si hay NAT presente.
Las VPNs de acceso remoto pueden basarse en SSL/TLS (con cliente o sin cliente) o en IPsec. El túnel dividido (split tunneling) reduce el ancho de banda en el equipo principal (headend) y mejora la experiencia del usuario, pero aumenta la exposición; el túnel completo (full tunneling) centraliza los controles de seguridad a costa del ancho de banda y la latencia.
Valide el Path MTU y habilite el descubrimiento de PMTU; la sobrecarga del cifrado (encrypted overhead) reduce el MTU efectivo y puede causar fragmentación sin la configuración adecuada.

Firewalls y prevención de intrusiones:

Los firewalls aplican permisos/denegaciones con inspección con estado (stateful inspection) y reconocimiento de aplicaciones (NGFW). En los routers, el firewalling basado en zonas (zone-based firewalling) proporciona políticas con estado entre zonas; las ACLs por sí solas no tienen estado (stateless).
Un IPS analiza el tráfico en busca de firmas, anomalías o comportamientos; un IPS en línea (inline) puede bloquear, mientras que un IDS pasivo solo alerta. El ajuste (tuning) es esencial para reducir los falsos positivos.
Diseñe para flujos simétricos a través de dispositivos con estado; el enrutamiento asimétrico rompe las tablas de estado. Posicione los sensores donde vean el tráfico correcto (p. ej., entre zonas confiables y no confiables).

Operaciones de seguridad: Monitoreo, registro y triaje de incidentes

Auditoría, registros y sincronización de tiempo:

Sincronizar relojes para precisión forense:

undefined

Habilitar el registro local y remoto con la severidad adecuada:

undefined

Aumentar la visibilidad de los eventos de autenticación y el uso de comandos con la contabilidad de AAA:

undefined

Usar el registro de ACL en las denegaciones con criterio; los registros de alto volumen pueden disparar el uso de la CPU. Considere el muestreo con NetFlow/IPFIX para establecer una línea base del tráfico.

Flujo de trabajo para el triaje de incidentes:

Detectar y delimitar el alcance: Usar syslog, traps de SNMP y datos de flujo para identificar orígenes, puertos y volúmenes anómalos. Correlacionar contadores en ACLs, CoPP e interfaces.
Contener: Aplicar denegaciones de ACL dirigidas temporalmente, desactivar puertos de switch comprometidos o poner VLANs en cuarentena. Para ataques DDoS en el plano de control, ajustar el policing de CoPP y considerar límites de tasa upstream o blackholing.
Erradicar y recuperar: Eliminar artefactos maliciosos, rotar credenciales (incluyendo claves y secretos compartidos), rehabilitar servicios de forma incremental mientras se monitorea.
Post-incidente: Preservar registros/instantáneas de configuración, realizar un análisis de causa raíz y codificar controles preventivos (p. ej., expandir las protecciones de Capa 2, refinar el RBAC).

Brechas operativas comunes:

La falta de NTP conduce a líneas de tiempo inutilizables.
Registrar todo en todas partes crea ruido; ajuste la severidad y los filtros según el rol del dispositivo.
La ausencia de un proceso de emergencia (break-glass) probado prolonga las interrupciones cuando los servidores AAA no están accesibles.

Escenario de un problema práctico

Orion Retail Group debe asegurar la administración de dispositivos, segmentar el tráfico de usuario a aplicación para IPv4/IPv6, detener la actividad fraudulenta (rogue) de DHCP/ARP en las tiendas, habilitar el acceso remoto seguro para el personal y mejorar la visibilidad para la respuesta a incidentes, todo sin interrumpir las operaciones.

Implementar AAA centralizado con TACACS+ y respaldo local (fallback)

Configuración: Poner en marcha servidores TACACS+; definir aaa new-model con el grupo TAC-GRP, autenticación/autorización/contabilidad; crear un usuario local de emergencia (breakglass) con privilegio 15.
Justificación: Las identidades centralizadas y la autorización por comando aplican el principio de mínimo privilegio, proporcionan pistas de auditoría de las acciones administrativas y permiten la revocación rápida de credenciales. El respaldo local preserva el acceso durante las caídas de AAA.

Migrar el acceso de gestión a SSH y restringirlo por origen

Configuración: Generar claves RSA, forzar ip ssh version 2, deshabilitar Telnet, configurar line vty con transport input ssh y login authentication default; aplicar la access-class MGMT_VTY in para permitir solo los hosts de salto (jump hosts) del NOC.
Justificación: Cifrar el tráfico de gestión previene la interceptación de credenciales; las ACL de gestión reducen la superficie de ataque a un conjunto pequeño y conocido de orígenes.

Proteger el plano de control con una política de CoPP conservadora

Configuración: Crear un class-map para SSH, SNMP, NTP; aplicar un policy-map COPP-POLICY que aplique policing al tráfico conocido de gestión/control y limite la tasa de class-default; asociarlo a la entrada del plano de control (control-plane input).
Justificación: Limitar la tasa del tráfico del plano de control mantiene la disponibilidad durante inundaciones de tráfico sin bloquear protocolos esenciales. Empezar con tasas relajadas evita la autodenegación accidental de servicio.

Reforzar la integridad de la Capa 2 en las tiendas

Configuración: Habilitar DHCP snooping en las VLAN de acceso, confiar solo en los uplinks hacia la WAN/relay; aplicar límites de tasa a las solicitudes/ofertas. Habilitar DAI en las mismas VLAN; añadir asignaciones estáticas para dispositivos con IP fija. Habilitar IP Source Guard en los puertos de acceso.
Justificación: Estas características bloquean servidores DHCP fraudulentos (rogue), suplantación de ARP (ARP spoofing) y suplantación de IP en el primer salto, previniendo el movimiento lateral y los ataques de tipo man-in-the-middle.

Segmentar aplicaciones con ACLs precisas (IPv4 e IPv6)

Configuración: Desplegar ACLs extendidas de IPv4 en las interfaces orientadas al acceso para permitir solo los protocolos requeridos (p. ej., HTTPS a los servidores de aplicaciones) y denegar/registrar todo lo demás. Desplegar ACLs de IPv6 con permisos explícitos para ICMPv6 (ND/RA/RS) y permisos específicos de la aplicación; aplicar con ipv6 traffic-filter.
Justificación: Los filtros cercanos al origen y específicos del protocolo minimizan el tráfico no deseado y reducen el desperdicio de ancho de banda; preservar ICMPv6 asegura que el descubrimiento de vecinos (neighbor discovery) y PMTU funcionen de manera fiable.

Habilitar el acceso remoto seguro y el cifrado de sitio a sitio

Configuración: Construir túneles IPsec de sitio a sitio en modo túnel entre las tiendas y los centros de datos usando IKEv2, AES-GCM, PFS y tiempos de vida (lifetimes) alineados con las ventanas operativas. Proporcionar una VPN de acceso remoto basada en SSL/TLS para el personal con túnel dividido (split tunneling) para reducir la carga en el headend, junto con verificaciones de postura del endpoint.
Justificación: Cifrar las rutas no confiables protege la confidencialidad/integridad; el túnel dividido equilibra la seguridad con el rendimiento cuando se combina con controles en el endpoint.

Desplegar un firewall e IPS en el perímetro y en la agregación del centro de datos

Configuración: Implementar una política de firewall con estado (stateful) entre las zonas no confiables, de usuario y de servidores; posicionar el IPS en línea (inline) en las rutas críticas con firmas ajustadas para las aplicaciones de retail. Asegurar la simetría de la ruta o habilitar el uso compartido de estado.
Justificación: Los firewalls aplican políticas de zona de alto nivel; el IPS detecta/bloquea exploits que se aprovechan de las debilidades de las aplicaciones y los protocolos. La ubicación y el ajuste correctos previenen los falsos positivos y los problemas de estado asimétrico.

Fortalecer el hardening, el registro y la respuesta

Configuración: Establecer enable secret, forzar una longitud mínima de contraseña y la limitación de intentos de inicio de sesión (login throttling); habilitar el arranque seguro de imagen/configuración. Configurar NTP, syslog remoto y en búfer con severidad informational, y la contabilidad de comandos de AAA. Añadir sentencias deny log con moderación en las ACLs clave. Probar el procedimiento de emergencia (break-glass).
Justificación: Las credenciales robustas y la integridad del dispositivo reducen el riesgo de compromiso; los registros sincronizados y duraderos junto con la contabilidad aceleran el triaje. Los procedimientos de recuperación practicados minimizan el tiempo de inactividad durante los incidentes.

Al ejecutar estos pasos en orden —desde la identidad y el plano de gestión, pasando por el hardening de Capa 2, hasta la segmentación y el transporte cifrado, y finalmente la inspección perimetral y la visibilidad operativa— Orion logra una seguridad por capas de mínimo privilegio con controles medibles y una interrupción mínima.

← Diseño y Operaciones de LAN Inalámbricas · Todos los dominios · WAN →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Aprueba tu examen →

Cisco 200-301: Seguridad de Red y Control de Acceso — Guía de estudio

Resumen

Principios de Seguridad y Fundamentos del Control de Acceso

AAA y Gestión Segura de Dispositivos

Filtrado de Tráfico con ACLs de IPv4/IPv6

Protecciones de Capa 2, VPNs y Defensas Perimetrales

Operaciones de seguridad: Monitoreo, registro y triaje de incidentes

Escenario de un problema práctico

Pass the whole exam — not just this question

Related guides

Una suscripción. Todos los exámenes.