Ce billet sera rafraichi au fil du temps, pour rester pertinent

Suivi des changements :

• 30 Oct 2017 : Première publication
• 10 Nov 2017 : Ajout du module CanvasBlocker
• 22 Nov 2017 : Remplacement du module Qwant for firefox ; suppression du module Privacy Settings ; remplacement de Random Agent Spoofer par AgentX
• 23 Nov 2017 : Ajout d’une section de configuration (remplace Privacy Settings)
• 28 Jan 2018 : Ajout d’une section de configuration (privacy.resistFingerprinting=true)
• 28 Jan 2018 : Remplacement de AgentX par Random User Agent
• 1er Mai 2018 : Référencement du module Neat Url
• 10 Sep 2018 : Ajout du paramètre disable_session_identifiers
• 24 Sep 2018 : Ajout de 9 paramètres de gestion de la télémétrie (about:config)
• 25 Sep 2018 : Ajout de la clé opt-out pour la télémétrie (about:config)
• 30 Sep 2018 : Ajout de clés de configuration (puny+privacy_level+dtmf+autres) (about:config)
• 2 octobre 2018 : Ajout de clés de configuration (about:config)
• 4 octobre 2018 : Ajout de clés de configuration
• 6 novembre 2018 : Ajout de clés de configuration (about:config)
• 27 décembre 2018 : Suppression de la clé de configuration “privacy.trackingprotection.storagerestriction.enabled” qui semble avoir disparu à partir de Firefox 63, je conseille de positionner network.cookie.cookieBehavior à la place
• 1er janvier 2019 : Ajout d’une clé de configuration (about:config)
• 21 octobre 2019 : Je dégage complétement Qwant, qui est inutilisable, n’est pas fiable, trace les User agent de ses utilisateurs, et s’autorise même à les bloquer.
• 21 octobre 2019 : Désactivation du DNS over HTTPS, qui envoie tout à cloudfare…(about:config)
• 13 novembre 2019 : Ajout d’une clé de configuration pour contrer les attaques de requêtes sur le cache (about:config)

EDIT du 21 octobre 2019 : je ne conseille définitivement plus d’utiliser Qwant
Qwant a semble-t-il décidé de bloquer les utilisateurs qui n’affichent pas un User-Agent qui lui plaît.
Plusieurs remarques quant à cette approche :

• Pour ma part, si j’utilisais Qwant, c’était en espérant que vous ne REGARDIEZ PAS spécialement mon User-Agent.
• Qu’est ce que c’est que cette approche de BLOQUER les utilisateurs qui ne vous plaisent pas? Cela fait PLUSIEURS JOURS que ça dure, et tout ce que vous avez à répondre, c’est ne pas rétablir le service et poster sur twitter des messages ridicules “On renouvelle nos excuses“. C’est pitoyable.
• Le présente post, que je maintiens, a pour but d’AIDER des utilisateurs NON TECHNIQUES à sécuriser leur vie privée. J’ai un peu l’impression d’avoir l’air d’un con : j’ai conseillé à des gens une solution qui NE MARCHE PAS. Pas 5 minutes, pas 1 heure, ça fait trois jours là. Le sujet s’arrête là. Qwant, tu dégages.
• Je ne veux pas dire, mais un User-Agent flottant, c’est précisément caractéristique d’utilisateurs qui essayent de protéger leur vie privée. VOUS ETES EN TRAIN DE BLOQUER VOTRE CIBLE!!!

Je conseille aux lecteurs de ce billet de supprimer l’extension QWANT, et de positionner Duckduckgo comme moteur de recherche par défaut.
Fin de l’édition du 21 octobre 2019

Je reprends la plume sur le sujet de la protection personnelle.
Comment, simples particuliers, pouvons-nous nous protéger au mieux des espionnages réalisés par les GAFA, et les CIA/NSA/FSB/BND/Échelon/DGSE/ToutCeQueVousVoulez ?

L’objectif de ce post est donc de rendre ces protections accessibles à des non techniciens, ou simplement à des personnes pas intéressées par la technique.
Si vous êtes un expert en sécurité, vous trouverez qu’on peut faire mieux, ou affiner. J’évite volontairement de mentionner ici des modules de sécurité très puissants mais demandant des connaissances approfondies du web, ou des interactions lourdes, à l’utilisateur.
Si vous voulez vraiment ne pas être espionné, n’allez pas sur Internet. Ces modules vous protègent du tout venant, c’est à dire que vous pouvez espérer échapper ou gếner avec ceci le marketting de base et les opérations de fliquage à grande échelle opérées sur l’ensemble de la population. Si vous êtes ciblés par une opération plus fine, je ne peux rien pour vous 🙂

