Portsentry : Détection de scans de ports

Q: Portsentry voit bien le scan dans les logs mais l'IP n'est jamais bloquée, pourquoi ?

Deux causes dans la quasi-totalité des cas. Soit BLOCK_TCP et BLOCK_UDP sont restés à 0, ce qui correspond au mode détection seule : la détection est journalisée, aucune action n'est prise. Soit KILL_ROUTE est encore commenté ou ne correspond pas à votre pare-feu — une commande iptables sur un système qui n'utilise que firewalld échouera silencieusement. Décommentez la bonne ligne, passez les deux BLOCK_* à 2, puis redémarrez le service.

Q: Quelle différence entre BLOCK_TCP="1" et BLOCK_TCP="2" ?

La valeur 1 ajoute l'IP dans /etc/hosts.deny. Ce fichier n'est consulté que par les services compilés avec les TCP wrappers, ce qui est devenu rare : la protection est donc très partielle. La valeur 2 exécute la commande KILL_ROUTE et insère une vraie règle de pare-feu, qui bloque l'intégralité du trafic de cette IP quel que soit le service visé. Sur un système moderne, 2 est le seul choix raisonnable.

Q: J'ai bloqué une adresse IP légitime par erreur, comment la débloquer ?

La règle est en tête de la chaîne INPUT, il suffit de la supprimer : sudo iptables -D INPUT -s IP_BLOQUEE -j DROP. Vérifiez ensuite avec sudo iptables -L INPUT -n qu'elle a bien disparu. Sous firewalld, la variante --timeout=600 de la rich rule évite ce problème puisque le blocage expire automatiquement au bout du délai.

Q: Comment tester Portsentry sans se bloquer soi-même ?

Le test consiste à lancer nmap -p 1-1024 IP_DE_VOTRE_SERVEUR, mais il doit impérativement partir d'une machine dont vous pouvez vous permettre de perdre l'IP — surtout pas de votre poste d'administration ni de l'IP depuis laquelle vous êtes connecté en SSH. Pendant le scan, suivez sudo tail -f /var/log/syslog (ou /var/log/messages sur CentOS) : vous verrez l'alerte puis l'ajout à la liste de blocage, confirmé par sudo iptables -L INPUT -n.

Security

Difficulte: Advanced

4 min de lecture 25/07/2026

Tutoriel pour installer et configurer Portsentry, un outil qui détecte les scans de ports et bloque les adresses IP des attaquants.

Retour aux tutoriels

L'essentiel

