Como mitigar ataques switches de capa 2.

Para el caso de un switch CISCO Catalysts se debe entrar en el modo de configuración de

cada boca y seguir los siguientes pasos.

1. Configurar la boca como de acceso para HOST asignándole una VLAN para usuarios,
es decir, no de gestión. Con el comando

Switch(config)# interface <id_de_interfaz>

Switch(config-if)# Switch port mode access

2. Habilitar el modo de seguridad para la interface.

Switch(config-if)# Switch port-security

3. Habilitar el número máximo de MAC que aprendera el switch para esa boca. Si no se
especifica este comando se asume una.

Switch(config-if)# Switch port-security maximum (1-132)

4. Configurar las MAC que se admiten en la boca. Si la cantidad es menor que las que
admite como máximo el resto las aprenderá hasta completarlo y no admitirá más.

Switch(config-if)# Switch port-security mac_address_1 mac_address_2 …

5. Opcionalmente se le puede indicar al IOS que debe hacer en caso de violación de

MAC.

Switch(config-if)# Switch port-security violation [shutdown | rectrict | trap ]

Shutdown bloqueara la boca

Restrict restringe el acceso a la MAC illegal.

Trap enviar un trap a una estación SNMP o con un gestor de TRAPs SNMP. Usar la
versión SNMP más alta posible.

6. Verificar la configuración de puertos asegurados.

Switch# show port-security interface <id-interface>

7. Bajar los segundos de memorización de una MAC en tablas ARP o incluso poner
estáticas las que se puedan, para mitigar el envenenamiento ARP. Incluso en redes
medianas esta solución no solo no es definitiva sino que no es escalable. Una
alternativa más tajante es tener a cada equipo en una VLAN con un router on stick.

8. Configuración DHCP Snooping.

Activar DHCP snooping

Switch(config)# IP DHCP Snooping

Activar DHCP snooping Para una VLAN

 Switch(config)# IP DHCP Snooping vlan <Vlan_id>

Definir las bocas válidas

Switch(config-if)# IP DHCP Snooping trust

Configurar el ratio de paquetes DHCP máximo por segundo. Si es para una interfaz (no
trusted) no fiable (de cliente) se aconseja un máximo de 100 y para las de confianza subir
este valor conforme a la cantidad de equipos.

Switch(config-if)# IP DHCP Snooping limit rate <ratio>

Comprobar la configurarión de DHCP snooping.

Switch# show IP DHCP Snooping

Los modelos 3550 o superiors (switches de capa 3) incorporan además Dynamic ARP
Inspection (DAI) que les permite validar una petición ARP en base a la validez de la MAC
asociada con la IP tomando como referencia la información almacenada en la tabla DHCP
snoop y mediante VACL (Vlan Access List) que permiten indicar las MAC correspondiente
para las IP estáticas.

Mitigando VLAN hopping attacks

Para mitigar VLAN hopping attacks se requieren varias modificaciones en la configuración.

Una de las más importantes es dedicar una Vlan exclusiva para todos los puertos de trunk.
También es conveniente mantener deshabilitados los puertos no usados y que además
pertenezcan a una Vlan sin uso. Colocar todos los puertos que no sean de trunk en modo
usuario, esto se hace de modo explicito en DTP con el comando de configuración de
interfaz switchport mode access . Aunque sea paranoico conviene no usar la VLAN 1
para nada. Enviar todas las tramas etiquetadas que se reciben en puertos de trunk a la
Vlan Nativa.

Previniendo la manipulación de Spanning-Tree Protocol

Lo primera medida es asignar al switch raíz prioridad cero, pero eso no asegura que el
atacante no lo haga y casualmente tenga una MAC más baja. Los modelos de switch de
CISCO de gama alta incluyen un sistema de protección llamado Bridge Guard

El comando de modo de interfase spanning-tree guard loop previene que un

puerto designado cambia a raíz aunque si puede ser bloqueado o que
un puerto raíz pase a ser designado o bloqueado.

Otra comando útil es en modo global spanning-tree portfast

bpduguard default que habilita de modo global en todos los puertos
donde se haya indicado spanning-tree portfast el colocarlos en
estado error-disable si reciben BPDU´s