Je commence par un avertissement : ces conseils sont fournis sans garantie… Je vous fais part de mes connaissances, du mieux que je peux, ni plus, ni moins. Tout ce que je présente ici, je l’utilise moi-même. 100% des préconisations livrées ici sont des logiciels libres, accessibles gratuitement et facilement. Le lecteur que vous êtes est en outre cordialement invité à me faire part de toute amélioration quant à ce contenu !

Le présent article concerne la navigation depuis un ordinateur. Pour se protéger depuis une tablette ou un smartphone, c’est assez proche, mais il existe parfois de subtiles différences, que je détaillerai peut être dans un autre article.

Voici donc :

1. Utilisez Firefox. Pas chrome, pas Internet Explorer

Pourquoi? parce que firefox, qui a beaucoup de défauts, a une qualité, c’est d’être open source. Ils peuvent faire de la saloperie, mais cela se verra. Les autres, c’est juste des boîtes noires. Les utiliser, c’est faire confiance aux GAFA, qui sont les premiers sur la liste des nuisibles qui adorent collecter pléthore de données personnelles.
Si vous utilisez n’importe quel autre navigateur open source, c’est très bien, et peut être mieux. Simplement, je parle de ce que je connais, alors mon focus ici sera sur firefox.

2. Voici un paquet de changements à réaliser sur Firefox.

Pour chacun, j’essaye d’expliquer pour le lecteur pressé en quelques mots le coeur de ce qu’elle apporte, puis les configurations que je préconise. Et je poursuis avec plus d’informations quand c’est pertinent.
ATTENTION : certaines de ces extensions nécessitent une configuration pour être efficaces. Lisez la suite du billet, ne vous contentez pas de les installer…
Il n’y a pas vraiment de priorités entre elles, je les trouve toutes indispensables et complémentaires même si je mets en premier :

Passons aux configurations et détails

• Cookie Autodelete

Cette extension va simplement, sur une base de temps régulière, effacer tous vos Cookies. C’est une opération de salubrité publique (et privée :-p ), et franchement, je ne comprends pas que ces fonctions ne soient pas intégrées à Firefox et activées par défaut. Le fait que Google finance Mozilla n’y est peut-être pas étranger.

L’extension met à disposition une liste blanche, à laquelle vous pouvez (et devriez) ajouter les quelques sites web où vous ne voulez pas revalider vos identifiants à chaque visite. C’est très simple d’ajouter un site en liste blanche, rendez-vous sur le site en question, clickez sur l’icone de l’extension et cliquez sur “+Liste blanche”, et c’est bon !

Voici ma configuration (le plus important est en haut : Activer le nettoyage automatique ? Délai avant nettoyage 1 minute.)



• Privacy Badger

Excellent module, écrit et maintenu par l’EFF. Ce module journalise les traçages réalisés par des sites “partenaires” des pages que vous visitez, et bloque ceux qui abusent. Le fonctionnement est détaillé ici.
La très grande force de ce module est qu’il n’a pas besoin de listes noires de bloquage, il apprend tout seul au fur et à mesure que vous naviguez, et détermine les tiers espions sur la base de leur comportement.
Ce module n’a pas besoin de configuration particulière pour bien fonctionner. Vous pouvez, si un site dysfonctionne, demander à privacy badger de ne rien bloquer pour cette page précise (je n’ai jamais eu besoin de le faire), en suivant le menu qui se déroule si vous cliquez sur l’icone.
L’installation du module est suivie d’un cheminement d’accueil et de présentation assez bien fait.

• uBlock Origin

uBlock Origin est également un filtre anti-traqueur et anti-publicité. Il se base pour sa part sur des listes noires, ce qui le rend assez complémentaire, de mon point de vue, de privacy badger. Il dispose d’une configuration assez extensible. Rendez-vous dans les paramètres du module, visitez a minima l’onglet “3rd-party filters”. J’y active tous les filtres “ublock” sauf Experimental, ainsi qu’Easylist, Easyprivacy, Fanboy’s Enhanced Tracking List, et les filtres spécifiques à la France marqués FRA.

• Decentraleyes

Ce module est très complémentaire des bloqueurs présentés ci-avant. Il annule tous les appels réseaux vers des bibliothèques Web très populaires, en renvoyant directement le contenu qu’il conserve en cache. Ceci évite nombre de requêtes vers des serveurs Google (ou autres), et donc autant de pistage. En pratique, cela ne bloque aucune fonction.

• HTTPS Everywhere

Ce module contient une liste de sites web qui fonctionnent en mode chiffré. Si vous essayez de naviguer sur l’un des sites qu’il connait, en omettant de commencer votre requête par “https”, il va le faire à votre place, afin de sécuriser votre connexion.

• Smart Referer

