A menudo los problemas de conectividad provienen de la rotura de componentes, un clima adverso o simplemente un problema de configuración. Una vez que su red esté conectada a Internet o abierta al público en general, van a aparecer una gran cantidad de amenazas provenientes de los mismos usuarios. Esas amenazas pueden estar en un rango desde las benignas hasta las indiscutiblemente malévolas, pero todas van a tener impacto en su red si no está configurada correctamente. Esta sección se enfoca en algunos problemas comunes encontrados una vez que su red es utilizada por seres humanos reales.

Si una universidad aloja su sitio web localmente, los visitantes del sitio desde fuera del campus y del resto del mundo van a competir con los trabajadores de la universidad por el ancho de banda. Esto incluye el acceso automatizado desde los motores de búsqueda que periódicamente escanean su sitio por completo. Una solución para este problema es dividir el DNS y reflejar el sitio. La universidad refleja una copia de sus sitios web en un servidor que puede ser una compañía de almacenamiento web europea, y utiliza el DNS dividido para direccionar a todos los usuarios de fuera de la universidad hacia el sitio reflejado, mientras que los usuarios de la universidad acceden al mismo sitio pero a nivel local. Los detalles sobre cómo configurar esto se proveen en el capítulo tres.

Un servidor proxy debe ser configurado para aceptar solamente conexiones desde la red de la universidad, no desde el resto de Internet. Esto se debe a que gente de todos lados se va a conectar y utilizar los proxis abiertos por una variedad de razones, como por ejemplo evitar pagar por ancho de banda internacional. La forma de configurarlo depende del servidor proxy que usted use. Por ejemplo, puede especificar el rango de direcciones IP para la red del campus en su archivo squid.conf de manera que esta sea la única red que puede utilizar Squid. Alternativamente, si su servidor proxy está detrás del límite de un cortafuego, puede configurar el cortafuego para que le permita solamente a los servidores internos que se conecten al puerto proxy.

Un servidor de correo electrónico configurado incorrectamente puede ser encontrado por gente inescrupulosa, y usado como un servidor de retransmisión para enviar grandes cantidades de mensajes y de correo no deseado.

Ellos lo hacen para ocultar la verdadera fuente del correo no deseado y para evitar ser atrapados. Para detectar esta vulnerabilidad, haga la siguiente prueba en su servidor de correo electrónico (o en el servidor SMTP que actúa como servidor de retransmisión en el perímetro de la red del campus). Use telnet para abrir una conexión al puerto 25 del servidor en cuestión (con algunas versiones Windows de telnet, puede ser necesario escribir 'set local_echo' antes de que el texto sea visible):

telnet mail.uzz.ac.zz 25

Si se permite conversación de línea de comando interactiva (como el ejemplo que sigue), el servidor está abierto para retransmitir:

MAIL FROM: spammer@waste.com
250 OK - mail from <spammer@waste.com>
RCPT TO: innocent@university.ac.zz
250 OK - rcpt to spammer@waste.com

En su lugar, la respuesta después del primer MAIL FROM debe ser algo así:

550 Relaying is prohibited.

Una prueba en línea como esta, así como información acerca de este problema, están disponibles en sitios como http://www.ordb.org/. Como aquellos que envían correos masivos tienen métodos automatizados para encontrar los servidores de retransmisión abiertos, una institución que no protege sus sistemas de correo es casi seguro que va a ser víctima de abusos. Configurar el servidor de correo para que no sea un relevador abierto consiste en especificar las redes y hosts que están autorizados para transmitir mensajes a través de él en el MTA (por ejemplo, Sendmail, Postfix, Exim, o Exchange). Éste probablemente va a ser el rango de direcciones IP de la red del campus.

El abuso del ancho de banda a través de programas entre pares (P2P) para compartir archivos como Kazaa, Morpheus, WinMX y BearShare se puede prevenir de las siguientes formas:

• No permita la instalación de nuevos programas en las computadoras del campus. Para prevenir la instalación de programas como el Kazaa, no debe darse a los usuarios comunes acceso de administrador a las estaciones de trabajo. Muchas instituciones también estandarizan la configuración de sus máquinas, instalando el sistema operativo requerido en una computadora, luego instalan todas las aplicaciones y las configuran de una forma óptima, incluyendo la imposibilidad de que los usuarios instalen nuevas aplicaciones. Una imagen del disco de esta PC se clona a todas las otras PCs utilizando un programa como Partition Image (vea http://www.partimage.org/) o Drive Image Pro (vea http://www.powerquest.com/). Es probable que de vez en cuando los usuarios puedan eludir el control y consigan instalar nuevo software o dañar el que ya tenía instalado la computadora (provocando por ejemplo que esta se “cuelgue” a menudo). Cuando esto pasa, un administrador simplemente puede restablecer la imagen del disco, logrando que el sistema operativo y todo el software en la computadora sean exactamente como se especificó originalmente.

• Bloquear esos protocolos no es una solución. Esto pasa porque Kazaa y otros protocolos son lo suficientemente hábiles como para eludir los puertos bloqueados. Por omisión Kazaa utiliza para la conexión inicial el puerto 1214, pero si no está disponible intentará utilizar los puertos 1000 al 4000. Si también están bloqueados, utiliza el puerto 80, haciéndose ver como tráfico de consultas web. Por esta razón los ISPs no lo bloquean, pero sí lo "limitan", utilizando un administrador de ancho de banda (vea el capítulo tres).

• Si limitar el ancho de banda no es una opción, cambie el diseño de la red. Si el servidor proxy y los servidores de correo están configurados con dos tarjetas de red (como se describe en el capítulo tres), y esos servidores no están configurados para reenviar ningún paquete, entonces van a bloquear todo el tráfico P2P. También van a bloquear todos los otros tipos de tráfico como Microsoft NetMeeting, SSH, software VPN, y todos los otros servicios no permitidos específicamente por el servidor proxy. En redes con un ancho de banda escaso se puede decidir que la simplicidad de este diseño prepondera sobre las desventajas que tiene. Esta decisión puede ser necesaria, pero no debe tomarse a la ligera. Los administradores no pueden predecir las formas innovadoras en las que los usuarios van a hacer uso de la red. Si bloqueamos preventivamente todos los accesos, también impediremos que los usuarios puedan hacer uso de cualquier servicio (aún los servicios de ancho de banda lento) que su proxy no soporte. Si bien esto puede ser deseable en circunstancias de ancho de banda muy lento, en general nunca debe ser considerada como una buena política de acceso.

Existen programas que se instalan a sí mismos y luego utilizan ancho de banda –por ejemplo el denominado Bonzi-Buddy, el Microsoft Network, y otros tipos de “gusanos”. Algunos programas son espías, y permanecen enviando información sobre los hábitos de búsqueda (y de consumo) de un usuario hacia una compañía en algún lugar de Internet. Estos programas se previenen, hasta cierto punto, educando a los usuarios y cerrando las PCs para evitar el acceso como administrador a los usuarios normales. En otros casos, tenemos soluciones de software para encontrar y remover estos programas problemáticos, como Spychecker (http://www.spychecker.com/), Ad-Aware (http://www.lavasoft.de/), o xp-antispy (http://www.xp-antispy.de/).

Los últimos sistemas operativos de Microsoft Windows suponen que una computadora con una conexión LAN tiene un buen enlace a Internet, y descarga automáticamente parches de seguridad, correctores de fallas y mejoradores, desde el sitio web de Microsoft. Esto puede consumir grandes cantidades de ancho de banda en un enlace a Internet costoso. Los dos posibles enfoques a este problema son:

• Deshabilitar las actualizaciones de Windows en todas las estaciones de trabajo. Las actualizaciones de seguridad son muy importantes para los servidores, pero que las estaciones de trabajo en una red privada protegida como la red de un campus las necesiten, es algo debatible.

• Instalar un Servidor de Actualización de Software. Este es un programa gratuito de Microsoft que le permite descargar todas las actualizaciones de Microsoft durante la noche al servidor local y luego distribuirlas desde allí a las estaciones de trabajo cliente. De esta forma las actualizaciones de Windows utilizarán el ancho de banda del enlace a Internet durante el día. Desafortunadamente, para que esto funcione, todos los PCs cliente deben ser configurados para utilizar el Servidor de Actualización de Software. Si usted tiene un servidor DNS flexible, también puede configurarlo para que responda todas las solicitudes al sitio web windowsupdate.microsoft.com, y lo redireccione hacia su servidor de actualización. Esta es una buena opción sólo para redes muy grandes, pero puede ahorrar una incalculable cantidad de ancho de banda de Internet.

Bloquear el sitio de actualizaciones de Windows en el servidor proxy no es una buena solución porque el servicio de actualización de Windows (Actualización Automática) va a continuar intentando más agresivamente, y si todas las estaciones de trabajo lo hacen, se produce una pesada carga en el servidor proxy. El extracto de abajo es del registro del proxy (registro de acceso Squid) donde esto fue hecho bloqueando los archivos de gabinete Microsoft (.cab).

La mayoría del registro Squid lucía así:

2003.4.2 13:24:17 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:18 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:18 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab HEAD 0
2003.4.2 13:24:19 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:19 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:20 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:21 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:21 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab GET 0
2003.4.2 13:24:21 192.168.1.21 http://windowsupdate.microsoft.com/ident.cab
  *DENIED* Banned extension .cab HEAD 0

Si bien esto puede ser tolerable cuando tenemos unos pocos PC cliente, el problema crece significativamente cuantos más nodos se agregan a la red. En lugar de forzar al servidor proxy a procesar solicitudes que siempre van a fallar, tiene más sentido redireccionar los clientes del Software de Actualización a un servidor local de actualización.

Además de las actualizaciones de Windows, muchos otros programas y servicios dan por sentado que el ancho de banda no es un problema, y por lo tanto lo consumen por razones que el usuario no puede predecir. Por ejemplo, los paquetes anti-virus (como el Norton AntiVirus) se actualizan a sí mismos directamente desde Internet, automática y periódicamente. Sería mejor si esas actualizaciones se distribuyeran desde el servidor local.

Otros programas como el reproductor de video RealNetworks, descarga actualizaciones y publicidad automáticamente, así como envía información sobre los hábitos de uso a un sitio en Internet. Pequeñas aplicaciones (conocidas como applets) aparentemente inocuas (como Konfabulator y miniaplicaciones que crean accesos directos desde el escritorio del usuario, conocidas como Dashboard widgets) sondean continuamente los servidores de Internet buscando información actualizada. Esta información puede requerir poco ancho de banda (como las actualizaciones del estado del tiempo o de noticias), o mucho ancho de banda (como las cámaras web). Estas aplicaciones deben ser limitadas o bloqueadas por completo.

Las últimas versiones de Windows y Mac OS X tienen un servicio de sincronización horaria. Este mantiene el reloj de la computadora en la hora exacta conectándose a dos servidores de sincronización en Internet. Para eso es mejor instalar un servidor local de hora y distribuir la hora exacta desde allí, en lugar de ocupar el enlace de Internet con esas solicitudes.

Las computadoras que tienen el sistema operativo Windows se comunican entre ellas usando Network Basic Input/Output System - NetBIOS (es una interfaz de programación que permite a las aplicaciones instaladas en computadores diferentes dentro de una red local comunicarse) y Server Message Block - SMB (un protocolo para compartir archivos, impresoras, puertos y otros servicios y dispositivos entre computadores). Estos protocolos operan sobre TCP/IP y otros protocolos de transporte. SMB es un protocolo que realiza elecciones para determinar cuál computadora va a ser el buscador maestro. El buscador maestro es una computadora que mantiene una lista de todas las computadoras, recursos compartidos e impresoras que usted puede ver en el Entorno de Red. La información sobre recursos compartidos también es transmitida a intervalos regulares.

El protocolo SMB fue diseñado para redes LAN y causa problemas cuando la computadora con Windows está conectada a Internet. A menos que el tráfico SMB sea filtrado, se esparcirá por el enlace a Internet, desperdiciando el ancho de banda de la organización. Para prevenirlo se pueden tomar los siguientes pasos:

• Bloquear el tráfico SMB/NetBIOS saliente en el enrutador perimetral o en el cortafuego. Este tráfico consume ancho de banda, y peor aún, presenta un riesgo de seguridad. Muchos “gusanos” en Internet y herramientas de penetración buscan activamente SMB abiertos, y explotan dichas conexiones para ganar ulterior acceso a su red.

• Instale ZoneAlarm en todas las estaciones de trabajo (no en el servidor). Una versión gratuita se puede encontrar en http://www.zonelabs.com/. Este programa le permite al usuario determinar cuáles aplicaciones pueden hacer conexiones a Internet y cuáles no. Por ejemplo, Internet Explorer necesita conectarse a Internet, pero el Explorador de Windows no. ZoneAlarm puede bloquear el Explorador de Windows para que no lo haga.

• Reduzca los recursos compartidos de la red. Idealmente, sólo el servidor de archivos debería tener recursos compartidos. Puede utilizar una herramienta como SoftPerfect Network Scanner (disponible en http://www.softperfect.com/) para identificar fácilmente todos los recursos compartidos en su red.

Los gusanos y los virus pueden generar una gran cantidad de tráfico. Por ejemplo el gusano W32/Opaserv aún prevalece, a pesar de que es muy viejo. Se esparce a través de los recursos compartidos de Windows y es detectado por otras personas en Internet porque intenta esparcirse aún más. Por esta razón es esencial que haya una protección anti-virus instalada en todas las PCs. Más esencial aún es la educación de los usuarios en cuanto a no ejecutar archivos adjuntos, así como no dar respuesta a correos no deseados. De hecho debería haber una política de que ni las estaciones de trabajo, ni el servidor, puedan correr servicios que no están utilizándose. Una computadora no debería tener recursos compartidos a menos que fuera un servidor de archivos; y un servidor no debería correr servicios innecesarios. Por ejemplo, los servidores Windows y Unix generalmente corren un servicio de servidor web por omisión. Éste debería deshabilitarse si dicho servidor tiene una función diferente; cuantos menos servicios corra una computadora, menos posibilidades tiene de ser atacada.

Ocasionalmente, un error cometido por un único usuario puede llegar a causar un problema serio. Por ejemplo, un usuario cuya cuenta universitaria está configurada para reenviar todo el correo a su cuenta personal en Yahoo. El usuario se va de vacaciones, y todos los correos que le fueron enviados se siguen reenviando a su cuenta en Yahoo la cual puede crecer sólo hasta 2 MB. Cuando la cuenta de Yahoo se llene, va a comenzar a rebotar los correos para la cuenta de la universidad, la cual inmediatamente los va a reenviar a la cuenta de Yahoo. Un lazo de correo electrónico se forma cuando se envían y re-envían cientos de miles de correos, generando un tráfico masivo y congestionando los servidores de correo.

Existen opciones dentro de los servidores de correo que son capaces de reconocer los lazos. Estas opciones deben activarse por omisión. Los administradores también deben tener cuidado de no apagarlas por error. Debe también evitar instalar un sistema de re-envío SMTP que modifique los encabezados de los correos de tal forma que el servidor de correo no pueda reconocer el lazo que se ha formado.

Un usuario puede iniciar varias descargas simultáneas, o descargar grandes archivos tales como 650MB de imágenes, acaparando la mayor parte del ancho de banda. La solución a este tipo de problemas está en el entrenamiento, hacer descargas diferidas, y monitoreo (incluyendo monitoreo en tiempo real, como se subrayó en el capítulo seis). La descarga diferida se puede implementar al menos de dos formas:

En la Universidad de Moratuwa, se implementó un sistema utilizando el direccionamiento URL. A los usuarios que acceden a direcciones ftp:// se les ofrece un directorio donde cada archivo listado tiene dos enlaces: uno para la descarga normal, y otro para la descarga diferida. Si se selecciona la descarga diferida, el archivo especificado se pone en cola para descargarlo más tarde, y al usuario se le notifica por correo electrónico cuando la descarga está completa. El sistema mantiene una memoria intermedia (cache) de archivos descargados recientemente, y cuando los mismos se solicitan de nuevo, los recupera inmediatamente. La cola de descarga se ordena según el tamaño del archivo, por lo tanto los archivos pequeños se descargan primero. Como una parte del ancho de banda se dedica para este sistema aún en las horas pico, los usuarios que solicitan archivos pequeños pueden recibirlos en minutos, algunas veces hasta más rápido que una descarga en línea.

Otro enfoque puede ser crear una interfaz web donde los usuarios ingresan el URL del archivo que quieren descargar. El mismo se descarga durante la noche utilizando una tarea programada (o cron job por su nombre en inglés). Este sistema funciona solamente para usuarios que no sean impacientes, y que estén familiarizados con los tamaños de archivos que pueden ser problemáticos para descargarlos durante las horas de trabajo.

Cuando los usuarios necesitan transferir archivos grandes a colaboradores en cualquier lugar en Internet, se les debe enseñar cómo programar la subida (upload) del archivo. En Windows, subir archivos a un servidor FTP remoto se puede hacer utilizando un guión (script) FTP, que es un archivo de texto con comandos FTP similares a los siguientes (guardado como c:\ftpscript.txt):

open ftp.ed.ac.uk
gventer
mysecretword
delete data.zip
binary
put data.zip
quit

Para ejecutarlo, escriba esto desde la línea de comando:

ftp -s:c:\ftpscript.txt

En computadoras con Windows NT, 2000 y XP, el comando puede guardarse en un archivo como transfer.cmd, y ser programado para correr en la noche utilizando las Tareas Programadas (Inicio ⇒ Configuración ⇒ Panel de Control ⇒ Tareas Programadas). En Unix, se puede hacer lo mismo utilizando las opciones at o cron.

Los usuarios a menudo necesitan enviarse archivos grandes. Si el receptor es local, es un gasto innecesario de ancho de banda enviarlos vía Internet.Para eso se debe crear un recurso compartido en el servidor web local Windows / Samba / Novell, donde un usuario puede colocar archivos grandes para que otros los descarguen.

Como una alternativa se puede escribir una interfaz web para que un servidor web local acepte un archivo pesado y lo coloque en un área de descarga. Después de cargarlo al servidor web, el usuario recibe un URL correspondiente al archivo, que puede transmitir a sus colaboradores locales o internacionales para que accedan al archivo. Esto es lo que ha hecho la Universidad de Bristol con su sistema FLUFF. La universidad ofrece una facilidad para la carga de archivos pesados (FLUFF por su sigla en inglés) disponible en http://www.bristol.ac.uk/fluff/. Esos archivos pueden se accedidos por cualquiera al que se le haya dado su ubicación. La ventaja de este enfoque es que los usuarios pueden brindar acceso a sus archivos a usuarios externos, mientras el método de archivos compartidos funciona sólo para los usuarios dentro de la red del campus. Un sistema como este se puede implementar fácilmente como un guión (script) CGI utilizando Python y Apache.

• Anterior: Técnicas adecuadas para la resolución de problemas.
• Siguiente:Consejos generales.
• Volver al índice.