🚀 ZFW Security Expansion — Community Security Project for ZimaOS / Projet communautaire de sécurité pour ZimaOS

Insight & Feedback
1

:shield: ZFW Security Expansion Proposal

By-Roket Community Contribution for ZimaOS

:united_kingdom: ENGLISH

:waving_hand: Introduction

Hello ZimaOS community,

I’m By-Roket, a Systems Administrator / IT Infrastructure Manager, with a strong interest in self-hosting, networking, virtualization, Docker and infrastructure security.

I recently adopted ZimaOS and quickly became interested in its philosophy:

Making self-hosting and server administration accessible without requiring every user to become a Linux or networking specialist.

While using and testing ZimaOS, I also started looking closely at areas where security, visibility and administration could be improved.

My objective is not to criticize what already exists.

It is rather to:

  • understand what is missing;

  • build on good existing foundations;

  • improve security where useful;

  • keep administration simple;

  • contribute practical solutions to the ZimaOS community.

This is what brought me to ZFW.

:one: Original ZFW Project

First of all, full credit goes to the original project and its maintainer:

Holger Kuehn / Lintux

:link: Upstream repository

https://github.com/chicohaager/zfw

ZFW already provides an excellent security foundation for ZimaOS.

It adds one particularly important component that ZimaOS does not currently provide by default:

A real host firewall integrated directly into the ZimaOS dashboard.

Existing ZFW strengths already include

  • :shield: Host firewall integration;

  • :spouting_whale: Docker published-port filtering through DOCKER-USER;

  • :globe_with_meridians: IPv4 and IPv6 support;

  • :counterclockwise_arrows_button: Safe-Apply protection;

  • :eye: Exposure visibility;

  • :bar_chart: Firewall events and connection information;

  • :package: Docker/container-aware firewall rules;

  • :globe_showing_europe_africa: GeoIP functionality;

  • :down_arrow: Inbound rules;

  • :up_arrow: Outbound rules;

  • :vertical_traffic_light: Connection rate limiting;

  • :three_o_clock: Scheduled firewall rules;

  • :locked_with_key: ZimaOS session authentication for its control API.

ZFW therefore already provides a very strong base.

My intention is not to replace ZFW and not to create a closed competing product.

My preferred direction is:

Collaborate with the existing project, propose improvements upstream whenever possible, and keep development aligned with the ZimaOS community.

:two: ZFW Architecture & Security Model

One part of the current architecture that should remain is the separation between the firewall engine and its management interface.

The ZFW control daemon listens only on:

127.0.0.1

The ZimaOS gateway then provides access to the module.

This is the correct security model.

The control daemon does not need to listen on:

0.0.0.0

even when services hosted on ZimaOS are accessible through:

  • LAN;

  • VPN;

  • NAT;

  • UPnP;

  • IPv6;

  • reverse proxy;

  • Zima Net;

  • other tunnels.

The daemon is the control plane.

The firewall itself protects traffic on the network interfaces.

Conceptually

ZimaOS UI
    │
    â–Ľ
ZimaOS Gateway
    │
    â–Ľ
ZFW Control Daemon
127.0.0.1 only
    │
    â–Ľ
Firewall Engine
    │
    ├── eth0
    ├── eth1
    ├── Docker
    ├── IPv4
    ├── IPv6
    ├── VPN
    └── other interfaces

Keeping the control API local prevents it from becoming an additional exposed network service.

:three: Vision — ZimaOS Host Security Center

The long-term idea would be to progressively evolve ZFW into a more complete:

ZimaOS Host Security Center

without turning ZimaOS into a complicated enterprise firewall.

A normal user should easily be able to answer four questions:

:magnifying_glass_tilted_right: What is exposed?
:bust_in_silhouette: Who can access it?
:white_check_mark: Why is it allowed?
:prohibited: What has been blocked?

Advanced configuration should remain available, but the default interface should remain understandable.

:four: Network Interface Management

ZFW could automatically detect available interfaces such as:

  • Ethernet;

  • Wi-Fi;

  • Docker bridges;

  • WireGuard;

  • Tailscale;

  • Zima Net;

  • other VPN interfaces;

  • tunnel interfaces.

Instead of treating every interface identically, the administrator could classify them.

Example

eth0      → Protected LAN
eth1      → Management network
wg0       → Trusted VPN
docker0   → Docker
tun0      → Zima Net

Possible states:

  • :shield: Protected;

  • :white_check_mark: Trusted;

  • :prohibited: Excluded;

  • :wrench: Management only.

This could help users with multiple LANs, VLANs, VPNs or dedicated management networks.

:five: Configurable Auto-Ban / Brute-Force Protection

ZFW already contains threat-detection foundations.

The idea would be to extend them into a complete Auto-Ban system configurable directly from the UI.

Example

10 blocked attempts
within 60 seconds

→ Ban the source IP

The administrator could configure:

  • number of attempts;

  • detection window;

  • monitored ports;

  • monitored services;

  • IPv4 / IPv6;

  • enabled / disabled state.

Default behaviour proposed

Instead of automatically unbanning an attacker after a predefined delay:

Bans could remain persistent until administrator action.

:six: Banned IP Management

A dedicated page could display all blocked sources.

Example

IP Address
IPv4 / IPv6
Public / Private
Country
Reason
Target Port
Target Service
First Detection
Last Detection
Number of Attempts
Status

Available actions

  • :unlocked: Unblock;

  • :locked: Keep blocked;

  • :white_check_mark: Add to whitelist;

  • :memo: Add administrator note.

Example:

185.xxx.xxx.xxx
Public IPv4
Country: XX
Reason: SSH brute-force
Port: 22
Attempts: 46

Status: BLOCKED

:seven: Global Whitelist & Blacklist

:white_check_mark: Whitelist

Addresses or networks that automatic protections should never block.

Examples:

192.168.70.0/24
10.10.10.0/24
Trusted VPN subnet
Administrator workstation
Management VLAN

:prohibited: Blacklist

Manual permanent blocking of:

  • IPv4;

  • IPv6;

  • CIDR networks.

Domain blocking could potentially be investigated later, but actual firewall enforcement should preferably remain based on resolved IP addresses and networks.

:eight: Local Anti-Flood / Anti-DDoS Protection

Another protection layer could defend the ZimaOS host against abusive traffic that actually reaches it.

Possible protections:

  • SYN flood;

  • excessive new connections;

  • excessive simultaneous connections per source;

  • UDP flood;

  • ICMP flood;

  • abnormal connection bursts;

  • service-specific connection abuse.

Possible settings

Maximum new connections / second
Maximum simultaneous connections / IP
Detection window
Target service
Action

Possible actions

Rate Limit
Drop
Auto-Ban

:warning: Important limitation

This feature should never be advertised as protection against every type of DDoS attack.

If someone sends:

5 Gbit/s

toward a connection limited to:

1 Gbit/s

the Internet connection may already be saturated before packets reach ZimaOS.

That type of attack requires upstream protection from:

  • ISP;

  • router/firewall;

  • hosting provider;

  • CDN;

  • dedicated anti-DDoS infrastructure.

The goal here would instead be:

Protect the ZimaOS host and its services against abusive traffic that reaches the machine.

:nine: Improved GeoIP Protection

ZFW already provides GeoIP foundations.

The objective would therefore be to improve their accessibility and presentation.

:globe_showing_europe_africa: Inbound GeoIP

Example:

ALLOW all countries
EXCEPT:

RU
CN
KP
...

or:

ALLOW ONLY:

FR
BE
CH
DE

:globe_showing_americas: Outbound GeoIP

Example:

Application:
IoT Service

Block outbound connections to:
Selected countries

This could be useful for:

  • IoT-related applications;

  • externally downloaded applications;

  • applications expected to communicate only with specific regions;

  • sensitive services.

:ten: Improved Exposure Dashboard

One feature I would particularly like to explore is an improved Exposure dashboard.

Example

Service
Port
Protocol
Interface
Host / Docker
LAN Access
VPN Access
Potential WAN Exposure
Firewall Protection

Example result

Jellyfin
Port: 8096
Docker

LAN:        âś“
VPN:        âś“
WAN:        Possible
Protection: Active

Another example:

SSH
Port: 22
Host Service

LAN:        âś“
VPN:        âś“
WAN:        âś—
Protection: Active

And:

Admin Panel
Port: 8080
Docker

LAN:        âś“
WAN:        Possible

âš  Warning

The objective is simple:

Users should not need to inspect Docker mappings, sockets or iptables manually just to understand their exposure.

:one::one: NAT / UPnP / WAN Exposure Detection

Where technically possible, ZFW could also warn about possible external exposure caused by:

  • UPnP;

  • NAT-PMP;

  • router port forwarding;

  • public IPv6;

  • reverse tunnels;

  • remote access services.

The wording should remain conservative.

For example:

âš  Potential WAN exposure detected

rather than:

This service is definitely accessible from the Internet

unless ZFW can actually verify that.

Avoiding false security information is important.

:one::two: Application-Aware Firewall Rules

Firewall rules should increasingly follow applications, not just static port numbers.

Instead of:

TCP 8096
TCP 8920
UDP xxxx

the administrator could define:

Jellyfin
→ LAN
→ Trusted VPN

The firewall policy should ideally continue to follow the application when:

  • the container is recreated;

  • its internal IP changes;

  • published ports change;

  • the application is updated.

This would make firewall management much easier for normal ZimaOS users.

:one::three: User → Application Access Control

Another feature worth investigating would be access control based on ZimaOS users.

Concept

Administrator
→ All applications


Family User
→ Jellyfin
→ Files


Home Automation User
→ Home Assistant only

However, this feature must remain technically honest.

A network firewall normally sees:

IP Address
Connection
Protocol
Port

It does not automatically know which human is using the browser.

Reliable per-user control therefore requires a trusted identity layer such as:

  • authenticated gateway;

  • reverse proxy authentication;

  • usable ZimaOS identity information;

  • another secure authentication mechanism.

If a secure association between identity and network connection cannot be established:

ZFW should not pretend that it can provide reliable user-based firewall control.

