Pourquoi tous les gestionnaires de mots de passe sous forme d'extension pour navigateur web ne se valent pas ?

• Certains injectent leur interface utilisateur (tu sais, le bouton dans un formulaire qui permet de copier l'identifiant et le mdp) codée en JavaScript dans le contenu de chaque page web que tu visites, ce qui autorise ces dernières à dérober des mots de passe en contournant les sécurités mises en place par les navigateurs web ;
  
  
• D'autres communiquent avec leurs autres composants (genre la base arrière, le gestionnaire de mots de passe lui-même) sans authentifier le pair, ce qui permet aux sites web d'exécuter du code de leur choix genre lancer tel logiciel présent sur ta machine.

L'auteur considère que les gestionnaires de mots de passe mal codés cassent les bienfaits de la compartimentation : il y a plusieurs niveaux de privilèges dans un navigateur web, et les mauvaises extensions mettent nos secrets dans le niveau le plus faible.

C'est loin d'être théorique, l'auteur a émis plusieurs rapports de bugs concernant plusieurs gestionnaires de mots de passe.

On notera que les problèmes soulevés sont conceptuels / fondamentaux, ils concernent plusieurs extensions. Comment discerner celles concernées ? 1) affiche-t-elle une icône / un menu / autre dans le contenu des pages web ? 2) apparaît-elle dans l'onglet Sources de l'onglet Débogueur des outils de développement de Firefox ? Si oui à l'une de ces questions, alors l'extension est vulnérable.

J'utilise l'extension PassFF, frontal pour le gestionnaire de mots de passe Pass. Après vérification, elle est vulnérable à ce type d'attaques. Un autre frontal, l'extension browserpass, n'est pas vulnérable.

Via Aeris.

Dans un annuaire Active Directory, et dans l'implémentation libre Samba, DFS permet de mettre en place des alias sur les lecteurs partagés, d'unifier derrière un même nom des partages réseau stockés sur des serveurs de fichiers différents. Exemple : smb://nas.masociete.example/compta et smb://nas.masociete.example/direction : un même nom, mais, en réalité, les données sont stockées sur deux serveurs. Encore mieux : la syntaxe smb://nas.masociete.example/<NOM_UTILISATEUR> peut envoyer deux utilisateurs différents sur deux serveurs de fichiers différents.

La table des correspondances est stockée dans la machine qui a le rôle DFS, qui n'est pas forcément le contrôleur de domaine.

La machine qui joue le rôle DFS effectue uniquement la redirection, les transferts de données ne passent pas par elle. Dit autrement : un ss sur un poste de travail montrera une connexion SMB entre cette machine et le véritable serveur de fichiers, pas entre elle et la machine DFS.

Cas d'usage ?

• Migrer plus facilement les utilisateurs lors du remplacement d'un serveur de fichiers. Sans DFS (ni alias DNS), tu dois migrer utilisateur par utilisateur ou service/équipe par service/équipe (car tous les membres d'un service montent souvent les mêmes lecteurs réseaux), en passant sur chaque poste de travail pour changer l'adresse du/des lecteurs partagés (ce qui rend impossible une migration "tout en une nuit"), ce qui est galère, surtout avec le télétaff, et ce qui nécessite une synchronisation entre l'équipe qui migre le stockage et l'équipe qui paramètre les postes de travail ;
  
  
• Masquer l'infrastructure de stockage aux utilisateurs. Sans DFS, si l'on veut les rendre autonomes pour monter leurs lecteurs réseaux, il faut leur donner le nom du serveur et le nom du partage, voir pondre un bout de site web qui leur donne ces infos. #Compliqué.

Merci Rémi de nous avoir appris et mis en place cela.

Ici, nous utilisons snoopy. Packagé dans Debian GNU/Linux.

Avantages : un nom cool + pas besoin de ré-inventer la roue + contrairement à la méthode Octopuce, snoopy fonctionne en présence d'un hook preexec pour bash dont je me sers pour peupler mon agent SSH.
Inconvénient : par défaut, snoopy journalise également les actions d'origine non humaine (CRON, démon, tâche de fond, etc.), mais y'a moyen de définir des filtres dans sa configuration.

On peut aussi parvenir au même but avec psacct et acct.

Un prestataire me dit qu'il est possible de monter un même espace de stockage en mode bloc depuis plusieurs machines avec le protocole réseau ISCSI.

Je sais que ce n'est pas possible : ISCSI permet de monter un disque dur distant comme s'il était branché à la machine locale, pas de le partager. ISCSI = bus de données SCSI over Internet.
Mais bon, sur le moment, un peu de crédulité…

Mon collègue, qui a plus de connaissances que moi en stockage, me dit que ça paraît louche. Il teste quand même. Deux machines GNU/Linux montent, via ISCSI, un même espace de stockage de test hébergé sur notre NAS. Résultat : les données écrites depuis une machine n'apparaissent pas de l'autre côté. Il faut démonter/remonter l'espace de stockage pour voir les fichiers créés.

Discussion à trois avec notre prestataire, étonné : « ben avec VMware vSAN, ça marche : 5 hyperviseurs importent bien le même bloc de stockage ».

Mon collègue me dit alors que c'est normal : l'espace de stockage doit être formaté avec VMFS, le système de fichiers de VMware qui est un système de fichiers pour disque partagé.

Le monde du libre a ses systèmes de fichiers pour disque partagé : OCFS2, GFS2. Guiguiabloc nous illustre une utilisation d'OCFS2 (avec de jolis schémas).

Attention à ne pas confondre les systèmes de fichiers pour disque partagé avec les systèmes de fichiers répartis (CephFS, GlusterFS, RozoFS, etc.) dans lesquels les données sont… réparties et répliquées sur plusieurs machines.

Merci Alex de m'avoir appris tout ça.

Tuto sur comment migrer, sans (trop) d'interruption de service, un MariaDB dont les structures binaires de données sont corrompues.

On (re)découvre :

• perconabackup pour des sauvegardes BDDs au format binaire et innobackupex pour les utiliser pour créer un clone du serveur MariaDB ;
  
  
• GNU parallel pour paralléliser l'exécution d'une boucle for d'un script shell ;
  
  
• eatmydata, une bibliothèque de fonctions qui inhibe les appels systèmes fsync(), sync() (qui demandent au noyau d'écrire les données sur le support de stockage ‒ et pas uniquement en cache ‒ ce qui accélère grandement l'import / la restauration / la réparation).

bind() un service réseau sur une adresse IP que l'on n'a pas (dans une configuration "reprise sur panne" avec keepalived, par exemple) sans écouter sur toutes les adresses et les interfaces (avec « :: » et « 0.0.0.0 ») ?
Les paramètres de Linux « net.ipvX.ip_nonlocal_bind » sont là pour ça.

Je découvre le multipath ISCSI qui permet de redonder l'accès à un espace de stockage exporté au format bloc avec le protocole réseau ISCSI. Ainsi, il est possible d'avoir deux chemins réseaux totalement distincts (câbles différents, routage différent, etc.) ou même deux têtes logicielles sur un même NAS utilisées simultanément (c'est d'ailleurs le support Dell qui nous a obligé à mettre en place le multipath ISCSI avant la mise à jour logicielle de notre NAS Unity XT).

Avec Debian GNU/Linux 10, on installe le paquet logiciel multipath-tools (device-mapper multipath), un p'tit fichier /etc/multipath/multipath.conf, on découvre/login avec iscsiadm (comme d'hab) puis on monte /dev/mapper/mpathX-partY au lieu de /dev/sdX.

Merci Alex de m'avoir appris cela (et de l'avoir mis en place).