Ce module ajoute un peu de vie privée à l’en-tête “Referer” que votre navigateur envoie au site visité avec chacune des requêtes envoyées. Cela n’en a pas l’air, mais cela peut passer pas mal d’information à votre sujet.
Un peu de configuration est nécessaire pour ce module.
Voici ma configuration

• Random User Agent

Il s’agit simplement de modifier l’en-tête “User-agent” envoyé par Firefox quand il parle à un serveur.
Ce module est marqué comme obsolète (le 30 septembre 2018), mais fonctionne encore pour l’instant. Je lui trouverai un remplaçant s’il disparaît effectivement. On peut tester son efficacité en visitant : whatsmyos.com
Voici ma configuration :

Il change ainsi tout seul, aléatoirement, et vous pouvez si cela pose problème pour un site donné lui demander de le garder en liste blanche.
Si vous aviez installé AgentX, que je recommandais dans une version antérieure du présent article, je recommande de le remplacer par Random User Agent

• CanvasBlocker

Un nombre croissant de sites estiment avoir besoin d’identifier votre ordinateur de manière unique et répétable. Il s’agit d’une grave intrusion dans votre vie privée. Les cookies sont un moyen pour eux, ici, c’est une autre technique plus sournoise, qui fait réaliser des calculs complexes à votre ordinateur, dont le résultat est toujours propre à votre ordinateur, et répétable.
Ce module altère les appels réalisés, afin de retirer le caractère d’unicité et de répétabilité à votre ordinateur. Il s’agit donc d’un complément intéressant aux autres.
Ma configuration :


• Configuration Firefox

Ouvrez l’adresse : about:config dans la barre d’adresse de Firefox. Si un message vous demande d’être prudent, validez le.
Pour chaque entrée du tableau ci-dessous, changez la valeur. Il y a un formulaire de recherche qui permet de les rechercher rapidement.
Ce tableau reste ordonné par dates d’ajout. Quand j’ajoute des éléments, c’est toujours en bas.

Nom	valeur
media.peerconnection.enabled	false
media.peerconnection.turn.disable	true
media.peerconnection.use_document_iceservers	false
media.peerconnection.video.enabled	false
media.peerconnection.identity.timeout	1
privacy.trackingprotection.enabled	true
browser.cache.offline.enable	false
browser.safebrowsing.malware.enabled	false
browser.safebrowsing.phishing.enabled	false
browser.send_pings	false
browser.urlbar.speculativeConnect.enabled	false
dom.battery.enabled	false
dom.event.clipboardevents.enabled	false
geo.enabled	false
media.navigator.enabled	false
webgl.disabled	true
privacy.resistFingerprinting	true
Ajouts du 24 septembre 2018
toolkit.telemetry.updatePing.enabled	false
toolkit.telemetry.archive.enabled	false
toolkit.telemetry.bhrPing.enabled	false
toolkit.telemetry.server	https://adresse.inexistante.gryzor.com
datareporting.policy.dataSubmissionEnabled	false
toolkit.telemetry.firstShutdownPing.enabled	false
toolkit.telemetry.hybridContent.enabled	false
toolkit.telemetry.newProfilePing.enabled	false
toolkit.telemetry.shutdownPingSender.enabled	false
Ajouts du 30 septembre 2018
network.IDN_show_punycode	true
browser.sessionstore.privacy_level	2
media.peerconnection.dtmf.enabled	false
media.peerconnection.rtpsourcesapi.enabled	false
media.peerconnection.simulcast	false
geo.wifi.uri	https://adresse.inexistante.gryzor.com/
browser.search.geoip.url	https://adresse.inexistante.gryzor.com/
browser.safebrowsing.blockedURIs.enabled	false
services.sync.prefs.sync.browser.safebrowsing.downloads.enabled	false
services.sync.prefs.sync.browser.safebrowsing.passwords.enabled	false
browser.aboutHomeSnippets.updateUrl	https://adresse.inexistante.gryzor.com/
network.predictor.enabled	false
network.dns.disablePrefetch	true
network.http.speculative-parallel-limit	0
extensions.pocket.enabled	false
extensions.pocket.site	https://adresse.inexistante.gryzor.com/
extensions.pocket.api	https://adresse.inexistante.gryzor.com/
Ajouts du 2 octobre 2018
network.captive-portal-service.enabled	false
Ajouts du 4 octobre 2018
browser.search.geoSpecificDefaults.url	https://adresse.inexistante.gryzor.com/
browser.search.geoSpecificDefaults	false
pdfjs.disabled	true
Ajouts du 6 novembre 2018
network.trr.mode	5
network.trr.uri	https://adresse.inexistante.gryzor.com/
Ajout du 27 décembre 2018
network.cookie.cookieBehavior	3
Ajout du 1er janvier 2019
extensions.blocklist.enabled	false
Ajout du 21 octobre 2019
network.trr.mode	5
Ajout du 13 novembre 2019
browser.cache.cache_isolation	true