This feature should therefore begin as a research area, not as a promised capability.

:one::four: Safe-Apply Improvements

Safe-Apply is already one of the most important ZFW features.

That philosophy should remain central.

Possible improvements:

  • :stopwatch: clearer rollback countdown;

  • :green_circle: visible current Safe-Apply state;

  • :shield: protected management IP;

  • :globe_with_meridians: protected management network;

  • :sos_button: optional rescue network;

  • :floppy_disk: automatic configuration snapshot before Apply;

  • :right_arrow_curving_left: easier restoration of the last known-good configuration.

A firewall should never make recovery harder than the problem it is trying to solve.

:one::five: Configuration Backup & History

Possible configuration-management features:

  • configuration snapshots;

  • last known-good configuration;

  • manual backup;

  • restore;

  • rule history;

  • change history.

Example

2026-09-03 14:32

Rule:
Jellyfin LAN

Previous source:
192.168.1.0/24

New source:
192.168.70.0/24

This would also make troubleshooting much easier.

:one::six: Dry-Run / Simulation Mode

Before applying a firewall configuration, ZFW could simulate the expected result.

Example

SSH
192.168.70.20
→ ALLOWED

Jellyfin
192.168.70.25
→ ALLOWED

Jellyfin
10.20.30.5
→ BLOCKED

SMB
Guest VLAN
→ BLOCKED

This could significantly reduce configuration errors.

:one::seven: IPv4 / IPv6 Parity

IPv6 should never become the forgotten side door.

Every important security function should clearly indicate whether it protects:

IPv4  âś“
IPv6  âś“

or clearly report a limitation:

IPv4  âś“
IPv6  âś—

The objective is to avoid improving IPv4 security while silently leaving a different path open through IPv6.

:one::eight: Privacy, Transparency & Trust

Trust is particularly important for a security module.

The principles I would like to preserve are:

:unlocked: Open Source

The source code should remain publicly inspectable.

:prohibited: No Added Telemetry

No usage analytics added by this project.

:house: Local-First

Firewall rules, security events and banned addresses remain on the user’s ZimaOS system.

:cloud: No Mandatory Cloud

Core firewall functionality should work locally.

:locked_with_key: No Hidden Remote Control

No external service should be able to silently change firewall rules.

:bar_chart: No External Collection of Firewall Events

Security information should remain local unless the administrator explicitly configures an external integration.

:one::nine: Licensing & Upstream Coordination

Before publishing any modified ZFW build, I want to clarify the licensing situation directly with the original maintainer.

The current ZFW project metadata identifies the project as using the:

ISC License

However, I could not find a dedicated LICENSE file at the repository root.

Before publishing any derived beta build, I would therefore like to obtain explicit confirmation regarding:

  • modification rights;

  • redistribution;

  • attribution requirements;

  • use of the ZFW name;

  • preferred contribution workflow.

Until this is clarified, this project remains:

An architecture and community contribution proposal — not a redistributed ZFW release.

Technical research, isolated testing and proof-of-concept development can continue.

However, I do not intend to publicly distribute a modified ZFW beta until the licensing and upstream position are clearly confirmed.

My preferred outcome remains:

Upstream collaboration whenever possible.

:two::zero: Development & Testing Strategy

Development should initially happen in isolated test environments rather than on a production ZimaOS server.

Planned environments may include:

  • Proxmox;

  • VMware;

  • ZimaOS virtual machines;

  • snapshots;

  • multiple virtual network interfaces;

  • Docker test applications;

  • IPv4;

  • IPv6;

  • VPN;

  • tunnel scenarios.

Failure scenarios should be deliberately tested.

Example

Bad firewall rule
→ Can Safe-Apply recover?


Docker restart
→ Are firewall protections restored?


ZimaOS reboot
→ Does ZFW return correctly?


Network interface changes
→ Can the administrator still recover?


IPv6 enabled
→ Are protections equivalent to IPv4?

The objective is not only to test whether a feature works.

It is also to test:

What happens when it fails?

:two::one: Current Project Status

At this stage, this project is:

A design and architecture proposal

There is currently:

  • no public modified By-Roket ZFW release;

  • no public beta fork;

  • no replacement for the official ZFW project.

Before moving toward a distributable beta, I would like feedback from:

  • Holger / Lintux;

  • IceWhale;

  • existing ZFW users;

  • ZimaOS community members;

  • network/security users.

:two::two: Feedback Requested

I would especially appreciate feedback on the following questions:

Architecture

Which features belong directly inside ZFW?

Which features should potentially remain separate modules?

Security

Are there important attack scenarios missing from this proposal?

Networking

Which network configurations should be tested?

Usability

Which functions would actually help normal ZimaOS users?

Compatibility

Which ZimaOS services or networking components should never be accidentally filtered?

:bullseye: Final Goal

The objective can be summarized simply:

Build on the excellent foundation already provided by ZFW, fill useful security gaps, keep everything transparent, and make ZimaOS safer without making it harder to use.

If Holger is interested in collaborating or accepting some of these improvements directly upstream, that would be my preferred direction.

— By-Roket

:france: FRANÇAIS