Protocolo IEEE 802.1x y servidores de acceso

802.1x components

802.1x is a standardized framework defined by the IEEE that is designed to provide port-based
network access. 802.1x performs port-level authentication of network clients by using
information unique to the client and with credentials known only to the client. The 802.1x
framework defines three roles in the authentication process :

• Supplicant – The endpoint that is seeking network access is known as the supplicant.
The supplicant may be an end user device or a standalone device, such as an IP
phone.
• Authenticator – The device to which the supplicant directly connects and through
which the supplicant obtains network access permission is known as the authenticator.
• Authentication server – The authenticator acts as a gateway to the authentication
server, which is responsible for actually authenticating the supplicant.

The authentication process consists of exchanges of Extensible Authentication Protocol (EAP)

messages. This exchange occurs between the supplicant and the authentication server. The
authenticator acts as a transparent relay for this exchange and as a point of enforcement for
any policy configuration instructions the authentication server may send back as a result of the
authentication process.

802.1x and EAP

An alternative wireless LAN (WLAN) security approach focuses on developing a framework for
providing centralized authentication and dynamic key distribution. This approach is based on
the IEEE 802.11 Task Group i end-to-end framework using 802.1x and EAP to provide this
enhanced functionality. Cisco has incorporated 802.1x and EAP into its Cisco Wireless Security
Suite. The three main elements of an 802.1x and EAP approach follow:

• Mutual authentication between the client and the RADIUS authentication server
• Encryption keys that are dynamically derived after authentication
• Centralized policy control, where session time-out triggers re-authentication and new
encryption key generation

When these features are implemented, a wireless client that associates with an access point
cannot gain access to the network until the user performs a network logon. After association,
the client and the network access point or RADIUS server exchange EAP messages to perform
mutual authentication, with the client verifying the RADIUS server credentials, and vice versa.
An EAP supplicant is used on the client machine to obtain the user credentials. Upon successful
client and server mutual authentication, the RADIUS server and client then derive a client-
specific Wired Equivalent Privacy (WEP) key to be used by the client for the current logon
session. User passwords and session keys are never transmitted in the clear over the wireless
link.

802.1x can be deployed to authenticate users, such as desktop users in a corporation or

teleworkers accessing the network form a home office. In the home office scenario, access
control is required in order to prevent other residents from the home from gaining access to
controlled corporate resources . The authenticator and supplicant are the two components are
used to implement 802.1x functionality. The authenticator is a network component that checks
credentials and applies the access policy, usually implemented on a router, switch, or wireless
access point. The supplicant is a software component on users' workstation that answers the
challenge from the authenticator. Supplicant functionality may also be implemented on network
devices in order to authenticate to upstream devices. Mutual authentication functionality may
also be employed when network devices must restrict access policy to each other. Cisco IOS
Software does not currently support mutual authentication.

In the simplest scenario, no traffic is allowed to flow from a client device to the network until the
client authenticates. 802.1x frames are the only traffic between the client, or supplicant, and the
access-control device, or authenticator. A user trying to access network resources must provide
access credentials using software on the client workstation. Microsoft Windows XP includes
802.1x supplicant support, while an add-on component for Microsoft Windows 2000 is available
as a Microsoft Hotfix.
When the user provides their credentials, the information is transmitted to the authenticator by
some variant of EAP. The user's information is encrypted in the EAP transfer, so that their
credentials cannot be easily compromised. The authenticator will transmit the credentials to the
AAA server, which will verify the user credentials against its database. If the AAA server is
configured to return a network access policy, it will return the policy associated with the user or
their corresponding group. The authenticator will apply the network policy to the user's
connection, allowing traffic to flow according to the policy. The policy may include traffic
engineering values, VLAN information for user connection, and IP address information.

The authenticator can be configured with default access policies to offer restricted connectivity
for client devices that do not have supplicant support. This allows unauthenticated users to have
limited network access, but they will be required to provide credentials in some other fashion if
access to restricted resources is needed. Default policy provision for IP phones, for instance,
may be required, as IP phones do not yet include supplicant capability.