Gestión de Software

RPM es una herramienta de gestión de software creada originalmente por Red Hat, y más tarde hecha GNU y puesta a disposición del público (http://www.rpm.org/). Forma parte del corazón de la administración en la mayoría de sistemas, ya que una de las tareas más importantes de cualquier administrador es la instalación y mantenimiento de software actualizado. Varias estimaciones otorgan la mayor parte de la culpa de los incidentes de seguridad a las malas contraseñas, y al software viejo con vulnerabilidades conocidas. Lo cual no es tan sorprendente como uno podría pensar, pero mientras que el servidor medio contenga entre 200 y 400 paquetes de software de media, uno empieza e ver por qué mantener el software actualizado puede ser una tarea importante.

La página del manual de RPM es bastante mala, no existe una forma de hacerla agradable. El libro "Maximum RPM" (ISBN: 0-672-31105-4) por otra parte es realmente estupendo (disponible gratuitamente en http://www.rpm.org/ en formato post script). Le sugeriría este libro a cualquier administrador de Red Hat, y puedo asegurar que es de lectura necesaria si está pensando en construir paquetes RPM. Las bases de RPM son autoexplicativas, los paquetes vienen en formato rpm, con una simple convención de nombre de fichero:

nombre_paquete-versión_paquete-rpm_versión_construcción-arquitectura.rpm

servidor-nfs-2.2beta29-5.i386.rpm sería "servidor-nfs", versión "2.2beta29" del "servidor-nfs", la quinta construcción de ese rpm (p. ej. se ha empaquetado y construido 5 veces, modificaciones menores, cambios en la localización de ficheros, etc.), para la arquitectura Intel, y es un fichero rpm.

Red Hat linux 5.1 venía con 528 paquetes, y Red Hat Linux 5.2 venía con 573, cuando te paras a pensar te das cuenta que es un montón de software. (SuSE 6.0 viene en 5 CD’s, no me he molestado en contar cuántos paquetes). Por lo general acabarás con unos 200-300 paquetes instalados (más aplicaciones en estaciones de trabajo, los servidores tienden a ser más livianos, pero no siempre es el caso). Así que cuáles se deberían instalar y cuáles se debería evitar instalar si fuese posible (como los paquetes de servicios remotos). Tengo que decir algo, los RPM’s que vienen con las distribuciones Red Hat suelen ser bastante buenos, y por lo general duran entre 6-12 meses antes de que se descubra que están estropeados.

Hay una lista de URL’s y listas de correo con erratas específicas por distribución y más adelante, dentro de este documento se indicarán dónde están disponibles las actualizaciones

El sistema de paquetes de Debian es un paquete similar a RPM, sin embargo carece de cierta funcionalidad, aunque en conjunto hace un trabajo excelente gestionando los paquetes de software de un sistema. Combinado con la utilidad dselect (ya un poco desfasada), se puede conectar con sitios remotos, recorrer los paquetes disponibles, instalarlos, ejecutar scripts de configuración necesarios (como para gpm), todo desde la comodidad de tu consola. La página del manual de dpkg "man dpkg" es bastante grande.

El formato general de un fichero con un paquete de Debian (.deb) es:

nombrepaquete_versiónpaquete-debversion.deb

ncftp2_2.4.3-2.deb

Al contrario que los ficheros rpm, los ficheros .deb no traen indicativo de la arquitectura (no es que tenga demasiada importancia, pero es algo que hay que tener en cuenta).

Debian tiene más de 1.500 paquetes disponibles para el sistema. Aprenderás a amar al dpkg (funcionalmente tiene todo lo necesario, sólo me dejo algunas de las florituras que tiene rpm, por otra parte, dselect tiene algunas características que ya quisiera yo que tuviera rpm).

Más adelante hay una lista de URL’s y listas de correo con información específica sobre erratas por distribuciones.

La mayoría de las distribuciones modernas de Linux utilizan un sistema de gestión de paquetes para instalar, llevar un seguimiento y eliminar software del sistema. Sin embargo hay muchas excepciones, Slackware no utiliza un sistema de gestión de paquetes per se, sino que tiene tarballs precompilados (un fichero tar comprimido que contiene ficheros), los cuales tan sólo hay que desempaquetar desde el directorio raíz para instalarlos, algunos de los cuales también pueden ser eliminados, pero funciones tales como consultas, comparación de ficheros instalados contra ficheros de paquetes (intentando encontrar ficheros falsificados, etc.) simplemente no están. O quizás quieras probar la última copia de X, y nadie se las ha apañado todavía para hacer un bonito fichero .rpm o .deb, así que tienes que pillar el código fuente (normalmente viene comprimido en un tarball), desempaquetarlo e instalarlo. Esto no supone más peligro real que un paquete, ya que la mayoría de los tarballs tienen asociadas firmas MD5 o PGP, que puedes descargar y comprobar. La verdadera preocupación con estos ficheros es la dificultad que existe a veces para hacer el seguimiento de si se tiene cierto tipo de software instalado, determinar la versión, y después eliminarlo actualizarlo. Recomendaría que no se utilizasen tarballs si fuese posible, si hay que usarlos, es una buena idea hacer una lista de los ficheros del sistema antes de instalarlo, y otra después de instalarlo, y posteriormente compararlas utilizando ‘diff’, para averiguar qué fichero ha sido colocado en qué lugar. Simplemente ejecuta ‘find /* > /listaficheros.txt’ antes y ‘find /* > /listaficheros2.txt’ después de instalar el tarball, y utiliza ‘diff –q /listaficheros.txt /listaficheros2.txt > /listadiferencia.txt’ para obtener un listado de qué es lo que ha cambiado. Alternativamente, un ‘tar –tf blah.tar’ sacará un listado de los contenidos del fichero, pero como la mayoría de los tarballs, acabarás ejecutando un script de instalación/compilación e instalando el software, de modo que un simple listado de ficheros no te va a dar una idea exacta de qué fue lo que ha sido instalado/modificado. Otro método de llevar un seguimiento de qué es lo que se ha instalado vía tar es utilizar un programa como ‘stow’; stow instala el paquete en un directorio aparte (/opt/stow/), por ejemplo, y después crea links desde el sistema a ese directorio, según sea necesario. Para ejecutar Stow es necesario tener Perl instalado, y se encuentra disponible en: http://www.gnu.ai.mit.edu/software/stow/stow.html

Algo que he pensado cubrir por semi-separado es la verificación de la integridad del software adquirido desde sitios remotos. Generalmente, la gente no se preocupa, pero hace poco entraron en ftp.win.tue.nl, y se insertó un troyano en el paquete (entre otros) TCP_WRAPPERS. Se hicieron 59 descargas antes de que el site eliminase los paquetes ofensivos e iniciase un procedimiento de control de daños. Siempre se debería verificar la integridad de los ficheros que descargues desde sitios remotos, algún día pueden entrar en un sitio de los grandes y mucha gente sufriría bastantes daños.

RPM

Los paquetes RPM pueden estar (y de hecho lo suelen estar) firmados con PGP por el autor. Esta firma se puede comprobar para asegurar que el paquete no ha sido falsificado o es una versión con troyano. Esto queda descrito más adelante en el capítulo 7 de "Maximum RPM" (disponible en línea en http://www.rpm.org/), pero consiste en añadir las llaves de los desarrolladores a tu llavero público PGP, y después utilizar la opción –K, que cogerá la llave apropiada del llavero y verificará la firma. De esta forma, para insertar un troyano en un paquete firmado correctamente, se necesitaría robar la llave PGP privada y la contraseña para descifrarla, lo cual sería casi imposible.

dpkg

dpkg soporta MD5, de modo que hay que conseguir las firmas MD5 mediante un canal seguro (como correo firmado con PGP). MD5 viene con la mayoría de las distribuciones.

PGP

Se distribuyen muchos tarballs con firmas PGP en ficheros ASCII separados, para verificarlos, se añade la llave de los desarrolladores a tu llavero y se utiliza PGP con la opción –o. De esta forma, para insertar un troyano en un paquete y firmarlo correctamente, habría que robar la llave privada PGP del desarrollador y la contraseña para descifrarla, lo cual debería ser casi imposible. PGP para Linux está disponible en ftp://ftp.replay.com/.

MD5

Otra forma de firmar un paquete es crear un checksum MD5. La razón por la que se utilizaría MD5 (ya que cualquiera puede crear una firma MD5 válida para un paquete de software con troyano), es que MD5 es bastante universal y no está controlado por leyes de exportación. La debilidad es que de alguna manera hay que distribuir con antelación las firmas MD5 por un canal seguro, lo cual se suele hacer vía correo, cuando se anuncia un paquete (vendedores como Sun lo hacen con los parches).

RPM

Hay una gran variedad de herramientas disponibles para instalaciones automáticas de ficheros rpm.

ftp://ftp.kaybee.org/pub/linux/

AutoRPM es probablemente la mejor herramienta para mantener actualizados los rpm’s, se le hace apuntar a un directorio ftp, y descarga e instala cualquier paquete que sea más nuevo que los que se tienen. Por favor, ten en cuenta que si alguien envenena tu caché de dns, te pueden comprometer con facilidad, de modo que asegúrate que utilizas la dirección IP del ftp y no su nombre. También deberías considerar apuntar a un sitio ftp interno con los paquetes que has probado, y mantener un mayor control sobre él. AutoRPM requiere tener instalado el paquete libnet Net::FTP para perl.

ftp://missinglink.darkorb.net/pub/rhlupdate/

rhlupdate también se conectará a un sitio ftp y cogerá todas las actualizaciones necesarias, se aplican las mismas advertencias que más arriba, y de nuevo requiere tener instalado el paquete libnet Net::FTP para perl.

http://www.iaehv.nl/users/grimaldo/info/scripts/

RpmWatch es un sencillo script en perl que instalará actualizaciones en lugar de ti, ten en cuenta que no descargará los paquetes que necesitas, tienes que hacer un mirror de ellos localmente, o tenerlos accesibles localmente vía algo como NFS o CODA.

dpkg

dpkg tiene un instalador automático interesante, llamado ‘apt’, además de instalar software, capturará e instalará el software necesario para cumplir las dependencias, se puede descargar de: http://www.debian.org/Packages/stable/admin/apt.html

tarballs / tgz

No se han encontrado herramientas, por favor, dime si conoces alguna (aunque más allá de hacer mirror, desempaquetar automáticamente y ejecutar "./configure; make; make install", no se me ocurre nada más).

installwatch

installwatch monitoriza lo que hace un programa, y lleva un log al syslog de cualquier cambio que hace al sistema. Se parece al programa "time" en que ejecuta el programa de forma escalonada, de modo que pueda monitorizar lo que ocurre, el programa se ejecuta como "installwatch /usr/src/algo/make" por ejemplo (opcionalmente se puede utilizar "-o nombrefichero" para hacer un log a un fichero específico), installwatch está disponible en: http://datanord.datanord.it/~pdemauro/installwatch/

instmon

instmon se ejecuta antes y después de instalar un paquete tarball / tgz (o cualquier paquete, por lo que respecta). Genera una lista de fichero que han cambiado, la cual se puede utilizar más adelante para deshacer cualquier cambio. Está disponible en: http://hal.csd.auth.gr/~vvas/instmon/

Otra forma de manejar paquetes/etc. es convertirlos. Existen diferentes utilidades para convertir ficheros rpm a tarballs, rpm’s a deb’s, etc.

alien

alien es probablemente la mejor utilidad para convertir ficheros, maneja rpm’s, deb’s y tarballs bastante bien. Se puede descargar de: http://kitenet.net/programs/alien/

slurp

Slurp adopta un enfoque interesante, de alguna forma se comporta como installwatch, pero también tiene alguna de las características de alien. Monitoriza el sistema a medida que se instala el paquete, para lo cual crea un rpm. Slurp se puede conseguir en: http://students.vassar.edu/~jajohnst/slurp/

Encontrar software

Uno de los mayores problemas con Linux es encontrar software que no viene con tu distribución. Buscar en Internet es un coñazo. Sin embargo existen algunos recursos que pueden aliviar tus penas:

• http://www.rpmfind.net/
• http://www.linuxapps.com/
• http://www.freshmeat.net/

Volver