Encore dans ma mission d'administration d'une solution antispam, notre équipe reçoit une demande à propos de « fichiers bloqués ». Il s'agit des fichiers Microsoft Office (.XSLX / .DOCX / .PPTX / etc.).
Cependant aucune de ces extensions n'est bloquée, contrairement aux « traditionnels » .EXE, .BIN, .XML, .WMF… C'est donc en investiguant sur ces fichiers bloqués, alors qu'ils ne le devraient pas, que nous avons découvert une grande différence entre ces « nouveaux » formats et leurs prédécesseurs : les plus récents sont en réalité des « conteneurs », au même titre que les archives RAR ou ZIP.
Notre solution va donc inspecter le conteneur en profondeur, y trouve les .XML et éventuels .WMF (si une image est insérée dans le fichier), et bloque ainsi le fichier.
Qu'il bloque une « menace potentielle », je veux bien. Mais qu'il ne précise rien sur la raison du blocage dans les logs, voilà qui facilite grandement la résolution du problème… PEBKAC.
C'est en lisant le #773 que ce souvenir m'est revenu : il y a bien quinze ans, lorsque mon cher paternel a décidé de changer son ordinateur (combo total clavier/écran/souris), il m'a donné son ancien PC (à l'époque sous Win95, ça date).
Une fois le tout reçu, je m'emploie au branchement. À l'époque novice dans le domaine, je fais appel à ces choses trop peu répandues de nos jours que sont « la logique » et « le bon sens ». Je mets le bidule gris dans la prise grise, le bidule orange dans la prise orange (clavier/souris, c'est vieux), la grosse prise dans la grosse prise, le bidule bleu sur le port tout bleu qui à l'air d'être ça…puis j'allume finalement le tout.
Avec le recul, je me dis que j'aurais dû me méfier… Non pas du fait qu'il m'ait donné son ordinateur… mais du fait qu'il ait été complètement estomaqué par le seul fait que je sois parvenu à le brancher tout seul (alors que lui-même n'y arrivait pas). Je sais maintenant que c'était le signe annonciateur de nombreux… PEBKAC.
Je fais une recherche concernant le domaine d'un partenaire. L'ami de l'administrateur e-mail (la commande
nslookup) me donne deux entrées MX.
Je suis agréablement surpris, l'admin en face semble connaître son boulot puisque je vois deux entrée MX avec des noms FQDN. Je vois tellement d'IP à ces endroits ces derniers temps que j'avais presque oublié que cela pouvait être autre chose.
Je m’intéresse d'un peu plus près à ces deux entrées :
mail1.<domaine>.<ext>
mail2.<domaine>.<ext>
Bien, maintenant j'ai besoin des IP sur lesquelles pointent ces entrées MX. Un bon vieux
ping fera l'affaire.
Quelle n'est pas ma surprise de constater que les deux entrées MX renvoient sur la même IP…. Autant laisser une unique entrée à ce moment là.
L'administrateur pour qui « la redondance » est « le fait de doubler les entrées MX sur une même adresse IP ». PEBKAC.
Toujours au cours de ma mission longue durée, suite et fin du #9646 :
Comme prévu, la solution n'a pas fonctionné. Ils ont donc, dans l'ordre :
– Whitelist du domaine en sortie (toujours aucun filtrage en sortie, aucune amélioration) ;
– Whitelist de l'adresse en entrée (pas mieux et aucun rapport avec le problème qui se situe en sortie) ;
– Et pour finir, Whitelist du domaine en entrée (sans plus de succès).
On a fini par prendre le problème en main et par le résoudre nous-mêmes. Mais ci-dessus, trois bonnes raisons d'en conclure que ce ticket a été géré par des… PEBKAC.
Voici un ticket qui vient tout juste de tomber dans la boîte :
« Sujet : Implement antispam system whitelist
– Domain to Whitelist : www.01net.com »
J'ai l'intime conviction qu'ajouter ce site à la Whitelist de mes anti-spams messagerie ne va pas beaucoup avancer l'utilisateur. Et demander de mettre un site Web les Whitelist Mail…
Mais ce n'est pas le plus beau : le site en question n'est d'ailleurs même pas bloqué par notre proxy Web. PEBKAC.
Toujours prestataire en mission dans l'équipe Messagerie d'un grand groupe, je reçois par ticket une demande de whitelist. Tout pourrait aller bien, sauf que la demande est :
« Pouvez vous whitelister https://<sitecollaboratif>.<domaine>.fr pour les personnes suivantes :
– <Utilisateur A>
– <Utilisateur B>
– <Utilisateur C> »
Une certaine personne devrait apprendre à LIRE les tickets créés avant de les transmettre à notre équipe sur le seul prétexte que le mot « Whitelist » apparaît dans le sujet, car le ticket concerne le proxy « Web » qui est hors du périmètre de mon équipe et n'a aucun lien avec le proxy « Mail » que nous gérons.
Bien évidement, le ticket est retourné chez celui qui l'a assigné. PEBKAC.
Aujourd'hui, petite coupure réseau dans l'entreprise où je travaille (5 à 10 minutes, pas plus). Un utilisateur ayant constaté le problème a donc prévenu l'équipe réseau… par e-mail.
Bien évidement, comme son message ne passait pas, il a contacté le support (par téléphone) pour ouvrir un incident auprès de l'équipe Messagerie (dont je fais partie).
Je me demande encore si je dois m'énerver contre l'utilisateur qui pense que les e-mails sont transmis par télépathie, contre mon collègue qui était lui aussi victime de la coupure et qui a spécifiquement attendu que ce problème soit résolu pour créer le ticket au sujet du mail sans faire le rapprochement entre les deux événements, ou encore simplement contre les deux. PEBKAC.
Ticket d'un utilisateur:
« Bonjour, je ne parviens pas à m'envoyer un e-mail. Je reçois une notification le lendemain. Pouvez vous regarder ? »
Je regarde les courriers envoyés sur mes passerelles, et je les vois en rétention. J'observe d'un peu plus près :
Expéditeur : <prénom>.<nom>@<sous-domaine>.<domaine>.com
Destinataire : <prénom>.<nom>@<domaine>.<sous-domaine>.com
Lorsque je lui fais remarquer, il me répond que c'est « mon système de me*de qui fait n'importe quoi ».
Ajoutons à cela que ce message ne contient rien de très « professionnel » (MP3/MP4)… Non seulement il n'est pas fichu de savoir écrire sa propre adresse e-mail, mais en plus il est de mauvaise foi. PEBKAC.
Journal de bord du Capitaine Fox, 7 mars : cela fait quatre jours que notre équipe (dédiée messagerie uniquement) se prend la tête pour un domaine de messagerie auquel il est impossible d'envoyer des courriers depuis notre nouvelle infrastructure de messagerie. Tous les enregistrements DNS ici sont bien faits, rien à signaler par ici, ce serait trop simple.
J'ai donc mis rapidement en place une solution de contournement qui passe par notre ancienne infrastructure (encore en activité pour le moment) et nous avons demandé à l'équipe réseau de rechercher ce qui pourrait poser problème chez eux, ce à quoi ils nous ont répondu que tout était OK de leur côté… jusqu'à aujourd'hui.
La cause venant d'un tunnel VPN utilisant une adresse
x.x.0.0/16. Oui,
/16 !
Pas de chance, l'IP publique des MX tombe dans cette plage. Suite à la correction avec l'IP de destination du VPN, nos
telnet sur l'IP du MX port 25 et nos e-mails passent sans souci.
Pour celui qui a monté un VPN sur une plage
/16, PEBKAC.
Un nouveau problème similaire à mon anecdote précédente. Cette fois (outre le fait d'avoir encore un administrateur qui ne sait pas faire un enregistrement DNS correctement), une perle de l'un de mes collègues du support qui nous suggère de « Mettre le destinataire du message sur la Whitelist d'entrée ».
Outre que le fait que le problème se situe au niveau de la résolution DNS, et peut être contourné exclusivement par l'ajout d'une route statique pour ce domaine, je ne vois pas en quoi spécifier l'autorisation de passer de l'adresse du « destinataire » en « entrée » de notre domaine de messagerie peut aider à « envoyer » le message vers cette adresse… PEBKAC.
Bienvenue sur PEBKAC.fr, le site qui recense les anecdotes où l’on se moque des utilisateurs ne maîtrisant pas l’outil informatique. PEBKAC est un acronyme signifiant « Problem Exists Between Keyboard And Chair ».