Paranoia Constructiva a finales de 2003

Por Rick Moen

Traducción al español por Charles Bedón
el día 8 de Abril de 2004, para La Gaceta de Linux

Hace unas semanas, estaba ayudando a mi suegra, que estaba trabajando en su Ph.D (Doctorado) en seguridad computacional, a hacer una encuesta a media docena o algo así de usuarios de Linux en un grupo de usuarios local, CABAL, acerca de nuestras prácticas en seguridad. El resultado fue el siguiente:

¿Usamos software anti-virus? (No, excepto cuando manipulamos archivos o correos electrónicos destinados a computadores con sistemas operativos de Microsoft) ¿Examinamos la seguridad de nuestra red usando software de escaneo de vulnerabilidad, como Nmap o Snort? (Muchos lo hacemos, sí). ¿Usamos aplicaciones de seguridad para análisis de logs como el LogCheck? (Lo mismo que la anterior). ¿Usamos Sistemas de Detección de Intrusos(IDS) como Tripwa[i]re?(Casi nunca). ¿Qué medidas tomamos para eliminar los brechas de seguridad que se presentan comúnmente? (Varias). ¿Usamos scripts de filtraje de tráfico IP a nivel de kernel("Firewalls")? (Algunos lo hacemos. Muchos de los usuarios más experientados operando redes UNIX puras no lo hacen)

Estas preguntas seguían rondando mi cabeza cuando le pregunté a nuevos administradores de Linux. Algunas veces, ellos respondían muy astutamente: P:"¿Cómo puede esta seguro de que su sistema no ha estado envuelto en situaciones hostiles?" R: "Excelente pregunta. No se puede saber con plena seguridad. Un intruso realmente sutil y competente manifiesta esas habilidades en parte siendo difícil de detectar, y cubriendo sus huellas. Pero los intrusos (o sus herramientas de ataque automatizadas) en general irrumpen en un sistema para realizar acciones altamente restringidas para el común de los usuarios, dejando pistas que serán detectadas por los administradores capaces y que siempre estén alerta, quienes saben que sus sistemas notarán eventos peculiares suficientemente bien." Esa respuesta deja interrogantes un poco preocupantes -como se pretendía.

Dos clases de Ataques

Siempre les digo a los nuevos administradores que hay dos tipos de amenazas para los sistemas: desde fuera y desde adentro. Las preocupaciones comunes se orientan generalmente hacia el primero. El tipo de datos que se obtienen ejecutando

nmap -vv -sT -sR -O -n -oN tcpscan.log 10.0.1.3
nmap -vv -sU -sR -O -n -oN udpscan.log 10.0.1.3
nmap -vv -sA -sR -O -n -oN ackscan.log 10.0.1.3

Desde fuera de su LAN (una máquina diferente) hacia la IP de su host 10.0.1.3, para suponer/estimar qué tan fuerte es el escudo más exterior(el figurativo) -en caso de un ataque desde alguna otra parte.

Pero la segunda clase de amenaza -desde adentro - es más preocupante e interesante. O sea, si una forma de entrar (ssh o lo que sea) desde dentro de su máquina, y alguien roba el password u otro dato requerido para usarlo, entonces tiene invitados indeseados, quienes pueden romper la seguridad de su sistema desde su propia consola de comandos. Es bien conocido que el último paso es a menudo exitoso, pero la noticia es cómo es de facil y frecuente que los passwords sean robados.

Considere un acceso ilimitado al ssh de su(s) máquina(s), una práctica muy utilizada y apreciada por los usuarios de UNIX. ¿Alguna vez se ha logueado por ssh desde una máquina que no administra personalmente y tiene absoluta confianza en ella? Incluso si no, ¿siempre lleva consigo el archivo ~/.ssh/known_host2, de tal manera que pueda estar seguro de que el host al que está accediendo es realmente suyo? Si alguna vez ha sido negligente en alguno de estos aspectos, y es un poco mala-pata[con mala suerte], los chicos malos robarán sus datos de acceso(password y otros) y entrarán después haciéndose pasar por Ud..

Incluso si nunca ha hecho ninguna de estas cosas (siendo extrañamente paranoico, de hecho), ¿puede decir los mismo de todos los amigos quienes les ha dado cuentas? Nunca nadie ha usado un cibercafé o un computador en una universidad, o usado PuTTY en un PC familiar Windows con spyware(software espía), o tal vez incluso con un grabador-de-botones-pulsados conectado al teclado. Piense si no.Y ahí está su problema

