Quali repository di pacchetti di Linux Distro sono sicuri e quali no?

14

La maggior parte delle distro che conosco hanno una sorta di funzionalità di repository in cui è possibile scaricare nuovi pacchetti dopo l'installazione. Quali distro lo fanno in modo sicuro e quali non lo fanno in modo sicuro.

Sto pensando in particolare a vettori di attacco come man-in-middle e problemi come la violazione della sicurezza sia sul meta server del repository che sui mirror dei file del repository.

Ho sentito che sia Slackware che Arch Linux sono molto vulnerabili perché mancano della firma del pacchetto. È vero? Ci sono altre principali distro linux vulnerabili a semplici attacchi man-in-middle?

security distros repository

— grm
fonte

se il sito della distro è in chiaro http o ftp e la distro è ottenuta come iso da questa connessione e questa connessione di base è MITM rispetto a quanto bene fa un pacchetto 'post-mortem' che firma sui pacchetti di aggiornamento?

— n611x007,

7

Questa non è una risposta diretta alla tua domanda, ma ci sono diverse cose che puoi fare per mitigare questo rischio. Il più semplice è controllare i pacchetti scaricati rispetto ai checksum da un mirror diverso da quello scaricato.

Quando il mio gestore dei pacchetti (poldek ) scarica un pacchetto, l'ho impostato per conservare una copia degli rpm scaricati in una cartella cache. Controlla automaticamente il checksum del download rispetto al repository dei pacchetti e avvisa / interrompe in caso di mancata corrispondenza, ma se tu fossi preoccupato per l'attacco man-in-the-middle contro il tuo repository distro sarebbe facile scrivere uno script secondario che abbia sfogliato tutti i pacchetti scaricati e verificarli rispetto ai checksum scaricati da un altro mirror. Puoi anche eseguire la tua prima installazione come esecuzione a secco in modo che i pacchetti vengano scaricati ma non installati, quindi esegui lo script di verifica, quindi esegui l'installazione effettiva.

Questo non impedisce a un pacchetto compromesso di entrare nel repository della distro, ma la maggior parte delle distribuzioni ha altri modi per mitigarlo, e persino i pacchetti firmati non garantirebbero che questo non sia mai un problema. Ciò che fa è soffocare il vettore di attacco man-in-the-middle mirato. Usando una fonte separata e scaricando su un canale separato, uccidi la facilità con cui un pacchetto compromesso potrebbe essere lasciato cadere in una linea sfruttata.

— Caleb
fonte

1

Esiste un pacchetto per Arch chiamato paccheckche esegue questa operazione, confronta i pacchetti con diversi mirror prima dell'installazione e avverte di eventuali discrepanze.

— Lupo,

Le liste dei mirror sono probabilmente pubbliche, quindi un attaccante non può teoricamente complottare il MITM tutte secondo lo schema? Se un utente malintenzionato prende di mira specificamente il tuo server, questo non sembra ancora più probabile? Tuttavia, questo è probabilmente molto più di quello che fa la maggioranza di Linux.

— n611x007,

10

I pacchetti Debian vengono sommati e i checksum sono firmati da una chiave nel portachiavi Debian. Il aptgestore pacchetti assicura che il pacchetto scaricato abbia il checksum corretto e che il file di checksum sia stato firmato correttamente.

— jmtd
fonte

5

I pacchetti Fedora sono firmati e compilati. Anche i repository di terze parti come rpmfusion firmano i loro pacchetti.

Yum (il gestore pacchetti) richiede un flag speciale ( --nogpgcheck) per installare pacchetti che non sono stati firmati.

— Kanak
fonte

e così anche i pacchetti di downsteam ovvero Red Hat e CentOS

— fpmurphy,

3

Tutti i pacchetti Arch Linux usano una somma md5 o sha1 per verificare che tutti i bit siano presenti. Spetta al manutentore del pacchetto scegliere l'algoritmo di hashing. I pacchetti installati da AUR (spesso solo un piccolo file di testo PKGBUILD) dovrebbero essere controllati dall'installazione prima di essere installati. I repository contenenti i pacchetti binari ufficiali sono supervisionati da utenti fidati (TU).

