10 de November 2008
Filezilla y los zelotes
Hace poco monté un servidor ftp seguro con vsftpd. Es un proceso sencillo, un servidor muy común y con muy buena fama, y no tuve ningún problema. Salvo que mi cuñado decía que no veía nada en el servidor. Yo miraba los logs, veía que él entraba, que subía ficheros sin problemas, y no entendía que podía pasar. Él insistía en que no veía nada en el servidor, y el asunto quedó en el aire.
Hasta este fin de semana. Este fin de semana, estaba configurando el acceso al ftps desde otra máquina, y me encontré con el mismo problema de mi cuñado. El cliente elegido, Filezilla, entraba perfectamente, se logaba y hasta subía ficheros y cambiaba de directorio sin problemas. Pero fallaba cada vez que hacía un listado. Esta vez con la información añadida de que lo que había hecho en esa máquina era actualizar un Filezilla que si funcionaba.
Un poco de google dió con el problema. Este verano, la gente de Filezilla descubrió un error en la manera en la que casi todos los servidores ftp (incluido el propio filezilla como servidor) implementaban las conexiones SSL y TSL, que, al parecer, provocaba la posibilidad de un ataque MITM.
La respuesta de Filezilla fue un poco… exagerada. Es cierto que es teóricamente un vector de ataque importante. Es cierto que rompe la integridad de la comunicación ftps. Pero aún así, bloquear el acceso a todos estos servidores (vsftpd, ProFTPD, Xlight FTP Server, SurgeFTP…), de forma unilateral, implica pensar poco en el usuario final. Hace poco tuvimos el problema del ssh de debian, y la solución implicó tanto a clientes como a servidores. No se dejó colgado a nadie, para evitar este tipo de problemas.
Sin embargo, Filezilla actuó por su cuenta, y sin informar a ningún servidor. Parcheó su cliente, su servidor, provocó las iras de los usuarios (y las de mi cuñado), y se echó a dormir. Para ser uno de los clientes ftp/s mas populares del mercado, demostró que le importaban muy poco los usuarios. Incluso cuando, pese al nivel de belicosidad del hilo se sugiere, con mucha educacion, y apoyado por el segundo usuario mas activo del foro, se sugiere lo mas lógico, un warning grande y feo avisando de que el servidor puede ser inseguro; la respuesta del ¿único? desarrollador de Filezilla no sólo es negativa, sino desagradable y sin sentido.
Dada la coyuntura específica de vsftpd, no tenía dudas de que se había parcheado rápidamente. Así fue, incluso con una entrada en el blog del desarrollador explicando el problema en detalle. Pero mi sorpresa es que no estaba arreglado en etch. Ni en backports. Ni en sid. ¡Ni en experimental! La gente de debian se había dormido en sus laureles esta vez, pese a que hay dos bugs pidiendo la actualización desde hace meses.
Deprimido por el hecho de que ubuntu, fedora y Red Hat, entre otros, habían parcheado no sólo en una sino en dos releases su vsftpd, (ubuntu 8.04 y 8.10, Fedora 8 y 9, RHEL 4 y 5), mientras que debian no había hecho nada, me puse a compilar y empaquetar. Por si le sirve a alguien mas, aquí dejo el vsftpd 2.0.7 empaquetado para etch. Lleva los mismos parches que se aplicaban en el 2.0.5, que es la versión antigua, modificados para reflejar los cambios en el código. Lo único que garantizo es que funciona con Filezilla >=3.1.3.