Note : je garantis que tant que je controlerai le domaine “gryzor.com”, l’adresse “adresse.inexistante.gryzor.com” restera non définie dans les DNS. Rien ne vous force à me croire, et vous devriez bien entendu positionner n’importe quel nom de domaine dont vous avez la certitude qu’il restera non défini ici, plutôt que le mien. Utiliser “https://mozilla.invalid/” par exemple si vous faites confiance à la RFC 2606 qui réserve le suffixe .invalid comme jamais résolu.

[Ajouté le 25 septembre 2018] Il faut également en créer:
(Pour créer une valeur, faire “clic droit” puis “Nouvelle” puis (par exemple) “valeur booléenne”).

Nom	type	valeur
security.ssl.disable_session_identifiers	booléen	true
toolkit.telemetry.coverage.opt-out	booléen	true
extensions.fxmonitor.enabled	booléen	false

• Neat URL

Ce module retire des morçeaux d’URLs (configurables), quand ils correspondent à des trackers bien connus, tel que Urchin (racheté par Google). Je l’utilise sans altérer sa configuration par défaut.
Il s’agit d’un vecteur de traçage d’activités supplémentaire, que ce module combat.

PS : Oui, ce billet est fastidieux à lire, et croyez-moi, l’écrire m’a demandé pas mal de temps. Je ne doute pas qu’il vous prenne plusieurs dizaines de minutes pour appliquer ces paramètrages sur votre ordinateur. Simplement, nous n’avons plus les moyens, en 2017, d’ignorer ces espionnages et l’impact à grande échelle qu’ils ont sur notre vie privée et au final sur nos libertés.

«Notre liberté repose sur ce que les autres ignorent de notre existence» — Soljenitsyne

par Dell Cameron – le 19 septembre 2018 – source gizmodo.com

Illustration: Dell Cameron (Gizmodo)

Faire l’acquisition d’un robot aspirateur peut ressembler à une super bonne idée. Non mais c’est vrai, qui aime passer l’aspirateur? Mais si l’appareil en question était présenté comme connecté à l’internet, disposant d’un microphone et d’une caméra, et se déplaçant à volonté dans votre domicile à toute heure du jour, peut-être que vous y penseriez à deux fois.

Des chercheurs de Positive Technologies ont découvert deux vulnérabilités dans un modèle d’aspirateur robot – et ils soupçonnent que ces vulnérabilités affectent d’autres modèles, qui pourraient permettre à un pirate de prendre le contrôle du robot, et de l’utiliser pour espionner son propriétaire – ou d’enregistrer des vidéos au moyen de la caméra embarquée, ce qui s’annonce bien pratique : ce modèle de caméra voit même dans le noir.

Par chance pour cette fois, pour infiltrer l’appareil, les chercheurs indiquent que l’attaquant devra avoir déjà pénétré le réseau, ou disposer d’un premier accès physique à l’aspirateur. Pour le dire plus simplement, il faudrait probablement qu’un pirate s’en prenne à vous personnellement [jusqu’au jour où cette attaque sera ajoutée dans un kit et répandue automatiquement par rebond via d’autres piratages, NdT].

Il reste que ce problème illustre les exemples innombrables, qui voient des appareils de l’internet des objets, équipés de caméras et de micros, achetés et installés par vous-même dans votre maison, constituent un risque considérable du point de vue du respect de votre vie privée. Alors, à tout considérer, après tout, prendre le risque de voir enregistré ce que vous vous autorisez à dire dans un cadre privé, ainsi que tous mouvements qui pourraient être jugés non acceptables une fois publiés, réalisés par vous dans ce que vous estimiez être la sécurité de votre foyer, peut-être bien que c’est un peu cher payé pour ne pas passer l’aspirateur soi-même.

Le modèle d’aspirateur directement concerné dans cette instance est le “Diqee”, équipé d’une caméra appelée “360”, elle-même fabriquée à Dongguan, en Chine. Comme nous l’avons reporté, l’une des attaques possibles qui a été découverte permet une exploitation à distance, qui peut être utilisée pour détourner l’usage de l’appareil et en faire un “microphone à roulettes”, selon Positive Technologies. La seconde vulnérabilité, qui semble ne pouvoir être exploitée qu’au travers d’un accès physique à l’aspirateur, est activable par l’insertion d’une carte microSD dans le port de mise à jour du robot, disent les chercheurs.