:shield: Proposition d’évolution de ZFW Security

Contribution communautaire By-Roket pour ZimaOS

:waving_hand: Introduction

Bonjour à toute la communauté ZimaOS,

Je suis By-Roket, Responsable / Administrateur Systèmes et infrastructures IT, avec un intérêt particulier pour le self-hosting, les réseaux, la virtualisation, Docker et la sécurité des infrastructures.

J’ai récemment adopté ZimaOS et je me suis rapidement intéressé à sa philosophie :

Rendre le self-hosting et l’administration d’un serveur accessibles sans obliger chaque utilisateur à devenir spécialiste Linux ou réseau.

En utilisant et en testant ZimaOS, j’ai également commencé à examiner les domaines dans lesquels la sécurité, la visibilité et l’administration pourraient encore évoluer.

Mon objectif n’est pas de critiquer ce qui existe déjà.

Il est plutĂ´t de :

  • comprendre les fonctions manquantes ;

  • s’appuyer sur les bonnes bases existantes ;

  • amĂ©liorer la sĂ©curitĂ© lorsque cela est utile ;

  • conserver une administration simple ;

  • proposer des solutions utiles Ă  la communautĂ© ZimaOS.

C’est ce qui m’a amené à m’intéresser à ZFW.

:one: Projet ZFW original

Tout d’abord, le mérite du projet original revient à son développeur et mainteneur :

Holger Kuehn / Lintux

:link: DĂ©pĂ´t upstream

https://github.com/chicohaager/zfw

ZFW constitue déjà une excellente base de sécurité pour ZimaOS.

Il apporte notamment un élément particulièrement important qui n’est actuellement pas présent nativement dans ZimaOS :

Un véritable pare-feu hôte intégré directement au tableau de bord ZimaOS.

Parmi les fonctions et points forts actuels de ZFW

  • :shield: Pare-feu hĂ´te intĂ©grĂ© ;

  • :spouting_whale: filtrage des ports Docker publiĂ©s via DOCKER-USER ;

  • :globe_with_meridians: prise en charge IPv4 et IPv6 ;

  • :counterclockwise_arrows_button: Safe-Apply ;

  • :eye: visibilitĂ© des services exposĂ©s ;

  • :bar_chart: Ă©vĂ©nements firewall et informations sur les connexions ;

  • :package: règles prenant en compte les conteneurs Docker ;

  • :globe_showing_europe_africa: fonctions GeoIP ;

  • :down_arrow: règles entrantes ;

  • :up_arrow: règles sortantes ;

  • :vertical_traffic_light: limitation du nombre de connexions ;

  • :three_o_clock: règles horaires ;

  • :locked_with_key: authentification de l’API avec les sessions ZimaOS.

ZFW fournit donc déjà un socle particulièrement solide.

Mon objectif n’est ni de remplacer ZFW, ni de créer un produit fermé concurrent.

Ma préférence serait :

Collaborer avec le projet existant, proposer les améliorations upstream lorsque cela est possible et rester dans l’esprit de la communauté ZimaOS.

:two: Architecture et modèle de sécurité ZFW

Une partie importante de l’architecture actuelle doit selon moi être conservée : la séparation entre le moteur firewall et son interface d’administration.

Le daemon de contrĂ´le ZFW Ă©coute uniquement sur :

127.0.0.1

La passerelle ZimaOS permet ensuite à l’interface d’accéder au module.

C’est le bon modèle de sécurité.

Le daemon n’a pas besoin d’écouter sur :

0.0.0.0

mĂŞme lorsque certains services ZimaOS sont accessibles via :

  • LAN ;

  • VPN ;

  • NAT ;

  • UPnP ;

  • IPv6 ;

  • reverse proxy ;

  • Zima Net ;

  • autres tunnels.

Le daemon représente le plan de contrôle.

Le moteur firewall protège quant à lui le trafic des interfaces réseau.

Schéma simplifié

Interface ZimaOS
      │
      â–Ľ
Passerelle ZimaOS
      │
      â–Ľ
Daemon ZFW
127.0.0.1 uniquement
      │
      â–Ľ
Moteur Firewall
      │
      ├── eth0
      ├── eth1
      ├── Docker
      ├── IPv4
      ├── IPv6
      ├── VPN
      └── autres interfaces

:three: Vision — Centre de sécurité ZimaOS

L’objectif à plus long terme serait de faire progressivement évoluer ZFW vers un véritable :

Centre de sécurité hôte pour ZimaOS

sans transformer ZimaOS en pare-feu d’entreprise compliqué.

Un utilisateur classique devrait facilement pouvoir répondre à quatre questions :

:magnifying_glass_tilted_right: Qu’est-ce qui est exposé ?
:bust_in_silhouette: Qui peut y accéder ?
:white_check_mark: Pourquoi cet accès est-il autorisé ?
:prohibited: Qu’est-ce qui a été bloqué ?

Les réglages avancés resteraient accessibles lorsque nécessaire.

:four: Gestion des interfaces réseau

ZFW pourrait automatiquement détecter :

  • Ethernet ;

  • Wi-Fi ;

  • bridges Docker ;

  • WireGuard ;

  • Tailscale ;

  • Zima Net ;

  • autres VPN ;

  • autres tunnels.

