Apt Secure en Debian
Secure Apt
| Me he permitido traducir este artículo (con la gran ayuda de Esther Castellanos) sobre Secure Apt que está disponible en el wiki de Debian. Está escrito por Joey Hess. Se admiten correcciones de todo tipo SECURE APT Recientemente, las ramas Unstable y Testing de Debian han comenzado a usar criptografía fuerte para validar los paquetes descargados. A esto se le llama comúnmente Secure Apt (o apt-secure ) y fue implementado en la versión 0.6. Como la documentación (aquí y aquí ) es verdaderamente escasa sobre cómo funciona esto desde el punto de vista de un administrador, este documento intentará explicar en detalle cómo funciona Secure Apt y cómo usarlo. 1.Todo sobre Secure Apt CONCEPTOS BÁSICOS Aquí están unos pocos conceptos básicos que necesitarás para entender el resto del documento. Un checksum (suma de comprobación) es un método para coger un fichero y reducirlo a un número pequeño de forma razonable que identifica únicamente el contenido de un fichero. Esto es mucho más difícil de hacerlo bien de lo que puede parecer, y el tipo de checksum más comúnmente utilizado, el md5sum, está en proceso de romperse. La criptografía de llave pública está basada en el par de llaves, una llave pública y una privada. La llave pública se da a todo el mundo; la llave privada debe permanecer en secreto. Cualquiera que posea la llave pública puede cifrar un mensaje para que sólo pueda ser leído por alguien que posea la llave privada. También es posible usar una llave privada para firmar un archivo, no para cifrarlo. Si una llave privada es utilizada para firmar un archivo, entonces cualquiera que tenga la llave pública puede comprobar que el archivo fue firmado por esa llave. Nadie que no tenga esa llave puede falsificar la firma. Esas llaves son números bastante largos (al menos 1024 bits, por ejemplo 256 o más dígitos hexadecimales) y para hacer más fácil el trabajar con ellos, incorporan una identificación de llave, que es un número corto de 8 ó 16 dígitos que puede ser utilizado para referirse a ellos. GPG es la herramienta usada en Secure Apt para firmar los ficheros y comprobar sus firmas. Apt-key es un programa que se usa para gestionar el anillo de llaves de gpg para asegurar Apt. El anillo de llaves se guarda en el archivo /etc/apt/trusted.gpg (no se debe confundir con el archivo /etc/apt/trustdb.gpg con el que está relacionado y que no es muy interesante). Apt-key puede ser usado para mostrar las llaves en el anillo de llaves, y para añadir o remover una llave. TRABAJO PRELIMINAR DE SECURE APT: CHECKSUMS Un archivo de Debian contiene un archivo llamado Release, el cual se actualiza cada vez que cualquiera de los paquetes en el archivo cambian. Entre otras cosas, el fichero Release contiene algunos md5sums de otros ficheros en el archivo. Un extracto de un ejemplo de fichero Release: (Los ficheros Release también incluyen checksums sha1, las cuáles serán útiles una vez que md5sums estén completamente rotos, aunque Apt aún no las utilice). Ahora si miramos dentro de un fichero Release, encontraremos más md5sums, una por cada paquete listado en él. Por ejemplo: Estas dos checksums permiten a Apt verificar que se está descargando una copia correcta del fichero Packages, con un md5sum que concuerde con el del fichero Release. Y cuando descarga un paquete individual, también puede comprobar el md5sum sobre el contenido del fichero Packages. Si Apt falla en cualquiera de estos pasos, abortará. Nada de esto es nuevo en asegurar Apt, pero proporciona los cimientos.Hay que fijarse que hasta ahora hay un fichero que Apt no tiene la manera de comprobarlo: el fichero Release. Secure Apt trata de hacer verificar a Apt el fichero Release antes de que haga cualquier otra cosa con él, y tapando este agujero, de tal forma que hay una cadena de verificación desde el paquete que vas a instalar hasta el proveedor del paquete. FICHEROS RELEASE FIRMADOS Para tapar el agujero, Secure Apt añade una firma gpg para el fichero Release. Esto está puesto en un fichero llamado Release.gpg que se envía junto al fichero Release. Se parece a algo así, aunque realmente sólo gpg mira normalmente su contenido. (Técnicamente hablando, esto es una firma gpg ascii-armored separada) CÓMO APT USA RELEASE.GPG Secure Apt siempre descarga los ficheros Release.gpg cuando está descargando los ficheros Release, y si no puede descargar el Release.gpg, o si la firma está mal, lo advertirá, y te dirá que el fichero Packages al cual apunta el fichero Release, y todos los paquetes enumerados dentro, son de una fuente sin autentificar. Así es como apararece durante un apt-get update: Observa que la segunda mitad del número largo es la identificación de la llave que Apt no conoce, es este caso es 2D230C5F. Si ignoras ese aviso e intentas instalar un paquete después, Apt te advertirá de nuevo: Si dices Y (Sí) aquí, no puedes saber si el paquete que estás obteniendo es el paquete que supuestamente estás instalando, o si es otra cosa se te ha presentado una chistera con una sorpresa dentro. Observa que puedes deshabilitar esas comprobaciones ejecutando Apt con allow-unauthenticated. Es algo digno de tener en cuenta que las nuevas versiones del instalador de Debian usan el mismo mecanismo de firmar el fichero Release durante el debootstrap del sistema base de Debian, antes de que Apt esté disponible, y que incluso el instalador usa este sistema para verificar partes de sí mismo que se descarga de la red. Además, Debian actualmente no firma los ficheros Release en sus CD's; Apt puede ser configurado para autentificar siempre los paquetes desde los CD's, por lo que esto no es un gran problema. CÓMO DECIRLE A APT QUÉ AUTENTICAR La seguridad del sistema entero depende de que haya un fichero Release.gpg, el cual firma un fichero Release, y de Apt comprobando que esa firma use gpg. Para comprobar la firma, debe conocer la llave pública de la persona que firmó el fichero. Esas llaves se mantienen en el anillo de llaves de Apt (/etc/apt/trusted.gpg), y administrando esas llaves es donde aparece Secure Apt. Por defecto, los sistemas Debian vienen preconfigurados con la llave del archivo Debian en el anillo de llaves. Aquí 4F368D5D es la identificación de la llave, y observad que esta llave sólo era válida por un año. Debian rota estas llaves como última línea de defensa contra algunas brechas de seguridad que rompen una llave. Eso conseguirá que Apt certifique el archivo oficial de Debian, pero si añades algún otro repositorio de Apt a /etc/apt/sources.list, también tendrás que darle a Apt su llave si quieres que Apt las certifique. Una vez que tienes la llave y la has verificado, es simplemente hacer un apt-key add file para añadirlo. Conseguir la llave y verificarla es la parte más complicada. CÓMO ENCONTRAR UNA LLAVE Todavía no hay una localización estándar donde puedas encontrar la llave para un repositorio Apt ya dado. Hay un estándar aproximado sobre cómo poner la llave en una página web para el repositorio o como un fichero dentro del mismo repositorio, pero no es un estándar real, por lo tanto tendrías que encontrarlo. El archivo Debian que firma la llave está disponible en http://ftp-master.debian.org/ziyi_key_2006.asc (se cambia 2006 por el año en curso). (La herramienta que se usa para firmar en los servidores de Debian se llama Ziyi , por Ziyi Zhang). El mismo gpg tiene una forma estándar de distribuir llaves, usando un servidor de llaves desde el que gpg puede descargarse una llave y añadirlo a su anillo de llaves. Por ejemplo: (¿Qué significa el aviso gpg: finalmente no se han encontrado llaves verificadas ? --> El aviso finalmente no se han encontrado llaves verificadas significa que gpg no estaba configurado para verificar una llave específica. Las configuraciones de verificación son parte de las webs de verificación de OpenPGP, algo que no interesa aquí. Por lo tanto no hay ningún problema con esta advertencia. En configuraciones normales la propia llave del usuario está finalmente verificada.) CÓMO AÑADIR UNA LLAVE DE FORMA SEGURA Añadiendo una llave al anillo de Apt, le dices a Apt que verifique todo lo que la llave ha firmado, y esto te permite saber de forma segura que Apt no instalará nada que no haya sido firmado por la persona que posee la llave privada. Pero si eres lo suficientemente paranóico puedes ver que esto únicamente lleva las cosas a un nivel superior, y ahora en lugar de tenerte que preocupar de si un paquete, o un fichero Release es válido, te puedes preocupar de si realmente has conseguido la llave correcta. ¿Es realmente la http://ftp-master.debian.org/ziyi_key_2006.asc que se mencionó arriba la llave que firma el archivo de Debian, o es éste documento una trampa inteligente?. Es bueno ser paranóico con la seguridad, pero verificando las cosas desde este punto es más difícil. Gpg tiene el concepto de una cadena de autentificación, que puede empezar con alguien en quien confías, que firma la llave de alguien, que firma alguna otra llave, etc., hasta que llegas a la llave del archivo. Si eres lo suficientemente paranóico, querrás comprobar que la llave de tu archivo está firmada por una llave en la que puedes confiar, con una cadena de autentificación que se remonta a alguien que conoces personalmente. Si quieres hacer esto, ve a una conferencia de Debian o quizás en un Grupo de Usuarios de Linux (LUG) local para firmar la llave. (Nota: no todas las llaves del repositorio de Apt se firman por otra llave. Quizá la persona que configura el repositorio no tiene otra llave, o quizás no se sienten cómodos firmando esa llave con su llave principal.) Si no puedes aguantar este nivel de paranoia, haz lo que tú consideres apropiado a la hora de añadir una nueva fuente de Apt y una nueva llave. Quizás quieras mandar un correo electrónico a la persona que te da la llave y verificarla, o quizás quieras tener la oportunidad de descargártela y dar por hecho que tienes la auténtica. Lo importante es que reduciendo el problema a lo que las llaves del archivo autentifica, Secure Apt permite que seas tan prudente y seguro como acostumbras a ser. Aquí hay un mensaje en una bitácora con un procedimiento para verificar la integridad de la llave. ROTACIÓN ANUAL DE LA LLAVE DEL ARCHIVO DE DEBIAN Como se ha mencionado arriba, la llave que firma el archivo de Debian cambia cada año, en Enero. Como Secure Apt es reciente, no tenemos mucha experiencia a la hora de cambiar la llave y todavía quedan puntos sin explicar. En Enero de 2006, se hizo una nueva llave para el 2006 y el fichero Release comenzó a firmarse por ella, pero para intentar evitar romper los sistemas que tienen la vieja llave del 2005, el fichero Release fue firmado también por esa. La intención era que Apt aceptaría una firma u otra dependiendo de la llave que tuviera, pero Apt resultó ser defectuoso y rechazó autentificar el fichero a menos que tuviera ambas llaves y fuera capaz de comprobar ambas firmas. Esto se arregló en la versión 0.6.43.1 de Apt. Hubo también confusión acerca de cómo la llave se distribuyó a usuarios que ya tenían sistemas que utilizaban Secure Apt; inicialmente fue subido al sitio web sin ningún tipo de anuncio y sin ninguna manera de verificarla y los usuarios se vieron forzados a descargársela manualmente. Esto se arregló por la introducción del paquete debian-archive-keyring, que gestiona las actualizaciones del anillo de llaves de Apt. Basado en esta experiencia, aquí vemos cómo podrían funcionar las cosas en el 2007:
Pero es muy pronto para decir algo. OTROS PROBLEMAS
Aunque la lista de apt-key hará el problema más fácil Si se pone una fecha lejos en el futuro, Apt tratará las llaves como caducadas. Esto no tiene nada que ver realmente con Secure Apt. Debsig-verify comprueba firmas incluídas dentro de paquetes individuales de Debian. Como tales firmas no se utilizan ampliamente (usamos en su lugar Secure Apt), el intalar esto no funciona muy bien, y eliminar el paquete debsig-verify arreglará el problema. CONFIGURANDO UN REPOSITORIO DE APT SECURE Por hacer HISTORIA Conectiva implementó algo similar en su fork de Apt. Los Desarrolladores de Debian Colin Walters e Isaac Jones implementaron Apt Secure para Debian en 2003. Cerca de la Navidad de 2003, Matt Zimmerman (?) integró este parche en Apt 0.6. En Febrero de 2005, Debian comenzó a migrar a apt-secure COMENTARIOS Y PREGUNTAS Debian no es Ubuntu y no tendrá instalado por defecto Sudo. Merecería la pena cambiar el uso de Sudo, y hacer que los ejemplos usen la cuenta de root explícitamente. ---Steve Kemp Dados los modos de error que he visto de las gpg recv-keys, sugerir que un usuario lo ejecute como root no me parece muy sabio. Pero realmente nunca lo he probado. A pesar de que Sudo no se instala por defecto (en Sarge), pienso que la mayoría de la audiencia de esta página está familiarizado con él, o pueden saltárselo. --- Joey Hess ¿Tiene sentido preinstalar el debian-server-keyring en cada sistema Debian?. Al menos se le debería preguntar al usuario si él/ella confía en esa llave. Hasta ahora (07/01/2006) la Firma Automática de Llaves del Archivo Debian no es la colección más fuerte de llaves. Así no es posible probar vía opathfinders si hay una ruta de autentificación de mi llave a la Firma Automática de Llaves del Archivo Debian (ver www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder o www.lysator.liu.se/~jc/wotsap/search.html) Sí, el paquete debian-archive-keyring será el camino para actualizar la llave para todos los sistemas Debian, así que debe ser instalado en todos, y supongo que será estándar. -- Joey Hess ¿Podemos integrar de alguna manera esta idea en la página?. Pienso que también es importante que nos movamos en esta dirección. --madduck COPYRIGHT Este documento tiene Copyright 2006 de Joey Hess y otros bajo los términos de la GNU GPL Copyright © 2006 de la traducción: Daniel Barragán Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". |