Apparemment, aucune sécurité ne limite l’accès au logiciel dès lors que vous disposez d’un accès physique à l’aspirateur. Toujours selon Positive Technologies, il est très facile techniquement de mettre à jour le micrologiciel en y ajoutant un script, qui permettrait d’intercepter, par exemple, tout le trafic circulant sur le réseau de votre maison. À ce stade, vous pouvez même commencer à vous poser la question suivante – qu’est ce qui est pire : se faire enregistrer à son insu chez soi par une caméra, ou bien voir capturer à son insu chez soi son historique de navigation? (Nous posons cette question sans jugement de valeur).

Positive Technologies déclare à Gizmodo avoir suivi la procédure de notification standard et avoir notifié Diqee du problème constaté. Ils ne savent pas, cependant, si les vulnérabilités ont été corrigées par une mise à jour, ou si les propriétaires de robots aspirateurs ont été prévenus.

Diquee n’a pas répondu à notre demande de commentaire.

Si vous vous sentez concerné par cette sorte de menace, vous devriez chercher un robot aspirateur qui ne dispose pas du tout de wifi. Ou tout simplement acheter un aspirateur “pas robot” [En plus, c’est moins cher, NdT].

Ce billet est un simple mémo, contenant des points techniquement évidents, mais qui échappent à beaucoup d’utilisateurs.

Si vous n’y comprenez rien et suivez simplement les quelques conseils proposés ici, vous pouvez espérer que la sécurité de vos connexions au web et la protection de votre identité seront améliorées (ou pas!).

Note : cette liste ne se prétend en aucun cas exhaustive (ni efficace, d’ailleurs). Si l’aimable lecteur a des améliorations à apporter, je prends les contributions avec joie !

Un peu de charabia pour commencer :

1. Les navigateurs dits modernes envoient plein de données à leur éditeur “pour vous rendre service”. Ces fonctions sont souvent activées par défaut. Rappelons que Chrome est édité par Google, et que Firefox est financé par Google… Aussi ces deux navigateurs ont tendance à aller requêter à tout va les serveurs de la firme.
2. Votre navigateur, par défaut, laisse n’importe quel site poser des Cookies. Ce comportement par défaut est très dommageable. Même un site que vous ne visitez pas directement (un hébergeur de publicité, par exemple) se retrouve à traquer vos comportements sur le Net. Il est également connu que la NSA (pour ne citer qu’elle) utilise les cookies de tiers pour nous traquer. Mon opinion est que nous ne pouvons plus, en tant qu’utilisateurs, laisser les cookies s’infiltrer à volonté dans nos navigateurs. Mis à part quelques domaines qu’il appartient à chacun de choisir, nous devons les refuser, ou, plus intelligemment, limiter drastiquement leur durée de vie.
3. Certains sites proposent du HTTPs, mais vous laissent surfer en HTTP non chiffré, par défaut.
4. Les navigateurs (et beaucoup de sites) activent javascript, qui est un langage complet coté client. Mais c’est le serveur que vous visitez (et parfois, un site partenaire) qui envoie à votre nagitateur le code à executer, ce qui pose des problèmes de sécurité.
5. Edit 2014-01-17 Flash pose ses propres cookies, en dehors du champ de vision du navigateur

Voici donc mes bonnes pratiques (les numéros correspondent aux menaces ci-dessus) :

1. Un peu de configuration propre au navigateur pour commencer.
   • Sur Firefox, dans la fenêtre de Préférences (ou Options), l’onglet Sécurité présente :
     • Bloquer les sites signalés comme étant des sites d’attaque
     • Bloquer les sites signalés comme étant des contrefaçons

     Pour ma part,je décoche toujours ces deux options, que je considère comme invasives!

   • Coté Chrome/Chromium, on a l’équivalent dans les préférences (il faut déployer les Préférences avancées…) :
     • Utiliser un service Web pour résoudre les erreurs de navigation
     • Utiliser un service de prédiction afin de compléter les recherches et les URLs saisies dans la barre d’adresse
     • Prédire les actions du réseau pour améliorer les performances de chargement des pages
     • Activer la protection contre le phishing et les logiciels malveillants

     À mes yeux, chacune de ces options est équivalente à “envoyer des requêtes chez nous pour traquer chaque caractère que vous tapez au clavier“, alors pour moi, c’est non merci!

2. • Sur Firefox, installez Cookie Monster. Il s’agit du module le plus pratique et le moins gênant que j’ai trouvé pour protéger mes cookies. Pensez à interdire les cookies par défaut, dans les options du module. Si le manque de cookie est un problème pour certains sites, on peut dès lors les autoriser un à un, temporairement ou définitivement, via un simple clic sur l’icône présentée par l’extension. Pensez aussi à supprimer tous les cookies existants, au moment de l’installation du module, via la fenêtre d’options principale de Firefox.
   • Coté Chrome/Chromium,l’extension Vanilla Cookie Manager est tout simplement excellente, et constitue à mes yeux la référence : elle accepte tous les cookies, mais limite leur durée de vie à la session de navigation ; et elle maintient une whitelist de domaines pour lesquels on accepte des durées plus longues. Ce fonctionnement sollicite finalement très peu l’utilisateur, fournit les fonctionnalités qui dépendent souvent de l’acceptation de cookies, et réalise automatiquement un grand nettoyage à chaque redémarrage du navigateur.