L’administrateur pourrait définir pour chaque interface :

  • :shield: ProtĂ©gĂ©e ;

  • :white_check_mark: Fiable ;

  • :prohibited: Exclue ;

  • :wrench: Administration uniquement.

Exemple

eth0      → LAN protégé
eth1      → Réseau d’administration
wg0       → VPN fiable
docker0   → Docker
tun0      → Zima Net

:five: Auto-Ban / Protection brute-force configurable

ZFW possède déjà des bases permettant de détecter certains comportements suspects.

L’idée serait d’étendre cette base en véritable système Auto-Ban configurable directement depuis l’interface.

Exemple

10 tentatives bloquées
en moins de 60 secondes

→ Bannissement de l’IP source

L’administrateur pourrait choisir :

  • nombre de tentatives ;

  • fenĂŞtre de dĂ©tection ;

  • ports concernĂ©s ;

  • services concernĂ©s ;

  • IPv4 / IPv6 ;

  • activation / dĂ©sactivation.

Comportement proposé par défaut

Plutôt qu’un déblocage automatique après quelques heures :

Le bannissement pourrait rester permanent jusqu’à intervention de l’administrateur.

:six: Gestion des IP bannies

Une page dédiée pourrait afficher :

Adresse IP
IPv4 / IPv6
Publique / Privée
Pays
Motif
Port ciblé
Service ciblé
Première détection
Dernière détection
Nombre de tentatives
État

Actions

  • :unlocked: DĂ©bloquer ;

  • :locked: Laisser bloquĂ©e ;

  • :white_check_mark: Ajouter Ă  la liste blanche ;

  • :memo: Ajouter une note.

:seven: Listes blanche et noire globales

:white_check_mark: Liste blanche

Adresses ou réseaux ne devant jamais être bloqués automatiquement.

Exemples :

Réseau d’administration
Poste administrateur
VPN de confiance
VLAN Management

:prohibited: Liste noire

Blocage manuel de :

  • IPv4 ;

  • IPv6 ;

  • rĂ©seaux CIDR.

La gestion de domaines pourrait éventuellement être étudiée plus tard, mais le moteur firewall devrait idéalement continuer à travailler sur de véritables IP et réseaux.

:eight: Protection locale anti-flood / anti-DDoS

Une autre couche pourrait protéger la machine contre le trafic abusif qui arrive réellement jusqu’à elle.

Exemples :

  • SYN flood ;

  • trop de nouvelles connexions ;

  • trop de connexions simultanĂ©es par IP ;

  • UDP flood ;

  • ICMP flood ;

  • rafales de connexions ;

  • abus ciblĂ© contre un service.

Paramètres possibles

Connexions nouvelles maximum / seconde
Connexions simultanées maximum / IP
Fenêtre de détection
Service ciblé
Action

Actions possibles

Limiter
Bloquer
Auto-Ban

:warning: Limite importante

Cette fonction ne doit pas être présentée comme une solution miracle contre tous les DDoS.

Si une connexion Internet de :

1 Gbit/s

reçoit :

5 Gbit/s

de trafic malveillant, la connexion peut être saturée avant même que ZimaOS puisse intervenir.

La protection doit alors intervenir en amont :

  • opĂ©rateur ;

  • routeur/firewall ;

  • hĂ©bergeur ;

  • CDN ;

  • solution anti-DDoS.

L’objectif de ZFW serait plutôt :

Protéger la machine ZimaOS et ses services contre le trafic abusif qui atteint réellement le serveur.

:nine: GeoIP amélioré

ZFW possède déjà des fonctions GeoIP.

L’objectif serait donc d’améliorer leur présentation et leur facilité d’utilisation.

:globe_showing_europe_africa: Entrant

Tout autoriser
SAUF :

Pays sélectionnés

ou :

Autoriser UNIQUEMENT :

FR
BE
CH
DE

:globe_showing_americas: Sortant

Exemple :

Application :
Service IoT

Bloquer les connexions
vers certains pays

:ten: Vue Exposition améliorée

Une vue Exposition pourrait regrouper :

Service
Port
Protocole
Interface
HĂ´te / Docker
Accès LAN
Accès VPN
Exposition WAN potentielle
Protection Firewall

Exemple

Jellyfin
Port : 8096
Docker

LAN :        âś“
VPN :        âś“
WAN :        Possible
Protection : Active

L’objectif :

Comprendre immédiatement ce qui écoute et ce qui peut être atteint sans devoir analyser manuellement Docker, les sockets ou iptables.

:one::one: DĂ©tection NAT / UPnP / exposition WAN

Lorsque cela est techniquement possible, ZFW pourrait signaler une exposition potentielle liée à :

  • UPnP ;

  • NAT-PMP ;

  • redirections de ports ;

  • IPv6 publique ;

  • reverse tunnels ;

  • services d’accès distant.

Exemple :

⚠ Exposition WAN potentielle détectée

Il faudra néanmoins éviter d’affirmer qu’un service est réellement accessible depuis Internet si cela n’a pas pu être vérifié.

