Fonte APT de VPN: que concede e como limitala

Descargar un cliente VPN é unha decisión única; engadir o seu repositorio APT non o é. O segundo indica ao xestor de paquetes de onde pode vir software futuro, e iso é unha transferencia permanente de autoridade, non unha descarga. Pode ser o arranxo correcto cando o provedor mantén o repositorio como é debido. Aínda así merece unha decisión deliberada, e a maioría das guías de instalación omítena.

Unha sinatura autentica un arquivo, non o seu código

APT verifica os metadatos asinados do repositorio e despois confía nas sumas de comprobación dentro deses metadatos para os paquetes que descarga. O que iso demostra é que o arquivo coincide co que publicou o titular da clave, e nada sobre o código que contén. Un paquete asinado correctamente pode seguir levando scripts de mantedor inseguros, e eses scripts execútanse como root mentres se instala o paquete. O manual de apt-secure traza exactamente esa liña entre a autenticación do arquivo e unha revisión do software.

Así que a pregunta útil non é se a sinatura valida, xa que unha sinatura rota detén a instalación de todos os xeitos. É de quen escolle vostede confiar na sinatura a partir de agora. Unha clave de sinatura roubada é peor que un paquete roubado, porque o atacante segue producindo metadatos válidos moito despois da primeira versión mala. A rotación é a única reparación, e depende de que o provedor publique unha clave nova por unha canle que vostede poida verificar de forma independente.

Por iso a identidade da clave merece tanta atención como o URL do repositorio. Unha clave tomada dun enderezo nunha resposta antiga dun foro non establece nada sobre o editor, mentres que HTTPS protexe o transporte ata quen respondeu ao teléfono. A seguridade do transporte e a identidade do editor son cuestións separadas, e só a primeira se resolve cun certificado.

Limite a clave á fonte, non ao sistema

O APT moderno acepta unha referencia Signed-By específica da fonte. Unha clave xestionada polo operador pode vivir en /etc/apt/keyrings/, e a entrada da fonte nomea a clave que pode autenticar ese arquivo. Iso é máis estreito que botar a mesma clave nun conxunto de confianza global, onde pode avalar fontes que vostede nunca quixo permitir. Siga a versión de APT instalada e as instrucións actuais do provedor en lugar de mesturar fragmentos de distintas xeracións de guías.

curl -fsSL https://repo.example.com/vpn-key.gpg -o /etc/apt/keyrings/vpn.gpg
echo "deb [signed-by=/etc/apt/keyrings/vpn.gpg] https://repo.example.com/debian stable main" > /etc/apt/sources.list.d/vpn.list

Nunca repare un fallo de sinatura desactivando a verificación nin marcando como fiable un arquivo descoñecido. Iso cambia un erro visible por un invisible, e o invisible dura ata que alguén audite a lista de fontes. Se a clave non coincide, a corrección correcta é atopar a clave correcta, non quitar a comprobación.

Obteña os detalles do repositorio e a identidade da clave do proxecto ou dun administrador xestionado. Unha clave copiada dunha entrada de blog é unha afirmación sobre a autoría, non unha proba dela. Cando un provedor publique unha canle de rotación, anótea xunto coa clave, porque esa canle é o que fai posible a seguinte rotación.

Fixar a fonte non é unha lista branca de paquetes

Restrinxir unha clave a unha fonte limita que arquivo pode autenticar, non que paquetes pode publicar ese arquivo. O repositorio pode enviar moito máis que o cliente VPN que vostede quería, e a selección de candidatos e as prioridades de APT deciden que versión elixible gaña. Revise a transacción proposta antes de confirmala, incluída a lista de dependencias, porque as dependencias chegan do mesmo arquivo. O alcance dunha clave non pode expresar ’só este paquete’.

Se necesita un control máis forte, exprésao como política sobre nomes ou versións de paquetes e manteña esa política baixo xestión de configuración. Ler unha transacción leva un minuto; descubrir un paquete inesperado seis meses despois leva unha revisión.

Os paquetes inesperados son o momento de parar en lugar de continuar, e a pregunta para o propietario do arquivo é por que fan falta. Un repositorio que publica unha ducia de paquetes arredor dun cliente é normal para un provedor que distribúe unha suite de escritorio. Tamén é unha superficie maior do que implicaba a guía de instalación, e esa é a parte que merece rexistrarse. Ningún dos dous resultados é motivo para desconfiar da sinatura; ambos son motivos para escribir o que aceptou.

Rexiste a autoridade e como retirala

Escriba o propietario do arquivo, a versión do sistema operativo admitida, a canle de rotación da clave e o procedemento de retirada. Eses catro feitos son o que necesita un sucesor cando o cliente se retira ou o provedor rota a súa clave. Sen eles, a seguinte persoa herda unha liña de fontes e un ficheiro de clave sen ningunha historia.

A retirada é o paso que se omite, así que escríbao no momento de instalar. Borre a entrada da fonte e a súa clave dedicada á vez, e comprobe se esa clave se referencia noutro lugar antes de borrar o ficheiro. Unha clave compartida borrada sen esa comprobación converte unha limpeza nunha caída non relacionada, que é o peor resultado para un cambio rutineiro. Despois confirme que as actualizacións ordinarias seguen resolvéndose unha vez que a entrada desapareceu.

Queda unha cousa tras retirar o repositorio: calquera paquete xa instalado desde el segue funcionando ata que algo o substitúa. A pregunta honesta é que autoridade engadiu e con que estreiteza se expresou o seu papel.