La Sorpresa de Noviembre

Esto nos provocó problemas de seguridad en noviembre. Una cronología puede ayudarnos a hacerno una idea:

• 2003-08-25: Liberación del kernel v. 2.4.22 con un bug de manejo de memoria que no había sido detectado.

• Septiembre 2003: Andrew Morton descubre que no estaba siendo aplicado chequeo de límites en el código del kernel en las direcciones de memoria cuando se hacía la llamada del sistema brk(). Ni él ni nadie reportando para el LKML está[ba] consciente de las implicaciones de los bugs de seguridad. Sin embargo, un chico malo desconocido, que leyó los Changelogs se dio cuenta de estas implicaciones en algún momento entre esta fecha y 2003-11-02.

• 2003-09-24: Andrew Morton hace un parche para la serie de kernel 2.6.

• 2003-10-02: Marcelo Tosatti hace un parche para la venidera v. 2.4.23.

• 2003-10-09: Se pone a disposición la solución para el problema de brk() en la versión preliminar 2.4.23-pre7.

• 2003-11-02: Un chico malo desconocido irrumpe en el host de desarrollo de la FSF savannah.gnu.org. Posteriormente se establece que el método utilizado es el mismo usado en las máquinas mencionadas abajo.

• 2003-11-19: Un chico malo desconocido explota el bug para suplanta al usuario local root del servidor de desarrollo del Proyecto Debian, llamado "Master". Desde ahí se introdujo en los servidores klecker, murphy y gluck. Los paquetes de archivos de Debian fueron colocados en "no point".

• 2003-11-20: En un día, el Proyecto Debian detecta la "infección" y apaga sus cuatro máquinas para hacer análisis forense y generar de nuevo(build): Los administradores notan un patrón sospechoso de "oopses"[de la interjección oops!] en el kernel y confirma sus sospechas, siendo informado por el AIDE(un IDS) en klecker, murphy, y gluck de cambios sin autorización en los directorios /sbin/init y /usr/lib/locale/en_US.

• 2003-11-28: Liberada la v. 2.4.23, incorporando la solución para el problema de brk().

• 2003-12-01: FSF descubre una "infección" de savannah.gnu.org .

• 2003-12-02: Un servidor del Gentoo Project (operado por un particular) miembro del cluster rsync.gentoo.org cluster es comprometido en lo que parece ser la misma forma. La "infección" es detectada una hora después con un IDS y un verificador de integridad de archivos. No fue comprometido el árbol de archivos (los "paquetes" software de Gentoo).

Habrá notado lo rápido que la gente de Debian y Gentoo se dio cuenta del problema, y lo corrigió - un punto al cual vuelvo. Pero el primer punto a tener en cuenta es cómo el chico malo entró a hacer lo que hizo - un primer paso necesario antes de que pudiera usar la falla en el kernel.

Se detectó que uno de los más de 1000 desarrolladores de Debian había sido víctima de un robo de datos de seguridad[password u otros]. Usó el cliente de ssh en una máquina, en alguna parte, y que ya había sido violentada. El software de ssh fue "troyaneado" y logueó privadamente sus credenciales en el login del servidor de Debian, lo cual llevó luego al atacante -quien era entonces capaz de entrar como si fuera un desarrollador. Sólo entonces usó el bug del kernel para escalar en los privilegios hasta obtener acceso de root, algo que también pudo haber hecho es encontrar una falla sin parchar en alguna otra parte del software que afectaba la seguridad. El punto esencial es: El intruso a pesar de todos (probablemente) siendo razonablemente cauteloso y prudente, porque uno de sus procesos de grabación de password tuvo suerte en alguna parte.

IDS y sus Descontentos

Dos cosas pusieron un alto inmediato en el problema de los sitios de debian.org y gentoo.org. Uno fue la presencia de alertas de administradores de sistema[sysadmins], quienes en el caso de debian.org, notaron el patrón de "oopses" del kernel en dos máquina simultáneamente, juzgaron esto lejos de ser una gran coincidencia y lo reportaron. (Alarmas similares probablemente fueron enviadas en gentoo.org a los administradores jefe, pero pocos detalles del incidente fueron revelados por ellos.)

