![[HaBo]](/styles/default/logoklein.png)
Boxenknacker
New member
Hallo zusammen,
ich möchte euch heute mein erstes eigenes Open-Source-Projekt vorstellen und würde mich über technisches Feedback oder ein Security-Review aus der Community freuen: das **AntiNix-Panzer-Gateway (Ironclad Edition)**.
### Die Idee dahinter
Inspiriert vom Whonix-Konzept (strikt isolierte Gateway- und Workstation-VM), wollte ich ein extrem schlankes, **100 % systemd-freies** Tor-Gateway auf Basis von **antiX Linux (Debian Trixie)** bauen, das auch auf älterer Hardware oder schmalen VMs (ab **512 MB RAM**, ~250–300 MB Verbrauch im Leerlauf, ~6 GB Basisgröße) flüssig läuft.
### Technische Eckpunkte
* **Fail-Closed Firewall & eBPF/XDP:** Auf `eth0` greift ein `xdp-filter`-Schild, kombiniert mit einem strikten Fail-Closed-`nftables`-Regelwerk (`forward drop`, kein `MASQUERADE` NAT). Der gesamte Traffic der Workstation (`eth1`) wird im Kernel-Space zwingend in Tor's `TransPort` (`9040`) und `DNSPort` (`5353`) umgeleitet.
* **Strikte UID-Isolation:** Desktop-Prozesse (`user`, UID `1000`) und Root-Shells sind per `nftables` (`meta skuid`) vom direkten WAN-Zugriff ausgesperrt. Nur die dedizierten System-User (`debian-tor` / UID `107` und `i2pd` / UID `105`) dürfen ausgehende Verbindungen über `eth0` aufbauen.
* **Snowflake Auto-Fallback:** Beim Login (über Slimski PAM & `dhcpcd`-Hooks) versucht Tor zuerst einen direkten Verbindungsaufbau. Falls DPI oder Firewalls blockieren, schaltet das Gateway automatisch auf **Snowflake** um (mit Mozilla- und Freifunk-STUN-Servern, komplett ohne Google-Abhängigkeiten).
* **Optionales paralleles I2P-Routing (`i2pd`):** Ein schlanker C++-`i2pd`-Daemon (~35 MB RAM) lässt sich per GUI-Button zuschalten und stellt HTTP- (`4444`) und SOCKS5-Proxys (`4447`) exklusiv für `eth1` bereit.
* **Kernel- & OPSEC-Härtung:** U. a. `page_poison=1 slub_debug=P`, `libpam-tmpdir`, `libpam-pwquality`, deaktiviertes USB-Massenspeicher-Automounting, Lynis-Audit sowie ein Desktop-**Panic Kill-Switch** (trennt `eth0`/`eth1` physisch, killt Krypto-Daemons per `SIGKILL`, leert Caches und löst `poweroff -f` aus).
### Bekannte Kleinigkeiten
Da der Fokus klar auf der Netzwerk- und Kernel-Isolation lag, gibt es im angepassten IceWM-Theme noch kleine kosmetische Schönheitsfehler (z. B. fehlende Titelleisten-Symbole zum Schließen/Minimieren/Maximieren – Shortcuts wie `Alt+F4` funktionieren natürlich). Das kommt im nächsten Update dran.
### Quellcode, Configs & Download
Alle Konfigurationsdateien (`nftables.conf`, `torrc`, Skripte), Prüfsummen (`SHA256SUMS.txt`) und den ISO-Download findet ihr transparent auf GitHub:
github.com
Ich bin gespannt auf eure Meinung, Verbesserungsvorschläge oder Kritik zu den `nftables`- und eBPF-Regeln!
Gruß Boxenknacker
ich möchte euch heute mein erstes eigenes Open-Source-Projekt vorstellen und würde mich über technisches Feedback oder ein Security-Review aus der Community freuen: das **AntiNix-Panzer-Gateway (Ironclad Edition)**.
### Die Idee dahinter
Inspiriert vom Whonix-Konzept (strikt isolierte Gateway- und Workstation-VM), wollte ich ein extrem schlankes, **100 % systemd-freies** Tor-Gateway auf Basis von **antiX Linux (Debian Trixie)** bauen, das auch auf älterer Hardware oder schmalen VMs (ab **512 MB RAM**, ~250–300 MB Verbrauch im Leerlauf, ~6 GB Basisgröße) flüssig läuft.
### Technische Eckpunkte
* **Fail-Closed Firewall & eBPF/XDP:** Auf `eth0` greift ein `xdp-filter`-Schild, kombiniert mit einem strikten Fail-Closed-`nftables`-Regelwerk (`forward drop`, kein `MASQUERADE` NAT). Der gesamte Traffic der Workstation (`eth1`) wird im Kernel-Space zwingend in Tor's `TransPort` (`9040`) und `DNSPort` (`5353`) umgeleitet.
* **Strikte UID-Isolation:** Desktop-Prozesse (`user`, UID `1000`) und Root-Shells sind per `nftables` (`meta skuid`) vom direkten WAN-Zugriff ausgesperrt. Nur die dedizierten System-User (`debian-tor` / UID `107` und `i2pd` / UID `105`) dürfen ausgehende Verbindungen über `eth0` aufbauen.
* **Snowflake Auto-Fallback:** Beim Login (über Slimski PAM & `dhcpcd`-Hooks) versucht Tor zuerst einen direkten Verbindungsaufbau. Falls DPI oder Firewalls blockieren, schaltet das Gateway automatisch auf **Snowflake** um (mit Mozilla- und Freifunk-STUN-Servern, komplett ohne Google-Abhängigkeiten).
* **Optionales paralleles I2P-Routing (`i2pd`):** Ein schlanker C++-`i2pd`-Daemon (~35 MB RAM) lässt sich per GUI-Button zuschalten und stellt HTTP- (`4444`) und SOCKS5-Proxys (`4447`) exklusiv für `eth1` bereit.
* **Kernel- & OPSEC-Härtung:** U. a. `page_poison=1 slub_debug=P`, `libpam-tmpdir`, `libpam-pwquality`, deaktiviertes USB-Massenspeicher-Automounting, Lynis-Audit sowie ein Desktop-**Panic Kill-Switch** (trennt `eth0`/`eth1` physisch, killt Krypto-Daemons per `SIGKILL`, leert Caches und löst `poweroff -f` aus).
### Bekannte Kleinigkeiten
Da der Fokus klar auf der Netzwerk- und Kernel-Isolation lag, gibt es im angepassten IceWM-Theme noch kleine kosmetische Schönheitsfehler (z. B. fehlende Titelleisten-Symbole zum Schließen/Minimieren/Maximieren – Shortcuts wie `Alt+F4` funktionieren natürlich). Das kommt im nächsten Update dran.
### Quellcode, Configs & Download
Alle Konfigurationsdateien (`nftables.conf`, `torrc`, Skripte), Prüfsummen (`SHA256SUMS.txt`) und den ISO-Download findet ihr transparent auf GitHub:
AntiNix-Panzer-Gateway/README.md at main · Boxenknacker/AntiNix-Panzer-Gateway
An ultra-lightweight, systemd-free, and hardened Tor Gateway based on antiX Linux. - Boxenknacker/AntiNix-Panzer-Gateway
github.com
Ich bin gespannt auf eure Meinung, Verbesserungsvorschläge oder Kritik zu den `nftables`- und eBPF-Regeln!
Gruß Boxenknacker
Zuletzt bearbeitet: