[Logo]
[Titre]

[Retour]

Archive for juillet, 2014

Citation du jour

Mercredi, juillet 16th, 2014

« La confiance, c’est la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement. »
CF : Blog nebule – Nébuleuse sociétale et confiance – Chiffrement par défaut

Nouveaux serveurs – mise en ligne

Mercredi, juillet 16th, 2014

Voici la suite de l’article Nouveaux serveurs.

Les deux nouveaux serveurs Whisky et X-ray sont terminés et opérationnels.

Prochaine étape, mettre en place un certificat signé pour le webmail.

Et puis il faut ajouter un serveur de tchat jabber (xmpp) sur Whisky.

Tunnel TLS pour ldap

Dimanche, juillet 13th, 2014

Il y a semble-t-il un bugg récent assez gênant sur la libraire GnuTLS sous Debian 7. Suite à une mauvaise implémentation semble-t-il au niveau de la négociation des algorithmes de chiffrement, il est impossible de générer ou d’utiliser des certificats pour les programmes qui utilisent cette librairie. Et c’est le cas notamment de slapd, le serveur d’annuaire LDAP (OpenLDAP) sous UNIX.

Le problème aurait pu passer presque inaperçu… mais il y eu heartbleed…Et il se trouve donc qu’un certain nombre d’admins systèmes ont dû changer très rapidement les certificats de leurs serveurs, et ont dû tomber sur ce problème.

Il devient ainsi impossible de relier un serveur de messagerie ou un serveur web avec un annuaire LDAP utilisant OpenLDAP. J’ai notamment le problème avec mon serveur postfix

Il est possible de ne pas utiliser la connexion à l’annuaire via TLS. C’est potentiellement un gros problème de sécurité en fonction des différents réseaux que vont traverser ces flux. Bref, ont n’a plus de sécurité sur un flux qui contient toute l’authentification du réseau. C’est assez moyen.

Il est aussi possible de mettre en place une solution de remplacement avec stunnel. Cela revient en fait à faire manuellement la connexion et le tunnel sécurisé par TLS. En plus, on peut conserver les mêmes certificats que le démon slapd.

Côté serveur

Il faut commencer par désactiver l’utilisation du port tcp/636. Pour cela, il faut modifier une ligne dans le fichier /etc/default/slapd :
SLAPD_SERVICES="ldap://127.0.0.1:389/"

Redémarrer le démon slapd.

Ensuite,on concatène le certificat et sa clé dans un seul fichier :
cat /etc/ssl/private/slapd.key /etc/ssl/certs/slapd.crt > /etc/ssl/private/slapd-all.crt

Enfin, on crée le bout du tunnel côté serveur, en réutilisant le certificat :
stunnel -d 636 -r 127.0.0.1:389 -p /etc/ssl/private/slapd-all.crt

Côté client

Le client, c’est le service qui utilise l’annuaire LDAP, par exemple postfix.

On crée le bout du tunnel côté client :
stunnel -c -d 6389 -r ldap.serveur.net:636

Enfin, on dit au client, en l’occurrence postfix, d’utiliser le tunnel. Modifier le fichier /etc/postfix/main.cf (ou équivalent) :
account_server_host = ldap://localhost:6389/

Et on redémarre postfix

CF : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737921

(suite…)

Nouveaux serveurs

Mardi, juillet 8th, 2014

Je profite de la disponibilité récente de machines virtuelles (VPS) chez OVH à des tarifs vraiment abordables pour scinder des services du serveur zulu :

  1. xray : serveur d’annuaire LDAP, Debian Linux 7.0 ;
  2. whisky : serveur de messagerie (smtp+xmpp+webmail), Debian Linux 7.0.

Le serveur annuaire est opérationnel mais pas encore exploité. Le serveur de messagerie est encore en cours de configuration. Pour ce dernier, je pensais utiliser Kolab, mais au vue des problèmes de configuration pour exporter l’annuaire sur un autre serveur je reviens à Horde

L’annuaire est un service critique pour plusieurs autres services comme la messagerie, les blogs et le wikis.

La messagerie est un point, que dis-je, LE point de vulnérabilité commun à tous les services que l’on utilise sur Internet. Ils ont tous en commun de demander une adresse email de secours sur laquelle on peut recevoir le nécessaire pour réinitialiser les mots de passes. Cela concerne les réseaux sociaux comme facebook et twitter, mais aussi google, gmail, yahoo, live, les assurances, les impôts, les sites marchants, les banques, etc…

Ajout de photos de Corse

Mardi, juillet 8th, 2014

J’ai traité deux photos récentes de Corse :

_img.1024x1024
2014.06.26img_2989co

_img.1024x1024
2014.06.26img_2989nb

Changer de code PIN sans le connaître

Lundi, juillet 7th, 2014

Prenons le cas d’un voleur de téléphone à l’arraché. Mettons qu’il se retrouve avec un téléphone de type Android avec l’écran non verrouillé.

Il est possible dans ce cas de rapidement modifier le code PIN, ou tout autre méthode de verrouillage de l’écran, pour s’approprier le téléphone. Évidemment, par défaut on ne peut pas changer le code PIN si on ne le connaît pas. Je précise que le téléphone n’est pas rooté.

Bon, il faut peut-être déjà changer le délai avant verrouillage pour avoir le temps de travailler. Ça se passe dans les Paramètres, Sécurité, Verrouiller automatiquement.

On ne peut pas changer tout de suite le code PIN de déverrouillage du téléphone parce qu’il demande de le saisir pour accepter d’en mettre un nouveau. Il faut trouver une autre solution pour le changer. Il est possible de le faire via des applications qui ont le droit d’administration de l’appareil. Si si, ça existe.

Si on installe, par exemple, NFC Unlocker ça devient possible.
Direction donc les Applications, Play Store, rechercher « NFC Unlocker », sélectionner l’application , Installer.

Ensuite, il faut lui donner les droits d’administration. Ça se passe dans les Paramètres, Sécurité, Administrateurs de l’appareil, cocher « NFC Unlocker », Activer.

Enfin, on lance l’application « NFC Unlocker », Settings, General, Password… et on change le code PIN sans aucun problème.
CQFD :-)

Ce qui m’a mis la puce à l’oreille, c’est l’application « Uber Device Lock ». Cette application propose par défaut de changer le code PIN… mais ça ne fonctionne pas derrière, le code est invalide…
Heureusement l’application plante assez souvent, ce qui permet de déverrouiller l’écran quand même…

Batterie explosive !?

Lundi, juillet 7th, 2014

Voici une nouvelle contrainte pour les personnes qui prennent l’avion en direction des USA. D’ici peu, il ne sera plus possible de prendre l’avion avec un appareil électronique si sa batterie est à plat.

Cela révèle surtout que ces appareils très chers qui nous auscultent à l’embarquement sont incapable de faire la distinction entre une batterie et un pain d’explosif. Est-ce une nouvelle forme d’explosif ou tout simplement le concept même des détecteurs qui ne le permet pas ?

C’est vrai aussi que certaines batteries explosent parfois, mais surtout à la charge ou si l’usage est intense.

Bref, bientôt, on prendra l’avion tout nu pour être sûr de ne pas dissimuler « quelque chose » de dangereux…

CF : Le Monde, ZDNet