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.