CCNP SWITCH 16: asegurar el acceso de un switch

( redes / certificaciones / ccnp_route-switch / switch )

 Port Security

Los switches Catalyst ofrecen una característica de seguridad para limitar qué y/o cuantas direcciones MAC pueden acceder en un interface. Se puede configurar en una interface con Vlan de voz (VoIP) pero No en TRUNKs. Para ello primero se debe habilitar la característica con el comando:

switch(config)# interface type mod/num
switch(config-if)# switchport port-security

Una vez activado, por defecto SOLO permite una dirección MAC, por lo que si queremos habilitar más debemos indicarlo con este comando:

switch(config-if)# switchport port-security maximum max-addr

donde max-addr puede ser de 1 a 1024. Por defecto si no se indica este comando es 1 MAC permitida y si el puerto está configurado con VoIP debemos permitir al menos 3 (recomendación de Cisco).

Un dato a tener en cuenta es que cuando se activa port-security las direcciones de MAC no expiran como lo harían por defecto, si queremos que expiren debemos configurar el comando (minutos puede ser de 1 a 1440 minutos):

switch(config-if)# switchport port-security aging time minutos

También podemos definir estáticamente direcciones MAC que pueden transmitir tráfico por el interface usando el comando:

switch(config-if)# switchport port-security mac-address mac-addr

La dirección MAC mac-addr debe expresarse como 3 grupos separados por puntos (0000.0000.0000). En caso de que definamos estáticamente menos direcciones de las permitidas en la interface, el resto de direcciones MAC que queden hasta el máximo permitido serán aprendidas dinámicamente.

Por último debemos especificar que acción se debe tomar en caso de que se supere el número de direcciones MAC permitidas o que se aprende una dirección MAC no definida estáticamente, con el siguiente comando:

switch(config-if)# switchport port-security violation {shutdown | restrict | protect}

Con el siguiente comando conseguimos que las MACs aprendidas dinámicamente se conviertan en MACs seguras pegadas (sticky) y son añadidas a la running config:

switch(config-if)# switchport port-security mac-address sticky

Solo se quedan en la running config por lo que si queremos que tras un reinicio del switch se mantengan las MAC debemos copiar la running a la startup config.

IMPORTANTE: No se puede configurar direcciones MAC sticky o estáticas usando port security en una interface de voz (voice VLAN).

En caso de que queramos limpiar la(s) MAC(s) de un interface para poder permitir otra MAC podemos usar este comando a nivel de dirección MAC o de interface:

switch# clear port-security dynamic [address mac-addr | interface type mod/num]

Para ver el estado de una interface usaremos el comando:

switch# show port-security interface type mod/num

Para ver un resumen rápido SOLO de interfaces que están en modo errdisable (que incluye la razón de por qué está así), podemos usar el comando:

switch# show interfaces status err-disabled

Para un listado de las interfaces configuradas con port security con sus contadores y la acción configuradas por cada una de las interfaces, podemos usar el comando:

switch# show port-security

 Autenticación basada en interface

Los switches Catalyst soporta autenticación basada en interface, una combinación de autenticación AAA y seguridad de interface. Esta característica está basada en el estándar 802.1x que una vez activado no pasa nada de tráfico hasta que un usuario se autentica.

Como es lógico tanto el ordenador o servidor del usuario final como el switch deben soportar el estándar 802.1x usando EAPOL (Extensible Authentication Protocol = EAP Over LANs). Si la parte del cliente (PC) está configurado con soporte de 802.1x pero el switch no, el cliente se comunica normalmente descartando el protocolo 802.1x. Si es al contrario, el switch está configurado con soporte de 802.1x y el cliente (PC) no entonces no se transmite ningún tipo de tráfico.

El protocolo 802.1x es un protocolo de Capa 2, en el punto que un switch detecta la presencia de un dispositivo dejando la interface en estado NO autorizado. El cliente (PC) solo puede comunicarse usando EAPOL. Por eso el cliente (PC) requiere de una aplicación o software que soporte 802.1x.