:one::two: Règles orientées applications

L’objectif serait de gérer progressivement les applications elles-mêmes plutôt que simplement leurs ports.

Exemple :

Jellyfin
→ LAN
→ VPN fiable

La règle devrait idéalement continuer à fonctionner lorsque :

  • le conteneur est recrĂ©Ă© ;

  • son IP interne change ;

  • ses ports sont remappĂ©s ;

  • l’application est mise Ă  jour.

:one::three: Contrôle Utilisateur → Application

Une autre piste serait d’étudier :

Utilisateur ZimaOS
→ Applications autorisées

Exemple

Administrateur
→ Toutes les applications


Utilisateur famille
→ Jellyfin
→ Fichiers

Cependant, un pare-feu voit principalement :

Adresse IP
Connexion
Port
Protocole

Il ne sait pas naturellement quelle personne utilise un navigateur.

Un contrôle fiable par utilisateur nécessitera donc une vraie couche d’identité :

  • passerelle authentifiĂ©e ;

  • reverse proxy ;

  • identitĂ© native ZimaOS exploitable ;

  • autre mĂ©canisme sĂ»r.

Cette fonction doit donc commencer comme axe de recherche, et non comme promesse.

:one::four: Amélioration de Safe-Apply

Safe-Apply est déjà l’une des fonctions les plus importantes de ZFW.

Elle devrait rester au centre du projet.

Améliorations possibles :

  • :stopwatch: compte Ă  rebours plus visible ;

  • :green_circle: Ă©tat du rollback ;

  • :shield: IP d’administration protĂ©gĂ©e ;

  • :globe_with_meridians: rĂ©seau d’administration protĂ©gĂ© ;

  • :sos_button: rĂ©seau de secours ;

  • :floppy_disk: snapshot automatique avant Apply ;

  • :right_arrow_curving_left: restauration simplifiĂ©e de la dernière configuration fonctionnelle.

:one::five: Sauvegardes et historique

Fonctions possibles :

  • snapshots de configuration ;

  • dernière configuration valide ;

  • sauvegarde manuelle ;

  • restauration ;

  • historique des règles ;

  • historique des modifications.

:one::six: Mode simulation / Dry-Run

Avant d’appliquer une configuration :

SSH
192.168.70.20
→ AUTORISÉ

Jellyfin
LAN
→ AUTORISÉ

Jellyfin
Guest VLAN
→ BLOQUÉ

SMB
Guest VLAN
→ BLOQUÉ

Cette fonction pourrait considérablement réduire les erreurs.

:one::seven: Parité IPv4 / IPv6

IPv6 ne doit jamais devenir une porte secondaire oubliée.

Chaque fonction importante devrait indiquer clairement :

IPv4  âś“
IPv6  âś“

ou signaler clairement ses limitations.

:one::eight: Confidentialité, transparence et confiance

Les principes que je souhaite conserver sont :

:unlocked: Code source ouvert

Le code doit rester inspectable.

:prohibited: Pas de télémétrie ajoutée

Pas d’analytics ou de suivi d’utilisation ajouté par ce projet.

:house: Fonctionnement local

Les règles, événements et IP bannies restent sur la machine ZimaOS.

:cloud: Aucun cloud obligatoire

Les fonctions principales doivent fonctionner localement.

:locked_with_key: Aucun contrôle distant caché

Aucun service externe ne doit pouvoir modifier silencieusement le firewall.

:bar_chart: Pas de collecte externe des événements

Sauf configuration volontaire de l’administrateur.

:one::nine: Licence et coordination upstream

Avant de publier une version modifiée de ZFW, je souhaite clarifier directement la situation de la licence avec le mainteneur original.

Les métadonnées actuelles du projet indiquent :

Licence ISC

Cependant, je n’ai pas trouvé de fichier LICENSE dédié à la racine du dépôt.

Je souhaite donc obtenir une confirmation concernant :

  • les droits de modification ;

  • la redistribution ;

  • l’attribution ;

  • l’utilisation du nom ZFW ;

  • la mĂ©thode souhaitĂ©e pour contribuer.

En attendant, ce projet reste :

Une proposition d’architecture et de contribution communautaire — pas une nouvelle distribution ZFW.

Les recherches, tests en VM et preuves de concept peuvent continuer.

Cependant, je ne souhaite pas distribuer publiquement une bêta dérivée avant d’avoir clarifié ce point.

Ma préférence reste :

La collaboration upstream lorsque cela est possible.

:two::zero: Méthode de développement et de test

Le développement commencera dans des environnements isolés plutôt que sur un serveur ZimaOS de production.

Environnements envisagés :

  • Proxmox ;

  • VMware ;

  • VM ZimaOS ;

  • snapshots ;

  • plusieurs interfaces rĂ©seau ;

  • applications Docker de test ;

  • IPv4 ;

  • IPv6 ;

  • VPN ;

  • tunnels.

Les scénarios d’échec devront être volontairement testés.

Exemple

Mauvaise règle firewall
→ Safe-Apply permet-il de récupérer ?


Redémarrage Docker
→ Les protections restent-elles actives ?