La otra fue un muy ponderado pero poco usado software llamado Sistema de Detección de Intrusos basado en hosts, el clásico ejemplo es Tripwire, inventado por Gene Spafford y Eugene Kim en el mítico laboratorio de seguridad COAST de la universidad de Purdue de 1992 a 1994. lo más importante de su historia es que era propietario(con el código fuente disponible para verlo, pero no autorizado para desarrollar independientemente sobre él), fue ofrecido a la venta para negocios, y con una edición "libre para uso no comercial" llamado Tripwire Academic Source Release(ASR) disponible para descargar.

Después de un tiempo, Tripwire se reescribió, lo cual desafortunadamente no hizo nada con los regaños de los programadores acerca de los problemas de usabilidad(acerca de lo cual hablaremos luego), y luego, bajo presión de las alternativas en código abierto y con ayuda de VA Linux Systems, su compañía patrocinadora (Tripwire, Inc) reliberó Tripwire en octubre de 2000 como software de código abierto y bajo licecia GNU GPL.

Eugene Kim CTO tiene desde entonces, una indignación profesa a la participación dispersa, en respuesta a la comunidad de codificadores de código abierto - pero el orgullo y alegría de la firma, se convirtió en C++ no portable y sin soporte de autoconfiguración.(¿Gosh, Gene, tal vez otros estándares de codificación antedilivianos, una escogencia bizarra del lenguaje, y su firma pasando a ser de código abierto sólo después de que mindshare había ya migrado a más alternativas de código abierto tienen algo que ver con esto?)

Recuerdo el Tripwire ASR; casi como todos los administradores de sistemas, no del todo encariñado -haber hecho caso a eso de empezar a vivir con él en 1994 y decidir que no valía la pena. Era y es un completo horror configurarlo. En teoría, se escribe una descripción de qué archivos y directorios(y qué aspectos de ellos) deben ser chequeados por cambios no autorizados, tener una instantánea del estado actual y no comprometido del sistema, y llevar al disco toda la información en un estado criptográfico verificable. Buena la teoría; dura la ejecución.

Desafortunadamente, las herramientas y la sintaxis de configurarción son crípticas, cada operación corre increíblemente lento, y su modo de chequeo de integridad del sistema tomaba mucho y la mayoría de los reportes al root no tenían sentido, así que éste debía estudiarlos y luego refinar el set de reglas poco amigables para gradualmente reenfocar su atención en los cambios del sistema que en realidad importaban y dejar de reportar trivialidades. Gracias al uso fuerte de la encriptación, cada uno de estos pasos tienden a hacerse interminablemente largos, y el proceso debe correrse iterativamente, muchas veces, usando un conocimiento experto del sistema propio. Antes de que los resultados empezaran a ser útiles y no solo un Babel de palabras.

La sobrecarga de información, el terrible lenguaje de configuración, la lenta y poco eficiente operación, la interfaz de administrador trastocada.... argh! Sálvenme de esto! Terminé peleándo con él en una o dos semanas.

No exactamente por coincidencia, empezando un año antes de que que Tripwire se volviera de código abierto, comenzó una seria competencia de código abierto, primero con AIDE, un paquete de Rami Lehti y Pablo Virolainen en Finlandia. AIDE se ha unido últimamente a diseños similares en 2001: Integrit de Ed L. Kashin, Samhain de Rainer Wichmann, Prelude de Yoann Vandoorselaere y no lo dude, otros.

Recoré cuando usaba AIDE, cuando salió en agosto de 1999, y jugaba con él un poco. Mientras Tripware era lento y cargaba el sistema, AIDE era rápido y legero. Mientras Tripware era críptico y propenso a colapsar con errores incomprensibles, AIDE era fácil de entender y depurar. Tenía un gran problema: la base de datos instantánea del sistema, el programa binario y el archivo de cofiguración no eran almacenados con verificación criptográfica(como sí lo hace Tripware). Los autores, exhortaron a que todo eso fuera almacenado en un medio protegido contar escritura y actualizado sólo cuando fuera necesario.

Mantener los archivos del AIDE en un diskette o CD era una molestia mayor. La alternativa, de sólo usarlos en el disco duro del propio sistema es más fácil, pero tiende a dar una falsa sensación de seguridad. Es decir, si cuando el chico malo venga a irrumpir en su sistema, no forzará el IDS también? De ser así, cuando el IDS le dice que todo anda bien, cómo saber que el chico malo no lo está manipulando para que saque esos mensajes amañados? Tripwire tiene una respuesta para esta objeción; AIDE y sus amigos no.

