Yves a écrit 404 commentaires

Oui, sans hésitation.
C’est la norme dans quelques administrations françaises et grandes entreprises où j’ai travaillé.

Le principe est simple :

• Le navigateur (IE, Firefox…) connaît les autorités de confiance habilitées à valider un certificat de site web.
• L’entreprise/administration établit au sein du groupe un poste de travail standard, dans lequel le(s) navigateur(s) intègrent une « autorité de confiance » interne (gérée par l’IT du groupe).
• Quand tu visites un site, ça passe par le proxy-MITM du groupe, qui ne fait que te répondre (signé avec un certificat généré à la volée et authentifié par l’autorité de confiance interne) ce que le vrai site a répondu. Si tu ne regardes pas le certificat, c’est complètement transparent.

Pourquoi faire ça ? Tout simplement pour la « sécurité », la surveillance, etc.
Historiquement, les entreprises aiment bien regarder ce qui entre et sort du réseau interne, pour vérifier que ça ne parle pas de jeu, de boursicotage, de sites sociaux… bref tout ce qui pourrait faire perdre en productivité. Tout cela se fait sous couvert (en partie justifié) de « sécurité » : audit, lutte contre la fuite de données, etc.
Avec SSL puis TLS, c’est plus compliqué. MITM et le DPI sont vus comme des solutions à ce genre de difficulté.

Triste conclusion des actualités…
Merci Mozilla pour la poursuite des efforts et la maintenance de ce navigateur au service de ses utilisateurs.
Merci aux rédacteurs pour cette page d’information.

« Chacun voit midi à sa porte », comme on dit (heure d’hiver ou d’été, je laisse chacun décider :-p )

Pour ma part, sachant qu’une faille logicielle a déjà failli m’atteindre, sur un logiciel en lequel j’avais pleinement confiance (exim), sur une distribution en laquelle j’avais pleinement confiance (Debian stable + màj. securité), et sachant que derrière il y a toute ma vie en scan (revenus, impôts, etc.), en mails, etc., je mets du coup la barre assez haut.

Tout d’abord, je te remercie pour ton commentaire nuancé et constructif :-)

Je voulais juste donner une anecdote amusante sur l’absence de réseau (avec un lien pour les plus curieux), et non m’étendre sur les détails, qui sont un peu hors-sujet, mais bon… je vais essayer de donner quelques précisions… Il faut par contre garder à l’esprit que c’est un projet en cours (non achevé).

De base, dans ma DMZ, à quelques exceptions près, l’accès sortant à Internet est bloqué. Et ce, par un paramétrage nftables qu’aucun service systemd n’a le droit d’altérer.

— Du côté de HAProxy, en cible, il y aura une isolation de namespace filesystem (comme un chroot) donc aucun accès à du contenu. À ce jour, il n’y a que de la protection par l’obscurité : HAProxy ne « sait » tout simplement pas où sont les rares données accessibles en DMZ (mais ça n’est pas si difficile à deviner). Comme tu l’as souligné, ça apporte un certain degré de sécurité mais ce n’est pas idéal…

=> En cas de faille permettant de faire exécuter par HAProxy un binaire quelconque, ce dernier n’aura sur le principe rien à communiquer avec l’extérieur, et s’il pourra peut-être recevoir des requêtes, il ne pourra en revanche pas en émettre.

— Du côté de Nginx, seules les sockets-Unix exposées servent à communiquer avec l’extérieur : recevoir des requêtes et y répondre. C’est le résultat d’un effort en cours pour retirer tous les accès réseau à Nginx ; à ce stade, je devrais pouvoir prochainement mettre en place une véritable isolation par namespace réseau, ce qui est ma cible.

=> En cas de faille permettant de faire exécuter par Nginx un binaire quelconque, ce dernier ne pourra pas utiliser le réseau, et n’aura de toute façon que peu de données accessibles.

— Php-fpm m’ennuie davantage… l’accès au réseau est restreint de manière similaire, mais il est plus délicat de mettre en place des restrictions sans aller jusqu’à ségréguer les applications PHP…

Hors DMZ, mais accessible depuis celle-ci, non ?

Oui, dans la « SafeZone » (hors-DMZ), on a accès aux données sensibles. Le point important est surtout que les logiciels qui y sont, et sont donc plus sensibles, ne sont pas directement exposés sur Internet : Nginx (en DMZ) agit en proxy et limite les possibilités de créer des paquets sur-mesure pour déclencher des bugs. Ça n’est pas entièrement sûr, mais ça l’est davantage qu’un accès direct ou par simple redirection de port.

Bref, tu as l’air de déjà le savoir : la sécurité n’est pas un interrupteur qu’on active ; c’est un millefeuille où chaque couche participe… et est insuffisante. Le choix du « nombre de feuilles » au millefeuille est un équilibre à trouver entre le risque, le coût de mise en œuvre et le coût d’une faille.
Comme je fais ce projet dans un but d’apprentissage en plus de son utilité immédiate, pour ma part, tant que ça reste 100% automatisé (ansible), ça me va ;-)

