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

Simular petición HTTP desde nuestra terminal

A veces cuando tienes que probar la conectividad a un servicio web no siempre te puedes fiar de lo que dice el navegador web (proxy empresariales, políticas de firewall, etc.)...

Entonces para evitar las capas de aplicación, seguridad, etc... podemos acceder al servidor web deseado desde la consola de nuestro equipo. ¿qué averigúamos con esto?
- Si desde consola no tenemos conexión el problema está en la conectividad (firewall, routers, etc.).
- Si desde nuestro PC accedemos, pero desde el navegador no: el problema está en la configuración del navegador, políticas de proxy, etc.

1. Escribimos: telnet la_web_quequeremos_probar.com 80 (donde 80 es el puerto de hhtp, 443 si queremos https).
2. Una vez nos diga Connected to... significa que hemos conectado y tenemos conectividad.
3. Si queremos ver que hay respuesta podemos teclear:
3.a GET / HTTP/1.1. Pulsmoas 1 vez intro
3.b host: loquequieras. Pulsamos 2 veces intro
3.c Nos sale un churro de texto que es lo que nuestro navegador convierte en una página web visible.

miusuario@miPC > telnet configuro.blogspot.com 80
Trying 74.125.77.191...
Connected to blogspot.l.google.com.
Escape character is '^]'.
GET / HTTP/1.1
host: yomismo

HTTP/1.1 302 Found
Location: http://www.google.com/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Mon, 26 Apr 2010 16:51:23 GMT
Server: sffe
Content-Length: 219

302 Moved

The document has moved
here.


Connection to blogspot.l.google.com closed by foreign host.
miusuario@miPC >

Borrar config switch HP

En ocasiones tienes que devolver un switch en el que has plantado tu configuración (RMA, equipo en préstamo, etc.) y no te interesa que el receptor del equipo pueda ver tu configuración de red, así que quieres borrar toda traza.

En los HP hay un comando para esto:

ProCurve Switch 2848# erase startup-config

Este comando borra la configuración de arranque del switch y lo reinicia. Una vez reiniciado está tal cómo vino de fábrica.

ATENCIÓN: Este comando no tiene vuelta atrás. Si lo ejecutas pierdes toda la configuración que tuvieras.

Monitor port en Cisco3560

Si necesitamos acceder al tráfico que circula por una red de switches debemos habilitar un puerto de switch para que nos copie el tráfico que circula por otra. Esta acción es útil cuando necesitas analizar el comportamiento de protocolos de red (STP, CDP, BGP, RIP, etc.) y los logs de los equipos no son suficientes.

Este sistema te copia todo el tráfico a la boca de red que tu digas, por lo que necesitas conectar un sniffer que te ayude a filtrar e interpretar el tráfico y protocolo que realmente necesites.

Ejemplo: Necesitamos monitorizar el tráfico que pasa por la boca Gi0/1 de nuestro switch. Conectaremos el sniffer en la Gi0/23.

(config)#monitor session 1 source interface GigabitEthernet 0/1
(config)#monitor session 1 destination interface GigabitEthernet 0/23

Ahora sólo queda capturar el tráfico que queramos y desmontar la monitor session:

(config)# no monitor session 1

En equipos Cisco puedes tener varias monitor session dependiendo del hardware y la versión de IOS. Consulta la documentación para saber cuál es tu capacidad.

P.D. Obviamente... además de ver el tráfico de red puedes ver las conversaciones del Messenger de tu compañera de oficina ;)

Estos comandos están probados en un switch Cisco3560 con IOS 12.2(52)SE.
Existen otras marcas con comandos diferentes pero la misma funcionalidad.