Esta clase de falsa garantía es la misma a menudo encontrada en lo usuarios de los sistemas basados en RPM, quienes confían en "rpm -Va" para "verificar" las firmas md5sum de los archivos instalados: los valores "verificados" versus una simple BD Berkeley en /var/lib/rpm - la cual claro, será actualizada por un intruso competente para validar sus cambios.

Así que al final de cuentas, no corrí AIDE rutinariamente. El proyecto Debian lo hizo y pagó por ello - el intruso había sido lo suficientemente sofisticado para aprovechar un anteriormente desconocido exploit del kernel, pero no lo suficiente para advertir que al AIDE y forzarlo antes de que pudiera informar acerca de él.

Lo Mejor de Ambos Mundos

Después de los incidente de seguridad de Noviembre, mi suegra levantó su ceja[ajá!!] por nuestros viejos administradores de Linux, que no corren IDS basados en host, sentí que tenía que revisar la materia y explorar opciones. Para mi gran fortuna, la última pieza de suertudamente[de buenas que], llegó a la lista de correos de seguridad de Debian, enviado por Lupe Christoph:

"No usamos AIDE exclusivamente en el sitio de un cliente, sino en combinación con Tripwire. Creemos que Tripwire es un poco más seguro porque usa bases de datos firmadas. Así que protegemos aide.db con Tripwire. AIDE se usa donde Tripwire no se puede usar por su limitada configurabilidad..."

Um... si. ¿Por qué no pensé en eso? La complicada configuración del Tripwire, se bajaría a una mínima cantidad de ítems, es más conveniente de manejar, incluyendo los archivos propios de AIDE, "inchequeables" de otra forma hace que dolor usual de usar Tripwire baje hasta ser sólo ruido de fondo, y hace que sus operaciones corran en menos de un período geológico. Mientras tanto, AIDE hace el resto -y no tengo que preocuparme de que me estoy engañando a mí mismo como un superconfiado usuario de los RPM. Funciona de maravilla.

Concluyendo el Sermón

La página de mi sitio web "Lexicon" incluyen las leyes de Moen:

Primera Ley de seguridad de Moen: "Es más fácil irrumpir desde dentro"Ej.: Muchos intrusos de Internet entran suplantando a alguien para ganar niveles de acceso de usuario, con passwords obtenidos con sniffers. El atacante obtiene dramáticamente un amplio campo de puntos débiles del sistema para atacar, comparado con penetrar al sistema desde afuera.

Segunda Ley de seguridad de Moen: "Un sistema puede ser tan seguro como la acción más estúpida que le permita ejecutar al usuario más torpe" sus usuarios son a menudo la parte más delgada del hilo; los chicos malos atacarán ahí(ej.: ingeniería social). Los administadores astutos tartarán de compensar esta tendesncia ej.: usando autenticación multifactorial, en lugar de sólo passwords.

Entre estas dos, una podría haber predecido la cantidad de pequeñas calamidades que cayeron sobre Debian, Gentoo, Savannah en noviembre. Dada la considerable cantidad de los datos de seguridad[passwords y otros] que son robados, especialmente en máquinas usadas por muchas personas, es una maravilla que no haya sucedido antes. Ese pequeño milagro se dio gracias a que dos de los tres detectaron y arreglaron la brecha de seguridad inmediatamente-por cortesía de los IDS basados en host.

La detección es fabulosa, y mejor que "una patada en la cabeza" (o vivir en el paraíso de los tontos), pero, ¿qué hay acerca de la prevención?. Una forma es corres un demonio ssh en un puerto adicional no estándar (tal vez 2222 en vez de 22) que requiera passwords one-time OPIE o S/Key en lugar de la autenticación convencional y susceptible a robos del ssh. Más exactamente, los passwords one-time pueden ser sustraidos, pero serán inútiles porque ya han sido usados por el usuario autorizado.

Los passwords one-time son una verdadera molestia de gestionar: Ud. genera una "semilla" password y llevárselo de alguna forma al usuario. O el lleva una copia impresa de la serie resultante de 500 o algunos de los passwords one-time, son descatados una vez usados o pone la semilla en una PalmPilot y genera esos passwords desde ella usando una PalmKey, Strip, o pilOTP para PalmOS.

Podría no usar esa configuración cada vez que estoy lejos de casa y tentado a cortar camino -o pedirle a mis usuario que lo hagan-- pero podría se bueno tener esa opción la próxima vez que esté en un cibercafé o algún banco público infestado de malware con Windows en alguna exhibición.

Algunas Medidas de protección a tener en cuenta:

• Limitando el acceso de rshell(o similares), tanto para otros como para Ud. mismo.

