Avec l'expansion pandémique (le terme est à la mode de "services" comme Google Analytics, les moyens de se prémunir des SpyWebs prennent de plus à en plus d'importance. Et si des outils comme adBlock offre une très protection locale efficace, la protection d'un réseau dans son entier ne peut se passer de privoxy, un proxy filtrant aux possibilités étonnantes et disponible sur beaucoup de systèmes de Windows à Linux en passant par AmigaOS.

Protéger ses données exposées par apache n'est pas toujours évident et comporte quelques pièges qui donnent une illusion de sécurité alors qu'il n'en est rien. Ce tutoriel ne va pas, loin de là, couvrir tous les aspects du sujet, mais juste tenter d'apporter quelques bases permettant de se protéger à travers quelques cas pratiques.

Il y a quelques temps, j'ai reçu sur mon adresse personnelle (et ultra-secrète), l'invitation d'une amie pour un "réseau social" (un machin pour vous remettre avec d'anciennes relations en contact...) dont je tairais le nom plus par manque d'intérêt que par peur de poursuites.

Après petite enquête, j'ai appris que cette amie s'était juste inscrite pour tester et n'avais jamais, par manque de temps, donné suite. Cependant, comme pas mal d'autres services (à la con) du même genre, ce site ne devait prendre toute sa puissance qu'après avoir fournit soit le mot de passe d'un compte WebMail (Yahho, GMail, AOL, etc..), soit avoir copié directement, et à la main, les précieuses adresses dans la zone prévue à cet effet. La justification de cette requête assez étrange est de permettre au site de retrouver les personnes déjà inscrites ou d'envoyer facilement, si vous le désirez, des demandes de mise en relation à celles qui ne le sont pas.

Résultat des courses, et sans que cette amie n'est faite la moindre demande de mise en relation, le site s'est permis d'envoyer des invitation à tous ses contacts, et comme par hasard, je commence à recevoir de SPAM (sex & co) sur mon adresse personnelle ultra-sécrète.

La suite ici...

Pour sécuriser une connection à un serveur web (https), un serveur imap (imaps) ou tout autre client utilisant SSL ou TLS, nous avons besoin d'un certificat. Dans une première approche il est possible d'utiliser des certificat dits "auto-signés". Générés très facilement, il sont très pratique pour développer et tester un site sécurisé mais beaucoup moins s'agissant d'une utilisation régulière et publique, principalement à cause des avertissements de sécurité qu'ils génèrent sur l'application cliente. L'autre option est alors d'acheter un certificat auprès d'un tiers de confiance. Certificat qui vous permettra à votre tour d'en générer d'autres qui cette fois seront acceptés sans erreur.

La troisième voie développée ici, entre l'auto-signature et l'achat, consiste à créer sa propre autorité certifiante qui, une fois importée, par exemple dans un navigateur, se comportera exactement de la même manière que si vous l'aviez achetée. Au delà de la compréhension technique des mécanismes mis en jeu, cette approche est plutôt bien adaptée à une petite structure qui n'a pas le goût de payer un certificat et pour qui distribuer ou pré-installer une autorité ne pose pas de problèmes (nombre restreint d'utilisateurs, postes pré-installés, etc.).

PAM, le système d'authentification centralisé de Linux même s'il n'est pas parfait, a le mérite de mettre d'accord la majorité des applications sur un mécanisme commun de gestion des crédits utilisateurs tout en restant étonnamment évolutif. L'objectif de ce billet est juste un premier dégrossissage de la manière dont PAM fonctionne et de ce qu'il est possible d'en faire.

Salut c'est Dédé !

J'ai l'immense plaisir de t'annoncer qu'il y a 72 heures, tu t'es fait flasher à 9072 kbit/s en train de télécharger, illégalement, de la musique sur Internet.

Du coup, j'ai la joie et l'honneur de procéder à la coupure de ta connexion Internet.

Quoi ? T'es pas content ?

La suite ici...

Tout le monde s'authentifie avec un mot de passe, nous avons vu comment le faire avec une clef usb, voyons maintenant comment passer l'étape biométrique avec un lecteur d'empreintes.

Si pour la protection de vos données vous avez opté pour l'option d'un dossier sécurisé par encfs ou LUKS, saisir à chaque ouverture de session un mot de passe supplémentaire devient vite pénible. Et comme c'est humain, dés que quelque chose est trop pénible, on a tendance à le contourner. L'objectif est donc ici de n'utiliser qu'un seul et même mot de passe pour se connecter ET ouvrir le dossier protégé dans la foulée.

L'idée ici est assez simple : utiliser la partition d'un clef usb pour s'authentifier sur un serveur grâce au plugin pam_usb. Ainsi, plus aucun mot de passe n'est demandé.

La scène se passe prés du centre boursier de la capitale où l'ami d'un ami prenait un café dans un de ces endroits modernes qui vous offre le WIFI pour faire passer le prix de la consommation. A côté de lui, un monsieur sérieux avec costard, cravate et bonnes manières, pianotait fébrilement sur son portable jusqu'à ce que la nature lui rappelle son existence. Il se tourne alors vers l'ami de l'ami en lui demandant s'il aurait la gentillesse de garder son bébé le temps d'une courte pause. L'ami de l'ami a une allure rassurante et lorsqu'il accepte, le monsieur s'en va l'esprit tranquille. Il revient une dizaines de minutes plus tard, visiblement content de retrouver son matériel à sa place.