Keeping the Gates: How log2table protects my OpenBSD servers

Running servers exposed to the internet is a constant battle. Every day, automated bots, scanners, and opportunistic attackers probe every open port, test every service, and look for the slightest weakness. In 2018, I've developed a tool called log2table that quietly and efficiently handles all of this — and I want to share how it works and what I've learned from running it in production.

The core idea

The principle behind log2table is simple but powerful: assign a weight to each suspicious event. Every time an attacker triggers a known bad pattern — a failed SSH attempt, a crafted HTTP request, a probe against a known vulnerability — that IP accumulates points. Once it crosses a threshold of 100 points, its IP address is automatically added to PF's bad_ip table and blocked.

All of this behaviour is driven by two configuration files. In parameters.py, you define the general settings and thresholds. In rules.py, you write classes that inherit from a Generic base and specify both the log patterns to watch (via regular expressions) and the consequences of hitting them. For the Hackers class, for instance, crossing the 100-point threshold triggers a 3600-second ban. The beauty of it is that log2table watches multiple log files against multiple regular expressions simultaneously — so an attacker doesn't get to probe quietly before being noticed. They're caught the moment they misbehave.

What years of data taught me

log2table has been running without a hitch across my OpenBSD firewalls for several years now, and the patterns I've observed have been genuinely instructive.

In the first months after deployment, attack traffic dropped dramatically. I remember thinking, somewhat naively: "They've understood they're not welcome here." But after about a year, the numbers crept back up. So I extended the ban duration from one hour to several days — and sure enough, the PF table shrank again. It seems that many of these attackers, faced with multi-day bans, simply moved on to easier targets.

But persistence has its own rhythm. This past year, the table started growing again. The landscape is always shifting.

The ban-for-life principle

The latest evolution of my approach is what I call ban for life for repeat offenders. Every day, I dump the bad_ip table from all PF and store it in a small database. Periodically — weekly or monthly — I review that database and rank the worst offenders: the IPs that keep coming back despite repeated bans. Those IPs get added to a static text file that PF loads at startup:

table <blockips> persist file "/etc/blockips"
block in log quick proto tcp from <blockips> to any

It's a permanent door shut on the most persistent bad actors.

Based on data I've collected since 3 months, I've banned for life 187 IPs. Those IPs are IP been listed more than 15x in PF tables. This means that despite a ban of several days, they comeback once access is re-established. Doing such malicious interventions more than 15x in 3 months time, I conclude we cannot hope they will manage those problems by them self.

Why this matters

I genuinely cannot imagine running internet-facing servers without something like log2table. An unprotected machine doesn't just face a security risk — it faces a performance risk. Attackers consume CPU cycles, fill log files, and saturate connections. Real users pay the price.

If you're running servers on the internet, I strongly encourage you to look closely at your log files. They tell a story, and it's rarely a quiet one. On Linux, tools like fail2ban cover similar ground. On OpenBSD — and likely FreeBSD too — PF's table system makes log2table an elegant and efficient solution.

The attackers aren't going away. But with the right tools, you can make sure they do.

Feel free to swap in your repo links for parameters.py and rules.py where mentioned. Let me know if you'd like a different tone — more technical, more casual, shorter, or structured differently!