miércoles, 7 de octubre de 2009

Ejemplo de diagnostico de una red

Encontrarse con una red compleja puede dejarlo a uno sin saber por donde empezar.
Este es un ejemplo real:
La red esta compuesta por:
1) Tres switches en cascada Nortel Baystack 450 con un total de 72 puertos ethernet todos ocupados
2) El tercer switch esta en cascada mediante conexion por fibra optica
3) En la red hay innumerables switches parasitos conectados por terceros en su afan de hacer funcionar camaras ip, puntos de acceso (wifi), otras pc sin acceso a puestos de red "reales"
4) Enlaces wifi de gran alcance para interconectar dos sucursales, lo que aumenta notablemente el numero de terminales y en consecuencia nodos generadores de errores.
5) La cantidad de pc, casi todas con windows xp, es tal, que la presencia de un solo virus podria provocar fallos inesperados o inexplicables.

Se presento el siguiente problema:
Luego de la instalacion de un software de gestion que utiliza conexion odbc con servidor sql, ocurrio que la operacion que en algunos terminales tardaba uno o dos segundos, en otros tardaba 20 segundos.

La primer sospecha es el rendimiento del terminal, con factores como procesador, memoria, malware, etc. Pero se determino que no era ese el problema, incluso algunas pc en las que el sistema funcionaba lento, contaban con procesadores mas potentes y mayor cantidad de memoria que aquellos en los que el sistema funcionaba bien.
Por otro lado, en cualquiera de los terminales, tanto los "buenos" como los "malos", cualquier otro sofware, sea local o de red, funcionaba bien.

El siguiente en la lista de sospechosos es el propio software que, en definitiva, es el que comenzó con los problemas. Asi que se invita a los programadores a tratar de encontrar la causa.
Mi sospecha era que en aquellas pc malas, una version erronea de mdac, o la falta de algun parche podria se el causante.
Luego de varias pruebas en las que se utilizaron herramientas de sql server para hacer consultas sql remotas se llegó a la conclusion de que el problema esta centrado en la red.

Un experimento importante para descartar un mal funcionamiento del puerto del switch, incluso del cableado, fue probar que una pc mala seguia siendo mala aun cuando se la conectaba a la red utilizando el puesto en el que funcionaba una pc buena. (eso fue facil, simplemente el patchcord de una pc cercana era sufifientemente largo como para pedirlo prestado por un par de minutos)

Aislar la red

Se conectaron en red mediante un switch generico unicamente tres pc, el servidor sql, una pc "buena" y una pc "mala".
El resultado fue que todo funcionaba perfecto, la pc buena seguia funcionando igual y la pc mala mejoró tanto que incluso funcionaba mas rapido que la "buena".

El paso anterior ayudo a aislar el problema, ya se sabia que no estaba centrado en el software de gestion, si no en la red.

En este punto fui abandonado a mi suerte, los programadores dijeron: cambia el swich y problema resuelto.
Pero hacer una inversion de unos U$S 7000.00 requiere de cierto estudio.
Pensé: si al aislar de ese modo la red las cosas funcionan bien, podria ser que las pc malas tengan una vulnerabilidad afectada por otras pc de la red infectadas con algun virus.

¿Cómo resolver ese problema, o al menos como sacarme esa duda sin morir enredado en una maraña de cables utp?
Facil: instalé Wireshark en una pc mala y comencé a analizar el trafico que le llegaba. Simplemente se desactivan todos los programas que utilizan la red, como antivirus, actualizaciones automaticas, se detiene todo programa que utilice la red.
Luego se inicia wireshark y se espera a que "piquen" los primeros paquetes tcp.
En este caso, el flujo de informacion fue tal (y no era broadcast) que de inmediato tuve un diagnostico:
La pc tiene alguna vulnerabilidad que esta intentando ser atacada por algunas pc (infectadas) de la red las cuales pude identificar.
A veces una pc no infectada no esta libre de ser afectada por los virus. El virus confiker es un ejemplo claro ya que, anque no infecte, al intentar infectar, al bombardear constantemente a una pc vulnerable, la deja "tonta".

Una herramienta para detectar vulnerabilidades de este tipo (Gracias José Perez, socio!!)
es nmap. Este programa, en la version 5.0 tiene parametros para analizar si una pc esta comprometida al ataque de confiker o un clon.
Nmap es una herramienta de escaneo de redes para linux pero tambien puede ser instalada en windows.
El comando para analizar esa vulnerabilidad y otras es:

nmap -p445 --script=smb-check-vulns --script-args=unsafe=1 192.168.1.2

En donde 192.168.1.2 es un ejemplo de la direcion ip de una pc a analizar.

Todo muy bonito, pero el comando en cuestion me informaba que en la pc mala todo estaba bien.
Asi que opté por instalar todo cuanto pudiera en lo referente a actualizaciones de seguridad de windows xp. Despues de las actualizaciones, wireshark dejo de mostrar el enorme trafico. Todo estaba calmo.

Solo restaba probar el programa, que para mi sorpresa seguia igual de lento!!.

Siempre con el experimento de aislar la red en mente, y ahora ya mirando de reojo al switch, probé de cambiar la placa de red en la pc mala. El resultado fue que eso resolvio el problema!
Entre el switch y la placa de red hay algo que ralentiza las comunicaciones y en especial se ve afectada la comunicacion con el servidor sql.

Alentado por el buen resultado, se me ocurrio otro experimento: conecté una pc "mala" a un switch generico y este a su vez al Nortel. Eso tambien resolvio el problema. En palabras simples, el switch generico hace de interprete para que el nortel entienda a algunas placas de red.

Hizo falta un experimento mas para darme cuenta del verdadero problema, fue obvio cuando lo descubri y pensé: ¿Como no se me habia ocurrido esto antes???
Otra pc de la red presentaba el mismo problema por lo que me dedique a cambiarle la placa de red y mi segunda sorpresa en esta travesia fue que no logré mejoria al cambiar la placa.
Ahi el problema salto al instante: la placa no negocia bien el tipo de conexion.
Muchos de los que leyeron hasta aqui ya lo habran pensado ni bien inicie el relato y sí, esta bien, tienen razon. Me hubiese ahorrado mucho trabajo si hubiese forzado full duplex a maxima velocidad en la placa de red.