CrowdSec est un outil de défense réseau communautaire qui dépasse les limites de fail2ban en mutualisant les informations entre serveurs. Contrairement à fail2ban, isolé et réactif, CrowdSec permet à un serveur d’apprendre des attaques détectées ailleurs et d’appliquer des bannissements préventifs avant même qu’une IP malveillante n’atteigne son infrastructure. Le système repose sur trois composants : l’Agent, qui analyse les logs locaux et génère des décisions de blocage ; le Bouncer, qui applique ces décisions à différents niveaux (réseau, proxy ou application) ; et la CAPI, une API centrale qui agrège et redistribue les bannissements validés par consensus parmi la communauté.
Le modèle de CrowdSec répond à trois faiblesses majeures de fail2ban : l’isolement des serveurs, l’inefficacité face aux attaques distribuées (botnets utilisant des milliers d’IP) et le coût silencieux des attaques répétées sur les ressources. En partageant les signaux d’attaque et en appliquant des bannissements globaux, CrowdSec réduit la charge sur les infrastructures tout en améliorant la réactivité contre les menaces émergentes.
L’écosystème de CrowdSec permet une intégration flexible, avec des scénarios personnalisables et des mécanismes de consensus pour limiter les faux positifs. Prochainement, un billet détaillera son déploiement concret, illustrant comment cette approche communautaire transforme la sécurité des serveurs publics.
Cet article explique le fonctionnement technique des emails, en détaillant les étapes clés de leur transmission. L’idée principale est de montrer comment un email, envoyé depuis un expéditeur comme Gmail, parvient à un destinataire sur un autre service comme Yahoo. Le processus repose sur des protocoles comme SMTP pour l’envoi, tandis que des serveurs de messagerie (MTA) et des enregistrements DNS (MX) assurent le routage entre les serveurs. L’authentification via DKIM, DMARC et SPF est également abordée pour garantir la légitimité des messages.
L’auteur décrit ensuite les commandes SMTP utilisées pour envoyer un email, comme HELO pour l’identification, MAIL FROM pour l’expéditeur, RCPT TO pour le destinataire, et DATA pour le contenu. Une fois reçu, l’email est stocké et son en-tête est analysé avant d’être transmis au serveur du destinataire via des files d’attente, selon les configurations des fournisseurs de messagerie.
Ce tutoriel explique comment sécuriser l'envoi d'e-mails en utilisant les protocoles SPF, DKIM et DMARC. Il détaille les failles du protocole SMTP et comment ces trois mécanismes complémentaires, basés sur le DNS, permettent de vérifier l'identité des expéditeurs et de lutter contre le spam et le phishing. Le tutoriel aborde la configuration de chaque protocole, leurs limites et leurs synergies, avec des exemples de syntaxe pour les enregistrements DNS.
Navidrome est un serveur de musique open source et auto-hébergé qui permet d'écouter sa propre collection musicale depuis n'importe quel navigateur ou appareil mobile. Similaire à des services comme Spotify ou Apple Music, il permet également de partager facilement sa musique et ses playlists. Après une installation simple, Navidrome indexe toute la musique stockée sur votre disque dur, la rendant accessible via un lecteur web ou des applications mobiles compatibles avec l'API Subsonic. Vous pouvez ainsi rechercher votre musique, créer des playlists, noter et favoriser vos morceaux, albums et artistes préférés.
Ce guide compare SSHGuard et Fail2ban pour la protection SSH sur Debian/Ubuntu. SSHGuard, écrit en C, est plus léger (1-2 Mo) et utilise un parseur lexical natif, tandis que Fail2ban, en Python, consomme plus de ressources (9 Mo à 2.5 Go) et repose sur des expressions régulières. SSHGuard est idéal pour les serveurs avec ressources limitées et une protection SSH prioritaire, tandis que Fail2ban convient pour protéger plusieurs services avec des règles personnalisées. Le guide explique aussi l'installation, la configuration de base et le système de scoring de SSHGuard.
Cet article explique comment utiliser GoAccess, un outil open-source d’analyse de logs web, pour surveiller le trafic de son serveur Apache/Nginx directement depuis le terminal ou via des rapports HTML. L’article détaille l’installation sur Ubuntu, la configuration du format des logs, les commandes de base pour analyser les logs (y compris en temps réel), et des astuces pour filtrer le trafic (exclure les bots, les pages admin, etc.). Il propose aussi des alias pour simplifier l’utilisation, des méthodes pour sécuriser les rapports générés, et des techniques avancées comme l’automatisation via des scripts et cron. L’outil est présenté comme une alternative légère, performante et respectueuse de la vie privée à Google Analytics, idéale pour les développeurs qui veulent garder le contrôle sur leurs données. En résumé : installation rapide, configuration flexible, et résultats complets (visiteurs, pages, OS, géolocalisation, etc.) sans dépendre d’un service externe.
Cet article de Clever Cloud explore comment passer d’un prototype fragile à un serveur MCP (Model-Compute-Provider) fiable et sécurisé en production. L’auteur partage des leçons tirées de projets concrets, comme RAGmonsters, et insiste sur l’importance de concevoir des serveurs spécifiques au domaine plutôt que génériques pour garantir sécurité et prévisibilité. Les principes clés incluent la définition d’outils étroits et bien nommés, l’utilisation de types d’entrée/sortie stables, un comportement déterministe, le principe du moindre privilège, et une explicabilité intégrée. La sécurité, l’observabilité et l’évaluation continue sont présentées comme des piliers essentiels pour transformer une démonstration en infrastructure robuste, adaptée à un client aussi imprévisible qu’un LLM. L’article détaille aussi comment structurer les capacités (outils, ressources, prompts), sécuriser les accès, et surveiller les performances pour une intégration réussie en production. Une lecture indispensable pour qui souhaite industrialiser l’usage des agents LLM.
Optimiser la délivrabilité de vos emails passe par une configuration rigoureuse de votre serveur SMTP (comme Postfix) et l’application des normes SPF (autorisation des serveurs émetteurs), DKIM (signature cryptographique des emails) et DMARC (politique de gestion des échecs et rapports). Ces trois piliers, combinés à des outils de test comme Mail-tester.com, un reverse DNS valide, l’activation du TLS et la vérification des listes noires (RBL), permettent d’éviter que vos messages ne finissent en spam. Des services comme Postmark ou Google Postmaster Tools aident à analyser les rapports DMARC, tandis que l’IA (ChatGPT) peut faciliter le diagnostic des erreurs de configuration. L’objectif : atteindre un score optimal et garantir que vos emails arrivent bien en boîte de réception.
Forward Proxy vs Reverse Proxy : Le forward proxy agit comme un intermédiaire entre le client et internet, filtrant les requêtes (ex : contrôle d’accès, cache, anonymat) et nécessitant une configuration côté client, tandis que le reverse proxy se place entre internet et le serveur, protégeant ce dernier (ex : équilibrage de charge, sécurité, TLS termination, cache) et masquant son adresse IP. Le premier est utile pour gérer les requêtes sortantes (ex : réseaux d’entreprise), le second pour optimiser et sécuriser les requêtes entrantes (ex : sites web à fort trafic). En résumé, le forward proxy sert le client, le reverse proxy sert le serveur.
Tout est dans le titre - il s'agit de la configuration d'un serveur
Tout est dans le titre
Tout est dans le titre
Une exploration de l'écriture d'un serveur HTTP minimaliste dans différents langages : Rust, Golang, Vlang, Ziglang, C et ASM
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Le parcours du combattant pour configurer un serveur pour l'envoi d'un mail