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

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:

1. Scan open ports
2. Identify exposed services
3. Attempt repeated logins
4. 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]