3. Disponible pour Chrome, Firefox et Opera, et complétement transparente à l’utilisattion, HTTPS-everywhere active HTTPs sur les [grands] sites connus pour proposer HTTPs en parallèle de HTTP.
4. Est-il encore nécessaire de présenter Noscript, le module qui bloque par défaut Javascript, et le réactive (temporairement ou définitivement) sur base de whitelist ? Un must, même si beaucoup d’utilisateurs non avertis peuvent le trouver lourd à l’usage (effet “j’active javascript sur tous les sites que je visite”).
5. Edit 2014-01-17 Pour gérer (effacer régulièrement) les Cookies Flash sur Firefox, l’extension BetterPrivacy
6. Pendant que j’en suis à enfoncer les portes ouvertes, Adblock Plus est une évidence… Je crois qu’elle est disponible pour tous les navigateurs cités dans ce billet. Edit 2014-02-04 Penser aussi à étendre la liste de patterns d’Adblock plus, cela se fait tout simplement en ligne, avec easylist. Je pense qu’ajouter EasyPrivacy ainsi que peut être Fanboy’s Social Blocking List est un bon début !

Note : pour ceux qui veulent déprimer, voir ceci : HTTP Client Identification Mechanisms

Une idée simple : nombre de serveurs sont en ligne pour des utilisations autres que de la messagerie SMTP.
Ces serveurs sont appelés à envoyer quelques emails par jour au maximum, par exemple pour des tâches planifiées comme logcheck, ou de la supervision basique.
Chaque serveur consiste cependant en une réserve de ressources pour les spammeurs, qui adorent exploiter, entre autres, les vulnérabilités web, pour installer leur backdoor et relayer leur spam.
Dès lors, une contre mesure préventive très simple : sans attendre d’être la cible d’une attaque, chaque administrateur peut très simplement limiter à une poignée le nombre d’emails qui peuvent sortir chaque jour.
Sous Linux, cela ressemblerait à quelque chose comme :
iptables -t filter -A OUTPUT -p tcp –dport 25 -m limit –limit 12/d –syn -j ACCEPT
iptables -t filter -A OUTPUT -p tcp –dport 25 –syn -j REJECT

Penchons nous sur un test, avec un oeil orienté “sécurité”, du célèbre CMS spip.
Je teste donc la version 2.1.8. Lors de l’installation, spip m’indique que quelques répertoires doivent offrir au processus “apache” les droits en écriture. Ce n’est pas délirant, dans la mesure où la publication se fait en ligne : je vais y injecter des images, etc.
J’applique donc la règle du “privilège le plus faible” traditionnelle des systèmes de fichiers unix : j’assigne à ces repertoires le groupe apache, et en accordant à ce groupe les droits en écriture :
chgrp www-data IMG/ tmp/ local/ config/
chmod g+w IMG/ tmp/ local/ config/
L’installation terminée, je crée une rubrique, un article, et j’y colle une photo pour voir le résultat.
Le résultat, le voici : une image est bien ajoutée dans le répertoire IMG/ avec les droits en 666.
De nombreux fichiers de spip sont automatiquement passés en droits 666 ou 777, dans les installations par défaut. Y compris des fichiers PHP executés par le serveur web.
Franchement, ça fait peur.
J’ai trouvé une solution simple : remettre un chmod global à une valeur plus saine de manière globale pour spip.
Éditez votre fichier ecrire/mes_options.php, et posez-y le code suivant :
define(‘_SPIP_CHMOD’, 0770);
ou mieux
define(‘_SPIP_CHMOD’, 0570);
Le serveur web aura ainsi les droits de lire les fichiers, et son groupe les droits de lire et modifier ces fichiers.

Je reste tout de même estomaqué de voir un logiciel aussi populaire faire la bêtise monumentale du “chmod 777”, qui est comme chacun le sait réputée pour être la bêtise traditionnelle du newbie.
Pour référence, en sécurité, on ne doit JAMAIS positionner les droits 666 ou 777 sur un fichier, c’est une hérésie, et on a TOUJOURS une meilleure solution. La littérature à ce sujet ne manque pas : commencer par cet article sur la Séparation des privilèges

Et voici la nouvelle crise majeure de sécurité de l’information.
Le FBI est accusé d’avoir fait implanter une ou plusieurs backdoors dans la pile de chiffrement IPSEC d’OpenBSD.
10 années après les faits supposés, le responsable de cette opération se déclare délié de l’accord de confidentialité qu’il avait signé et en fait part à Theo de Raadt.