• ...especialmente cuando viene desde máquina de dudosa integridad y/o con recursos compartidos.

• Evitar pensar que tiene suerte y confía en una llave de host no verificada.

• En otras palabras, evitar cometer el error de usar ssh sin asegurarse del control a ambos lados, y evitando confiar en la red que hay entre ellos.

• Llevar una copia de archivo ~/.ssh/known_hosts2 file consigo, en un drive flash USB portátil, por ejemplo , de tal manera que Ud pueda saber que la conección ssh al home realmente está llegando a su máquina en vez de un Profesor Moriarty en la mitad de la red.

La página de información de Wichert Akkerman en Debian.org incluye algunas recomendaciones intrigantes en adición a esto, que incluyen algunas en cuanto a comportamiento:

• Nunca loguearse por ssh desde un host remoto u otro.

• Usar llaves únicas y passfrases[passwords compuestos] para cada host.

• Deshabilitar el acceso al passwd de ssh y usar sólo llaves [pares pública/privada]

• Restringir la lista de host permitidos para aceptar conexioones ssh en su sistema

La primera es interesante y sutil. ¿Cuántas veces se ha logueado ssh desde la máquina de otra persona, y luego se ha mandado un archivo con scp a Ud mismo? bien no lo haga. En lugar de eso use scp en modo "pull" desde su propia consola.

$ scp username@remotehost:/tmp/somefile .

...Mejor que eso escriba en la línea del host remoto esta línea

$ scp /tmp/somefile username@myhost:

¿Por qué? Esto nos devuelve el problema de los datos de autenticación robados de nuevo. Cuando Ud. inicia el scp desde un host remoto para bajar un archivo donde Ud está digamos myhost , acaba de proporcionar un dato de autenticación sustraible en una máquina que Ud no controla y en la cual no tiene por qué confiar. Bajar el archivo no tiene tanto riesgo..

Casi nadie sigue la segunda recomendación de Wichert(passwds únicos) porque los buenos passwords son difíciles de recordar. El cerebro humano no está cableado para soportar esa clase de retención de datos. Sin embargo, si tiene el suficiente cuidado pueden usar mi solución Keyring para PalmOS, una "cartera electrónica " para datos de autenticación, que los guarda en una base de datos 3DES encriptada. Bloqueable con una sola palabra, eso es todo lo que necesita recordar.

Adicionaría otra recomendación a las de Wichert

• Ponga atención y conozca sus sistemas muy bien.

Cuando los administradores de debian.org se dieron cuenta de la intrusión, no necesitaron exavtamente un IDS para saber que sus máquinas habían sido violentadas. Cuando notaron un patrón sospechoso en los "oopses" del Kernel, hicieron algunos chequeos e inmediatemente llegaron a la conclusión correcta. El reporte nocturno del AIDE sirvió, principalmente para confirrmar lo que ya sabían. En general, un administrador alerta es, de lejos, su mejor protección.

La seguridad en general es un difícil problema. Los tipos cansones y que siempre intentan fastidiar son un mal endémico, una significativa mejora también trae un inconveniente. Apenas he arañado la superficie de los modelos de amenaza más relevantes - y hay otras herramientas de chequeo chkrootkit que son importantes. Bueno, espero haber resaltado algunos de las herramientas[procedimientos] más eficaces que reportan las más grandes mejoras en este campo.

Bibliografía:

La opinión de Christophe Lupe acerca de Sinergia entre AIDE y Tripwire
http://www.mail-archive.com/debian-security@lists.debian.org/msg11293.html

Las leyes de Moen y otros ítems en Lexicon
http://linuxmafia.com/~rick/lexicon.html

Páginas de Wichert Akkerman acerca de la "Infección" de Debian.org en el 2003
http://www.wiggy.net/debian/developer-securing/

Nmap, una utilidad de código abierto gratuita para exploración de redes o auditoría en seguridad
http://www.insecure.org/nmap/

Snort, un IDS de código abierto entrre muchos (pero orientado a la red, no basado en hosts)
http://www.snort.org/

Logcheck, un script para detectar logueos anómalos y enviar correos al administrador
http://alioth.debian.org/projects/logcheck/

