Portsentry: Port Scan Detection

Q: Portsentry logs the scan but the IP is never blocked, why?

Two causes cover almost every case. Either BLOCK_TCP and BLOCK_UDP are still set to 0, which is detection-only mode: the event is logged and nothing else happens. Or KILL_ROUTE is still commented out, or does not match your firewall — an iptables command on a system that only runs firewalld will fail silently. Uncomment the right line, set both BLOCK_* values to 2, then restart the service.

Q: What is the difference between BLOCK_TCP="1" and BLOCK_TCP="2"?

Value 1 adds the IP to /etc/hosts.deny. That file is only consulted by services built against TCP wrappers, which has become rare, so the protection is very partial. Value 2 runs the KILL_ROUTE command and inserts a real firewall rule, blocking all traffic from that IP whatever service it targets. On a modern system, 2 is the only sensible choice.

Q: I blocked a legitimate IP by mistake, how do I unblock it?

The rule sits at the top of the INPUT chain, so just delete it: sudo iptables -D INPUT -s BLOCKED_IP -j DROP. Then confirm with sudo iptables -L INPUT -n that it is gone. Under firewalld, the --timeout=600 variant of the rich rule avoids the problem entirely since the block expires by itself after the delay.

Q: How do I test Portsentry without locking myself out?

The test is to run nmap -p 1-1024 YOUR_SERVER_IP, but it must come from a machine whose IP you can afford to lose — definitely not your admin workstation, and not the IP your SSH session is coming from. During the scan, follow sudo tail -f /var/log/syslog (or /var/log/messages on CentOS): you will see the alert and then the addition to the block list, confirmed by sudo iptables -L INPUT -n.

Security

Difficulty: Advanced

4 min read 25/07/2026

Tutorial to install and configure Portsentry, a tool that detects port scans and blocks attackers' IP addresses.

Back to tutorials

Key takeaways

Portsentry works as a honeypot: it listens on TCP and UDP ports you do not use. Any connection to one of them can only be a reconnaissance scan, so the source IP is blocked at the firewall before the attacker has even found a real vulnerability.
The decisive setting is BLOCK_TCP / BLOCK_UDP in /etc/portsentry/portsentry.conf: 0 detects without blocking, 1 writes to /etc/hosts.deny (barely effective these days), 2 adds a firewall rule — the only genuinely useful option.
KILL_ROUTE holds the actual blocking command, where $TARGET$ is substituted with the attacker's IP: /sbin/iptables -I INPUT -s $TARGET$ -j DROP for iptables, or a rich rule via firewall-cmd with --timeout=600 under firewalld, which makes the block expire on its own.
By default Portsentry only covers unused ports below 1024. The advanced modes TCP_MODE="atcp" and UDP_MODE="audp", enabled in /etc/default/portsentry (or /etc/sysconfig/portsentry on CentOS), extend the listener to every unassigned port: far more effective, but more exposed to false positives.
Validation: sudo systemctl restart portsentry, an nmap -p 1-1024 launched from a machine whose IP you can afford to lose, watch /var/log/syslog, then run sudo iptables -L INPUT -n to see the DROP rule appear at the top of the chain. Manual unblock: sudo iptables -D INPUT -s BLOCKED_IP -j DROP.

What is Portsentry?
Portsentry is a proactive defense tool that acts as a "honeypot". It listens on TCP and UDP ports that you do not use. If an attacker attempts to connect to one of these ports (which is typical of a reconnaissance scan), Portsentry detects it immediately and can block the attacker's IP address at the firewall level.

Why use Portsentry?

Early detection: A port scan is often the very first step of an attack. Detecting it lets you block an attacker before they even find a real vulnerability.
Deterrence: Automatically blocking scanners reduces the "noise" in the logs and discourages automated attacks.
Lightweight: Consumes very few resources.

Prerequisites

A Linux server (Ubuntu/Debian, CentOS/RHEL).
Root access or sudo privileges.
A firewall such as iptables or firewalld.

Premium Content

This advanced tutorial is reserved for premium members.

9,90€ / month

All advanced tutorials
New content every week
Progress tracking
Cancel anytime

Written by

Morgann Riu

Cybersecurity and Linux administration expert. I share my knowledge through free tutorials and training to help system administrators and developers secure their infrastructures.

My profile LinkedIn GitHub

Frequently asked questions

Portsentry logs the scan but the IP is never blocked, why?

Two causes cover almost every case. Either BLOCK_TCP and BLOCK_UDP are still set to 0, which is detection-only mode: the event is logged and nothing else happens. Or KILL_ROUTE is still commented out, or does not match your firewall — an iptables command on a system that only runs firewalld will fail silently. Uncomment the right line, set both BLOCK_* values to 2, then restart the service.

What is the difference between BLOCK_TCP="1" and BLOCK_TCP="2"?

Value 1 adds the IP to /etc/hosts.deny. That file is only consulted by services built against TCP wrappers, which has become rare, so the protection is very partial. Value 2 runs the KILL_ROUTE command and inserts a real firewall rule, blocking all traffic from that IP whatever service it targets. On a modern system, 2 is the only sensible choice.

I blocked a legitimate IP by mistake, how do I unblock it?

The rule sits at the top of the INPUT chain, so just delete it: sudo iptables -D INPUT -s BLOCKED_IP -j DROP. Then confirm with sudo iptables -L INPUT -n that it is gone. Under firewalld, the --timeout=600 variant of the rich rule avoids the problem entirely since the block expires by itself after the delay.

Should I enable the advanced atcp and audp modes?

They change the picture: in standard mode Portsentry only listens on unused ports below 1024, so a scanner sweeping the high ports goes unnoticed. With TCP_MODE="atcp" and UDP_MODE="audp" in /etc/default/portsentry, it listens on every unassigned port and catches far more scanners. The trade-off is a higher risk of false positives, so have your unblocking procedure ready before enabling them.

How do I test Portsentry without locking myself out?

The test is to run nmap -p 1-1024 YOUR_SERVER_IP, but it must come from a machine whose IP you can afford to lose — definitely not your admin workstation, and not the IP your SSH session is coming from. During the scan, follow sudo tail -f /var/log/syslog (or /var/log/messages on CentOS): you will see the alert and then the addition to the block list, confirmed by sudo iptables -L INPUT -n.

Share this tutorial

X LinkedIn WhatsApp

Did you enjoy this article?

Was this article helpful?

Thanks for your feedback!

Comments

Recommended for you

Sécurité

In-depth article on the topic

Combien de VRAM pour faire tourner un LLM en local ? Le guide de calcul (2026)

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.