Le Blog de Genma

Comment sauvegarder son Raspberry Pi ?

jeudi 1 janvier 1970 à 01:00

Il existe différentes façons de sauvegarder son Raspberry Pi. Il y a la sauvegarde des "données" (si on l'utilise comme serveur multimédia ou autre) et la sauvegarde du système en lui-même. La stratégie de sauvegarde ne sera guère différente de celle que l'on adoptera dans le cas d'un PC.

Sauvegarde classique

On peut faire un script basé sur rsync, qui sera mis en tâche cron par exemple, et qui sauvegardera/copiera les données modifiées de façon régulière sur un disque externe. Vu la taille, une clef USB branché sur le Raspberry pi peut suffire. Attention, cela ne protègera pas contre un problème du Raspberry pi. Vu que la clef est branchée dessus, elle peut-être corrompue (par un problème matériel, logiciel). Idéalement, on fera une copie/sauvegarde supplémentaire sur un emplacement autre (disque dur réseau par exemple).

Sauvegarde de type dump

La taille de la carte SD étant assez petite, on peut envisager de faire un dump (via dd) régulier de la carte SD sur un disque dur autre. Dans ce cas, il faut éteindre le Raspberry, sortir la carte SD, la mettre dans un autre ordinateur et on en fait un dump complet. Là aussi, on pourra faire un script pour automatiser le dump (avec la date dans le nom par exemple). L'avantage est que l'on a une vraie sauvegarde/copie, mais l'inconvénient majeur est que le Raspberry est indisponible le temps du dump. Et que l'on n'aura pas une sauvegarde temps réel.

Conclusion

Idéalement, on combinera les deux : une sauvegarde dump par semaine et une sauvegarde classique quotidienne, sur les données changeantes (à définir selon l'usage que l'on fait de son Raspberry Pi).

A lire sur le même sujet
Les articles tagués Sauvegarde
Les articles tagués Raspberry Pi

Sur les signatures et vérifications par clef

jeudi 1 janvier 1970 à 01:00

Ce texte est une traduction de la page On Digital Signatures and Key Verification du projet Qubes (Présentation du Qubes OS Project).

Ce texte est un complément à mon tutoriel Comment vérifier l'intégrité d'un fichier que l'on télécharge ?

Début de traduction

Ce que les signatures numériques peuvent et ne peuvent pas prouver

La plupart des personnes - même les développeurs - sont confus sur les concepts de base que sous-tendent les signatures numériques. Par conséquent, la plupart des gens devraient lire cet article, même si cela semble trivial à première vue.

Les signatures numériques peuvent à la fois prouver l'authenticité et l'intégrité à un degré raisonnable de certitude. L'authenticité garantit qu'un fichier donné a bien été créée par la personne qui l'a signé (c'est à dire, qu'il n'a pas été modifié par un tiers). L'intégrité garantit que le contenu du dossier n'a pas été falsifiés (par exemple, qu'un tiers n'a pas modifié de façon indétectable son contenu en cours de route).

Les signatures numériques ne peuvent pas prouver autre chose, par exemple, que le fichier signé n'est pas malveillant. En fait, il n'y a rien qui pourrait empêcher quelqu'un de signer un programme malveillant (et cela arrive de temps en temps dans la réalité).

Le point est, bien sûr, que les gens doivent choisir en qui ils auront confiance (par exemple, Linus Torvalds, Microsoft, le projet Qubes, etc) et supposer que si un fichier donné a été signé par un tiers de confiance, alors il ne devrait pas être malveillant ou des contenir des erreurs énormes. Mais la décision de faire confiance à un tier donné est au-delà de la portée des signatures numériques. Il s'agit plus d'une décision politique et sociologique.

Une fois que nous prenons la décision de faire confiance à certains tiers/personnes, les signatures numériques sont utiles, car elles permettent que nous limitons notre confiance uniquement aux quelques tiers que nous choisissons et nous n'avons donc pas à nous soucier de toutes les "mauvaises choses qui peuvent arriver en cours de route" entre nous et le tiers, par exemple, avec des cas de compromission de serveur (Qubes-os.org va sûrement être compromise un jour), via un membre malveillant au sein de la société d'hébergement, du fournisseur d'accès, dans le cadre du piratage du Wifi... etc

En vérifiant tous les fichiers que nous téléchargeons et qui prétendent avoir été émis par le tiers auquel nous avons choisi de faire confiance, nous éliminons toutes préoccupations liées aux mauvaises choses évoquées ci-dessus, car nous pouvons facilement détecter si des fichiers ont été falsifiés (et par la suite choisir de s'abstenir de l'exécution, de l'installation ou de l'ouverture de ces fichiers corrompus).

