A Lightweight Linux Firewall with Integrated Auto-Ban (nftables-primary backend)

Jani Willberg — Sun, 01 Mar 2026 12:37:29 +0000

Any publicly exposed Linux server will receive constant background
noise:

SSH brute-force attempts
SMTP authentication abuse
IMAP / POP3 login attempts
Port scanning
Automated service probing

This is normal on the modern internet.

The traditional protection stack usually looks like this:

A firewall (iptables, nftables, UFW, CSF…)
Fail2ban for log-based banning
Separate services handling detection and enforcement

It works — but it’s layered and fragmented.

MEF was built to simplify this model: a lightweight firewall service combined with an integrated auto-ban engine, designed with nftables as the primary backend.

What MEF Actually Is

MEF consists of two independent components.

mef — Firewall Loader

Loads persistent firewall rules from /etc/mef/mef.rules
Runs once at boot (systemd oneshot service)
Uses nftables primarily (iptables fallback supported)
Keeps rule management explicit and readable

This is the static firewall layer.

mefdaemon — Auto-Ban Engine

Monitors logs (systemd journal or standard log files)
Detects repeated authentication failures across services
Responds to suspicious behavior such as repeated connection attempts or scanning
Bans abusive IP addresses directly at the firewall level

This is the dynamic protection layer.

Both components can run independently — or together.

Multi-Service Abuse Detection

MEF is not limited to SSH.

Common attack patterns look like this:

Scan open ports
Identify exposed services
Attempt repeated logins
Retry across multiple services

Protection should not be protocol-specific.

MEF can respond consistently whether the target is:

Port 22 (SSH)
25 / 587 (SMTP)
143 / 993 (IMAP)
110 / 995 (POP3)
etc ...

The goal is practical mitigation of authentication abuse and hostile
probing.

nftables-First Enforcement

Instead of inserting firewall rules repeatedly, MEF relies on structured
rule handling.

Conceptually, enforcement can look like this:

nft add set inet filter banned_ips { type ipv4_addr; flags timeout; } nft add rule inet filter input ip saddr @banned_ips drop

When an IP crosses defined thresholds, it is added to the set. nftables
handles enforcement efficiently and cleanly.

This avoids:

Growing rule chains
Repeated rule insert overhead
Fragmented firewall logic

Lightweight by Design

MEF is intentionally minimal.

No heavy dependency stack
No complex jail abstraction layers
No bloated background processing
Designed for VPS and hosting environments

The focus is:

Practical abuse mitigation
Clear rule structure
Low resource usage

It is meant to run quietly in the background while protecting exposed
services.

What It Is Not

MEF is not:

A full IDS/IPS platform
A behavioral AI engine
An enterprise security appliance

It is:

A modular firewall + auto-ban system
Focused on real-world abuse patterns
Built around modern Linux firewall tooling

Why Not Just Fail2ban?

Fail2ban works well and has been battle-tested for years.

MEF differs in:

A simpler, modular structure
nftables-first enforcement
Optional RBL and cloud-based preemptive blocking
Minimal runtime dependencies

It is not meant to replace every security tool — but to offer a modern, lightweight alternative for common abuse scenarios.

Core Capabilities

Beyond basic firewall + log banning, MEF includes:

Dual-Stack Support

Native support for both IPv4 and IPv6 environments.

RBL Integration

Optional DNS-based Real-time Blackhole List (RBL) lookups allow blocking known malicious IP addresses proactively.

Community Cloud Protection

Optional cloud-based threat lookups enable shared intelligence between installations, allowing preemptive blocking of known abusive IPs.

Port Scan Detection

Basic port scan detection by monitoring connection attempts across multiple unique destination ports over time.

Flexible Allow/Deny Control

Support for static and dynamic whitelists and blacklists, with automatic rule updates.

Minimal Dependency Footprint

No Python or Perl runtime requirements. Designed to keep CPU and memory usage low.

Use Case

MEF fits environments where:

Services are publicly exposed
Authentication abuse is common
Administrators prefer nftables over legacy stacks
Minimal overhead is important

Feedback Welcome

I’m interested in any feedback from real-world deployments, testing, or production use.

In particular, I’m exploring the idea of more service-specific handling based on live activity data.

Project repository: [https://github.com/jwillberg/mef]

DEV Community: Jani Willberg