Plusieurs points intéressants :
* Ces allégations sont invérifiables. Du code de ce type est éminemment complexe à écrire et à auditer (cf la faille Debian SSH, énorme et restée béante pendant plusieurs mois). Une équipe s’est mise à auditer le code en question, mais qu’en conclure si ils trouvent des problèmes ? Cela pourrait aussi bien être un bug. Ils peuvent aussi bien ne pas en trouver, cela ne prouvera pas l’absence de faille.

* Ces allégations sont parfaitement crédibles. La pile IPSEC d’OpenBSD était la première implémentation ouverte (à code source ouvert et réutilisable), et a donc été reprise par de nombreux systèmes. Cela en faisait a priori une cible de choix.

* Surtout : une fois le code complétement audité : qui pourra certifier que cette stack IPSEC est enfin sûre ? OpenBSD est déjà réputé pour être l’un des systèmes les plus audités du monde ; une scrutation de plus est-elle de nature à changer quoi que ce soit à la confiance que l’on peut apporter à la sécurité de ce système ? De ce point de vue, cette crise est un non-événement, car elle ne change rien à cet état de fait.

Open source ou pas, la question de la confiance dans les systèmes de chiffrements – et dans la sécurité des systèmes en général – est de nouveau posée. Ce ne sont certes pas les audits réalisés dans les cadres légaux (comme les critères communs) qui y répondront!

Salutations enfin au courage de Theo de Raadt, qui sait parfaitement que faire pour assurer la confiance à moyen et à long terme. À défaut de certitudes sur la sécurité de l’OS, voici de quoi étayer une conviction sur les intentions de ceux qui gèrent ce projet.

Je vois une sortie de crise, qui à défaut d’être complète, serait intéressante : que Monsieur Gregory Perry publie toutes informations en sa possession sur ces fameuses failles intentionnelles. Personne ne pourra dès lors le traitera de menteur ; on pourra au plus douter qu’il ait tout divulgué…

L’insécurité a son marché, et ses phénomènes d’adoption, analysables de manière très proche à celle dont on considère l’adoption d’une technologie de produits par le marché.
.
(Source : arstechnica )
Le marché de l’insécurité s’étant structuré, les exploits se vendent, s’industrialisent et se propagent très rapidement. On est vraiment très loin des auteurs de virus “sympa” des années 90.
Cette fois-ci, Java est en cause. Tout simplement parce qu’il est devenu universel, installé partout, et en particulier des systèmes Desktop aux terminaux mobiles en tous genres y compris les téléphones dits intelligents, en passant par les serveurs web. Et parce qu’il est, semble-t-il, vraiment facile à attaquer. Et ce qui tourne dans une machine virtuelle Java est bien loin de la couche d’analyse des antivirus.
Java dispose de toutes les qualités requises : la puissance d’un language complet, la difficulté pour les administrateurs de comprendre les tenants et aboutissants en terme de sécurité, un panel d’applications écrites par tout un chacun sans la moindre notion de ce qu’est la sécurité. Et j’oubliais, Java et ses failles sont portables.
Considérons Java du point de l’utilisateur moyen, et regardons les processus à suivre en cas de découverte d’une faille critique dans les versions installées. L’utilisateur doit mettre à jour :
– son ordinateur de bureau
– son téléphone portable
– sa voiture / son gps
– sa webcam, son alarme de maison, …
– bientôt, son frigo
– et j’en oublie
Il peut également tenter de s’assurer que les services en ligne critiques qu’il utilise sont à jour.
Et je ne parle pas du niveau moyen et de la sensibilité à la sécurité du développeur web moyen sur technologie Java.
Quand Java aura été corrigé (est-ce vraiment faisable? je ne suis pas bien placé pour le savoir), ou en tous cas quand le marché se sera doté d’outils pour protéger un peu mieux ses applications Java, nul doute que ce marché de l’insécurité passera à une nouvelle technologie. Pourquoi pas pdf? Notoirement, pdf est un language très puissant, et encore très facile à attaquer. Son tour viendra sur le marché de l’insécurité de masse.
[Edit] : Adobe en est bien conscient, qui annonce le sandboxing de son reader pdf

Il y a un peu plus d’un an, nous avons été frappés par la fameuse faille OpenSSL sur les systèmes Debian.
Pour résumer rapidement, l’espace de définition des clés de chiffrement s’est trouvé réduit de plusieurs milliards de milliards à 32767. Donc, si vous disposiez d’une clé SSL vulnérable, je n’avais que 32767 essais (maximum) à faire pour usurper votre identité sur votre système.