Toutefois, pour les signatures numériques aient sens, nous devons nous assurer que les clés publiques que nous utilisons pour la vérification de signature sont en effet celles d'origine. N'importe qui peut générer une paire de clés GPG en prétendant qu'elles appartiennent au "Le projet Qubes," mais bien évidemment, seule la paire de clés que nous (c'est à dire, les développeurs Qubes) avons généré est légitime. La section suivante explique comment vérifier la validité des clés de signature de Qubes.

Importation Qubes clés de signature

Chaque fichier publié par le projet Qubes (rpm, tgz, dépôts git) est signé numériquement par l'une des clés de développeur ou de livraison de version. Chacune de ces clés est signé par la clé de signature du Qubes Master (0x36879494).

La clé publique principale peut être téléchargé à partir d'un serveur de clés, par exemple :

gpg - recv-keys 0x36879494
 
 
 Pour plus de sécurité, nous publions également l'empreinte digitale de cette clé maîtresse ici dans ce document:
 
 
 pub 4096R/36879494 2010-04-01
 Empreinte de la clé = 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3e 3687 9494
 uid Qubes Master Signing Key
 
 
 Il devrait également y avoir une copie de cette clé sur le site principal du projet, ainsi que dans les archives des listes de diffusion développeurs et utilisateurs du projet.
 
 Une fois que vous avez téléchargé et vérifié l'empreinte digitale de la clé de signature du Master, vous devez importer cette clé et définir son niveau de confiance à "ultime" (oh, bien), de sorte qu'elle puisse être utilisé pour vérifier automatiquement toutes les clefs des développeurs :
 
 
 gpg - edit-key 0x36879494
 puis : confiance, 5, y, q


Maintenant, vous pouvez facilement télécharger l'une des clefs d'un développeurs ou de livraison de version, qui aura été utilisé pour signer un fichier particulier de type rpm, tgz, ou tag git. Par exemple :
$ Gpg - recv-keys AC1BF9B3
 $ gpg --recv-keys AC1BF9B3
 gpg: requesting key AC1BF9B3 from hkp server keys.gnupg.net
 gpg: key AC1BF9B3: public key "Qubes OS Release 1 Signing Key" imported
 gpg: no ultimately trusted keys found
 gpg: Total number processed: 1
 gpg: imported: 1 (RSA: 1)
 
 
 Vous pouvez également télécharger toutes les clefs des développeurs actuellement utilisées (et aussi une copie de la clé maîtresse) à partir du répertoire des clefs sur notre serveur:
 http://keys.qubes-os.org/keys/
 
 Les clés des développeur sont configurés pour n'être valable qu'1 an seulement, alors que la clef Master Qubes n'a pas de date d'expiration. Cette dernière clé a été générée et est conservée dans une machine dédiée, déconnectée et isolée, et la partie privé (espérons-le) ne quittera jamais cette machine isolée.
 
 Vous pouvez maintenant vérifier l'ISO correspond à sa signature:
 
 $ gpg --verify Qubes-R2-rc1-x86_64-DVD.iso{.asc,}
 gpg: Signature made Sun 20 Apr 2014 10:06:13 BST using RSA key ID 0A40E458
 gpg: Good signature from "Qubes OS Release 2 Signing Key"

La clé utilisée pour signer ce ISO doit être signé par la clé principale Qubes :
$ gpg --list-sig 0A40E458
 pub 4096R/0A40E458 2012-11-15
 uid Qubes OS Release 2 Signing Key
 sig 26CA2CD7 2013-02-26 [User ID not found]
 sig C55BCFE3 2014-02-20 [User ID not found]
 sig 36879494 2012-11-15 Qubes Master Signing Key
 sig 3 0A40E458 2012-11-15 Qubes OS Release 2 Signing Key
Vérifier le code source de Qubes
 Les développeurs qui récupèrent le code de notre serveur Git doivent toujours vérifier les tags sur la dernière validation. Toutes les commits qui ne sont pas suivis par une étiquette signée ne devraient pas être de confiance !
 Pour vérifier une signature sur une étiquette de git, vous pouvez utiliser la commande :
$ Git tag-v 
Fin de traduction
 A lire également :
 Présentation du Qubes OS Project).
 Comment vérifier l'intégrité d'un fichier que l'on télécharge ?


      Source : http://genma.free.fr/?Sur-les-signatures-et-verifications-par-clef

Sur les signatures et vérifications par clef

jeudi 1 janvier 1970 à 01:00

Ce texte est une traduction de la page On Digital Signatures and Key Verification du projet Qubes (Présentation du Qubes OS Project).

Ce texte est un complément à mon tutoriel Comment vérifier l'intégrité d'un fichier que l'on télécharge ?

Début de traduction

Ce que les signatures numériques peuvent et ne peuvent pas prouver

Importation Qubes clés de signature

La clé publique principale peut être téléchargé à partir d'un serveur de clés, par exemple :

