Me despertó el jueves el sonido de agua cayendo y aunque el dormitorio estaba todavía oscuro comprendí que la mañana estaba avanzada. Varios de los gatos de la casa andaban rondando por allí y en la penumbra distinguí la colección de botellas individuales de escocés del compañero de piso de Dan esparcidas por el suelo. Pensé que había llegado el momento de decidir la dirección de nuestro próximo movimiento.
Andrew llevaba una semana en la Well y ahora poseíamos algunos datos reales y algunas pistas potencialmente sólidas. Pero nuestro intruso seguía suelto y sin control, y necesitábamos ponemos en movimiento. Con la opción de la Colorado SuperNet cada vez menos viable, tenía que afrontar la idea de efectuar nuestra observación desde la Netcom. Uno de los mayores proveedores de servicio InterNet del país, la Netcom haría que nuestra investigación fuese como buscar a alguien en la estación Grand Central Terminal. Me sentía frustrado por el bloqueo en la CSN, y dediqué infructuosamente varias horas de principios de la tarde a ver si había alguna forma de evadir el impedimento del FBI de Los Ángeles en Colorado.
Después, como Julia estaba nerviosa, hablamos un rato. Los dos teníamos claro que John contaba con los recuerdos agradables de Wylbur Hot Springs para debilitar la decisión de ella de abandonarlo.
“Temo no poder conservar mi sentido de la perspectiva cuando esté con él”, dijo. No estaba segura de su capacidad para independizarse de John y la preocupaba verse absorbida nuevamente por la relación entre ellos. “Esto va a ser difícil”, añadió. “Quiero asegurarme de descansar lo suficiente esta noche”.
Estábamos a media tarde y yo decidí que no quería volver a la Well. Por un lado, el fotógrafo de Wired que yo trataba de evitar seguía allí clavado esperando. Andrew me había llamado ya varias veces y yo seguía diciéndole “ahora voy”, pero estaba claro que debíamos aceptar la oferta de apoyo de la Netcom. Hacía mucho que veíamos tráfico desde allí y un observatorio en su cuartel general nos proporcionaría un puesto de escucha de alcance nacional en su extensa red y posiblemente una ubicación que nos situaría más cerca de nuestro atacante. Además, teníamos varios sucesos reveladores —las sesiones abruptamente interrumpidas— que tal vez pudiésemos utilizar para determinar la identidad del intruso en el sistema Netcom.
Me puse al habla con Rick Francis, el vicepresidente de la Netcom para el desarrollo de software, que había participado en la conferencia telefónica en la Well el martes, le conté mi plan y le pregunté si su oferta seguía en pie. Me excusé por llamarlo al final de un día de trabajo, pero a él no parecía importarle y me dijo que su personal se quedaría aún un rato más para hablar con nosotros.
Antes de irme llamé a Andrew e hice que me leyera la hora exacta de varios sucesos corregida según su mejor cálculo de nuestro error de sincronía, de forma que tuviésemos algo que comparar con los registros de la Netcom. Eran casi las cuatro cuando Julia y yo compramos unos burritos en Zona Rosa, en Haight Street, y cogimos la I-280 hacia San José en su Mazda. Pensé que de una forma u otra más adelante podría traer mi ordenador de la Well.
La 280, que recorre una extensión de la falla de San Antonio, es considerada por muchos la autopista más hermosa del mundo. La descripción es simpática, aunque siempre me ha parecido una figura retórica. Arrimada a la falda de las montañas de Santa Cruz, la 280 corre por el centro de la península y es en realidad la Mulholland Drive de Silicon Valley. Camino del sur la carretera serpentea a través de Woodside, Portola Valley y las colinas de Los Altos, donde se mezclan la riqueza nueva y la vieja. Conduciendo por los miles de acres que una vez fueron propiedad rural de Leland Stanford, se pueden ver aún las vacas pastando no muy lejos del 3000 de Sand Hill Road, centro cerebral de la comunidad de los capitalistas de riesgo, principal beneficiaria de lo que se ha descrito como la mayor acumulación legal de riqueza de la historia.
Por el camino me comí mi burrito y telefoneé a Kent Walker para comunicarle nuestro próximo paso. Le hablé de los obstáculos en Colorado y le pregunté sobre los alcances de la ley de Intimidad de Comunicaciones Electrónicas, que hace ilegal interceptar llamadas de teléfonos móviles. Aunque sea ilegal escuchar llamadas orales, ¿sería una violación de la ley verificar simplemente la presencia o ausencia de un portador de datos enviado por modem en una llamada de teléfono móvil? Me respondió que mientras no descifrásemos el contenido de la información, la intercepción probablemente sería legal. A esas alturas mi pregunta era solamente hipotética, pero en cierto momento se me había ocurrido que tal procedimiento pudiera ser nuestra única opción.
Veinticinco kilómetros más al sur, en Cupertino, la I-280 pasa junto a las nuevas instalaciones de investigación y desarrollo de Apple Computer. Aquí, en 1993, el ex presidente de Apple, John Sculley, planeó establecerse como principal funcionario técnico de la compañía, sólo para ser depuesto por un golpe de mano en el directorio muy semejante a aquel por el cual él mismo desplazó ocho años antes al visionario original de Apple, Steve Jobs. Desde Cupertino la carretera describe un arco a través del corazón de Silicon Valley, brindando interminables imágenes de la fabricación de semiconductores, diseño de ordenadores y plantas de montaje.
La Netcom está alojada en una torre de acero y cristal de doce plantas frente a la Winchester Mystery House muy próxima a la 280 en San José. Aunque actualmente sea una atracción turística, el hogar de los Winchester fue proyectado por la paranoica viuda del inventor del rifle de repetición que lleva su nombre y está llena de habitaciones ocultas y pasajes secretos que no conducen a ninguna parte. El nombre Winchester fue más tarde tomado en préstamo por la división de fabricación de unidades de disco de IBM, situada en el mismo extremo sur del valle, para el primer disco duro moderno.
Una vez que traspusimos las puertas de acceso e iniciamos la búsqueda de las oficinas de la Netcom, tuvimos la impresión de haber errado y hallarnos al otro lado de la calle, en la Mystery House. Acabamos bajando unas escaleras, cambiando de dirección después de asomarnos a un vestíbulo y subiendo otras varias antes de dar finalmente con el despacho de Rick Francis.
Sociológicamente hablando, Silicon Valley se divide en techies y suits. La diferencia entre ambos suele ser que los suits saben cómo vestirse y han conseguido abrirse paso desde las filas de los ingenieros a la órbita de los directivos. Francis era visiblemente uno de estos últimos, con su camisa abotonada, sus mocasines con borlas y el suéter con dibujos, el uniforme típico de los gerentes de mercadotecnia y los vicepresidentes ejecutivos a lo largo del Valley. Era evidente que lo de tratar con alguien de fuera sobre un asunto de seguridad informática era territorio virgen para él, y aunque quería colaborar, no estaba completamente seguro de lo que podía esperar de mí y en consecuencia estaba levemente en guardia.
Después de haberle puesto rápidamente en conocimiento de lo que sabíamos tras nuestra estancia en la Well, subimos con Francis a reunimos con dos miembros de su equipo técnico. Uno de ellos John Hoffman, administrador de sistemas, era del tipo del ingeniero ensimismado y estaba encargado de la configuración y el mantenimiento de los sistemas informáticos de la Netcom. El otro, Robert Hood, era administrador de red: tenía el aspecto del auténtico hacker que realmente conoce su oficio. Era tranquilo, competente y nada arrogante acerca de sus capacidades. Era asimismo el contrapunto de Francis en materia de apariencia. Rollizo y bien afeitado, Hood poseía una abundante cabellera negra rizada que le caía veinte centímetros más allá de los hombros. Vestía una desteñida camiseta negra adornada por una calavera sonriente, pantalón tejano, zapatillas deportivas, y llevaba colgado del cinturón un busca alfanumérico. Me resultó simpático de entrada. Robert era el clásico hacker de Silicon Valley que disfruta efectivamente con su trabajo. Había crecido con la Netcom desde los primeros días de la empresa como proveedora local de Internet.
Una vez que Francis les dijo a Hood y a Hoffman que nos dedicaran todo el tiempo y el equipo que necesitásemos, buscamos una sala de conferencias y nos pusimos a trabajar. Yo dejé claro que nuestro objetivo era localizar a nuestra presa lo más pronto posible y avanzar a contracorriente hasta dar con él. Una vez más repasé los datos provenientes de la Well y señalé que las conexiones en las que estábamos interesados venían reiteradamente de la Netcom y la CSN. Les expliqué asimismo que teníamos la creciente sospecha de que nos las estábamos viendo con Kevin Mitnick. Los de la Netcom ya sabían quién era; al parecer les había causado muchos problemas en el pasado.
Le mostré a Robert la lista de ocurrencias que Andrew me había leído y le pregunté si la información servía para averiguar qué cuenta podría estar utilizando el intruso en la Netcom.
“No hay problema”, respondió.
Durante la reunión, Robert y yo monopolizamos prácticamente la palabra sopesando los obstáculos para realizar el filtrado de paquetes en la Netcom. Yo hice preguntas sobre su red interna, sobre detalles de incidentes de forzamiento recientes y sobre la clase de precauciones que estaban adoptando. Pregunté también sobre los números de tarjetas de crédito robados que habíamos encontrado en la cuenta dono en la Well, y resultó que habían sido robadas casi un año antes flotando durante un tiempo en el submundo informático; su existencia había sido mencionada el año anterior en la revista 2600. Francis dijo que inicialmente la Netcom no tenía ningún firewall protector y que los datos de los clientes se habían conservado en ordenadores relativamente desprotegidos. El descuido había sido un costoso error, y lo sabían. Quiso saber si teníamos una copia sacada el presente año después de mediados de enero. Si los datos de las tarjetas de crédito habían sido robados de nuevo, estaban ante un problema gordo.
Al final fue una reunión breve, lo cual me sorprendió, pues habíamos conseguido obviar la mayor parte de las concesiones a la sociabilidad e ir directamente al grano. A continuación Francis dijo que quería que escuchase una cinta y nos llevó a una habitación próxima a su despacho, donde nos pasó la grabación del diálogo mantenido entre uno de los piratas que habían estado importunando en la Netcom y un técnico auxiliar. Francis tenía una obvia curiosidad por saber si la voz era semejante a la de los mensajes en mi sistema de correo vocal en San Diego. En la llamada grabada el técnico hablaba con el pirata acerca de la motivación de este ultimo para forzar los ordenadores de la Netcom y lo interrogaba sobre algunos de sus métodos; pero Julia y yo estuvimos de acuerdo en que la voz al otro extremo de la línea no tenía nada que ver con la de mi buzón.
Eran casi las 6:30 y Francis se disculpó por tener que irse temprano. Le habría encantado quedarse a observar, explicó, pero tenía un importante viaje de negocios a la mañana siguiente. Pero antes de irse dio su autorización final para nuestra búsqueda.
“Recuerde, cualquier cosa que le haga falta, pagamos nosotros”, dijo. “Y si tiene que viajar a alguna parte para rastrear a ese tipo, la Netcom corre con los gastos”.
Después de los choques con Claudia y de ser menospreciado por todo el mundo en la Well, el apoyo incondicional por parte de la Netcom fue un bienvenido alivio. Por primera vez empecé a sentir que teníamos una razonable probabilidad de pescar al ladrón de nuestros datos.
Julia, los dos tíos de sistemas de Netcom y yo subimos y nos apretamos en el pequeño despacho de Robert, que apenas tenía espacio para una estación de trabajo Sun y estaba atestado de manuales técnicos.
La lista que yo le había tomado por teléfono a Andrew nos daba la hora precisa de inicio y finalización de las sesiones provenientes de la Netcom con destino a las cuentas ilícitas en la Well, de modo que nuestro reto era descubrir si había un usuario único cuya entrada en la Netcom hubiera sido registrada en todas las horas de mi lista. Teníamos un indicio determinante: la hora de la conexión interrumpida en la Well debía corresponder a un similar registro de salida en la Netcom, algo que debía resaltar en las montañas de datos registrados. Además, si descubriésemos que nuestro atacante era una persona sola en vez de varias o de una pandilla que compartiese la cuenta, simplificaría grandemente nuestra tarea: Limitaría la caza a una única localización. Yo confiaba en la Navaja de Occam[32], el principio científico según el cual cuando coexisten teorías para explicar un fenómeno desconocido, ha de preferirse la más sencilla.
Robert se sentó ante su estación de trabajo y los tres nos amontonamos en torno suyo a observar mientras él buscaba en sus archivos registros de entrada y de salida ocurridos en determinadas horas. Me di cuenta inmediatamente de que era un auténtico gurú del Unix. Jamás vacilaba con el teclado, y los comandos fluían sencillamente de sus dedos. Cuando yo formulaba una pregunta, no se detenía a recordar cómo buscar una información determinada, sino que el resultado aparecía casi instantáneamente. Robert se sentía además comprometido en la captura de nuestro intruso. “Ese tipo nos ha estado molestando de veras”, dijo. “He empezado a tomarme esto como algo personal. Si das con él, allí estaré yo contigo. Y también Rick Francis y Bob Rieger, nuestro presidente. Están realmente furiosos con esto”.
Parecía entusiasmado por nuestra llegada. Con la permanente expansión de la Netcom en diferentes ciudades había tenido ya abundante trabajo. Ahora sentía una gran expectación por una aventura en la que no tendría que considerar la importancia de su trabajo oficial de administración de sistemas sino la cacería de un intruso.
Para encontrar una coincidencia entre los datos de la Netcom y la Well tenía que buscar información entre las 23 Sun SPARCstations que constituían el servicio online de la Netcom. Robert tenía un guión de búsqueda por los registros de estadísticas de uso del sistema de todas las máquinas a partir del 1 de enero, pero llevaría su tiempo.
Mientras el guión operaba, Robert empezó a hablarme de la red interna de la Netcom. Me explicó que las 23 SPARCstations estaban conectadas a un anillo de red local FDDI (Fiber Distributed Data Interface). Conectados también a este anillo estaban los ordenadores de distribución que proporcionaban conexión con Internet, así como su propia red transcontinental T-3, capaz de mover casi 45 millones de bytes de información por segundo. Este sostén, a su vez, estaba conectado a un entramado de líneas de datos T-1 que vinculaba a sus clientes de datos de alta velocidad y a sus Puntos de Presencia o POP con su concentrador de red en San José.
En lugar de tener un único número telefónico 800 o de larga distancia, la mayoría de los proveedores nacionales de servicio de Internet colocan POPs con pequeños grupos de modems de conexión en docenas e incluso cientos de ciudades por todo el país. Fue esa capacidad para establecer una red privada de datos —que fuera más allá de la red estándar telefónica pública— lo que creó las economías de escala que hicieron posible que la Netcom prosperase como proveedor de servicio de Internet a escala nacional con teléfonos de llamada incluso en ciudades bastante pequeñas por todo el país.
Quizá el esfuerzo de la Netcom por hacer fácilmente accesible su red obrara a nuestro favor. Si bien nunca habíamos visto al intruso utilizar las líneas telefónicas de llamada de la Well para acceder directamente al sistema Online de Sausalito —Netcom tenía líneas de llamada en 51 ciudades por todo el país—, si él era descuidado era posible que revelase por su propia mano su ubicación llamando a un número local de Netcom. El dispositivo de rastreo de la compañía telefónica podría entonces permitimos localizarlo, incluso si estuviese empleando un teléfono móvil.
Hablamos de lo que supondría establecer un seguimiento en una red de ordenadores que era más grande que cualquiera de las que yo hubiera tenido por delante alguna vez. Lo que necesitaba era un único punto desde el cual pudiéramos acceder a todos los paquetes que pasaban por la red. Con la Well la cosa había sido como instalarse en una esquina de la calle principal de una pequeña ciudad del Medio Oeste, interceptar todos los Ford rojos o todos los coches con matrícula de California que pasaran y hacerle una foto al conductor de cada uno. Con la Netcom, en cambio, sería como venir a Los Ángeles y hacer lo mismo en la autopista de Santa Mónica.
Resultó que había un solo punto de atasco en esta red. Esa fue la buena noticia. La mala era que ese punto se hallaba en el principal anillo FDDI. El FDDI es un elemento de red de ordenadores de muy alta velocidad que transmite datos a 100 millones de bytes por segundo, diez veces más rápido que la red Ethernet con la que operábamos en la Well. El seguimiento en esta red requería hardware adicional y un software específico, pues las herramientas de seguimiento de Ethernet empleadas en la Well eran aquí inútiles.
Para entonces disponíamos de los datos sobre registros de entrada de usuarios y Robert empezó a hurgar en ellos buscando una coincidencia. Al cabo de un rato resultó cada vez más evidente que había una única cuenta que coincidía en cada caso con los registros de entrada del transgresor en la Well.
Nuestro culpable parecía ser el usuario de una cuenta llamada gkremen. Había varios registros de entrada locales desde San Francisco este mes, pero cada una de los accesos a gkremen por teléfonos de llamada remotos venía exclusivamente a través de su remoto POP en Raleigh-Durham, Carolina del Norte.
“Estoy seguro de que es él”, dijo Robert, pero yo no quería llegar a conclusiones prematuramente, en especial porque sólo contábamos con cuatro puntos de datos, tres registros de entrada a la Well y una sesión ftp a partir de lo cual trabajar. Prestamos más atención a gkremen. ¿Quién era aquel tío? Encontramos información sobre cuentas de Netcom que indicaba que gkremen era un usuario legítimo, no una cuenta inventada como muchas de las que habíamos encontrado en la Well y en Internex. Gkremen arrendaba una conexión de red de alta velocidad de Netcom directamente desde el emplazamiento de su ordenador, pero tenía además en los sistemas de Netcom una cuenta secundaria, conocida como cuenta “shell” o de cobertura. Daba la impresión de que el verdadero gkremen utilizaba la cuenta en raras ocasiones, y el examen de los registros de conexión fue haciendo cada vez más evidente que su cuenta había sido “expropiada”.
Robert recorrió el directorio de gkremen, que resultó bastante anodino excepto por algo que le llamó la atención: un pequeño programa llamado test 1. Nos explicó que se trataba de una versión del programa telnet que no registraba su utilización. Normalmente, cuando alguien utiliza el programa telnet estándar de Netcom para conectar con otro ordenador, quedan registrados el nombre del usuario y el del ordenador remoto. Robert había empezado ya a trabajar en una modificación para el sistema operativo de la Netcom para que no se pudiera eludir la función de registro. Era obvio que alguien había secuestrado la cuenta de gkremen y la estaba usando clandestinamente. Cada vez daba más la impresión de que habíamos dado en el clavo. Explorando los registros de entrada de gkremen descubrimos incluso conexiones provenientes de emplazamientos conocidos, como escape.com y csn.org. No obstante, su favorita parecía ser Raleigh; en los pasados cinco días había accedido 26 veces desde allí. Había estado operando casi diariamente, incluyendo algunas sesiones esa misma mañana.
Creía recordar que algunos de mis amigos que viven en Raleigh se quejaban de la calidad de su servicio telefónico.
“Robert, ¿sabes qué compañía telefónica está cerca de Raleigh?”, le pregunté.
“Claro”, replicó él, “la GTE”.
“Oh, no”, dije con un gemido. “Me lo temía”.
La GTE era conocida por la lasitud de su seguridad. Era notorio que los conmutadores de su oficina central solían caer en manos de chiflados del teléfono que clandestinamente los reprogramaban para conseguir llamadas gratis y a menudo realizar esotéricos y desagradables trucos. Nuestra tarea se dificultaría mucho más si nuestro intruso había logrado también manipular el equipo de la compañía telefónica, pero ese era un obstáculo que no tendríamos que afrontar por el momento.
Potencialmente, el descubrimiento de Raleigh era un avance significativo. Nuestras operaciones de seguimiento resultarían sumamente simplificadas si el intruso estuviera sencillamente conectando con la Netcom desde el POP de Raleigh. La Netcom utilizaba una red Ethernet en cada uno de sus POP para conectar desde Portmasters hasta routers. Si pudiéramos encontrar un único emplazamiento local en la periferia de la red nacional de datos de Netcom evitaríamos tener que armar un sistema de seguimiento FCCI y seleccionar entre la enorme cantidad de datos que discurren por el meollo de la red FDDI aquí en San José. Empezamos a examinar los horarios de vuelos para ver con qué rapidez podíamos poner a alguien en Raleigh y al mismo tiempo llamé a Kent para pedirle que consiguiera una orden de intervención telefónica para el POP de Raleigh.
“Esta noche no puedo porque ya es tarde”, contestó. “Pero la tendré a primera hora de la mañana. ¿Cuál es la compañía telefónica?”. Se lo dije, pero él no pareció experimentar ante la GTE la misma reacción que yo.
Mientras yo hablaba con Kent, Robert escribió un sencillo guión para que cada vez que se usara la cuenta gkremen llegase a su busca un alerta informándole de qué POP de Netcom venía la llamada.
Eran casi las 8:30 de la noche, y el busca de Robert sonó casi enseguida de haber él terminado de instalar la alerta, pero esta vez con una mala noticia. Gkremen había registrado una entrada, pero no provenía del sistema de la Netcom a través de su POP de Raleigh: esta vez venía ¡de Denver!
“Maldición, pensé, ha actuado de forma increíblemente constante durante los últimos cinco días y ahora que aparecemos cambia de emplazamiento”. Quería decir que no podíamos estar seguros de que pasaría por Raleigh y que, por tanto, para rastrearlo tendríamos que examinar los datos de todo el país en la red Netcom. Me pregunté por un momento si lo habíamos asustado o estaba realmente en otra parte. Aunque era posible que estuviese conectando a diferentes POPs en un intento por encubrir y ocultar su ubicación real, Robert mencionó que ellos estaban teniendo problemas técnicos en Raleigh y era también posible que el intruso estuviese telefoneando a un POP distinto para conseguir una línea de modem que funcionase.
Mientras vigilábamos, Robert utilizó un programa de diagnóstico en el POP para espiar una sesión de tecleo de gkremen. Aunque el software no estaba pensado para el seguimiento de una sesión en vivo, funcionaba con ese objeto, más o menos. Cuando la persona que estaba usando la cuenta de gkremen tecleaba, Robert pulsaba el ratón, y el contenido de un pequeño buffer[33] de memoria de un Portmaster en el emplazamiento de Denver aparecía en su pantalla mostrándonos lo que el intruso tecleaba. Desgraciadamente, el buffer sólo podía mostrar sesenta fragmentos de caracteres de la actividad que iba en cada dirección, por lo que veíamos casi todo lo que el intruso escribía en su teclado, pero sólo teníamos un atisbo ocasional de lo que él estaba efectivamente viendo en su pantalla. Nos encontramos además con otro problema que dificultaba aún más el ver claramente lo que ocurría. En aquel tiempo la Netcom estaba luchando con un defecto de software en el mayor de sus routers Cisco. Se trata de los ordenadores encargados de encaminar los billones de paquetes de datos diarios que circulan por el anillo de red FDDI y enviarlos a sus destinatarios respectivos en Internet. Cada treinta segundos o así la red entera sufría un miniacceso, lo que significaba que perdíamos más pulsaciones de teclado.
No obstante los paquetes perdidos, igual podíamos hacernos una idea aproximada de lo que él hacía. Lo observamos mientras intentaba forzar la entrada en un ordenador en la CSN, al parecer sin éxito, y luego se volvía hacia otro ordenador de la instalación de Colorado y trataba de editar uno de sus archivos de configuración del sistema, pero se encontraba con que era un archivo sólo de lectura y, por tanto, no podía ser manipulado.
Observamos que a continuación el transgresor utilizaba el comando de transferencia de archivos para conectar con el ordenador de archivo público del CERT, el centro gubernamental de información sobre seguridad.
Me puse a reír. “Parece que tenía razón, los críos están leyendo manuales técnicos”, dije.
Estaba buscando en los archivos del CERT la palabra “monitor”, y sus intenciones eran obvias: intentaba saber cómo reinsertar un pequeño programa de seguimiento de red dentro del sistema operativo de uno de los ordenadores de la CSN. El programa, conocido por NIT (Network Interface Tap), es una parte estándar del software operativo básico del ordenador, pero generalmente se quita por motivos de seguridad. Si él conseguía reinstalarlo en el sistema operativo podría capturar secretamente contraseñas y otros datos útiles. Encontró lo que buscaba en un archivo llamado 94:01.ongoing.network.monitoring.attacks. El archivo proporcionaba instrucciones para desactivar el software de seguimiento, y ahora él procuraba averiguar cómo activarlo de nuevo. Lo irónico del asunto era que el archivo de CERT no era siquiera un aviso reciente, sino en realidad de hacía más de un año. No obstante, él lo seguía con la misma atención de quien sigue una receta en un libro de cocina, trabajando en las mismas narices de los administradores de sistema de la CSN.
Al ver que nuestro intruso venía ahora de Denver, le puse otra llamada a Kent para decirle que necesitábamos un rastreo y localización de llamadas telefónicas allí, además de en Raleigh. Mientras Robert y Julia permanecían absortos en los fragmentos de las sesiones del intruso, yo empecé a pensar en cómo íbamos a montar una operación de seguimiento que nos permitiese efectivamente rastrearlo. Cada POP de la Netcom tenía bancos de modems conectados a un dispositivo llamado servidor de comunicaciones Portmaster, fabricado por Livingston Enterprises, una compañía de Pleasanton, California. El Portmaster permite al usuario acceder a los ordenadores de la Netcom de su propia red. Nuestro problema era que los Portmaster, a diferencia de otros modelos, mezclaba las sesiones independientes de cada ordenador en una sola corriente de datos, lo que nos imposibilitaba desmenuzar individualmente cada sesión. Robert conocía al fundador de la Livingston y dijo que haría una llamada de emergencia para preguntarle si podía ayudamos.
Nuestro siguiente problema era encontrar la forma de realizar el seguimiento del anillo de FDDI. La tarea requería un ordenador rápido, una tarjeta interfaz y un concentrador para enganchar la máquina al anillo de la Netcom. Desgraciadamente la Netcom no disponía de recambios de ese hardware. Suponiendo que pudiésemos conseguir el hardware, aún nos haría falta un código fuente del controlador de software para la tarjeta y poder modificarlo de forma que nos permitiese el seguimiento del anillo. Yo recordé que tenía software FDDI copiado en una cinta en mi casa de San Diego, pero como nadie tenía allí una llave de reserva, no iba a servirnos de mucho.
Estuve paseándome por el atestado despacho de Robert intentando pensar dónde podíamos conseguir un concentrador FDDI para enganchar un ordenador de seguimiento al anillo de Netcom.
Me devané los sesos pensando dónde podría encontrar semejante equipo en Silicon Valley a esa hora de la noche. No podía simplemente entrar en cualquier parte y servirme, y era improbable que lo que necesitábamos lo tuviesen en Fry’s, la tienda de suministros famosa en el valle por vender desde ordenadores hasta patatas chip, pues los concentradores FDDI cuestan normalmente muchos miles de dólares.
De pronto me di cuenta que conocía a la persona justa.
Llamé a mi amigo Soeren Christensen, el gurú en redes ATM de la Sun, con quien yo había trabajado. Estaba aún en la oficina cuando telefoneé y, después de explicarle nuestros apuros, le dije que era vital que para las 7 de la mañana siguiente —hora a la que el intruso solía reaparecer cada día— dispusiéramos de una estación de rastreo instalada y en funcionamiento
“Soeren, ¿te acuerdas de aquel concentrador FDDI que estaba en el techo de vuestro laboratorio en Mountain View antes de que os mudaseis a Menlo Park?”, le pregunté. “No lo habréis conservado y lo tendréis abandonado por ahí, ¿verdad?”.
“Creo que puedo dar con lo que necesitas, Tsutomu. Me parece que recuerdo por dónde está”, respondió. “Es probable que encuentre también algún hardware extra. Voy a echar una ojeada”.
“Estupendo”, dije. “¿Dónde podemos vernos?”.
Resultó que Soeren planeaba cenar con su mujer en una pequeña cervecería de Sunnyvale llamada la Fault Line, no lejos de las oficinas de la Netcom. “Ordenaremos un poco aquí y nos reuniremos contigo allí dentro de un ratito”, le dije.
Cuando colgué el auricular, Robert y Julia seguían observando las payasadas del intruso, y me llevó cierto tiempo arrancarlos de allí para estar seguro de llegar a tiempo al restaurante. Eran casi las diez menos veinte de la noche y la cervecería cerraba dentro de veinte minutos. Resolvimos ir todos en el mismo coche, puesto que planeábamos volver a pasar el resto de la noche preparando las operaciones de seguimiento. El Mazda de Julia estaba casi enteramente ocupado por mi equipo de esquí, así que nos apilamos en el brillante Mustang verde azulado de John Hoffman. Tanto Robert como Hoffman tenían lo que parecían potentes coches americanos recién salidos de fábrica. Mientras que el modelo estándar de coche del ingeniero de Silicon Valley es normalmente un BMW o un Saab, los dos técnicos de la Netcom debían estar algo impregnados de la cultura nativa de San José. Era un poco como en American graffiti, el filme de 1973 en el que George Lucas describe los primeros años sesenta en una ciudad del Central Valley de California donde la vida gira aún en torno a los coches y no los ordenadores.
La Fault Line es una de las docenas de cervecerías que han surgido en la zona de la bahía durante la última década. Sustituto mejorado de las tabernas de cerveza y hamburguesa de una era anterior, estas minicervecerías poseen una cocina californiana más sofisticada, así como una selección de cervezas exóticas, elaboradas en grandes cubas generalmente a la vista detrás de mamparas de cristal al fondo del edificio.
Julia y yo quedamos perplejos ante la lista de cervezas, pero admitimos que después de un par de vasos no habría forma de permanecer activo toda la noche, que era lo que al parecer nos esperaba.
Soeren y su esposa, Mette, ya habían llegado cuando aparecimos los cuatro. Vi que la camarera le traía a Mette puré de rábano picante. “Sólo en California”, pensé. Mientras le contaba a Soeren lo que nos proponíamos, todos intentábamos relajamos, porque sabíamos que aquel podía ser el último paréntesis de descanso que tendríamos en bastante tiempo. Durante la cena hablamos del sistema de seguimiento que necesitábamos instalar y del problema de conseguir un ordenador lo bastante rápido para adaptarse al anillo FDDI de la Netcom. Soeren, uno de los mejores diseñadores de equipamiento de redes de la Sun, dijo que había encontrado las suficientes partes sueltas de hardware como para que armásemos un ordenador a la medida. Creía también tener el controlador del código fuente del FDDI en una copia en cinta que guardaba en su apartamento, cercano al restaurante, de modo que convinimos en que Julia volviera más tarde con él a recogerla.
Después de la cena nos detuvimos en el aparcamiento mientras Hoffman maniobraba marcha atrás hasta situar su coche junto al maletero del de Soeren.
“Esto parece un negocio con drogas en Silicon Valley”, dijo Julia. Todos reímos nerviosamente.
Desde luego que en realidad era sumamente improbable que alguien nos dedicase siquiera una segunda mirada. Probablemente, la mitad de las empresas del valle empezaron con los vendedores trabajando con la mercancía en el maletero de su coche. Soeren me alcanzó dos bolsas llenas de elementos diversos, incluyendo conectores, memoria, un módulo procesador y varias tarjetas interfaz. Mirando el material, dije: “Vaya, no deberías haberte tomado el trabajo de desarmarlo, podrías haber traído el ordenador entero”.
En cuanto llegamos a la Netcom, Hoffman se puso a armar el nuevo ordenador de seguimiento, poniendo pequeñas pegatinas verdes en todas las piezas de equipo de Sun para que pudiésemos identificarlas fácilmente. Eran más de las once cuando llamé por el busca a Andrew, que estaba en Berkeley cenando con Mark Seiden en el Siam Cuisine, el primero, y algunos dicen que todavía el mejor, de los restaurantes de la East Bay. Habíamos convenido en cederle a Mark parte de nuestra estrategia de seguimiento para facilitarle el rastreo del intruso en Internex.
“Andrew, necesito que vuelvas a la Well a recoger mi RDI y a traer todas nuestras herramientas de software aquí a la Netcom”, le dije. “Va a ser una larga noche, porque hemos de tener el seguimiento listo para cuando él entre en actividad de nuevo mañana por la mañana”.
Nuestro transgresor iniciaba su tarea generalmente alrededor de las 7, hora del Pacífico, y luego continuaba accediendo de forma intermitente a lo largo del día. Solía desaparecer por unas horas a eso de las tres de la tarde y luego retornaba a pleno rendimiento y con frecuencia permanecía activo hasta bien pasada medianoche. Era cada vez más claro que quien fuera que estuviese al otro lado de la pantalla de nuestros ordenadores no era un travieso casual, sino un adversario profundamente obsesionado con lo que fuera que estuviese haciendo.
Julia volvió alrededor de medianoche con la cinta FDDI de Soeren y nos llevó un buen rato dar con el controlador de cinta adecuado para leerla. Cuando finalmente miré el software de Soeren mi corazón dio un vuelco. Era ciertamente el código fuente del software del controlador, pero estaba escrito para el sistema operativo Solaris 2 de Sun. La Netcom operaba con Solaris 1. Era inútil.
Yo había esperado insertar fácilmente el software de Soeren en nuestro ordenador de seguimiento. Si efectivamente hubiésemos tenido el código fuente habría sido bastante sencillo. Habría querido usar mi software modificado de filtro de paquetes Berkeley (BFP) porque estaba escrito como para adecuarse al torrente de paquetes de datos que discurría por el anillo de fibra óptica de la Netcom. Ahora íbamos a tener que emplear otra estrategia.
A las 12:40, mientras desempeñábamos nuestras diversas tareas, el intruso reapareció. Seguía entrando desde Denver y continuaba interfiriendo los ordenadores de la CSN. Poco rato después Robert le vio forzar la entrada en fish.com, el ordenador de Dan Farmer. Observó al intruso examinando en el correo de Dan la aparición de sus diferentes hileras de texto, itni y tsu. La primera significaba que ciertamente seguía buscando la palabra Mitnick, y la segunda era probablemente por mí. Si mi oponente era realmente Mitnick, ahora había cobrado un acuciante interés en mí. Al cabo de un rato estaba de nuevo en los ordenadores de la Netcom, esta vez tratando de descubrir adonde era encaminado el correo de Rick Francis.
Como a las dos de la mañana apareció Andrew con nuestro hardware y software y se puso inmediatamente a trabajar con la intención de encontrar la forma de instalar el software de paquetes Berkeley en el software del controlador FDDI partiendo de cero. Yo estaba completamente seguro de que sin el código fuente no iba a funcionar, pero Andrew era optimista y se puso a la tarea.
La mayor parte del personal de la Netcom se había ido horas antes, dejándonos solos entre aquellos cubículos individuales separados por mamparas en los salones sin ventanas. Las únicas otras personas que quedaban eran unos instaladores al otro extremo del piso que ponían un nuevo PBX en el cuarto de las máquinas de la Metcom. La compañía tenía el aspecto de un típico negocio de Silicon Valley en pleno hipercrecimiento. Tan pronto como se trasladan a una nueva sede, estas organizaciones tienden a crecer exageradamente. Todo parece estar cambiando de continuo. Desgraciadamente, otra característica del valle es que las cosas tienden a derrumbarse a la misma velocidad con que se expanden.
Hacia las tres de la mañana todos notábamos la falta de sueño, y Robert, Hoffman y Julia iban a cada momento hasta la máquina expendedora de refrescos que estaba en un espacio abierto al otro lado de la oficina del primero. A mí la cafeína nunca me ha hecho efecto. Al cabo de un rato se empezaron a agotar las existencias.
“Pronto nos quedaremos sin nada que tenga cafeína”, dijo Andrew.
Yo me paseaba nerviosamente entre Andrew, que luchaba con el software FDDI; Robert, que controlaba las operaciones de la red; y John Hoffman, que seguía trabajando en el cuarto de máquinas de la Netcom para establecer nuestra nueva estación de seguimiento.
No obstante mis quejas sobre la Netcom, en realidad estaba sumamente impresionado por su organización. Entré en el cuarto de máquinas y vi filas y más filas de ordenadores de servicio SPARCstation. Todo estaba dispuesto de manera impecable y profesional. El diseño y la construcción del sistema parecían inobjetables.
Eran casi las tres y media de la mañana cuando finalmente encendimos el nuevo ordenador que había sido instalado detrás de la puerta cerrada con llave del cuarto de las máquinas de la Netcom. Hoffman le puso de nombre “looper”[34], en referencia a la red FDDI instalada a modo de anillo en torno al cual fluían los paquetes.
Andrew no había conseguido insertar el BFP sin el código fuente, y el tiempo para más experimentos se nos agotaba con rapidez.
Pensé en nuestras demás opciones. Teníamos dos tarjetas FDDI diferentes de Soeren: una hecha por la Sun y otras por una compañía llamada Crescendo. Estaba bastante seguro de que la de Sun, con su software estándar de controlador no nos permitiría, incluso operando en una SPARCstation veloz, filtrar paquetes con suficiente rapidez para seguir el ritmo del anillo FDDI de Netcom a plena carga. La tarjeta y controlador de la Crescendo supuestamente tenían un mejor rendimiento, pero yo no sabía hasta qué punto.
Probé primero la tarjeta Crescendo. Tenía la esperanza de que funcionara lo bastante bien como para que, incluso si no podíamos emplear el software BFP, la NIT hiciera el trabajo. La NIT es lenta, pero tal vez la velocidad de la tarjeta y la SPARCstation 10 pudieran compensar esa ineficacia. Si eso no solucionaba el problema, la única opción restante era pensar en alguna otra salida inteligente, que todavía no se me había ocurrido.
Una vez colocada la tarjeta, sólo fueron necesarios un par de minutos para damos cuenta de que no era ni de cerca lo bastante rápida y de que cuando la costa Este se pusiera en actividad estaríamos peleando una batalla perdida.
Todas las mañanas, alrededor de las cinco o las seis, el número de paquetes que circulaba por su red FDDI empezaba a aumentar, a medida que la gente de la costa Este registraba su entrada para revisar su correo y poner su red en funcionamiento. Robert se fijó en el visualizador que controlaba en su ordenador el número de paquetes en curso por el núcleo de la red FDDI. Unos 4.000 paquetes por segundo.
“Eso es habitualmente el nivel mínimo”, dijo.
Andrew, entretanto, vigilaba el funcionamiento del looper.
“Esto no va bien, Tsutomu”, dijo. La red Netcom apenas se percibía y ya estábamos perdiendo el uno por ciento de los paquetes que pasaban ante nuestra estación de seguimiento.
“Esto no sirve”, me quejé, sin dirigirme a nadie en particular.
Resolvimos probar la tarjeta FDDI de Sun, pero resultó ser todavía más lenta que la de la Crescendo, y menos fiable. Reinstalamos la primera y reanudamos nuestro intento de seguimiento de la red.
No servía. Al mirar la pantalla de la SPARCstation vimos que estaba funcionando a un 70 por ciento de su capacidad. No tardó en ponerse peor. Mientras estábamos sentados observando, el número de paquetes que perdíamos empezó a aumentar vertiginosamente según crecía la carga en la red. En mi mente se formó la imagen de una multitud de personas a lo largo de la costa Este, todavía en bata de dormir y cada una con el jarro de café en la mano, yendo a su estudio a conectarse a la Netcom. Me pregunté: “¿Disfrutarán esos la vida más que nosotros? Bueno, al menos ellos han dormido bien”.
“Tsutomu, dentro de poco vamos a estar en veinte mil paquetes por segundo”, dijo Robert.
Parecía evidente que teníamos que hacer algo que llevase sólo un par de minutos y funcionase, aunque fuera un kludge (en la jerga informática, un artefacto semejante a los inventados por Rube Golberg).[35]
“Podría funcionar si colocásemos algo delante de la NIT”, le dije a Andrew. “Podría intentar una chapuza escribiendo un prefiltro que clasifique los paquetes antes incluso de entrar a la NIT”.
Andrew asintió con la cabeza, aunque a esas alturas no estoy seguro de que en realidad le importase. Estaba tendido en un sillón de oficina frente a mí y parecía estar ya medio dormido.
Estuve pensando otro poco en el problema y repasé los archivos de fuente de los sistemas operativos que tenía en orden para tratar de entender algo mejor lo que estaba ocurriendo entre el software del sistema y la NIT. Probablemente, un filtro muy pequeño fuese bastante rápido; no descomunalmente rápido, claro, pero quizá lo suficiente para poder hacer frente a la cantidad de paquetes que pasaran por delante de nuestra máquina de seguimiento incluso en los momentos de máxima carga. Mi programa era lo menos parecido a una solución perfecta, un pedacito de software de muy bajo nivel que colocado delante de la NIT descartaría la mayor parte de los paquetes antes siquiera de que llegasen al ineficaz y engorroso programa. Le puse snit___foo y lo escribí sin tomarme siquiera la molestia de usar un editor. Simplemente fui copiando cada línea que escribía en un archivo y luego la convertí para que pudiera ser leída por el ordenador.
Me senté ante el RDI y escribí lo más rápido que pude mientras Andrew miraba por encima de mi hombro. Cuando terminé, me volví hacia él y dije: “¿Has notado que hiciera alguna cosa mal?”.
Él echó una rápida ojeada a mi código para ver si en alguna parte corría el riesgo de desbaratarse. Mi programa estaba diseñado para filtrar hasta ocho direcciones de red diferentes y rechazar todos los demás paquetes. Si funcionaba correctamente, la NIT tendría que operar únicamente con un pequeño porcentaje de los paquetes que circulasen por el anillo FDDI.
Después que Andrew inspeccionó el código yo lo compilé en el RDI y pareció funcionar. Copiamos el programa en un disco flexible y lo llevamos al cuarto de las máquinas, donde lo pusimos en el looper. Era un kludge horrible, pero a esa altura no había nada que perder.
Yo estaba exhausto, pero la presión de saber que podríamos ver a nuestro oponente a las siete de la mañana me mantenía en actividad. Estuve un rato tratando de insertar correctamente mi programa en el núcleo del sistema operativo. Después de varios intentos comprendí qué era lo que estaba haciendo mal. Eran casi las seis cuando empezó el goteo de paquetes a archivos que reconstruiríamos más tarde ese día. La red de Netcom comenzaba a mostrar actividad. Hice algunas pruebas y todo parecía funcionar adecuadamente, y la carga en la máquina era manejable. Entonces Andrew y yo dedicamos algún tiempo a configurar el filtro. Con todo bajo control por el momento, abandoné el cuarto de las máquinas y fui a ver qué había sido de Julia. Ella mantenía el plan de irse el fin de semana con John y alrededor de una hora antes había desertado y se había acurrucado debajo de uno de los escritorios de la oficina, fuera del despacho de Robert. Seguía aún agotada en el rincón, con mi parka de almohada.
A Robert lo preocupaba el que los empleados de la Netcom que entrasen por la mañana fueran a llevarse una sorpresa al encontrar a una desconocida durmiendo debajo de un escritorio. Pero Andrew se había ocupado de ese problema colgando por encima de la cabeza de ella un trozo de papel que ponía: “¡No molestar!”.