Tripwire, el IDS original y clásico basado en hosts. Note que aunque Tripwire se autochequea, tiene un problema en común con los IDS basados y es que los intrusos pueden deshabilitar o forzarlos, para sabotear la protección. sin embargo, gracias a que cada parte de él está firmado criptográficamente, incluso los reportes nocturnos, tiene la ventaja de mostrar la evidencia de una violación. Si alguna vez ocurre una falla al recibir un reporte nocturno, le llega uno que falla en la autenticación, sabrá inmediatamente que algo pasa.
http://www.tripwire.org/
http://www.tripwire.com/

Nota de Tripwire:
Si está aplicando un régimen de verificación en un host y obtiene una respuesta mala, probablemente esté en lo correcto--y Tripwire Inc le recomineda que por lo menos, verifique los archivos que usa la herramienta diseñada para ese propósito, y preferiblement almacénelos en un medio de sólo lectura. Ajuste su nivel de paranoia(por ejemplo, recompilando componentes o usando ligaduras estáticas).

AIDE, el aspirante más nuevo
http://www.cs.tut.fi/~rammer/aide.html

Integrit, un recién llegado similar:
http://integrit.sourceforge.net/

Samhain, un recién llegado similar del que se dice es excepcionalmente bueno. Un administrador realmente cuidadoso correría dos IDS livianos, como AIDE o Samhain, y tiene a Tripwire para chequearlos a ambos, para evitar que las fallas de uno sólo sean los puntos de ataque
http://la-samhna.de/samhain/

Prelude-IDS, otro recién llegado:
http://www.prelude-ids.org/

OPIE (One-time Password In Everything) unn OpenSSH, por el módulo pam_opie
http://www.tho.org/~andy/pam-opie.html
http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2003-02/0122.html
http://www.derkeiler.com/Mailing-Lists/securityfocus/Secure_Shell/2003-02/0121.html

S/Key y OpenSSH:
http://dbforums.com/arch/181/2003/6/823985
Como con OPIE, podría necesitar recompilar el OpenSSH para asegurar el soporte:
http://www.sunfreeware.com/INSTALL.openssh

PalmKey:
http://palmkey.sourceforge.net/

Strip:
http://www.zetetic.net/products.html

pilOTP (proprietario):
http://astro.uchicago.edu/home/web/valdes/pilot/pilOTP/

Keyring para PalmOS:
http://gnukeyring.sourceforge.net/

Chkrootkit examina su sistema para encontrar software común y conocido para encubrir la presencia de un intruso ("rootkits"). De esta forma, le da una seguridad negativa de que "No, no veo señales de ningún rootkit que me diseñador me enseñara a detectar", y en ese sentido es similar a un antivirus. De ahí que  pueda descartar la presencia de "rootkits" de las cuales no conozca.
http://www.chkrootkit.org/

La página de Tips de seguridad de Jim Dennis tiene muchas ideas
http://www.starshine.org/sysadmoin/LinuxSecurityTips

Base de conocimiento de Linuxmafia (mi árbol de documentación PerlHoo documentation tree) también tinen más recursos
http://linuxmafia.com/kb/Security

 

Rick es miembro de la pandilla de las Respuestas.

Rick puesó a funcionar Unixen de libre distribución desde 1992, conocido primero como 386BSD, luego Lunux. Encontró que uno de ellos molestaba menos, mandó a volar su última máquina no Unix(OS/2 Warp) en 1996. Se especializa en recolección de pistas y publicación(documentación y capacitación), administración de sistemas, seguridad, diseño y administración de redes WAN/LAN y en dar soporte. Ayudó a planificar el LINC Expo(que pasó a ser la primera Conferecia y Exposición LinuxWorld, en San Jose), así como el Windows Refund Day, y muchos otros eventos conmovedores [motivantes] para la comunidad Linux en el área de San Francisco Bay. Ha escrito y editado para IDG/LinuxWorld, SSC, y la asociación USENIX; ha hablado en la Conferencia y exposición LinuxWorld Conference y en numerosos grupos de usuarios.

Su primer computador fue la regla de cálculo de su padre, seguido por una tarjeta de acceso para visitantes de un mainframe IBM en Stanford(1969). En un acto de masoquismo, migró hacia los primeros sistemas HP de tiempo compartido, People's Computer Company's PDP8s, y varios de esos microcomputadores que nunca volarían a Orville en el mítico Homebrew Computer Club -- Luego más horrores del tipo Big Blue. Él está más calificado que la mayoría para saber qué tal estamos ahora.

Cuando no está jugando con la ruleta .com en Sillicon Valley, disfruta los largos paseos en bicicleta, ayudando a organizar convenciones de ciencia ficción, y concentrándose en volverse un bloque sin tallar.