Message Erreur Secure Boot

[romain254]

Oui,
voilà ce que ça donne :
amnesia@amnesia:~$ mokutil --pk --short
d52ac7db95 HP UEFI Secure Boot PK 2017

[Thierz]

@fran.b

Renseignement ppris, cela veut dire que je n’ai pas une clef OEM garantie par le constructeur mais celle de «fabriquant» du firmware EFI
En clair ça n’est pas un souci

Regarde cet article : PKfail, la faille qui met KO le secure boot

Faille majeure, mais faible probabilité d’être ciblé, c’est à toi de voir si le risque est acceptable ou pas.

[romain254]

Oui,
je sais, c’est bien ce que je cherchais à la base, une distribution live avec une partition persistente qui ne vient pas polluer le disque de la machine.
C’est tombé sur Tails dès le début de mes recherches et je suis resté la-dessus.
Pour autant, ce n’est pas l’idéal, c’est une distribution contraignante.
J’en cherche une autre avec des caractéristiques similaires mais plus souple dans l’utilisation au quotidien, si tu as une idée ou de l’expérience à ce sujet, merci.

[romain254]

Oui,
c’est une des caractéristiques qui m’a plu au début.

[romain254]

Pour moi ça semble bien être une clef d’origine HP, non ?

[Clochette]

@romain254

Mon problème c’est de pouvoir ouvrir un port sur une distrib live semble t-il particulièrement bien « cadenassée » pour répondre à des obligations provenant de microsoft.
Un comble quand même !
Merci.

Est d’utiliser une distribution live avec une persistance pour une utilisation de tous les jours … de surcroît sur un PC ou ni le firmware est à jour ni le système d’exploitation dessus (pas fini d’installer).

La distribution Tails redirige les connexion vers TOR, je ne crois pas qu’il y est de Naviguateur qui puissent facilement exploiter le port 443.

Vue que tu tournes en rond avec Tails et ton OS Windows pas installé, utilisent un Ubuntu/Debian live ou autre distribution comme ça si tu utilise un Portable le permettant (HP, Lenovo, Toshiba, Dell), tu l’installes si pas disponible.
Mais comme dit précédemment, il faut parfois un OS installé pour manipuler la partie EFI.
Sinon c’est clé usb depuis laquelle tu démarré l’outil fourni par le constructeur (il ne le font pas tous, voir avec le matériel).

Dans tous les cas Tails ne sera pas d’un grand secours, à la différence de Kali qui se veux un outil de Forensics, Tails est une distribution voué à simplement être utilisée tel quelle.

[anon3605821]

@romain254

C’est tombé sur Tails dès le début de mes recherches et je suis resté la-dessus.

tu t’es enquiquiné pour rien comme ca a été dit par ailleurs un debian live aurait ete aussi simple et tu aurais eu peut etre moins d’emdts pour la config initiale
Pour ce qui est de la « persistence » il me semble que la live debian la propose aussi
Tor laisse des traces sur ton reseau sauf si tu te connectes via un wifi qui n’est pas le tien

[romain254]

@Clochette

Est d’utiliser une distribution live avec une persistance pour une utilisation de tous les jours … de surcroît sur un PC ou ni le firmware est à jour ni le système d’exploitation dessus (pas fini d’installer).
La distribution Tails redirige les connexion vers TOR, je ne crois pas qu’il y est de Naviguateur qui puissent facilement exploiter le port 443.

Où est le problème ?
Ça tournait depuis 2 ans et soudainement les gens de tails décident de prendre en considération les exigences de microsoft, je n’y suis pour rien.
Le navigateur ne pose pas de problème dans mon cas de figure, c’est la ligne de commande et gnome-firmware (je n’ai essayé que ces solutions) qui sont bloqués.

[romain254]

@anon3605821

tu t’es enquiquiné pour rien comme ca a été dit par ailleurs un debian live aurait ete aussi simple et tu aurais eu peut etre moins d’emdts pour la config initiale

Enquiquiné avec quoi ?
Quelle config initiale ?

[fran.b]

@romain254

Ça tournait depuis 2 ans et soudainement les gens de tails décident de prendre en considération les exigences de microsoft, je n’y suis pour rien.

