Ajouter à une liste de lectureC'était sans compter sur la vigilance du Chevalier Wietse (Venema), qui décida alors que c'était assez, et qu'il était temps de faire quelque chose. C'est ainsi que naquit Postscreen, et fut intégré dans la version 2.8 de Postfix.
1. La vraie introduction
Postscreen est un processus de Postfix qui filtre le courrier entrant le plus tôt possible, l'objectif étant de rejeter le spam avant que cela ne consume des ressources sur le système. Postscreen a plusieurs niveaux de filtrages, chaque niveau allant un peu plus dans le détail, et donc consommant un peu plus de ressources. Plus tôt un email est rejeté, meilleur le système se portera, et Postscreen essaie donc d'être le plus efficace possible dès les premiers éléments de la connexion SMTP.
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
Par le(s) même(s) auteur(s)
DevOps : nuageux, avec chance de sécurité
Les évènements et personnages présentés dans cet article sont entièrement fictifs et ne représentent en rien le quotidien ou l’expérience de l’auteur… Enfin, faut quand même admettre que ça sent le vécu !
Mozilla InvestiGator : quand vos serveurs se prennent pour Sherlock Holmes
Avec suffisamment de serveurs à surveiller, l'investigateur expérimenté se retrouve souvent à chercher l'aiguille dans la botte de foin. Pour peu que l'infrastructure soit hétérogène, la recherche peut prendre plusieurs heures et souvent ne pas couvrir l’intégralité du domaine. Si vous êtes familier de ce problème et que PSSH ne fait plus l'affaire, la suite devrait vous intéresser. Une note toutefois : les personnages et situations qui suivent sont purement fictifs et ne représentent pas forcément la routine des investigations réalisées par l'auteur dans le cadre de son activité.
TLS, état des lieux côté serveur
Configurer TLS côté serveur est difficile. 19% des sites en HTTPS proposent toujours SSLv2. 28% vont négocier une session avec DES_CBC_SHA et ses clés de 56 bits si le client le demande. Il y a un peu plus d'un an, la majorité des experts en SSL/TLS recommandaient RC4 à AES. Quelques mois plus tard, c'était l'inverse. Une partie de la communauté cryptographique supporte Perfect Forward Secrecy, alors qu'une autre le refuse pour cause de lenteur. Il existe même des doutes sur le niveau réel de sécurité fourni par AES-256, par rapport à la version 128 bits. Ajoutons à cela une bonne dose de perte de confiance dans les standards existants, en particulier depuis que l'on sait Dual_EC_DRBG backdoored, et nous voici avec une parfaite recette de confusion et d'incohérence. Les désaccords sur la meilleure façon de configurer HTTPS sont nombreux. Et si le débat est utile aux experts, il est presque impossible pour un non-initié de naviguer dans la nébuleuse TLS, et d'en extraire une configuration de référence.