Vehent Julien

Il est courant de protéger l'accès aux infrastructures de production au travers de VPN ou de bastions SSH, et beaucoup d’organisations limitent encore ces points d'entrée à leur infrastructure interne. Lorsque l'organisation passe en mode télétravail à 100%, il faut forcément permettre l'accès depuis des adresses IP arbitraires, et se pose alors la question de surveiller ces accès pour détecter et bloquer rapidement une tentative d'accès malveillante.

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 !

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é.

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.

Il y a plus d'un an de cela, je vous présentais dans ces pages un formidable répulsif à Sus scrofa domesticus, j'ai nommé DSPAM. Au même moment, notre rédacteur en chef préféré m'avouait sa passion déraisonnable et certainement bien personnelle pour ce formidable résidu de cuisine qu'est le pâté de jambon, communément appelé Spam de mon côté de l'Atlantique. Fort de ma machine à tokens dopée aux amphétamines (toujours DSPAM), je m'empressais de pondérer les propos du malheureux finnois d'une statistique bien négative, et éventuellement repoussais lesdits échanges aux confins de mon dossier spam (sans pour autant bannir complètement l'intéressé, dont la conversation est toujours des plus constructive et bienvenue). Heureux de ma vie tranquille, lisant plaisamment mes courriels sans l'once d'une distraction viagriarienne « enlarge your peniche » pendant presque un an, je relâchais donc ma garde. Mais le spammer est malin, et sous prétexte de bricoler des bidules électroniques, le voilà qui libérait toute une armée de zombies spammers prêts à délivrer leurs contenus dégoûtants dans les entrailles de l'Internet.

Cela fait maintenant quelques années que Perl, en tant que langage de développement web, se fait discret. Beaucoup de développeurs l'utilisent toujours, mais la (relativement récente) vague Python/Ruby s'est ajoutée à PHP pour occuper l'essentiel du Web. En tant que sysadmin, j'ai une tendance naturelle au conservatisme : si ça marche, ne touche à rien. Bon, évidemment, ça ne s'applique pas partout, mais quand il s'agit de programmation, j'aime bien me dire que Perl fera le boulot au moins aussi bien, et peut-être mieux, que d'autres langages.J'étais donc curieux du petit dernier de la communauté Perl : le framework MVC Mojolicious. Petit frère du très reconnu Catalyst, Mojolicious est un projet récent qui essaie de corriger certains mécontentements que les moines de Perl ont pu ressentir en utilisant Catalyst. Dans la mesure où les robes en bure, hormis le fait que ça gratte, ce n'est pas ma spécialité (et n'étant pas développeur de nature), cet article n'est pas un rapport d'expertise sur Perl et les frameworks MVC, mais plutôt une introduction au développement web avec Perl et Mojolicious 1.1.

Vous avez déjà goûté du spam ? Je veux dire, du vrai spam. Celui qui est servi en boîtes rectangulaires et a vaguement la couleur du jambon. On m’en a servi, une fois, lors d’un réveillon, et je peux vous assurer que ce n’est vraiment pas bon ! Mais le spam dont on va parler ici est différent, plus électronique, mais tout aussi dégoûtant.Combattre le spam est probablement la tâche la plus complexe du postmaster. Les techniques sont nombreuses et il est indispensable de les cumuler pour obtenir un résultat pertinent.

On peut aujourd'hui largement envisager d'héberger un ou plusieurs services sur son serveur à domicile, et des mouvements comme auto-hebergement.fr l'ont bien illustré. Reste le problème de la bande passante en upload, qui bien que largement suffisante pour héberger des serveurs web, e-mail, jabber ou autre reste à utiliser intelligemment.Linux fournit cette intelligence sous forme d'un scheduler de paquets nommé Traffic Control (TC pour les intimes) et l'objectif de cet article est de présenter cette technologie et sa mise en place dans un cas d'étude d'hébergement web, DNS et même BitTorrent.Notons au passage que bon nombre de scripts et programmes existent pour simplifier la mise en place de la QoS (Quality of Service). Citons Wondershaper, Shorewall, ADSL-Optimizer, par exemple. Cet article n'en parlera pas, car l'objectif est ici de faire mais aussi de comprendre comment ça marche sous le capot, et pour ça, il faut démonter le moteur et mettre les mains dans le cambouis.

DomainKeys Identified Mail est une alternative aux systèmes d'authentification forte des e-mails que sont PGP et S/MIME. DKIM permet non pas d'authentifier l'auteur d'un e-mail, mais plutôt le domaine auquel il appartient. DKIM est le fils légitime de DomainKeys de Yahoo! et  Identified Internet Mail de Cisco.