Respecto al crackeo sufrido, me puse manos a la obra. Borré los scripts maliciosos que me habían puesto en la página y estuve vigilando el log de errores de acceso, para ver desde qué IP intentaban acceder a ellos. Una vez localizada la IP, la he "baneado"  (supongo que no servirá de mucho, porque el que sea tendrá posibilidad fácil de cambiarse de IP) y he visto que después de los accesos fallidos ha intentado acceder a la Chuwiki.

Pues bien, wordpress (este blog) y el SMF (el foro de java) se actualizan muy fácilmente. Basta entrar como administrador y el mismo panel de control te avisa de que hay una versión nueva. Le das a un botón y se actualiza todo solo. Pero no es así con mediawiki y por eso no tenía actualizada mediawiki a la última. De hecho, la versión es la primera que instalé hace ya fácilmente tres años. Tiene toda la pinta de que se han colado por ahí, explotando alguna vulnerabilidad de la mediawiki (aunque no tengo ninguna garantía). Por ello la he actualizado a la última…. ¡¡ y me he entretenido un montón !!.

Resulta que la actualización es más o menos sencilla, basta con hacer el consabido backup por si acaso, desempaquetar la nueva mediawiki sobre la antigua, tocar un fichero para poner el usuario y password de base de datos y  … ¡¡ ejecutar un script php desde línea de comandos !!. En este último punto es donde ha venido el entretenimiento.

No puedo ejecutar ese script llamándolo desde el navegador. El script detecta que no se está haciendo desde la máquina local y te dice que no tienes permisos. Tampoco tengo acceso a una línea de comandos de mi proveedor. Bueno, quizás sí tengo acceso, pero con todo el tema de certificados de seguridad, firmas digitales y demás que por un lado, no tengo ni idea de cómo se hace y que por otro lado, desde mi windows, no es tan sencillo y hay que andar instalando cosas como Putty. Así que por no echarme unas horas con eso, busqué otro método.

Y encontré uno la mar de entretenido. Resulta que desde mi panel de control web puedo programar tareas a ejecutarse en el servidor (comando cron para los que sabe de linux). Así que a eso me puse.

1. Comando cron para ejecutar "php -version" cada cinco minutos y recibir el correo con la salida del comando. Esto me sirve para saber si está el ejecutable php accesible. Lo de cada cinco minutos es porque como el servidor está en estados unidos, cualquiera adivina su hora exacta. Y cinco minutos para darme tiempo a recibir el correo y parar el cron. antes de que se ejecute por segunda vez. Correo afirmativo, está accesible php.
2. Ahora otro cron cada cinco minutos para ejecutar un ‘pwd’ (ver el directorio en el que se ejecuta el cron) y así saber que path tengo que poner para llegar al script de php. A los cinco minutos, ya sé el directorio de ejecución.
3. Y finalmente otro cron ejecutar el comando ‘php path/update_wiki.php’. Espera y ejecución correcta. Pruebo la wiki recién instalada y funciona bien, salvo un pequeño susto que comento al final.

Bueno, lo del cron no es que sea nada del otro mundo, pero lo que me ha llamado muchísimo la atención es la forma rupestre de ir ejecutando los comandos. Es como si estuviras programando un satélite a dos minutos luz. Ejecutas el comando y entre que va y vuelve, esperas cinco minutos por el resultado (lo siento, leo mucha ciencia ficción).

Y una pequeña estupidez de la actualización. Resulta que han cambiado la página principal de la mediawiki y ahora, en vez de "Portada", se llama "Página Prncipal", así que me llevé un pequeño susto cuando veo por primera vez la wiki recién instalada y aparace la página incial vacía.

ACTUALIZACIÖN: Mandé el Jueves la solicitud a google para volver a aparecer en el buscador y hoy, sábado, parece que ya aparezco.

Hace tiempo comenté que tenía un problema con la página aleatoria de la Wiki y el amigo google. Buscando una palabra en google, este me mostraba un enlace a la Chuwiki. Casualmente, este enlace, en vez de ser al artículo original, era la página aleatoria de la Chuwiki, por lo que pulsando el enlace mostrado por google, me iba a una página aleatoria y no a la buscada.

Hace un par de días volví a tropezarme con el problema. Busqué no sé qué en google, apareció un artículo de la Chuwiki, pinché el enlace y acabé en una página aleatoria. Así que me he decidido a arreglarlo. Por supuesto, para variar y por culpa mía, el cambio ha sido una pequeña odisea.

Lo primero de todo, por supuesto, ponerme a urgar en los ficheros php de MediaWiki, a ver dónde demonios está ese enlace de página aleatoria para quitarlo. Después de un par de horas de revisar el código, ir de un lado a otro, dar mil vueltas y no llegar a ningún sitio (está oculto el dichoso enlace), me decidí a hacer lo que debería haber hecho desde el principio: consultar la ayuda de la MediaWiki.

Las cajas de menú de la izquierda de la MediaWiki son bastante fáciles de modificar. Con permisos de administrador basta desde la misma web, editar la página MediaWiki:Sidebar. En esa página aparece el menú y se puede modificar a gusto. Para editar esa página, que no está fácilmente accesible, hay que poner la url directamente en el navegador:

http://www.tuwiki.com/index.php?title=MediaWiki:Sidebar&action=edit