Redémarrage ZimaOS
→ ZFW revient-il correctement ?


Modification d’interface
→ L’administrateur conserve-t-il un accès ?

Le but n’est pas seulement de vérifier :

Est-ce que cela fonctionne ?

mais Ă©galement :

Que se passe-t-il lorsque cela ne fonctionne pas ?

:two::one: État actuel du projet

À ce stade, il s’agit :

d’une proposition de conception et d’architecture

Il n’existe actuellement :

  • aucune version ZFW publique modifiĂ©e par By-Roket ;

  • aucune bĂŞta publique ;

  • aucun remplacement du projet ZFW officiel.

Avant d’aller vers une bêta distribuable, je souhaite recueillir les avis :

  • de Holger / Lintux ;

  • d’IceWhale ;

  • des utilisateurs actuels de ZFW ;

  • de la communautĂ© ZimaOS ;

  • d’utilisateurs spĂ©cialisĂ©s rĂ©seau/sĂ©curitĂ©.

:two::two: Retours recherchés

Je serais particulièrement intéressé par vos avis concernant :

Architecture

Quelles fonctions devraient être intégrées directement dans ZFW ?

Quelles fonctions devraient éventuellement rester dans des modules séparés ?

Sécurité

Quels scénarios d’attaque importants manquent dans cette proposition ?

RĂ©seau

Quelles architectures réseau devraient être testées ?

Simplicité

Quelles fonctions seraient réellement utiles à un utilisateur ZimaOS classique ?

Compatibilité

Quels services ou composants ZimaOS doivent absolument rester protégés contre une mauvaise règle ?

:bullseye: Objectif final

L’objectif peut être résumé simplement :

S’appuyer sur l’excellente base déjà fournie par ZFW, combler certains besoins utiles en matière de sécurité, conserver un projet transparent et rendre ZimaOS plus sûr sans le rendre plus difficile à utiliser.

Si Holger souhaite collaborer ou intégrer directement certaines évolutions dans le projet upstream, ce serait ma direction privilégiée.

— By-Roket

6 Likes
2

Great idea! I’ve actually already started working on a similar IP Blocklist project myself and have it at a point where it’s functional and could potentially be integrated or combined with a larger security project like this.

At the moment, I’m busy working on another project, so I haven’t had enough time to continue developing the IP Blocklist further. But the current version is already working quite well.

I’ll attach a screenshot of my project so you can see what I’ve been working on.

image
image1920Ă—896 407 KB

3 Likes
3

Hi By-Roket,

Thank you — this is the most thought-through proposal ZFW has received, and three
things in it tell me you read the code and not just the README: keeping the control
daemon on 127.0.0.1, refusing to advertise anti-DDoS as something a host firewall
cannot be, and treating user → application rules as a research question instead of a
feature promise. That last one is exactly right: a packet filter sees an address, not
a person. Being honest about a limitation is worth more to me in a security module
than a long feature list.

So, short answer on collaboration: yes, gladly — and upstream is my preference too.

Licensing. You are right, and thank you for checking before building anything.
mod-store/zfw.yaml declares license: ISC, but there is no LICENSE file in the
repository root, so GitHub reports no license at all. That is an omission on my side,
not a restriction. I will add the ISC LICENSE file (© Holger Kuehn) as soon as I am
back at a keyboard. Until it is there, take this post as explicit permission to
modify and redistribute under ISC with attribution.

One request on the name: please keep ZFW for builds that come out of the upstream
repository, and give your experimental builds a distinct name (for example “ZFW
Security Expansion”). Not a legal point — it keeps users from filing bugs against the
wrong project. Once changes are merged upstream, the question disappears by itself.

Workflow. Pull requests against master on GitHub - chicohaager/zfw: Host firewall for ZimaOS — a standalone module with a web UI and a live security dashboard. Default-drop INPUT allowlist + DOCKER-USER blocklist, IPv6-aware, dead-man Safe-Apply, GeoIP, threat detection. · GitHub. Small, one
topic per PR — this is a firewall, and every merge has to be reviewable against the
question “what happens when this rule is wrong”. For anything touching the rule model
or the apply path, please open an issue first so we agree on the shape before you
write the code.

Where I would start, if you want the highest-value contribution first: your test
matrix. Proxmox/VMware VMs, several NICs, VLANs, IPv6, deliberate failure scenarios.
I do not have that, and it is the single thing that would improve ZFW most. The failure
questions you listed — bad rule, does Safe-Apply recover; Docker restart, do the rules
come back; reboot; IPv6 parity — are exactly the ones I want answered by something
other than my own opinion.

Two notes so you do not rebuild what already exists:

  • The threat classifier already flags port scans (≥10 distinct destination ports from
    one source within a minute) and brute force (≥20 hits on a monitored port), and shows
    them as tags in the Events tab. It only flags — nothing writes a block rule from
    it. So Auto-Ban is an enforcement layer on top of an existing classifier, not a new
    subsystem. That is a well-scoped first feature.
  • The UI currently has seven tabs: Firewall, Rules, Exposure, Events, Connections,
    Audit, Versions. The README still describes an older five-section layout — my fault,
    I will fix it. Please read the running UI, not the README, when you check what exists.