Portsentry fonctionne en pot de miel : il écoute sur des ports TCP et UDP que vous n'utilisez pas. Toute connexion sur l'un d'eux ne peut être qu'un scan de reconnaissance, donc l'IP source est bloquée au niveau du pare-feu avant même que l'attaquant ait trouvé une vraie vulnérabilité.
Le réglage décisif est BLOCK_TCP / BLOCK_UDP dans /etc/portsentry/portsentry.conf : 0 détecte sans bloquer, 1 écrit dans /etc/hosts.deny (peu efficace aujourd'hui), 2 ajoute une règle de pare-feu — c'est la seule option réellement utile.
KILL_ROUTE contient la commande de blocage effective, où $TARGET$ est remplacé par l'IP de l'attaquant : /sbin/iptables -I INPUT -s $TARGET$ -j DROP pour iptables, ou une rich rule firewall-cmd avec --timeout=600 sous firewalld, ce qui fait expirer le blocage tout seul.
Par défaut Portsentry ne couvre que les ports inutilisés en dessous de 1024. Les modes avancés TCP_MODE="atcp" et UDP_MODE="audp", à activer dans /etc/default/portsentry (ou /etc/sysconfig/portsentry sur CentOS), étendent l'écoute à tous les ports non assignés : bien plus efficace, mais plus exposé aux faux positifs.
Validation : sudo systemctl restart portsentry, un nmap -p 1-1024 lancé depuis une machine dont vous pouvez perdre l'IP, surveillance de /var/log/syslog, puis sudo iptables -L INPUT -n pour voir la règle DROP apparaître en tête de chaîne. Déblocage manuel : sudo iptables -D INPUT -s IP_BLOQUEE -j DROP.

Qu'est-ce que Portsentry ?
Portsentry est un outil de défense proactif qui agit comme un "honeypot" (pot de miel). Il écoute sur des ports TCP et UDP que vous n'utilisez pas. Si un attaquant tente de se connecter à l'un de ces ports (ce qui est typique d'un scan de reconnaissance), Portsentry le détecte immédiatement et peut bloquer l'adresse IP de l'attaquant au niveau du pare-feu.

Pourquoi utiliser Portsentry ?

Détection précoce : Un scan de ports est souvent la toute première étape d'une attaque. Le détecter permet de bloquer un attaquant avant même qu'il ne trouve une vraie vulnérabilité.
Dissuasion : Bloquer automatiquement les scanners réduit le "bruit" dans les logs et décourage les attaques automatisées.
Léger : Consomme très peu de ressources.

Prérequis

Un serveur Linux (Ubuntu/Debian, CentOS/RHEL).
Accès root ou privilèges sudo.
Un pare-feu comme iptables ou firewalld.

Contenu Premium

Ce tutoriel avancé est réservé aux membres premium.

9,90€ / mois

Tous les tutoriels avancés
Nouveaux contenus chaque semaine
Suivi de progression
Annulation à tout moment

Se connecter Créer un compte

Écrit par

Morgann Riu

Expert en cybersécurité et administration Linux. Je partage mes connaissances à travers des tutoriels gratuits et des formations pour aider les administrateurs systèmes et développeurs à sécuriser leurs infrastructures.

Mon profil LinkedIn GitHub

Questions fréquentes

Portsentry voit bien le scan dans les logs mais l'IP n'est jamais bloquée, pourquoi ?

Deux causes dans la quasi-totalité des cas. Soit BLOCK_TCP et BLOCK_UDP sont restés à 0, ce qui correspond au mode détection seule : la détection est journalisée, aucune action n'est prise. Soit KILL_ROUTE est encore commenté ou ne correspond pas à votre pare-feu — une commande iptables sur un système qui n'utilise que firewalld échouera silencieusement. Décommentez la bonne ligne, passez les deux BLOCK_* à 2, puis redémarrez le service.

Quelle différence entre BLOCK_TCP="1" et BLOCK_TCP="2" ?

La valeur 1 ajoute l'IP dans /etc/hosts.deny. Ce fichier n'est consulté que par les services compilés avec les TCP wrappers, ce qui est devenu rare : la protection est donc très partielle. La valeur 2 exécute la commande KILL_ROUTE et insère une vraie règle de pare-feu, qui bloque l'intégralité du trafic de cette IP quel que soit le service visé. Sur un système moderne, 2 est le seul choix raisonnable.

J'ai bloqué une adresse IP légitime par erreur, comment la débloquer ?

La règle est en tête de la chaîne INPUT, il suffit de la supprimer : sudo iptables -D INPUT -s IP_BLOQUEE -j DROP. Vérifiez ensuite avec sudo iptables -L INPUT -n qu'elle a bien disparu. Sous firewalld, la variante --timeout=600 de la rich rule évite ce problème puisque le blocage expire automatiquement au bout du délai.

Faut-il activer les modes avancés atcp et audp ?

Ils changent la donne : en mode standard Portsentry n'écoute que sur les ports inutilisés sous 1024, donc un scanner qui balaye les ports hauts passe inaperçu. Avec TCP_MODE="atcp" et UDP_MODE="audp" dans /etc/default/portsentry, il écoute sur tous les ports non assignés et attrape beaucoup plus de scanners. La contrepartie est un risque accru de faux positifs, donc prévoyez la procédure de déblocage avant d'activer.

Comment tester Portsentry sans se bloquer soi-même ?

Le test consiste à lancer nmap -p 1-1024 IP_DE_VOTRE_SERVEUR, mais il doit impérativement partir d'une machine dont vous pouvez vous permettre de perdre l'IP — surtout pas de votre poste d'administration ni de l'IP depuis laquelle vous êtes connecté en SSH. Pendant le scan, suivez sudo tail -f /var/log/syslog (ou /var/log/messages sur CentOS) : vous verrez l'alerte puis l'ajout à la liste de blocage, confirmé par sudo iptables -L INPUT -n.

Partager ce tutoriel

X LinkedIn WhatsApp

Cet article vous a plu ?

Cet article vous a-t-il été utile ?

Merci pour votre retour !

Commentaires

Recommandé pour vous

Sécurité

Article de fond sur le sujet

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.