Linux Attitude

Niveau :      
Résumé : postfix ; catch all

Supposons que vous ayez une application qui envoie régulièrement des mails. Vous voulez tester cette application en conditions réelles, mais sans envoyer ces mails (par exemple un logiciel de spam :-)

Pour ne pas tout casser, nous allons juste changer la configuration du serveur utilisé pour envoyer les mails. Tous les mails, tous domaines et tous destinataires confondus seront acceptés.

Étape 1 : tout rediriger vers le compte de quelqu'un

Prenons un postfix. Ajoutons une ligne dans main.cf :

# on matche les mails qu'on va accepter avec des expression régulières
virtual_alias_maps = regexp:/etc/postfix/virtual

Créons notre fichier /etc/postfix/virtual :

# on redigige tout vers quelqu'un qui va pouvoir lire les mails
/@/	peck@ditoto.com

C'est bien mais on voudrait pouvoir centraliser ce serveur de test et trier les mails envoyés en fonction des serveurs d'origine (développement, recette, qualification ...).

Étape 2 : filtrer

On va donc rediriger vers un compte local créé pour l'occasion (si vous avez des comptes virtuel, il faut faire différemment, vous saurez faire) :

$ adduser genericmail

On adapte /etc/postfix/virtual et on n'oublie pas de laisser passer les destinataires finaux sous peine de boucles :

# on redirige tout vers notre filtre
if !/@ditoto.com$/
/@/	genericmail
endif

On relaie les mails de ces mêmes destinataires finau[xd] vers leur vrai serveur dans main.cf et on se prépare à utiliser procmail :

relay_domains = ditoto.com
mailbox_command = /usr/bin/procmail -Y -a $DOMAIN

Et enfin, le plus important, nous allons filtrer avec un procmail (au passage vérifiez qu'il est installé :-p) :

# on redirige en fonction du destinataire
:0
* ^TO.*@gnagna.fr.*
! peck@ditoto.com

# plus important, on peut le faire en fonction de la source
:0
* ^Received:.*from mamachine.dev.ditoto.com
! pock@ditoto.com

# et une petite règle par défaut pour ne pas être surchargé
:0
* ^.*
/dev/null

La fin

Voilà, vous avez un serveur mail paramétrable qui vous permet de faire ce que vous voulez des mails qu'il reçoit, quels que soient leurs destinataires. Rien de bien compliqué, mais bien pratique en environnement de test.

Niveau :      
Résumé : Stocker une passphrase sans protection

Stocker une passphrase sans protection, c'est possible ! Hé oui, grâce à la magie de l'informatique.

Tout d'abord, prenons une passphrase. Utilisons la technique des demi-bits et produisons des portions de passphrase. Enregistrons l'une sur un compte imap, l'autre sur une clé usb. On peut essayer de les protéger, mais ce qui est important c'est que la sécurité de la passphrase dépend de la somme des sécurités des éléments de stockage. Ainsi, seule une personne qui a accès à la fois à votre clé usb, à votre mail, à votre postit sous le clavier et à votre serveur web peut lire votre passphrase. Vous pouvez même avec les 2/3 de bit vous permettre de perdre un des éléments.

À quoi cela sert-il ? À pas grand chose finalement. Le but est uniquement de faire en sorte de ne pas perdre une passphrase ou une clé très importante qu'on ne peut stocker chez un tiers de confiance. En gros cela vous servira pour la clé de cryptage de vos fichiers de backup, il est probable qu'on l'ai perdu puisqu'on a besoin de backups, et il est probable qu'on ne le connait pas par cœur puisque ce genre de problème arrive rarement.

Les extrémistes de la sécurité me diront que c'est prendre un gros risque, et ils auront raison, avec un peu de patience, quelqu'un pourrait retrouver la clé. Et si elle chiffre des données très importantes, un attaquant la trouvera. Attention donc.

Par contre, quelques avantages :

• archivage quasi public
• il est impossible de retrouver la clé avec une seule donnée (ni même de simplifier une attaque)
• multiplication des sous-parties de la clé a l'envie
• redondance possible

Notez qu'il est même possible d'y ajouter des informations publiques non modifiées comme votre numéro de sécurité sociale (hé oui c'est un xor...)

Niveau :      
Résumé : sshd -T ; ssh -l

I'm back ! Ca y est j'ai déménagé. Je peux maintenant reprendre mon activité normale ...

Au cas où vous ne le sauriez pas, la dernière version de openssh vient de sortir, la 5.1. La lecture du changelog est très instructive. On y découvre entre autre deux nouveautés ben sympathiques.

Serveur

Commençons par une nouvelle option de sshd :

$ sshd -T

Cette option permet de tester la configuration du serveur. Ce genre d'option devrait être disponible sur tous les softs, grâce à elle, vous pourrez savoir du premier coup d'oeil si vous avez bien écrit votre configuration et si sshd a bien compris la même chose que ce que vous vouliez lui dire.

Client

Ensuite, une nouvelle option de ssh (qui n'est pas activée par défaut) :

$ ssh -o "VisualHostKey true" mamachine.net

Cette option affiche une interprétation du fingerprint de la machine distante sous forme d'ASCII art. Il est ainsi beaucoup plus facile de comparer 2 clés (il suffit de les regarder).

Cette fonction répond au problème de la confiance au serveur ssh. Lorsque vous vous connectez, ssh vérifie que le serveur distant est connu, si vous vous y êtes déjà connecté et que la clé n'a pas changé, on peut faire confiance en son identité. Mas lorsque c'est la première fois que vous vous connectez, il faut vérifier manuellement que la clé est ben la bonne. Avec cette option la vérification est simplifiée, on espère donc que les gens la feront plus souvent ...

Bonne nouvelle, je déménage ! Je veux dire que je change de région, de boulot, de vie ...

Donc les articles en prennent un coup. Mais ne vous inquiétez pas, je serai de retour d'ici une semaine. En attendant :

• Avez vous mis à jour vos dns ?
• Savez-vous tout sur le dns ?
• Avez-vous essayé le dernier noyau linux ?
• Connaissez-vous vos raccourcis shell par coeur ?