El blog del TIC

Un misterio que me lleva torturando bastante tiempo es de dónde sale la infección de Brontok que padecen nuestros pen drives. Brontok es un bichejo tonto, que se replica haciéndose pasar por archivos normales, pero con extensión .exe.

Por supuesto, puede ser que tengamos la infección en casa, y que nos traigamos el pendrive infectado todos los días. Siendo generosos, digamos que no es así, y que hay ciertas reservas de virus en aulas concretas. Los candidatos más claros son:

• Ordenadores congelados en aulas de bachillerato.
• Ordenadores congelados en departamentos.
• Ordenadores congelados en laboratorios.

La cura es instalar el AVG 9.0 en todos esos lugares. Voy a ir haciéndolo poco a poco.

Ahora que el proyecto MIES está cerca de finalizar, podemos anticipar que posiblemente será muy beneficioso para el centro. La infraestructura de la red ha mejorado enormemente, y sobre todo se ha racionalizado mucho: ahora sabemos a dónde va cada cable de red. El acceso a la intranet es completo en todas las aulas, y muy rápido.

Ha habido algunos problemas menores, pero en comparación a las ventajas que hemos obtenido son totalmente irrelevantes.

Una cuestión que me preocupaba mucho conservar nuestro servidor  y el filtrado de paquetes de nuestro firewall. Todo ello se ha conseguido sin el más mínimo problema: simplemente, Dumbo y Gárgamel se han mudado, junto al router, hasta el recinto TIC, conservando plenamente sus funciones. De fábula.

Por lo pronto, la valoración de la migración MIES es absolutamente positiva :-) .

Compartir impresoras usando el protocolo SMB ha resultado en un desastre. Sin previo aviso, el servidor de impresión puede ponerse a requerir una contraseña para conectarse a la impresora remota, sin que valga ninguna de las contraseñas reales para el servidor.

Se proponen en internet muchas soluciones posibles para este problema, tales como crear un usuario invitado, alterar los permisos y propiedades de las unidades compartidas, o alterar opciones en el sistema; ninguna de las que he probado ha funcionado.

Finalmente, he comprobado que lo mejor es aprovechar aquellas impresoras que tengan tarjeta de red, y configurarlas para aceptar trabajos por TCP/IP. Con este mecanismo he logrado que por fin se pueda imprimir en condiciones en la sala de profesores, después de mucho tiempo peleando con SMB para nada.

En general, podemos decir que SMB está completamente roto en las últimas versiones de Windows.

Para sacar copias de seguridad de particiones, he estado ensayando la manera de enviar archivos en tiempo real por nuestra intranet. Desde luego es muy sencillo, tanto en windows como en linux, utilizando netcat y ssh.

Digamos que quiero crear una imagen del disco duro en un fichero. Esto es fácil, simplemente:

dd if=/dev/sda1 bs=50M > imagen.sda1

Ahora bien, imaginemos que quiero enviar esa imagen a Dumbo directamente a través de la red, porque no tengo espacio en el disco duro. Pues para ello tenemos que abrir un socket con netcat que reciba el fichero (servidor), y conectarnos desde la máquina remota como cliente, también con netcat. Un ejemplo sería:

En Dumbo:

nc -v -w 20 -p 31337 -l > imagen.sda1

Esto abre un socket en el puerto 31337, pone a netcat a la escucha, y almacena los datos recibidos en el archivo imagen.sda1.

En la máquina:

Se trata de hacer lo mismo, pero en plan cliente y mezclado con dd:

dd if=/dev/sda1 bs=50M | nc -v -w 10 192.168.0.1 31337

El servidor tiene que estar currando antes, claro, aunque los timeouts son relativamente flexibles. Naturalmente, puedes añadir compresión tanto en el cliente como en el servidor, simplemente entubando con un  gzip — fast, o incluso, si te pones artístico, con compresión antes de enviar por red, y descompresión al vuelo al recibir los datos.

Un truco bastante bueno, sobre todo para la recuperación de datos puntuales, consiste en montar particiones en el loopback. Aquí hay que tener cuidado, porque el montaje en loopback es ligeramente detallista. Digamos que tengo una imagen de disco duro en ntfs, llamada imagen.sda1. Si aplico un file, obtengo información sobre la misma:

# file imagen.sda1

imagen.sda1: x86 boot sector; partition 1: ID=0×7, active, starthead 1, startsector 63, 117194112 sectors.

Lo importante aquí es que el inicio de la partición está en el sector 63, así que al montarla como fichero tenemos que saltarnos esa información física. Puesto que cada sector tiene 512 bytes, tenemos que saltarnos un offset de 512*63 = 32256 bytes. Así pues, la instrucción de montaje en loopback es:

# mount -o loop, offset=32256 -t ntfs /root/imagen.sda1 /mnt

Y así tengo montado un fichero en el loopback. Todo esto son trucos viejos, pero fáciles de olvidar.

El peor problema de admnistrar ordenadores de acceso público es lo rápido que degenera su eficiencia según se van instalando programas, cambiando configuraciones, introduciendo virus y demás. Las soluciones intentadas han sido:

1. Deep Freeze: no vale de nada, puesto que la congelación es demasiado radical, lo que lo vuelve muy antipático. Las actualizaciones se vuelven imposibles. Y si se deja una partición sin congelar, en ella se mete todo tipo de bichos. Además, al descongelar para instalar cosas, muchas veces entra todo lo que no había entrado en años, por mucho cuidado que se tenga.
2. Usuarios sin privilegios: Esto no protege contra el tipo de  infecciones que no se instalan, tales como troyanos de USB. Debería ser la protección más eficiente, pero no llega. Además, la clave de administrador siempre acaba cayendo en manos irresponsables; a partir de entonces, la entropía crece imparablemente.
3. Antivirus: Todo el mundo tiene antivirus, y casi todo el mundo acaba con el ordenador hecho una patata. El antivirus, en sí mismo, no garantiza nada.
4. Windows Steady State: Esto es una mezcla gentil del usuario sin privilegios con el deepfreeze. Como solución es casi buena, salvo que tampoco dura demasiado. Steady State tiene además un problema gordo con la compartición de recursos a través de red: pide contraseñas cuando no debe, no las reconoce cuando se dan, y en general compartir carpetas e impresoras es un proceso aleatorio y desagradable. He tenido que rechazar el uso de Steady State en la sala de profes por este motivo.

La única salida es asumir sabiamente que, hagamos lo que hagamos, o bien los usuarios se las van a arreglar para fundir el sistema, o bien estarán descontentos si ponemos los medios para evitarlo. Ergo, la reinstalada es inevitable. Así pues, tenemos que hacer que el proceso de reinstalar el sistema sea rápido, efectivo e indoloro.

La solución es particionar cada disco duro y meter en la partición de datos una copia de la partición del sistema, recién formateada, instalada y configurada para ese puesto en concreto. En cuanto el sistema empiece a mostrarse lento y errático, restauramos la partición al estado de fábrica, y a otra cosa.

Este es un proceso lento y meticuloso aunque fácil, así que voy a poner los pasos que hay que seguir:

1. Instala Windows, asegurándote de hacer dos particiones, y de formatear lentamente la partición de sistema. ¿Por qué? Pues porque vas a querer comprimirla una vez que crees la imagen de la misma, y el formateo lento uniformiza dicha partición, aumentando su compresibilidad. Es el equivalente al dd desde /dev/zero sobre la partición en los tiempos en los que se hacían floppies de arranque para UNIX. Es fundamental.
2. Instala el Windows, con toda la parafernalia que sea necesaria (actualizaciones, compresor, openoffice, acrobat, flash, impresoras, etc.) Crea un usuario administrador con contraseña, y otro usuario (también con perfil de administrador) para el público.
3. Mueve las carpetas del usuario público a la partición de datos. Esto es posible en Windows XP usando la herramienta (libre) TweakUI de las Microsoft Powertoys. Además es fácil.
4. Ahora es el momento de crear la imagen que quieres conservar. Reinicia el ordenador con una versión live de linux (o de cualquier UNIX libre), y analiza la estructura de las particiones del disco duro con fdisk /dev/sda. Por lo general, la partición de sistema está en /dev/sda1 mientras que la de datos estará en /dev/sda5 (puesto que Windows habrá creado una partición extendida, y todo eso).

Lo que tienes que hacer ahora es (añadiendo sudo en cada caso, si no eres root):

mount /dev/sda5 /mnt

cd /mnt

Lo cual monta la partición de datos y te pone en ella. Ahora es el momento de sacar la copia de seguridad:

dd if=/dev/sda1 bs=30000000 | gzip – -fast > /mnt/sda1_imagen.gz

Este comando lee la partición de sistema en crudo, en bloques de 30 millones bytes, y la comprime con gzip en modo rápido, para luego almacenarla en la partición de datos, en el fichero sda1_imagen.gz . ¿Por qué compresión rápida? Primero, porque suelen ser 40G de archivo a procesar, y segundo porque queremos que se comprima el espacio libre del disco duro, que es la inmensa mayoría. No vale la pena matarse por el espacio que no está libre, realmente. Con compresión rápida podemos reducir típicamente 40G de partición a 18G, lo cual está bastante bien.

¿Cómo haríamos para descomprimir una imagen de disco duro, una vez que los usuarios se hayan fundido el sistema lo suficiente? Pues fácil, vuelta a arrancar desde el live CD, y a continuación:

mount /dev/sda5 /mnt

dd if=/mnt/sda1_imagen.gz bs=30000000 | gunzip > /dev/sda1

o si te da igual controlar el tamaño de los bloques y tal, directamente con zcat:

zcat /mnt/sda1 > /dev/sda1_imagen.gz

Una idea francamente atractiva es crear un servidor de archivos con las imágenes de todos los discos duros copiados, de manera que un usuario inspirado no pueda borrar una imagen en un momento de inspiración. Bastaría con instalar Apache en nuestro servidor de archivos, y recoger la imagen correspondiente usando wget:

wget http://192.168.0.253/sda1_imagen_salaprofes1.gz –output-document=- | zcat > /dev/sda1