Aggiornamento : Arch ha ora introdotto la firma del pacchetto con pacman 4

— Alessandro
fonte

2

Tutto vero, ma i pacchetti non sono firmati e pertanto rimangono vulnerabili agli attacchi di mitigazione e mirroring compromesso, per quanto remota possibilità. È stata una funzionalità molto richiesta e il motivo principale per cui a malincuore ho smesso di usare Arch. Detto questo, è in corso una discussione al riguardo nei forum e wiki di Arch e Pacman - è un problema difficile da risolvere. A parte questo problema, Arch è una distribuzione fantastica.

— Eli Heady,

@Eli: non sto discutendo la verità di questo - non ho idea dello stato delle cose - ma non sarebbe un mercato evanescente da attaccare. Certo, Arch è una distribuzione piuttosto popolare, ma non tutti questi tipi di malizia si basano generalmente sulla capacità di fare un dollaro?

— Boehj,

1

Certo, dopo tutto questo è il motivo per cui la base utenti di Windows ha come target più di quella di Linux, giusto? Il fatto è che ciò che si applica all'aggregato di solito non si applica esattamente all'individuo. Ciò che intendo è che il modello di minaccia di tutti è diverso: se hai motivo di temere di essere individuato per un attacco, dovresti prendere le misure appropriate per ridurre il rischio. La mancanza della firma del pacchetto presenta vettori di attacco che non sono così difficili da sfruttare. Se hai bit preziosi da proteggere, questo problema dovrebbe essere preso in considerazione nella tua strategia di mitigazione delle minacce.

— Eli Heady,

È possibile installare Arch da un CD / DVD e quindi assicurarsi di verificare che le somme md5 / sha1 dei pacchetti binari corrispondano alle somme di diversi mirror prima dell'installazione, in modo simile a quanto suggerito da Caleb. Non c'è mai sicurezza al 100% in ogni caso, anche se vedo il punto della firma del pacchetto e desidero che Arch ce l'abbia.

— Alexander

quindi come si ottiene che il checksum sia consegnato in modo più sicuro rispetto a http o ftp in chiaro? il controllo delle firme dovrebbe essere in atto in che modo avviene esattamente su Arch?

— n611x007,

1

Chi ha detto che Slackware non ha la firma del pacchetto?

I pacchetti Slackware sono firmati con una chiave pubblica di Slackware. Quindi ogni pacchetto ha la sua firma con estensione .asc. Non solo i pacchetti ma anche altri file sono firmati, come CHECKSUMS.MD5. Questo contiene un elenco di checksum dei pacchetti.

La distro ha uno strumento ufficiale chiamato slackpkgper scaricare / installare pacchetti da un mirror. Dopo aver aggiornato il database dei repository locali con slackpkg updatelo strumento controlla la validità della firma del nuovo file MD5 e del log delle modifiche, ecc ...

Dopo aver scaricato un pacchetto (ma prima dell'installazione) vengono controllati la firma e MD5 del pacchetto.

È possibile ottenere la chiave pubblica con slackpkg update gpgo semplicemente importarla dal CD di installazione congpg --import GPG-KEY

C'è un altro strumento non ufficiale slapt-getper Slackware. Supporta anche i controlli GPG! In modo simile a slackpkg.

— fannullone
fonte

-2

OpenBSD di gran lunga. L'intero progetto è dedicato alla sicurezza, il team ha persino applicato una patch di oltre 5000 linee all'apache originale perché non riteneva che fosse abbastanza sicuro da poter essere utilizzato. Questo è tramite pkg_add ma non ho mai avuto problemi con esso.

— baweaver
fonte

4

Non stai rispondendo alla domanda: riguarda in particolare la verifica delle firme dei pacchetti scaricati (e delle porte, nel caso di * BSD).

— Gilles 'SO- smetti di essere malvagio' il

1

Sono d'accordo con @Gilles; OpenBSD è un ottimo sistema operativo, ma @grm ha chiesto informazioni sulla sicurezza della distribuzione dei pacchetti Linux.

— Livingstaccato,