Limitar el acceso a switches

Una regla básica para mantener una red segura es limitar el acceso a los equipos. 

La seguridad de acceso incluiría dos grandes accesos:

Seguridad física

La opción más simple es tener los equipos en salas cerradas con llave donde los usuarios no tengan acceso. Lamentablemente esto no es siempre posible.

Seguridad lógica

Los equipos están en la misma red física que los usuarios y por ello debemos asegurarnos de que no puedan acceder. Una buena estrategia es usar una VLAN específica para la gestión siempre diferente a la de usuarios.

Aún dificultando el acceso al tener diferentes VLAN hay que asegurarse que las conexiones remotas a los equipos (ssh, https), además de requerir usuario y contraseña, estén limitadas a aquellas con origen el departamento de redes de nuestra empresa.

HP:

El fabricante HP utiliza una estrategia sencilla para asegurar que las conexiones entrantes sean del departamento que nos interesa. Definimos las direcciones IP de aquellos que están autorizados a acceder. Esta limitación general aplica a todos los métodos de acceso (telnet, ssh, http, https):

ip authorized-managers 10.10.10.0 255.255.255.192
ip authorized-managers 10.20.10.0 255.255.255.192

CISCO:

El fabricante CISCO recurre a las access-list de tal forma que definimos una lista con aquellas direcciones que queremos permitir para posteriormente aplicar dicha ACL a la confiugración de accesos.

access-list 19 permit 10.10.10.0 0.0.0.64
access-list 19 permit 10.10.20.0 0.0.0.64
line vty 0 4
 access-class 19 in
 transport input ssh

Con esta configuración forzamos que el acceso sea únicamente vía ssh con 5 sesiones máximo y limitamos los rangos de acceso.

Inventariar en CISCO

A todos nos toca periódicamente hacer inventario de nuestros equipos. Si tenemos que confrontarlos con las facturas de compra la tarea se convierte en un suplicio, sobre todo si necesitamos comprobar que nos han facturado el número de módulos y accesorios correcto.

Si alguna vez tenéis que hacer un inventario de los equipos, módulos y accesorios CISCO de vuestra red hay varios comando imprescindibles.

Si tenéis acceso físico a los equipos lo más fácil será ir a verlos con un bloc de notas y un bolígrafo, pero en caso de no tener acceso físico por estar en otras ubicaciones estos son las instrucciones básicas:

1. Para sacar los números de serie y versiones de firmware de los equipos el comando básico es "show version"

2. Si tienes un equipo modular y quieres saber modelos y números de serie de las diferentes tarjetas: "show module"

Ejemplo de tarjetas de un 6500:
Core_1#sh module 

Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAL114XXXXX
  ....
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SAL114XXXXX

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  1  001e.4a9e.ac40 to 001e.4xxx.xxx   2.6   12.2(14r)S5  12.2(33)SXI8 Ok
  ....
  5  0019.e7d4.1a9c to 0019.4xxx.xxx   5.4   8.4(2)       12.2(33)SXI8 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status 
---- --------------------------- ------------------ ----------- ------- -------
  1  Centralized Forwarding Card WS-F6700-CFC       SAL114XXXXX  4.0    Ok
 .... 
  5  MSFC3 Daughterboard         WS-SUP720          SAL114XXXXX  3.0    Ok

Mod  Online Diag Status 
---- -------------------
  1  Pass
  ....
  5  Pass
Core_1#


3. Para conocer los GBICs que hay conectados en los switches: "show inventory raw":

Ejemplo en un equipo no modular (Cisco3750):
Cisco 3750#sh inventory raw 
NAME: "1", DESCR: "WS-C3560G-48TS"
PID: WS-C3560G-48TS-S  , VID: V03  , SN: FOC141XXXXX

NAME: "WS-C3560G-48TS - Power Supply 0", DESCR: "WS-C3560G-48TS - Power Supply 0"
PID:                   , VID:      , SN: AZS140XXXXX

....

NAME: "GigabitEthernet0/51 Container", DESCR: "GigabitEthernet Container"
PID:                   , VID:      , SN:            

NAME: "GigabitEthernet0/51", DESCR: "1000BaseSX SFP"
PID: Unspecified       , VID:      , SN: FNS143XXXXX    

NAME: "GigabitEthernet0/52 Container", DESCR: "GigabitEthernet Container"
PID:                   , VID:      , SN:            

NAME: "GigabitEthernet0/52", DESCR: "1000BaseSX SFP"
PID: Unspecified       , VID:      , SN: FNS143XXXXX    

Espero que sea de utilidad

Evitar switches no controlados en nuestra red

Sala de reuniones de una empresa mediana (tres consultores y un cliente...)

[Consultor 1] Oye José. Necesito bajarme el correo para recibir la última versión del powerpoint.

[Cliente] OK. Conectate en esa toma de pared.

[Consultor 2] Pues a mí también me iría bien conectarme.

[Cliente] Tú mismo...