Como tarea de inicio de curso, estoy tratando de lograr que todos los profesores nuevos tengan acceso al correo institucional de educamadrid. La tarea es un tanto liante, pero esencial: este correo es imprescindible para recibir ciertas comunicaciones oficiales, o para matricularse en algunos cursos. Crear una cuenta nueva es cosa de un par de minutos, pero trasladar o modificar una cuenta que está en manos del TIC de otro instituto puede llevar horas o días, según lo accesibles que estén los técnicos del otro centro.

En cualquier caso, me iré acercando a todos los profesores nuevos para crearles o trasladarles la cuenta de correo institucional. Creo que en este momento tengo cubierta la tarea al 60%.

Nuestros blogs están corriendo con wordpress 2.7. La versión más reciente es 2.8.4, y fija algunos problemas que ya son preocupantes. En cuanto consiga tiempo voy a actualizar mi blog y, si veo que el proceso es automatizable, extenderé la rutina al resto de las bitácoras. Si la cosa es más complicada, tendremos que ir dándole artesanalmente, uno por uno. Pero no creo que lleguemos a eso.

Ya en una ocasión habíamos tenido un script-kiddie en el sistema por causa de una plataforma poco actualizada. Me preocupa que pueda volver a ocurrir.

En breve comenzará la reestructuración del cableado del instituto a cargo de ICM, conocida como Proyecto MIES. El primero de Octubre a las 9:00 horas vendrán los representantes de ICM para informarnos de cómo va a ir la cosa, y los trabajos se iniciarán poco después.

Se trata de un recableado completo del instituto, que presumiblemente superará con mucho al actual. Esperemos que las molestias a la comunidad educativa sean mínimas; tanto vuestro TIC como el equipo directivo nos esforzamos para lograr que la instalación tuviera lugar en Julio o Agosto, pero no fue posible.

Aunque el cableado que nos van a instalar es tremendo, voy a intentar que se respete nuestro viejo cableado, por si tenemos que utilizarlo en un (ahem) caso de emergencia.

Stay tuned for updates.

Como todos los años, empieza la carrera por tener los tamagoshis configurados en el menor tiempo posible. Teniendo en cuenta las lecciones aprendidas en el año anterior, la cosa no debería llevar más de un par de días, aunque mi carga de trabajo es actualmente mucho mayor que la del curso pasado por estas fechas.

El problema de configurar el SGD es doble:

• Cargar la información de profesores y alumnos.
• Cargar la información de horarios.

Lo segundo es con diferencia lo más peliagudo; sin embargo, es fácil si se emplea una versión de evaluación del Peñalara. Lo primero es casi trivial gracias a los datos de matrícula que hemos ido acumulando.

Una variante respecto al curso anterior es que Tecnausa se ha puesto al día y ha logrado conectar SGD con SICE, usando el primer truco que se me ocurrió al respecto: capturando pulsaciones de teclado de forma que se introduzcan los datos automáticamente en una terminal SICE. Por lo que recuerdo, este método era bastante inconveniente porque:

1. No hay acceso directo a la API gráfica de Oracle Forms, que emplea una máquina virtual de Java firmada digitalmente. Por así decirlo, Java/Swing es opaco a Windows porque los widgets se interpretan a nivel de Java, y el SO sólo ve bitmaps. Esto quiere decir que es muy enojoso leer datos en pantalla o saber cuándo el sistema ha obedecido a tiempo un comando que se le ha lanzado. Y no podemos interceptar la máquina virtual porque está firmada digitalmente. Una salida posible a este dilema era usar un linux con Oracle Forms, que no emplea una máquina firmada; pero esto es, en el mejor de los casos, contrario a las directivas de ICM.
2. Para tener conexión entre SICE y SGD, hay que unir la red SICE con la red del centro, lo cual no haría ninguna gracia a ICM si se diera cuenta. La alternativa, llevar todos los días los datos con un USB a secretaría. Feo, feo.

En resumen, tengo bastante curiosidad por ver cómo han solucionado estas papeletas los muchachos de Tecnausa. Conozco un centro donde van a empezar a usarlo en pocos días, así que en breve comentaré mis opiniones sobre su sistema. En cualquier caso, la inyección de datos a través de AFDI me parece óptima, porque resuelve los anteriores problemas de manera natural. La desventaja (para Tecnausa) es que el método a través de AFDI es poco aplicable a gran escala.

Después de dar muchas vueltas al problema de la seguridad en los ordenadores, parece que la única solución para mantener algunos de ellos limpios es recurrir a los antivirus. El programa de congelación SteadyState ha fallado miserablemente en algunos puestos, creo que porque la clave de administración de los sistemas es lo bastante pública como para que la use todo el mundo.

En esos sistemas en los que la restricción al acceso con Steady State no es suficiente, voy a instalar el antivirus AVG Free, que es netamente superior a mi opción favorita hasta ahora, el Clamwin. El problema de clamwin es que no tiene eliminación automática, así que tendría que estar yo desinfectando cada amenaza en cada ordenador, lo que es imposible.

Naturalmente, también hemos cambiado las claves de administración en todos los sistemas que puedan correr peligro de quedar infectados.