@isanto1306 — an IP blocklist is precisely the enforcement half missing above. I would
be interested in that too; if it can be shaped as a ZFW rule source rather than a
separate daemon, it fits.

One caveat on my side: I am on holiday until Sunday, so my replies will be slow until
then. That is scheduling, not lack of interest — I will come back to the architecture
questions properly
— Holger / Lintuxer

3 Likes
4

Hi Holger,

thanks — that is actually very interesting.

My IP Blocklist project is already functional and currently uses a large IP blocklist together with ipset/iptables to block matching source IPs. It also already collects statistics such as blocked packets, blocked traffic, the last blocked IPs and related information.

I had originally designed it as a separate dashboard, but I like your idea of eventually turning the blocklist itself into a ZFW rule source instead of keeping it as a completely separate daemon. That could make much more sense in the long term and would avoid duplicating firewall functionality.

At the moment I’m heavily focused on another project, so I haven’t had enough time to continue developing the IP Blocklist further. But the basic functionality is already working.

Once I have more time, I’d definitely be interested in looking at how it could fit into ZFW cleanly.

Enjoy the rest of your holiday — no hurry from my side.

2 Likes
5

Hi,isanto1306

Thank you for sharing your work — I think your blocklist/IPSet and dashboard approach could be very useful for the future development of ZFW.

Before going further, I would prefer that we coordinate with Holger/Lintux as the official ZFW maintainer, so we can follow the architecture and contribution workflow he considers appropriate and avoid creating parallel implementations.

When the time comes, I would be very interested in learning more about your work, especially:

  • the source/provider of your IP blocklist;

  • how often it is updated;

  • IPv4/IPv6 support;

  • how you currently integrate it with ipset / iptables;

  • how the dashboard collects its statistics;

  • and, if possible, the code or architecture behind it.

This will help us evaluate the reliability of the data source and see how your work could potentially integrate cleanly into ZFW rather than becoming a separate firewall component.

For now, I suggest we wait for Holger’s guidance on how he would prefer us to exchange technical information and organize collaboration, so we can start on a clean and coordinated basis.

Thanks again for contributing and sharing your work.

— By-Roket:rocket:

6

Hi Holger,

Thank you very much for your detailed reply, the clarification regarding the ISC license, and especially for being open to upstream collaboration.

Your proposed workflow makes sense to me, and I would like to follow it.

My first priority will therefore not be to add new features, but to build a proper validation environment and test the current official ZFW codebase without modification.

I am currently rebuilding my Proxmox homelab for this purpose. The planned test environment will progressively cover:

  • ZimaOS virtual machines;

  • single and multi-NIC configurations;

  • virtual NICs and physical NIC passthrough;

  • 1 GbE / 2.5 GbE / 5 GbE interfaces;

  • Docker bridge and macvlan scenarios;

  • IPv4 and IPv6;

  • Docker restart;

  • ZimaOS reboot;

  • Safe-Apply and deliberately incorrect rules;

  • container recreation and port changes;

  • VLAN testing later, once my physical network infrastructure is ready.

The lab still requires some hardware and network work before I can run the complete matrix, so this will take some time. I would rather build the environment correctly and produce reproducible results than rush through the tests.

For each scenario, I plan to record:

Configuration → Action → Expected result → Observed result → PASS / FAIL → Logs / Notes

I also intend to create a private development/test repository with a clearly different name, based on the official upstream ZFW code.

Initially it will contain no changes to ZFW itself — only the test matrix, reports, sanitized logs and lab documentation.

If a problem is discovered, I will first reproduce and document it and let you review it before attempting any correction. I do not want to develop fixes independently and then present them afterwards.

If you already have a preferred diagnostic command, log collection method or test-report format for ZFW, I would be happy to use it.

Regarding this public topic, I would prefer to use it only for general progress, non-sensitive milestones and community feedback. Any security weakness, exploitable behaviour, detailed logs or sensitive infrastructure information should remain private until you consider disclosure appropriate.

You are also the ZFW maintainer, so I am completely happy for you to guide the public communication around the project. If at some point you prefer an official upstream topic maintained by you instead of this one, I would have no issue with that.

Once the lab has a useful foundation and some initial results, I would also be happy to invite you to the private repository so you can follow the work directly and guide the next steps.

I will send you a private message as well, with some additional information about the planned test infrastructure, current limitations, confidentiality considerations and how we could potentially organize deeper testing later if required.

Thank you again for the opportunity to contribute. I am looking forward to doing this properly and progressively.

— By-Roket

1 Like
7

Hi By-Roket,

thanks — that is the right order of work, and I am glad to do this together. I have answered the details (diagnostics, report header, disclosure path) by mail, so this thread can stay what you proposed: progress, milestones and community feedback.

One thing that belongs here because it changes what you test: ZFW v1.0.25 is out today — Release ZFW v1.0.25 · chicohaager/zfw · GitHub — and that is the version to pin for the lab. I will post here whenever a release changes anything you have already run.

Looking forward to the first results.

— Holger