gpg - recv-keys 0x36879494
 
 
 Pour plus de sécurité, nous publions également l'empreinte digitale de cette clé maîtresse ici dans ce document:
 
 
 pub 4096R/36879494 2010-04-01
 Empreinte de la clé = 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3e 3687 9494
 uid Qubes Master Signing Key
 
 
 Il devrait également y avoir une copie de cette clé sur le site principal du projet, ainsi que dans les archives des listes de diffusion développeurs et utilisateurs du projet.
 
 Une fois que vous avez téléchargé et vérifié l'empreinte digitale de la clé de signature du Master, vous devez importer cette clé et définir son niveau de confiance à "ultime" (oh, bien), de sorte qu'elle puisse être utilisé pour vérifier automatiquement toutes les clefs des développeurs :
 
 
 gpg - edit-key 0x36879494
 puis : confiance, 5, y, q


Maintenant, vous pouvez facilement télécharger l'une des clefs d'un développeurs ou de livraison de version, qui aura été utilisé pour signer un fichier particulier de type rpm, tgz, ou tag git. Par exemple :
$ Gpg - recv-keys AC1BF9B3
 $ gpg --recv-keys AC1BF9B3
 gpg: requesting key AC1BF9B3 from hkp server keys.gnupg.net
 gpg: key AC1BF9B3: public key "Qubes OS Release 1 Signing Key" imported
 gpg: no ultimately trusted keys found
 gpg: Total number processed: 1
 gpg: imported: 1 (RSA: 1)
 
 
 Vous pouvez également télécharger toutes les clefs des développeurs actuellement utilisées (et aussi une copie de la clé maîtresse) à partir du répertoire des clefs sur notre serveur:
 http://keys.qubes-os.org/keys/
 
 Les clés des développeur sont configurés pour n'être valable qu'1 an seulement, alors que la clef Master Qubes n'a pas de date d'expiration. Cette dernière clé a été générée et est conservée dans une machine dédiée, déconnectée et isolée, et la partie privé (espérons-le) ne quittera jamais cette machine isolée.
 
 Vous pouvez maintenant vérifier l'ISO correspond à sa signature:
 
 $ gpg --verify Qubes-R2-rc1-x86_64-DVD.iso{.asc,}
 gpg: Signature made Sun 20 Apr 2014 10:06:13 BST using RSA key ID 0A40E458
 gpg: Good signature from "Qubes OS Release 2 Signing Key"

La clé utilisée pour signer ce ISO doit être signé par la clé principale Qubes :
$ gpg --list-sig 0A40E458
 pub 4096R/0A40E458 2012-11-15
 uid Qubes OS Release 2 Signing Key
 sig 26CA2CD7 2013-02-26 [User ID not found]
 sig C55BCFE3 2014-02-20 [User ID not found]
 sig 36879494 2012-11-15 Qubes Master Signing Key
 sig 3 0A40E458 2012-11-15 Qubes OS Release 2 Signing Key
Vérifier le code source de Qubes
 Les développeurs qui récupèrent le code de notre serveur Git doivent toujours vérifier les tags sur la dernière validation. Toutes les commits qui ne sont pas suivis par une étiquette signée ne devraient pas être de confiance !
 Pour vérifier une signature sur une étiquette de git, vous pouvez utiliser la commande :
$ Git tag-v 
Fin de traduction
 A lire également :
 Présentation du Qubes OS Project).
 Comment vérifier l'intégrité d'un fichier que l'on télécharge ?


      Source : http://genma.free.fr/?Sur-les-signatures-et

Les métadonnées des mails

jeudi 1 janvier 1970 à 01:00

Rappel sur les métadonnées

Les révélations de Snowden ont montré que la NSA et d'autres services d'espionnage utilisaient et stockaient avant tout les métadonnées, qui permettent de savoir qui parle avec qui, d'avoir des données de géolocalisation etc. J'ai parlé dans différents articles de ce que sont les métadonnées, de comment les effacer, je liste donc lesdits articles ici et vous renvoie vers eux :
Comment votre PC vous trahit ? Les Metadata...
Nettoyer les métadonnées avec MAT
Slides sur les métadonnées - numéro 64 et suivantes

Les métadonnées des mails

Dans un billet de son blog Dattaz analyse les métadonnées sur un mail qu'il a reçu,(je tire d'ailleurs l'illustration suivant de ce billet) et y fais la réflexion suivante Note : les métadonnées sont des données servant à définir ou décrire une autre donnée quel que soit son support, dans le cas présent par quel serveur passe le mail. / !\ On peut par exemple connaitre l'adresse IP d'un expéditeur grâce aux métadonnées d'un mail si le serveur ne l'a pas supprimé. Inutile de vous dire que tout mail envoyé avec une adresse mail SFR envoie aussi dans les métadonnées l'adresse IP d'expédition, avec en supplément l'adresse IP locale…bien pour la vie privée..

