rulururu

post Protéger (un peu) son identité sur le web

December 26th, 2013

Filed under: Sécurité — admin @ 4:19 pm

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!

    • 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.
  2. 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.
  3. 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”).
  4. Edit 2014-01-17 Pour gérer (effacer régulièrement) les Cookies Flash sur Firefox, l’extension BetterPrivacy
  5. 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

post TCP est mort

June 3rd, 2013

Filed under: Innovation — admin @ 10:39 pm

Mais on ne le sait pas encore :)
Pour vous en convaincre, je n’ai qu’un exemple : mosh (pour MObile SHell).
Je qualifierai Mosh de complément à ssh : il s’initialise bien sur TCP port 22, puis poursuit les communications, avec -je crois et j’espère- le même niveau de sécurité sur une (ou plusieurs) sockets UDP.

UDP lui apporte la réactivité dans la gestion des acknowledgments.

En résumé, il virtualise la session par rapport à la connnexion. Si la connexion expire ou disparaît, la session persiste et cherche/attend simplement un nouveau support de connexion.
Avantages immédiats :

  • Un keepalive permanent super dynamique, très pratique au niveau shell (je vois les caractères que j’ai tapés et que le serveur n’a pas encore confirmés, ils sont soulignés)
  • Je me déconnecte 1/2 h (genre sur mon PC via le téléphone en 3G, j’éteinds le téléphone et prends bien mon temps pour le rallumer), je reviens, mosh reprend immédiatement la main
  • Je change d’IP (dans le train, ou je switche de la 3G à un réseau wifi) ; je n’ai pas le sentiment de perte de session, pas besoin de me reconnecter.

Inconvénients :

  • le passage des firewalls, eh oui – mais mosh-server permet de choisir son port UDP ;), donc finalement, ce n’est qu’un port de plus à ouvrir
  • mosh ne gère pas [encore] du forward de ports

Ce que je n’ai pas mesuré :

  • Dans quelle mesure mosh augmente le volume de données échangées, avec tous ces ACKs UDP, par rapport à une session SSH traditionnelle

Sur des connexions qui perdent plus de 10% de datagrammes, TCP est terrible. Il double progressivement les retry, si bien que très vite, en n’ayant pas de chance et en perdant quelques paquets, la connexion peut se bloquer complétement pour très longtemps. Surtout avec une surcouche SSL.

Bref, vous doutez? Essayez mosh, vous serez bluffés ! En plus, il est déjà packagé debian (et même dans stable – pfff je suis en retard ou quoi ?).

La suite ? Pour les applis mobiles, hyper-réactives…vivement une implémentation de HTTP sans TCP, allez, UDP 80 ? :)

Que celui qui n’a jamais attendu 1/4 d’heure le chargement de Google Maps me jette la première pierre !

post Le Cloud et la Crise

October 5th, 2012

Filed under: Uncategorized — admin @ 12:20 pm

On vit en pleine “révolution” du cloud.

Plus simple, moins cher (dans la mesure où louer est moins cher que posséder, mais c’est un autre débat), permettant aux DSI de se dégager de nombreuses responsabilités juridiques, le Cloud a le vent en poupe.

Coté grand public, on surfe surtout sur la simplicité de partager [du rien] des “contenus”, à la Facebook.

DSIs, qu’adviendra-t-il de vos précieuses données quand la crise changera de forme ?

* Si la bande passante devient [beaucoup] plus chère, par exemple parce que les coûts de l’énergie explosent ?

* Si le pays qui héberge la société qui héberge vos données prend des mesures de restriction d’information à l’égard de votre pays ? (Rigolez pas, les iraniens sont privés de beaucoup de services internet en ce moment par exemple)

* Si la société qui héberge vos données est une start-up, elle dépend beaucoup de la résilience du système financier…

Plus j’y réfléchis, plus les Clouds, dans le principe et dans les implémentations, m’apparaissent comme des constructions complexes et fragiles. À l’opposé, il me semble que les évènements économiques, géopolitiques  que nous vivons semblent présager d’instabilité et vont nous demander de faire preuve de résilience.

La diminution de risques qu’ils induisent me semble être formelle, juridique, mais pas [du tout] pratique.

On verra bien, mais pour ma part je m’abstiens soigneusement de stocker en ligne quoique ce soit de précieux, confidentiel, sans de sérieuses précautions.

Conservez vos backups et plans de secours comme la prunelle de vos yeux ^^

 

post Un tableau

August 8th, 2012

Filed under: Uncategorized — admin @ 9:30 am

post Réduire l’exposition au spam

May 5th, 2011

Filed under: Sécurité — gryzor @ 3:18 pm

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

post Accéder à un site Internet en temps de crise

March 23rd, 2011

Filed under: Uncategorized — gryzor @ 6:17 pm

Il existe un système de miroirs dynamiques sur Internet permettant de visiter un site trop chargé. Il suffit d’ajouter au site visité le suffixe “nyud.net”.
Au hasard, en ces temps d’anxieté nucléaire, le site de la CRIIRAD est accessible ici : http://www.criirad.org.nyud.net/

En ce qui concerne les émanations radioactives, la CRIIRAD nous indique que les gouvernements réalisent un black-out sur les données de mesure déjà réalisées sur le sol américain, canadien, etc. et exige que ces données collectées avec de l’argent public soient fournies au public.

C’est ici : http://www.criirad.org.nyud.net/actualites/dossier2011/japon/11_03_23_Volet1der.pdf

post Spip et la sécurité

January 15th, 2011

Filed under: Sécurité — gryzor @ 5:02 pm

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

post La backdoor du FBI dans OpenBSD

December 19th, 2010

Filed under: Sécurité — gryzor @ 4:28 pm

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é…

post Technologies de vulnérabilités

October 26th, 2010

Filed under: Innovation,Sécurité — gryzor @ 10:54 pm

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é.
Microsoft constate une augmentation massive des attaques sur technologie Java.
(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

post Adieu, Socrate

July 30th, 2010

Filed under: Uncategorized — gryzor @ 1:11 pm

Socrate
Tu as été le meilleur des chats… Tous ceux que tu as approchés ont ressenti cette aura de bienveillance et de bien-être que tu dégageais.
Ce 29 juillet au matin, un chauffard a mis fin aux bonheurs quotidiens que tu nous apportais, alors que tu n’avais pas 2 ans.
Tes 9 vies n’ont pas suffi… Je sais que tu resteras irremplaçable et je te souhaite de reposer en paix. Je n’oublierai jamais ma petite usine à ronronner ; ton départ abrupt me laisse un grand vide.
Mon esprit sait bien qu’on ne te verra plus entrer dans la maison et te frotter aux chaises, et pourtant toujours je regarde le soupirail que tu aimais ouvrir, et qui reste fermé.

ruldrurd
Next Page »
Powered by WordPress, Web Design by Laurentiu Piron
Entries (RSS) and Comments (RSS)