Le blogouille de Caro et Nico

Entre famille, sport et aventures !

Clou 1 – Pneu Kojak 0. Mais victoire du Slime !

Alors il y a des matins avec des choses incroyables sur la route. Ici une sorte de clou de 6cm de long qui a traversé de part en part (gauche à droite) mon pneu arrière Kojak 26×1.35 censé être increvable.

le clou qui ressort par le côté droit. Rajoutez un bon centimètre à gauche aussi.
6 cm le clou !

Comment est-ce possible cet angle de crevaison ? Aucune idée. Peut-on continuer à rouler ? Oui, comme dans la série urgence, on ne retire pas l’objet qui a blessé le pneu et on file au bloc, et même si la chambre et le pneu sont transpercés, on finit le trajet. Encore mieux, on rentre le soir du bureau à la maison (17km) tout de même avec une petit regonflage à la mousse à mi chemin. Ca tient !

Merci les pneus slime :

Pneu slime avec gel d’obturation intégré.

Et merci la mousse de réparation Zefal:

Bombe Zefal de mousse obturante et de regonflage.

et bon je vais tout de même changer le pneu Kojak 26×1.35 pour qui c’est la énième blessure, mais la première qui vraiment justifie une changement de pneu, les autres étant plutôt des coupures de verre sur la bande de roulement.

Pneu Kojak (sans cheveux) avec protection anti-crevaison.

Postfix : reject specific source domains

Edit the postfix main.cf configuration file to add a rejection on sender source :

smtpd_sender_restrictions = pcre:/etc/postfix/rejected_domains

Create the rejected_domains file, enter proper filtering like :

/facture.info$/ PERMIT specific sender from @facture.info
/\.info$/   REJECT All info other info domains are rejected

Compile the file into a database with postmap command :

postmap rejected_domains

This will update/create the postmap rejected_domains.db

Reload the postfix configuration

service postfix reload

Renouvellement certbot pour apache debian avec http-01

Bon Let’s Encrypt met fin au support du challenge type TLS-SNI. Donc on passe à autre chose, si possible automatisé. On se tente un challenge type http-01, qui passe finalement avec

certbot certonly –webroot -w /var/www -d www.caronico.fr

Tout simplement. Possibilité de le faire un mode –dry-run pour le faire un coup à blanc, ensuite pour de vrai, possibilité de vérifier la date et les détails du certificat dans le navigateur web.

Enfin refaire un coup de certbot renew –dry-run

pour simuler un nouveau rafraichissement du certificat. Attention à bien se positionner dans le dossier /var/www pour faire ces commandes.

Enfin, il faut relancer le service dovecot, pour recharger les nouveaux certificats mis à jour, sinon celui ci garde en mémoire les anciens certs.

Mise en place du DKIM

DKIM (DomainKeys Identified Mail) permet de protéger le nom de domaine au niveau des mails pour éviter qu’une autre personne en usurpe l’identité. Il faut plusieurs composants pour que cela fonctionne :

Installer opendkim et le configurer avec postfix. Attention sur le package debian il y a une certaine confusion sur le port de socket d’écoute entre 8891 et8892 dans les fichiers de config. Tout doit pointer vers le 8891.

Vérifier le tout dans un email de trafic de test de base que postfix arrive bien à communiquer avec opendkim et que tout circule. Bonus : les emails entrants bénéficient maintenant de vérification DKIM à leur tour.

Générer la clef de sécurité DKIM et l’intégrer aux records DNS domaine. Attention la clef étant assez grande (2048 bits) certaines interfaces de contrôle des DNS ont du mal à accepter une telle chaine. On peut passer en TXT / mode brut et éditer, sinon maintenant l’interface de OVH gère correctement l’insertion de de la chaine DKIM.

Ensuite on peut tester immédiatement avec un outils comme https://dkimvalidator.com/ si cela fonctionne. L’outils ne met pas en cache le DNS, donc dès que la modification est faîte on peut envoyer un mail signé. L’outils fournit pas mal de renseignements, en particulier si le mail est bien signé, si la signature publique est bien lisible dans le DNS (et quelle signature/record il tente de chercher) et enfin si la signature match. Bonus : on peut voir une analyse SpamAssassin de cet email et voir si des ajustements sont nécessaires.

Ensuite il faut ajuster le record DNS progressivement, en vérifiant bien l’impact sur le trafic de mails, ainsi que les reports DMARC des principales plateforme. Il y a plusieurs outils de tests sympa pour vérifier le handshake end-to-end, en envoyant un test de mail qui passe toute la chaîne de sécurité, avec vérification antispam complète, SPF, DKIM et spamassassin. Faire monter progressivement le niveau de policy du DKIM, de test vers prod, puis renforcer la policy vers QUARANTAINE, puis quelques jours plus tard vers REJECT.

En surveillant les rapports DMARC j’ai pu noter que le nombre de tentatives de spoofing a baissé, voir passé à zéro sous quelques semaines. Rudement efficace la policy reject !