y listo, ahí ponemos lo que queramos, incluso más cajas de menús. Tienes los detalles en Manual:Interface/Sidebar de la MediaWiki.

De todas formas y como siempre tiene que haber algo que incordie, después de hacer los cambios no veia en absoluto modificado el menú. El dichoso firefox tenía guardada la página en memoria y no me cambiaba el menú. Me dí cuenta al visitar otra página de la Chuwiki y ver que ahí si estaban cambiados los menús. Así que cada vez que hacía un cambio, no me quedaba más remedio que vaciar la caché del firefox ("herramientas"->"limpiar datos privados").

Ayer, sábado lluvioso, encerrado en casa, decidí entretenerme con el ordenador. Al final, es curioso cómo pasas la tarde, yendo de un lado a otro, sin hacer nada concreto, pero aprendiendo un montón. Ahí va mi pequeña historia del sábado y cómo se van encadenando las cosas.

• Tenía en mente una pequeña aplicación que me podía resultar de utilidad en el trabajo. Por supuesto la aplicación debía ser web y la iba a hacer en JSP. Me instalé Tomcat en Ubuntu e hice unas pruebas para ver que estaba bien instalado.
• Me cree con maven y eclipse mi proyecto web con JSP para empezar a trabajar.
• Mi aplicación va contra base de datos. Por cosas que había leído, me daba la impresión de que Tomcat puede gestionar las conexiones a base de datos con un pool de conexiones, liberando a la aplicación de tener que abrirse sus propias conexiones, así que me pongo a investigar el tema.
• Encuentro tutoriales, hago todo lo que se supone que hay que hacer, pero no me funciona. Siempre obtengo una excepción de acceso denegado, no hay permisos. Me pongo a investigar cómo gestiona Tomcat el tema de permisos y descubro el fichero catalina.policy.
• Por supuesto, no es tan fácil como tocar ese fichero. Tomcat lo genera automáticamente en el arranque machacando los cambios que hayas hecho, así que hay que buscar y tocar los ficheros que usa Tomcat para generar ese catalina.policy. Y por supuesto me doy cuenta de ese detalle después de tres o cuatro intentonas fallidas de tocar catalina.policy directamente.
• Una vez que funciona todo, como no encontré ningún tutorial que diga como configurar el pool de conexiones y además te advierta del tema de permisos, me decido a escribir el mio propio en la wiki: Configurar un DataSource y dar permisos en Tomcat.
• Al escribir el tutorial, además de explicar cómo se tocan los ficheros a mano, pongo que se puede hacer con el navegador si tenemos instalada la aplicación de administración de Tomcat. Se me ocurre poner una foto del panel de administración, pero pensando un poco, decido que queda más "guay" un video, así podría subir mi video a youtube. Pero claro, hay que capturar el video del escritorio.
• Me pongo a buscar aplicaciones que capturen video del escritorio en Ubuntu. Encuentro un par de ellas y las pruebo. No me van bien. Al final, una de ellas graba bien pero si la lanzas desde línea de comandos, no desde la interface gráfica de usuario. Al arrancarla desde línea de comandos, en el video capturado se ve la ventana de comandos donde arranco la aplicación, cómo la oculto, cómo la vuelvo a visualizar y cómo paro la grabación.
• Eso no es bonito, así que decido buscar un editor de video para cortar esos cachos. Encuentro uno pero …. no lee el formato .ogg ni .ogm que es en el que graba la aplicación anterior. Sospecha gorda. ¿admitirá youtube este formato?. Por supuesto, no. Hay que buscar un conversor de formatos.
• Me pongo a ello, encuentro varios que no me funcionan bien o no me dejan el video como quiero. Al final lo consigo, como no, usando directamente la línea de comandos con ffmpeg. Y ahora empezamos con los "return":
  • Convierto el video a avi
  • Edito el video y le corto lo que sobra
  • Subo el video a youtube
  • termino el tutorial en la chuwiki
  • escribo otro tutorial sobre las herramientas de video probadas.
  • y ya son las y pico de la madrugada y me voy a la cama.

Al final, pasé toda la tarde (y parte de la noche) entretenido, no hice nada de la aplicación que quería hacer, pero he subido mi primer video a youtube (no tiene demasiada buena calidad), he escrito par de tutoriales en la wiki y he aprendido algunas cosas sobre Tomcat: DataSources y permisos.

¿De verdad los ordenadores ahorran trabajo?

Llevo varios días borrando esa página. Al ver que el tema seguía, me decidí a bloquear las IPs de donde proviene ese spam, pero parece que no se les acaban. Seguramente están usando un proxy de IP dinámica, de esos que sirven para ocultar la IP real.

Mirando en la documentación de MediaWiki veo que existen cosas como Captchas estilo ConfirmEdit, pero no parece que sea de fácil instalación y sobre todo porque en los primeros párrafos empiezan a contar rollos de versiones que, por supuesto, yo no tengo.

Así que al final, encontré cómo hacer para que un usuario no registrado no pueda crear páginas, que básicamente consiste en editar el fichero LocalSettings.php y añadirle una línea como

$wgGroupPermissions['*']['create'] = false;

con lo que no permite a usuarios anónimos (debe ser el *) crear (por lo de create) páginas nuevas.

Es una pequeña limitación, pero supongo que a alguien que quiera crear una página y se vaya a poner a escribir algo en serio en ella, no le costará mucho más esfuerzo registrarse y darse de alta.