Leaving ports open on your server is like leaving your windows unlocked. Attackers don’t need to guess much, they just scan and knock until something responds. That’s why port management is important. With BitNinja’s PortHoneypot module, you now get built-in port blocking and allowing. No extra firewall scripts, no extra tools, no hidden costs.

In this article, we’ll take a deep dive into how port blocking works in BitNinja, why it matters, and how you can configure it for maximum security without breaking your services.

How PortHoneypot Works Under the Hood

The PortHoneypot module was originally designed to detect port scans and lure attackers into fake services. Technically, it doesn’t bind directly to your “real” service ports:

• It launches honeypots on ports above 60500.
• iptables rules forward traffic from the chosen ports to the honeypots.
• If a real daemon starts listening on a honeypot port, the module automatically releases it to avoid collision.
• On startup, it checks all listening sockets to stay out of the way of active services.

This same architecture also makes port blocking/allowing possible, starting from BitNinja 3.12.8.

Port Blocking and Allowing Explained

With the Port Blocker, you define rules in the module’s configuration:

• Blocked Ports: ports you want to close.
• Allowed Ports: ports you want to keep open — these have higher priority.
• Wildcard: block everything (*) and then only allow what’s explicitly listed.

Example:

[portblocker]
blocked_ports[]='*'
allowed_ports[]=22
allowed_ports[]=80
allowed_ports[]=443

This configuration creates a default deny policy, every port is blocked except SSH, HTTP, and HTTPS.

Default Protected Ports

To prevent accidents, some ports will always remain open, even if you set blocked_ports[]='*':

• BitNinja’s own ports.
• Core services: 20, 21, 22, 53, 80, 443, 465, 587, 993, 995.

If cPanel or Plesk is installed, their required ports are also auto-detected and excluded from blocking.

Practical Use Cases

1. Zero Trust by Default
   Start by blocking everything, then whitelist only what your apps actually need. This instantly reduces your attack surface.
2. Targeted Blocking
   Maybe you have some legacy services or unused admin panels. Just block their ports directly without touching the rest of the server.
3. Hybrid Policy
   Combine wildcard blocking with ranges of allowed ports. For example, allow only 2222:2250 if you have services clustered there.

Best Practices

• Document your open ports. Before you configure, list all services your server must expose (SSH, HTTP, database, monitoring).
• Use ports_never_use and ports_always_use. These give you extra control over which ports can/can’t be honeypotted.
• Watch out for FTP. If you use passive FTP, check the passive port range vs. honeypot startport to avoid overlap.
• Monitor logs. Incidents from blocked ports often indicate early scanning attempts.

Why It Matters

Port blocking isn’t glamorous, but it’s one of the simplest and most effective layers of defense:

• Attackers can’t exploit services that aren’t even reachable.
• A smaller attack surface = fewer incidents to investigate.
• Built-in intelligence ensures you don’t accidentally cut yourself off from critical services.

Conclusion

With BitNinja’s Customizable Port Blocking, you get the best of both worlds:

• granular control over what’s open,
• automation that avoids mistakes,
• plus honeypot integration for attacker detection.

Don’t let unused ports be your weakest link. Close them with BitNinja.

Ready to take full control of your server security?

Register now and start your 7-day free trial, no credit card required.
BitNinja gives you full access to all features, including port-level blocking, in every plan, no hidden fees.

Have questions or feedback? Feel free to reach out to us, we’re here to help.