Cuando un dispositivo se conecta a un interface configurado con 802.1x sigue estos pasos:

  1. Empieza el estado de autenticación (permitiendo solo comunicación de EAPOL (EAP Over Lan), CDP y STP.
  2. El switch pide autenticación o el cliente envía una trana EAPOL para empezar la autenticación.
  3. El switch envía la información de autenticación del cliente al servidor RADIUS y actua como proxy.
  4. Si la autenticación es exitosa, la interface pasa a estado autorizado y permite tráfico.

El protocolos 802.1x requiere de tres diferentes dispositivos que sean configurados para que la autenticación basada en puerto funcione:

 Configuración de 802.1x

  1.  Habilitar AAA en el switch Por defecto AAA está deshabilitado, por lo que para habilitarlo usaremos este comando:
    switch(config)# aaa new-model
  2.  Definir los servidores externos RADIUS Ahora definiremos uno o más servidores RADIUS con el siguiente comando (por cada server):
    switch(config)# radius-server host {hostname | ip-address} [key string]
  3. Definir el método de autenticación pra 802.1x Con el siguiente comando configuramos que todos los servidores RADIUS configurados en el switch sean usados para la autenticación 802.1x:
    switch(config)# aaa authentication dot1x default group radius
  4. Habilitar 802.1x en el switch
    switch(config)# dot1x system-auth-control
  5. Configurar cada interface del switch que usaran 802.1x
    switch(config)# interface type mod/num
    switch(config)# dot1x port-control {force-authorized | force-unauthorized | auto}
    donde cada estado puede ser:
    • force-authorized- La interface está forzada a permitir siempre lo que esté conectado. No es necesaria autenticación. Es el estado por defecto cuando se activa 802.1x. Deshabilita la autenticación 802.1x.
    • force-unathorized- La interface está siempre forzada a NO permitir la transmisión ni autenticación. Con lo cual NO se permite el estado autorizado para que el cliente pase tráfico.
    • auto - La interface negocia el estado de autorizado o no autorizado, si el cliente se autentica correctamente o no. Requiere que el cliente tenga una aplicación que soporte el protocolo 802.1x. Solo permite tramas EAPOL.
  6. Permitir multiples hosts en una interface del switch: Puede ser obvio que si configuramos 802.1x esperemos un solo cliente por interface, pero en ocasiones podemos necesitar que una interface haya más de un cliente (por ejemplo un hub u otro switch) por lo que necesitaremos configurar este comando en la interface oportuna:
    switch(config-if)# dot1x host-mode multi-host

Para poder verificar las interfaces configuradas con 802.1x podemos usar el comando:

switch# show dot1x all

Mitigar los ataques de suplantación (mitigating spoofing attacks)

EXAMEN: para evitar DHCP Spoofing el servidor DHCP debe crear una entrada ARP estática que no pueda ser actualizada por un paquete ARP dinámico.

EXAMEN: Ataques de ARP Spoofing son intentos de redirigir tráfico al host que se quiere atacar enviando un mensaje ARP con la identidad falsificada al host que transmite. (ARP spoofing attacks are attempts to redirect traffic to an attacking host by sending an ARP message with a forged identity to a transmitting host).

MAC Flooding

Este tipo de ataque consiste en inundar de direcciones MAC a un switch para que una vez llena la CAM el switch envia toda las tramas por cada uno de los puertos del switch ya que la MAC no está en la CAM, con lo cual el atacante ve tráfico que no debería ver. Una vez que el ataque cese, la CAM se irá restableciendo sacando de la tabla todas las MAC que expiren, pero mientras el atacante podrá conseguir información valiosa. Para prevenir estos ataques se pueden usar por security (la solución más común) e implementando VLAN access maps. (EXAMEN: Mac address flooding in an attempt to force a switch to send all information out every port by overloading the MAC address table).

DHCP Snooping

Los switches Catalyst pueden usar las característica de DHCP snooping para ayudar a mitigar el tipo de ataque llamado DHCP spoofing que consiste en configurar un servidor DHCP para capturar tráfico (una especie de man in the middle) y poder responder a las peticiones de DHCP.

Una vez DHCP snooping está activado, cada interface del switch puede estar como de confianza o no confianza (por defecto). Es lógico que los servidores DHCP legítimos estén en interfaces de confianza mientras que el resto de servidores/ordenadores (puertos de acceso) estarán en los de no confianza.

La interface intercepta todo el tráfico DHCP de una interface de no confianza descartando todos las respuestas DHCP ya que asume que vienen de un server que no es confiable. Además la interface (que detecta que hay un posible servidor DHCP no confiable) se pone en estado Errdisable lo cual la deja en shutdown.

Para configurar DHCP snooping primero debemos habilitarlo globalmente en el switch:

switch(config)# ip dhcp snooping

Después debemos indicar la(s) VLAN(s) que DHCP snooping se implementará:

switch(config)# ip dhcp snooping vlan vlan-id [vlan-id]

También se pueden indicar rangos de vlans indicando la vlan inicia y final separadas por un guión.

Por defecto todas las interfaces asumen que son de no confianza por lo que las respuestas DHCP no están permitidas (ni se espera recibirlas). Así que debemos indicar que interfaces son de confianza y hay un servidor DHCP válido y de confianza con los siguientes comandos:

switch(config)# interface type mod/num
switch(config-if)# ip dhcp snooping trust

Si queremos limitar el número de peticiones DHCP en un puerto de no confianza podemos usar estos comandos:

switch(config)# interface type mod/num
switch(config-if)# ip dhcp snooping limit rate rate

Para activar o desactivar la opción de DHCP option-82 podemos usar el comando:

switch(config)# [no] ip dhcp snooping information option

Por último para ver el estado del DHCP snooping usaremos el comando:

switch# show ip dhcp snooping [binding]

Si usamos binding nos muestra los que han sido rechazados.

IP Source Guard

Permite mitigar (aunque es muy complicado) la suplantación de direcciones IP y MAC. Para configurar IP Source Guard primero debemos habilitar DHCP snooping y si además queremos detectar suplantación de direcciones MAC también debemos configurar port security.

Para los servidores que NO usen DHCP podemos configurar asociaciones de IP-MAC-Vlan con el siguiente comando:

switch(config)# ip source binding mac-address vlan vlan-id ip-address interface type mod/num

Y para habilitar IP Source guard en una o más interfaces debemos configurar estos comandos:

switch(config)# interface type mod/num
switch(config-if)# ip verify source [port-security]

Si no indicamos port-security solo se inspecciona la IP origen, si lo indicamos además se inspecciona la dirección MAC origen.

Para comprobar el estado de IP Source Guard podemos ejecutar el comando:

switch# show ip verify source [interface type mod/num]

Si necesitamos comprobar la información que contiene en la base de datos de IP Source ya sea estática o dinámicamente, podemos usar el comando:

switch# show ip source binding [ip-address] [mac-address] [dhcp-snooping | static] [interface type mod/num] [vlan vlan-id]

Inspección de ARP dinámica

El ataque conocido como ARP poisoning o ARP spoofing es el que un atacante se coloca en el medio (man in the middle) y mediante la suplantación de MAC, enviando mensajes de ARP no solicitados dando la IP del gateway con su propia MAC, con lo que los hosts/servers actualizan su tabla de ARP con este nuevo valor enviando todo el tráfico al atacante, con lo que obtiene el tráfico de otro servidor o dispositivos que luego puede filtrar o espiar o simplemente rechazar de forma transparente para el usuario o dispositivo final.

Los switches Catalyst pueden usar la característica llamada Dynamic ARP Inspection (DAI) (Inspección de ARP dinámica) para ayudar a mitigar este tipo de ataques que consiste en definir interfaces de confianza o no confianza. DAI intercepta, manda logs y rechaza mensajes ARP en las interfaces de NO confianza que no coinciden con las uniones MAC/IP del DHCP snooping. Todo el tráfico que coincida pasa, el que no de descarta.

Para configurar Dynamic ARP Inspection debemos primero habilitarlo en una o más VLANs con el siguiente comando:

switch(config)# ip arp inspection vlan vlan-range

donde vlan-range puede ser una vlan, varias vlans separadas por comas o un rango de vlans (vlan_inicial-vlan_final).

Con esto conseguimos que se intercepte, haga log y descarte paquetes ARP con asociaciones inválidas de MAC-to-IP para ello mira en la base de datos de DHCP snooping o en APR introducidas estáticamente.

Por defecto todas las interfaces asociadas a las VLANs configuradas para inspeccionar son consideradas de no confianza por lo que se inspeccionan, si queremos que una interface no sea inspeccionada y por lo tanto considerada como de confianza (enlace contra otro switch por ejemplo) debemos configurar la interface de la siguiente forma:

switch(config)# interface type mod/num
switch(config-if)# ip arp inspection trust

En caso de que haya clientes (hosts) con direcciones IP configuradas estáticamente no habrá intercambio de mensajes DHCP donde se pueda inspeccionar, por lo que deberemos configurar una lista de acceso ARP definiendo la unión de IP-MAC que permitimos. Para ello usaremos estos comandos:

switch(config)# arp access-list arp-acl-name
switch(config-acl)# permit ip host sender-ip mac host sender-mac [log]
switch(config-acl)# exit

Debemos repetir el comando permit tantas veces como IP-MAC tengamos o queramos definir. Una vez definila la lista de acceso tenemos que aplicarla a Dynamic ARP Inspection usando el comando:

switch(config)# ip arp inspection filter arp-acl-name vlan vlan-range [static]

Con esto indicamos que todas las respuestas ARP que se intercepten se verifiquen contra la lista de acceso y en caso de que ninguna se cumpla se procede a comprobar la base de datos de DHCP snooping. Si especificamos static indicamos que si la lista de acceso con da positivo es como si tuviese al final de la misma un deny all y por consiguiente NO se comprueba la base de datos de DHCP snooping. Por defecto solo se validan las direcciones IP y MAC que se contienen en la respuesta ARP, por lo que la dirección MAC contenida en la cabecera Ethernet no se mira. Para validar que un paquete de respuesta ARP viene des la dirección listada dendro de él, podemos habilitar la validación de Dynamic ARP Inspection con este comando:

switch(config)# ip arp inspection validate {[src-mac] [dst-mac] [ip]}

Debemos asegurarnos que especificamos al menos una opción:

Debemos tener en cuenta estos puntos sobre Dynamic ARP Inspection (DAI):

Consejos y mejores prácticas para asegurar switches

Modificado el 3 Enero, 2015
   

Compartiendo conocimiento desde 1995 - I.M.D. I.M.D.