Avec un simple ctrl+u sur un mail que l'on a ouvert dans Thunderbird, il est donc possible de voir l'ensemble des métadonnées qui sont habituellement cachées, car non utile dans le cadre d'une correspondance par mail. Ces données sont importantes et peuvent s'avérer préjudiciables voire vous trahir. Que peut-on faire contre ça ?

Que faire contre ça ? TorBirdy

Une des solutions est d'utiliser TorBirdy. TorBirdy est une extension en cours de développement (encore au stade beta et donc sans aucune garantie) qui vient ajouter à Thunderbird et dont le but est de faire transiter les mails sortants et entrants via Tor. Par conséquent, TorBirdy protège votre vie privée en offusquant certaines métadonnées pouvant fuiter par les e-mails (comme les adresses IP source par exemple).

TorBirdy modifie également l'heure d'envoi des e-mails pour les mettre en UTC (+0000) à la place de votre fuseau horaire local, empêchant ainsi de donner une information importante, à savoir votre région/zone géographique d'habitation (qui est aussi une métadonnée qui peut s'avérer importante et utile dans certains cas).

TorBirdy nécessite que Tor tourne (ce qui peut être fait en lançant en parallèle le Tor Browser bundle) et n'interdit pas de chiffrer ses mails avec GPG, bien au contraire. L'expéditeur, le destinataire et le sujet du message resteront en clair, mais la provenance et le corps du message seront masqués/inaccessibles car chiffrés pour un observateur extérieur.

Les liens :
TorBirdy sur prism-break.org
TorBirdy sur le site du projet Tor
TorBirdy sur le site des extensions Mozilla.

Conservation d'adresses IP

jeudi 1 janvier 1970 à 01:00

C'est le billet de Greg @Cappadocius sur Twitter Des outils de traque où il dit j'ai de nouveau pléthore d'information : les adresses IP, le navigateur utilisé,… qui m'a fait me pencher sur mon propre blog. Cela fait un moment que j'ai enlevé les traqueurs du site depuis un moment, pour pour être cohérent avec mes préoccupations aux sujets du respect de la vie privée

Mais en fouillant un peu dans le contenu d'administration de SPIP, j'ai pu constaté que quand on commente sur le blog, les métadonnées associées aux commentaires sont stockées dans la base de données. Je demande un mail (pratique pour contacter des personnes qui ont fait un commentaire pertinent), mais je ne fais aucune vérification sur la validité du mail, un pseudo et un message (et ce ne sont même pas là des champs obligatoires). Etant donné la popularité relative du blog, je n'ai pas besoin de mettre de captcha, j'ai un plugin qui gère assez bien les spams, je mets les commentaires en mode "modéré a priori : votre contribution n'apparaîtra qu'après avoir été validée par un administrateur du site."

La table spip_forum contient donc entre autres, le champ auteur, le mail mais le plus important 'adresse IP de la personne ayant posté le message. C'est bien pratique pour bloquer des spammeurs (en ajoutant les adresses IP dans la zone DenyFrom du fichier .htacess d'Apache). Mais dans le cas d'une personne peu au fait des problématiques liées à l'anonymat sur Internet, j'ai potentiellement son mail et surtout l'adresse IP de la personne. Et je sais donc potentiellement à quelle heure et où se trouvait la personne..., et ce si, bien sûr, elle n'a pas utilisé Tor, un pseudo à usage unique (ou un autre décorrélé de ceux qu'elle utilise habituellement), un mail jetable...

Un grand pouvoir entraîne de grandes responsabilités.

Je sais bien qu'à chaque fois que l'on va sur un site web, on laisse une trace de son adresse IP dans les logs. Mais il faut être administrateur de la machine pour le voir. Là, c'est n'importe quel administrateur du CMS (le système de gestion du blog). Je suis seul administrateur, j'ai confiance en SPIP et je fais régulièrement les mises à jour de sécurité, mais je suis hébergé sur les pages persos de Free.fr, je ne sais pas à quel point c'est sécurisé de ce côté. Et j'ai donc accès des données assez personnelles auxquelles je ne souhaiterais pas avoir accès.

Pour la publication d'un message répréhensible par la loi, vu que comme je le disais, la publication des messages n'apparaissant qu'après ma validation, l'auteur est donc "moi" et c'est donc moi qui portera(it) la responsabilité des propos. Pas besoin de remonter à l'auteur via son IP par exemple... Il faudrait que je creuse le sujet sur la responsabilité de la publication, le fait que je conserve des IP et la possibilité de désactiver ça dans SPIP. A suivre donc.

A lire Des outils de traque sur le blog l'Antre du greg.