Non, ça n’est pas Microsoft, c’est le système de secure boot (largement initié par Microsoft il est vrai). Tous les OS installés ont un système de mise à jour du bios EFI et des bases de données des certificats.
Le fil va dérapé mais Apple OS est à Windows ce que Windows est à linux. Là je me bas pour qu’une personne puisse exécuter un qemu avec accélération sur un Mac M1 aarch64. Pourquoi? Pour faire tourner une version arm64 de la clef APESAM. Impossible de démarrer un mac M1 sur un périphérique extérieur sans modifier la machine. La seule solution que j’ai trouvé est de lancer un qemu qui utilise le périphérique extérieur comme disque, le tout avec l’accélération HVF. Oui, mais pour utiliser cette accélération, il faut avoir la certification d’Apple (une après midi et je n’ai pas fini). Cette certification est payante sauf si on est une gentielle association qui sème la paix et le bonheur dans le monde (c’est notre cas ).
Donc en clair tu as une machine et tu ne peux PAS l’utiliser comme tu veux. Entre autres, l’installation de linux sur les mac ARM64 est quasi impossible à ce jour.
Les PCs standards ARM64 et les Raspberries boutent ss pbm (à vérifier, je n’ai pas bcp de recul)
PS: peut être à mettre ds pause café ça non?

[romain254]

Tu veux dire qu’il n’y a pas d’échappatoire à cette histoire de certificats ?
Je suis obligé d’y passer ?
Au final, existe t-il une solution pour libérer temporairement le port 443 ?
Merci.

[fran.b]

sudo iptables -F INPUT
sudo iptables  -F OUTPUT 
sudo iptables -F FORWARD
sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F PREROUTING
sudo iptables -F POSTROUTING

Si iptables n’existe pas, essaye xptables
C’est surtout les routing et output qui comptent

[droopy191]

Je vous suggère la lecture de cette explication complète de Zargos

Fonctionnement de secure boot Debian

En résumé, la chaine de boot sécurisée est
UEFI → Shim → Grub → kernel
Par défaut, seules les clés Microsoft sont présentes dans le bios/EFI . Celles ci expirent ( cf votre premier message). La première étape est de voir si le fabricant de votre carte mère fourni un bios/efi mise à jour avec ces clés ( pour un CM de plus de 5-6 ans, c’est pas évident).

Si ce n’est pas le cas, vous pouvez soit désactiver secureboot ou vous pouvez intégrer votre propre clé et signer kernel et module avec celle ci ( loin d’etre simple, et à faire à chaque maj).

[Zargos]

@droopy191

( loin d’etre simple, et à faire à chaque maj).

Mise à joru du BIOS précisément.

@droopy191

Par défaut, seules les clés Microsoft sont présentes dans le bios/EFI .

Microsoft et fournisseur de la carte mère.
Pour M$ c’est normal, c’est eux qui sont à l’origine de la techno.

@fran.b

Si iptables n’existe pas, essaye xptables

Ou bien directement nftables? Car si Tail est issu de Debian, c’est nftables au cœur du pare-feu.

Quand au port 443, il n’y a aucune corrélation en le Secure Boot et le protocole HTTPS. Je ne vois pas le rapport ici.

[romain254]

Bonjour,
j’ai déjà tenté de désactiver le secure boot, sans succès.

[romain254]

Bonjour,
merci pour ta réponse.
Cette suite de commandes me permettraient de pouvoir éliminer temporairement cette problématique de port 443 ?

Voilà la réponse que j’obtient de la part de la base de données :

sudo fwupdmgr refresh
[sudo] Mot de passe de amnesia :
Mise à jour lvfs
Téléchargement… [ - ]
Failed to download metadata for lvfs: failed to download file: Failed to connect to cdn.fwupd.org port 443 after 790 ms: Could not connect to server

Idem avec gnome-firmware :

Concernant iptables, voilà ce que j’ai pu trouver :

sudo iptables -L --line-numbers
**[sudo] Mot de passe de amnesia : **
Chain INPUT (policy DROP)
**num target prot opt source destination **
1 ACCEPT all – anywhere anywhere state ESTABLISHED
**2 ACCEPT all – anywhere anywhere **
3 ACCEPT tcp – 10.200.1.2 10.200.1.1 multiport dports 9050,951
4 ACCEPT tcp – 10.200.1.6 10.200.1.5 multiport dports 951
5 ACCEPT tcp – 10.200.1.10 10.200.1.9 multiport dports 951
6 ACCEPT tcp – 10.200.1.14 10.200.1.13 multiport dports 9050,951
7 REJECT all – anywhere 10.200.1.0/24 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP)
**num target prot opt source destination **
**1 ACCEPT all – anywhere anywhere **
**2 ACCEPT all – anywhere anywhere **