Nginx a 3 sections de configuration :

• une pour le contenu HTTP, en écoute sur (je simplifie) /run/http ;
• une pour le contenu HTTPS, en écoute sur /run/https ;
• une pour le contenu HTTPS accédé depuis une IP de confiance ou une IP ayant port-knocké le bon « mot de passe », en écoute sur /run/https+.

Sur la DMZ, nftables gère le port-knocking et redirige sur un port interne spécifique en cas de port-knock réussi ; j’ai donc 3 ports HTTP(S), sur lesquels haproxy est en écoute.

Outre la gestion de quelques subtilités (type tunnel), haproxy se contente en gros de rediriger le traffic HTTP sur /run/http, le traffic HTTPS sur /run/https, etc. (je ne détaille pas les divers paramétrages systemd)

Ainsi :

• haproxy a accès au réseau mais à aucun contenu,
• nginx a accès au contenu (non-sensible) mais pas au réseau,
• pour le contenu sensible, nginx doit faire appel a un service back-end hors DMZ, par exemple Nextcloud qui tourne sur un uwsgi.

C’est en tout cas plus compliqué. En quoi est-ce plus sûr ?

Je comprends bien qu’en l’absence de carte réseau virtualisée l’OS invité n’en dispose plus et donc n’a plus, en théorie, de réseau.
Finalement, c’est un peu la même chose avec les espaces de nommage réseau.

Il me semble en fait que tu pars du principe qu’un programme malveillant pourra contourner l’isolation de son espace de nommage (et donc accéder à l’espace de nommage réseau de l’hôte), mais qu’une telle chose est impossible dans une VM… Il me semblait pourtant que des programmes malveillants avaient été observés, qui contournaient l’isolation de la VM pour accéder à l’hôte.

Plus de détails m’intéressent, si tu as des liens.

Anecdote amusante à ce sujet : sur mon serveur auto-hébergé, je suis probablement un des rares individus de la planète à faire tourner son serveur web (nginx) sans accès au réseau !

Depuis qu’une backdoor a failli s’installer sur mon serveur il y a quelques années via une faille d’Exim dans Debian (je n’y ai échappé que parce que j’avais monté ma partition noexec), je suis devenu un peu parano au niveau sécurité… Mais il y a encore pire que moi :-D

C’est simple : on appâte le chaland avec un prix imbattable, puis une fois qu’on l’a capturé, on lui fait payer le renouvellement bien plus cher… mais bon, qui a envie de s’embêter à changer une fois que tout fonctionne… Et donc, ça marche.

C’est exactement pareil que les offres du type :

Seulement 10€/mois ! (*)

(*) pendant 2 mois, puis 50€/mois.

Le plus dangereux, ce n’est pas ceux qui connaissent ou ceux qui ne connaissent pas.

C’est ceux qui croient connaître. C’est pratiquement une règle universelle…

Ah, peut-être pas, c’est vrai. Tout va bien, alors :-)

Et à part ça, s’être marié le jour de la bascule de 1999, c’est quand même une coïncidence amusante !

La correction est-elle du niveau du firmware ou du software ?
En gros, je me pose la question, pour OSMAnd, de savoir si on doit attendre une mise à jour Android, ou OSMAnd…

Démarche intéressante. Il est vrai qu’IPv6 change la donne à ce niveau. Mais encore faut-il que ton PC soit allumé quand tu n’es pas chez toi… Et un PC, c’est gourmand comparé à un petit serveur dédié et pas cher ;-)

Certes. Après, c’est son journal, que tu n’es pas obligé de lire. Il ne s’agit pas d’une dépêche…

C’est la meilleure synthèse de cette question que j’ai vue jusqu’à présent (du moins pour les « individus », pas pour les entreprises).

Et pourtant, un bémol quand même : rien ne nous oblige à faire notre pause-repas à 12h UTC. Le fait que notre journée ne soit pas organisée symétriquement autours du repas de « mi-journée » n’a donc aucune incidence sur le choix du fuseau horaire.

Au final, l’impact du choix du fuseau horaire n’est qu’administratif : révision des horaires d’ouverture des lieux divers, horaires de trajets, etc. ; et donc également financier.

Ce qui me paraît le plus logique est l’heure ± solaire (celle du fuseau dans lequel on est), mais notre société s’organise sur des critères financiers et non logiques.

Quand à la solution UTC-pour-tous, elle est simple et attirante (et supprime le saut de jour actuel à la longitude 180°), mais soulève évidemment la question du choix de la référence universelle : pourquoi UTC ? Les américains voudrons certainement CST, les chinois je ne sais pas…

Ah… OK je comprends.