[Consultor 3] ¿Puedo... ?

[Cliente] Sí claro.

[Consultor 3] Pues no quedan tomas libres...

[Consultor 1] Tranquilo Tomás, que yo tengo un switch... Mira lo conectamos a la pared y nosotros dos al switch.

....

[voces del exterior] ¿Tenéis Internet?.. Yo no, ¿tú? ... Me da un error la Excel...

Mientras tanto en la sala de explotación de redes...

[Ingeniero 1] Miguel, necesito los presupuestos para el mantenimiento del año que viene de los radioenlaces..

[Ingeniero 2] Sí... ya me lo pediste ayer...

Aparece una luz roja en la pantalla de monitorización de sistemas

[Ingeniero 1] Mierda. Se ha ido la red de la oficina de Teruel.

La aparición de un switch no controlado puede tirarte toda una red y dejando en nada meses de planificación, configuración y estabilización de tu red de usuarios.

No te puedes fiar de que los usuarios no conecten nada a la red (aunque siempre juren no hacerlo), así que tenemos que controlarlos nosotros mismos.

El principal problema de que conecten un switch no controlado en nuestra red es que pueda producir un cambio en la topología del arból de STP. Estos cambios pueden ser imperceptibles o provocar problemas (a la Telefonia IP no le gustan los cambios).

Los switches de gama media permiten dos acciones para este problema:

• Ignorar los mensajes del protocolo STP que envíe un switch no controlado.
• Bloquear la toma donde se conecte un switch no controlado.
• Avisar, vía SNMP, a los gestores de red.

Al aplicar estas políticas es muy importante tener un mapa de red con el conexionado físico de los equipos, ya que debemos permitir el tráfico de BPDU en aquellos enlaces conectados físicamente (estén activos o deshabilitados por STP) para evitarnos sorpresas al activarse caminos de backup (ante la caída de un switch la topología puede cambiar bastante, según la red que haya montada).

Para configurar estas protecciones simplemente debemos entrar en la configuración de spanning-treey activar estas opciones de securización.

En HP:

switch06(config)# spanning-tree 1-47 bpdu-filter bpdu-protection

Evitar servidores DHCP no controlados

Existe un tipo de ataques que consiste en hacerse pasar por servidor DHCP en la red. Así el equipo puede forzar que el tráfico generado desde equipos con IP dinámica pase por su tarjeta de red (y así capturar la información deseada). Es un ataque típico de Man-in-the-Middle.

Si en una red no se va a usar direccionamiento dinámico se puede bloquear el tráfico del protodolo DHCP, pero si se necesita debemos permitir este protocolo. Los switches actuales nos permiten restringir este tráfico para que sólo los servidores autorizados (los que la gente de Sistemas gestiona) envíen este tipo de información evitando así que haya intrusos haciéndose pasar por servidores DHCP.

En general la aplicación de esta política de seguridad es tan fácil como:

1. Activar la protección DHCP
2. Identificar la IP de los servidores autorizados a entregar este protocolo
3. Identificar desde qué puerto se recibirá este tráfico

El punto 3 suele ser el más complicado, pero en general para los switches de acceso el protocolo DHCP solo debería llegarle por los uplink. Este punto cambiará según la red que tengamos montada: hay que tener en cuenta los bucles existentes (el spanning-tree puede hacernos una jugada en este punto), etc. Aconsejo tener un mapa de red muy claro indicando dónde está el servidor y cuales son los caminos que pueden seguir el tráfico hasta llegar al cliente final.

Veamos un ejemplo en un switch de acceso de marca HP. En otras marcas será similar cambiando los comandos.

1. Activamos la protección de DHCP:

ACC-SW01 (config)#dhcp-snooping

2. Indicamos que servidores son los oficiales:

ACC-SW01 (config)#dhcp-snooping authorized-server 10.10.10.10
ACC-SW01 (config)#dhcp-snooping authorized-server 10.10.10.15

3. Indicamos desde qué puertos aceptaremos este tráfico (cuál es el camino para llegar desde nuestro switch a los servidores autorizados). Desde un equipo ed acceso lo más probable es que sea el uplink:

ACC-SW01 (config)#dhcp-snooping trust trk1 (suponemos que el uplink es un trunk y se llama trk1)

Esta es la idea básica... obviamente se puede complicar mucho :)

debug remotos

Sacar información de debug desde conexión remota

Los comandos de debug de los routers/switches tienen configurado por defecto mandar toda la información a la consola física del equipo. El problema viene cuando necesitas sacar esa información de debug de un equipo remoto al que te conectas por telnet/ssh. ¿Cómo hacer que esta información salga en tu pantalla y no en el conector serial del equipo?

1. Parar todos los debugs que tengas.
2. Desviar la información a tu sesión
3. Activar el debug que necesites

CISCO:

cisco# undebug all
cisco# terminal monitor
cisco# debug dhcp

HP:

switch# no debug all
switch# debug destination session
switch# debug dhcp-snooping