Chain OUTPUT (policy DROP)
**num target prot opt source destination **
1 ACCEPT all – anywhere anywhere state ESTABLISHED
2 ACCEPT icmp – anywhere anywhere state RELATED
3 ACCEPT tcp – anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match _apt
4 ACCEPT tcp – anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match proxy
5 ACCEPT tcp – anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match nobody
6 ACCEPT tcp – anywhere localhost tcp dpt:9050 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-upgrade-frontend
7 ACCEPT tcp – anywhere localhost tcp dpt:9062 flags:FIN,SYN,RST,ACK/SYN owner UID match htp
8 ACCEPT tcp – anywhere localhost tcp dpt:9062 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-upgrade-frontend
9 ACCEPT tcp – anywhere localhost tcp dpt:9063 flags:FIN,SYN,RST,ACK/SYN owner UID match tails-iuk-get-target-file
10 log_reject tcp – anywhere localhost tcp dpt:9063 flags:FIN,SYN,RST,ACK/SYN owner UID match amnesia
11 log_reject tcp – anywhere localhost tcp dpt:9052 owner UID match amnesia
12 ACCEPT tcp – anywhere localhost tcp dpt:9052 owner UID match root
13 ACCEPT tcp – anywhere localhost tcp dpt:951 owner UID match root
14 ACCEPT udp – anywhere localhost udp dpt:domain owner UID match amnesia
15 ACCEPT udp – anywhere localhost udp dpt:mdns owner UID match amnesia
16 ACCEPT udp – anywhere localhost udp dpt:domain owner UID match htp
17 ACCEPT udp – anywhere localhost udp dpt:mdns owner UID match htp
18 log_reject udp – anywhere localhost udp dpt:domain owner UID match _apt
19 log_reject udp – anywhere localhost udp dpt:mdns owner UID match _apt
20 ACCEPT udp – anywhere localhost udp dpt:domain owner UID match root
21 ACCEPT udp – anywhere localhost udp dpt:mdns owner UID match root
22 ACCEPT tcp – anywhere localhost tcp dpt:4101 flags:FIN,SYN,RST,ACK/SYN owner UID match Debian-gdm
23 ACCEPT tcp – anywhere localhost tcp flags:FIN,SYN,RST,ACK/SYN owner UID match amnesia
24 ACCEPT tcp – anywhere anywhere owner UID match clearnet
25 ACCEPT udp – anywhere anywhere owner UID match clearnet udp dpt:domain
26 ACCEPT tcp – anywhere anywhere owner UID match debian-tor tcp flags:FIN,SYN,RST,ACK/SYN state NEW
27 ACCEPT udp – anywhere anywhere owner UID match debian-tor udp dpt:domain
**28 lan all – anywhere 10.0.0.0/8 **
**29 lan all – anywhere 172.16.0.0/12 **
**30 lan all – anywhere 192.168.0.0/16 **
**31 log_reject all – anywhere anywhere **

Chain lan (3 references)
**num target prot opt source destination **
1 log_reject tcp – anywhere anywhere tcp dpt:domain
2 log_reject udp – anywhere anywhere udp dpt:domain
3 log_reject udp – anywhere anywhere udp dpt:netbios-ns
**4 ACCEPT all – anywhere anywhere **

Chain log_reject (8 references)
**num target prot opt source destination **
1 LOG all – anywhere anywhere LOG level debug uid prefix "Dropped outbound packet: "
2 REJECT all – anywhere anywhere reject-with icmp-port-unreachable

Merci.

[romain254]

@Zargos

Quand au port 443, il n’y a aucune corrélation en le Secure Boot et le protocole HTTPS. Je ne vois pas le rapport ici.

Bonjour,
je ne sais pas si c’est le cas mais le système me renvoie systématiquement la même erreur concernant le port 443 (cf. ma réponse précédente).
Merci.

[Zargos]

@romain254

je ne sais pas si c’est le cas mais le système me renvoie systématiquement la même erreur concernant le port 443 (cf. ma réponse précédente).

C’est un défaut de la configuration de ton système.

[fran.b]

Visiblement les commandes sudo n’ont pas efface tes règles iptables existantes
Bon fais un

Sudo iptables -I OUTPUT --dport 443 -j ACCEPT 

(Syntaxe à vérifier) Mais c’est curieux, les -F auraient dû tout effacer

[Zargos]

Vous êtes sur qu’il n’y a pas un UFW ou autre d’utilisé? car pour une distro de ce type, je doute que la ligne de commande soit la seule configuration possible.