D’ailleurs, paradoxalement, je trouve que côté compta, c’est pas terrible sur Linux, en tout cas en disposition BÉPO : certains logiciels (LibreOffice, Gnucash, d’autres ?) sont… hyper-pointilleux dans le respect de la langue française. Du coup, si je saisis 9.81 sur le pavé numérique, c’est considéré comme invalide parce que j’aurais dû saisir 9,81 :-(

Pour le côté DIY, c’est pas faux :-)

Et pourtant, si, ça sert.
Là, on ne parle pas d’afficher en temps réel un jeu 3D, mais simplement d’effectuer un dépannage en ouvrant à distance un Firefox, un Thunderbird, un Gnucash, un Keepass, une quelconque appli de tableau de bord…
Ça fonctionne encore.

Sans me prononcer sur la taille que représentent 400 personnes, je suis cependant d’accord avec Ysabeau sur le fait que le mode de communication de Wikimedia ne passe pas… Je ne saurais dire pourquoi. Un décalage culturel peut-être.

Compta ?? Pas compris…

J’explique : il est fréquent qu’un mot de passe contienne des chiffres, et dans ce cas là, l’endroit le plus accessible sur un clavier complet, c’est le pavé numérique. Je vois tout le monde autour de moi utiliser le pavé numérique ainsi.

Alors, oui, les français sont particulièrement touchés, mais il ne sont pas les seuls, car AZERTY n’est pas limité à la France. De plus, les ordinateurs portables sont concernés aussi, en taille 17″ ou supérieure.

Et il ne faut pas négliger la part de marché importante des PC un peu anciens, des gamers, bref… tous ceux qui pour une raison ou une autre utilisent un PC fixe.

Probablement pas.
Avant, le filtrage en entreprise, en gros c’était : HTTP ça va ; FTP, SMTP, IMAP, XMPP, etc. refusés. Et HTTPS… c’est compliqué, alors oui ou non selon là où on bossait.

Puis 2 choses sont arrivées :

1. Le contenu HTTP s’est mis à migrer vers HTTPS, et au lieu d’avoir HTTPS pour les banques et autres sites « sérieux » (c’était en fait un préjugé), on s’est mis à avoir HTTPS pour tout, y compris les loisirs, sites sociaux, etc.

2. HTTP(S) s’est mêlé de la messagerie avec les webmails, du transfert de fichiers directement en HTTP, de la messagerie instantanée (et assimilée : Facebook, etc.), des jeux, des bureaux distants, et j’en passe.

Les administrateurs de réseau n’ont donc pas eu d’autre choix que d’inspecter le HTTP et le HTTPS, pour savoir si c’est du HTTP normal ou de la messagerie (ex-SMTP/IMAP), ou du transfert de fichiers (ex-FTP), ou encore autre chose…

Oui, c’est ça. Dans les cas que je rencontre, ça marche bien. Je combine souvent avec le bit “s” sur le groupe principal.

Il est vrai que dans d’autres cas d’usage (notamment avec des fichiers qui se promènent beaucoup), il peut y avoir le problème que les ACL sont appliquées à la création, pas en cas de déplacement de fichier…

Avec parfois des conséquences : chez mon FAI (Bouygues), si je me connecte au SMTP depuis chez moi, j’ai 2 possibilités:

1. soit le port 25 de manière anonyme (ils vérifient juste que c’est une de leurs lignes DSL) ;
2. soit le port 587 authentifié.

A priori, j’aurais tendance à préférer le second, qui a en outre l’avantage de fonctionner aussi depuis pas-chez-moi. MAIS :

1. sur le port 25, je peux envoyer ce que je veux, notamment les mails de mon propre nom de domaine, en mode « smarthost » d’Exim ;
2. sur le port 587, seuls les alias@bbox.fr sont acceptés, sinon : « Sender address rejected: not owned by user monAdresseBouygues@bbox.fr »

Mouai… sauf qu’à cause de ça les sysadmins se sont vite rendus compte qu’il y avait tout et n’importe quoi en HTTP, et du coup on a maintenant droit à du « deep packet inspection » et à du MITM officiellement installé en proxy. Génial.

Auto-activé sur la page de login ? Comment as-tu fait ?

J’ajoute un 3ème problème : Quand le « compositeur » Wayland plante (peut-être à cause du driver graphique, je n’en sais rien… en tout cas, ça arrive), eh bien toute la session plante et on se retrouve sur la page de login. Avec X11, quand le window manager plante, on perd les décorations de fenêtre pendant quelques secondes, puis le window manager redémarre et tu continues comme si de rien était (j’ai d’ailleurs observé ce même comportement sur Windows…).

++ sur ta remarque concernant les CSD !
Autre cas où c’est pénible : les contrôles d’une fenêtre qui ne répondent plus lorsque l’application ne répond plus (surcharge temporaire ou plantage).

Et ? Le fait que ce soit le résultat d’un processus politique n’a rien à voir avec le fait que je trouve ça dommage, regrettable.
Quant au moinssage de mon précédent message, j’avoue ne pas le comprendre : il semble que nous soyons d’accord, au fond…