De manière assez curieuse, cette faille est restée très longtemps (presque 2 années!) en production sans que personne ne s’en aperçoive.

Cet article propose une chose que nous aurions pu faire avant (et que nous pouvons faire aujourd’hui) pour détecter ce problème beaucoup plus rapidement. Il s’agit simplement de s’appuyer sur l’audit public. Cette proposition est particulièrement pertinente pour l’utilisation de OpenSSH, mais doit probablement pouvoir s’élargir à d’autres usages.

Voici la proposition : modifier OpenSSH (ou OpenSSL?) pour qu’il compare chaque nouvelle clé publique reçue avec les clés déja connues. Si la clé reçue est la même qu’une clé déja connue, prévenir l’utilisateur.

Voilà, c’est tout.

Bien entendu, certaines personnes (et moi le premier) utilisent la même clé sur plusieurs systèmes. Les personnes qui font cela savent qu’ils le font, et ne seront pas perturbées par l’avertissement. En revanche, quand il s’agira d’une clé fraichement générée, je pense qu’il serait particulièrement intéressant d’être au courant que c’est la même clé.

Voilà, avec un tel système, je pense que 15 jours après la mise en production de la faille OpenSSL, la communauté se serait rendue compte que quelque chose ne tournait pas rond. Mieux vaut tard que jamais, je propose donc de modifier les outils pour lesquels ce type de process peut améliorer la sécurité (pour moi, au minimum, c’est le cas pour OpenSSH).

Les crédits de cette idée vont à X. Desurmont PhD.

Le monde de la sécurité web est impressionnant. Il regorge d’attaques parfois bien tordues, et difficiles à comprendre, et une fois de temps en temps, on nous “découvre” une nouvelle technique. Cette fois-ci c’est CSRF. Le point particulier de ce genre d’attaque, c’est qu’il n’y a rien de nouveau à savoir, n’importe qui ayant fait un tout petit peu de web la maîtrise déja… mais jusqu’ici sans le savoir. Bref, si cela doit démontrer une chose, c’est que personne ne maîtrise [plus] la sécurité du web.

Le point le plus amusant avec CSRF, c’est qu’il s’appuie sur une fonctionnalité fondamentale du web, présente depuis les version les plus antiques de HTTP : la possibilité d’inclure et d’adresser des éléments depuis d’autres sites web. Depuis quelques années, nous nous moquons des institutions dont les avocats ont créé une charte Internet qui interdit la création de liens hypertextes ou l’inclusion d’image ou d’autres objets sans leur accord. Avec CSRF, la question se pose : et s’ils avaient eu raison ?!

La plupart des projets développés en Logiciels Libres s’appuient sur des communautés de développeurs, qui se créent et évoluent au fil du temps selon les intérêts et talents de chacun. La méritocratie à la base de la constitution de ces communautés est-elle bien suffisante pour garantir l’intégrité des développeurs qui rejoignent un projet ?

Il semble que les projets LL disposent de peu de critères objectifs et stricts pour décider d’accorder à un contributeur des droits d’écriture sur tout ou partie du code. Les système simplement basés sur le vote des membres en place sont attaquables, par exemple par des attaques sociales. Un attaquant peut tâcher de devenir sympathique aux yeux de quelques membres clés, et cela peut suffire, en manifestant sa présence sur un salon IRC, et en envoyant les bons patches au bon moment…

Mettons nous à la place de vendeurs de Logiciels propriétaires/privatifs, qui n’ont pour certains eu de cesse ces derniers temps que de décrier les Logiciels Libres pour défendre leur bifsteak. Les moyens mis en oeuvre par ces acteurs sont parfois douteux, comme on le voit plus ou moins couramment lors de certaines campagnes de lobbying auprès d’institutions politiques. Ces vendeurs/éditeurs disposent de moyens colossaux, et peuvent vouloir nuire à tel ou tel projet, voire vouloir discréditer le Logiciel libre dans son ensemble. Si j’étais à leur place, je considérerais que payer des “taupes” pour infiltrer des projets et y semer du code dormant sur la durée pourrait être un moyen relativement efficace de parvenir à mes fins.

À la place, notamment, des distributions Linux, je me méfierais.

Suggestions :

• Formaliser un délai minimum et incompressible entre les premiers contacts avec un développeur et son admission au titre de commiteur
• Formaliser une politique sur le volume de code envoyé avant de gagner le moindre droit de commit
• Formaliser une procédure de parrainage
• Exiger une preuve d’identité de chaque développeur (et pourquoi pas un jour mettre en place une liste noire centralisée d’indésirables ?)

Aucun de ces moyens ne suffit à garantir l’intégrité d’un développeur, mais leur application conjointe pourrait ralentir considérablement les agissements d’un attaquant.