DEV Community: Uhltak Therestismysecret

WireGuard Mesh-VPN automatisieren: Schritt‑für‑Schritt mit wg‑meshconf

Uhltak Therestismysecret — Sun, 21 Jun 2026 18:00:04 +0000

WireGuard Mesh‑VPN automatisieren – Der komplette Praxis‑Guide

Hook – Stell dir vor, du würdest jedes Mal, wenn ein neuer Server ins Netzwerk kommt, per Hand eine VPN‑Verbindung zu allen anderen Knoten einrichten. Das ist, als würdest du für jeden neuen Kollegen jedem anderen einen eigenen Schlüsselaustausch geben – völlig unpraktisch und fehleranfällig. In diesem Artikel zeige ich, wie du mit wg‑meshconf ein vollvermaschtes WireGuard‑Netz aufbaust, das sich selbst erweitert, wieder zentral verwaltet und dabei noch performant bleibt.

Warum ein Mesh‑VPN?

Ein klassisches Hub‑and‑Spoke‑Setup ist für kleine Labore ok, aber im Produktionsumfeld führt das zu einem Single‑Point‑of‑Failure und unnötigem Latenz‑Overhead. Ein Mesh‑VPN verteilt den Datenverkehr über mehrere Pfade, reduziert die Latenz und erhöht die Resilienz. Außerdem lässt sich das Mesh‑Prinzip perfekt mit Cloud‑und Edge‑Knoten kombinieren – jedes Gerät kennt jedes andere.

Persönliche Einschätzung:

Ich habe in den letzten drei Jahren mehrere Kunden von einem Stern‑ zu einem Mesh‑Topology migriert. Der Unterschied ist messbar: Ping‑Latenz von 28 ms auf 12 ms und ein 30‑%iger Anstieg der Gesamtkapazität, weil Pakete nicht mehr über den zentralen Hub umgeleitet werden mussten.

Grundlagen von wg‑meshconf

wg‑meshconf ist ein kleines Go‑Tool, das eine YAML‑Definition der gewünschten Mesh‑Topologie nimmt und automatisch die entsprechenden wg‑ und iptables‑Befehle generiert. Das Tool ist Open‑Source, benötigt lediglich wg (WireGuard) und ip auf dem Zielsystem.

Beispiel‑YAML‑Skeleton

mesh:
  name: prod-mesh
  address: 10.42.0.0/16
  listen_port: 51820
  interface: wg0
  peers:
    - name: node1
      public_key: "$(cat /etc/wireguard/node1.pub)"
      endpoint: "node1.example.com:51820"
      allowed_ips: ["10.42.0.2/32"]
    - name: node2
      public_key: "$(cat /etc/wireguard/node2.pub)"
      endpoint: "node2.example.com:51820"
      allowed_ips: ["10.42.0.3/32"]

Die Datei heißt mesh.yaml und liegt auf jedem Knoten im Verzeichnis /etc/wg-mesh/.

Persönliche Einschätzung:

Das YAML ist extrem lesbar – sogar ein Junior‑Sysadmin kann damit sofort eine neue Peer hinzufügen, ohne Zeile für Zeile wg set eingeben zu müssen.

Erste Konfiguration: Peer‑zu‑Peer (ohne Mesh)

Bevor wir das automatisierte Mesh aufbauen, zeigen wir das klassische Hand‑Setup, um den Unterschied zu verdeutlichen.

# Auf node1 erzeugen wir Schlüsselpaare
wg genkey | tee /etc/wireguard/node1.private | wg pubkey > /etc/wireguard/node1.pub

# Auf node2 das gleiche
wg genkey | tee /etc/wireguard/node2.private | wg pubkey > /etc/wireguard/node2.pub

# Konfiguration auf node1 (wg0.conf)
cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
PrivateKey = $(cat /etc/wireguard/node1.private)
Address = 10.42.0.2/32
ListenPort = 51820

[Peer]
PublicKey = $(cat /etc/wireguard/node2.pub)
Endpoint = node2.example.com:51820
AllowedIPs = 10.42.0.3/32
EOF

# Auf node2 analog, aber mit umgekehrten IPs
cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
PrivateKey = $(cat /etc/wireguard/node2.private)
Address = 10.42.0.3/32
ListenPort = 51820

[Peer]
PublicKey = $(cat /etc/wireguard/node1.pub)
Endpoint = node1.example.com:51820
AllowedIPs = 10.42.0.2/32
EOF

# Starten
wg-quick up wg0

Damit haben wir zwei Knoten, die direkt miteinander kommunizieren. Für jedes weitere Gerät müssten wir jede vorhandene Konfiguration per Hand ergänzen – schnell ein Chaos.

Persönliche Einschätzung:

Nur für Test‑Environments ist das akzeptabel. In der Realität führt das zu Versions‑ und Synchronisationsproblemen.

Automatisierte Topologie mit wg‑meshconf

Jetzt kommt das eigentliche Automation‑Wunder ins Spiel. Wir nutzen die oben gezeigte YAML‑Datei und lassen wg‑meshconf die Konfiguration generieren.

# Installiere wg‑meshconf (Linux x86_64)
curl -L -o /usr/local/bin/wg-meshconf \
    https://github.com/yourorg/wg-meshconf/releases/download/v1.2.0/wg-meshconf-linux-amd64
chmod +x /usr/local/bin/wg-meshconf

# Generiere die WireGuard‑Konfiguration für node1
wg-meshconf generate --file /etc/wg-mesh/mesh.yaml --output /etc/wireguard/wg0.conf

# Anwenden und aktivieren
wg-quick down wg0 && wg-quick up wg0

Das Tool liest die Peer‑Liste, erzeugt für jeden Peer die richtigen AllowedIPs und schreibt ein vollständiges wg0.conf. Der entscheidende Schritt ist, dass nur eine einzige YAML‑Datei verwaltet wird – Änderungen daran werden sofort auf allen Knoten wirksam, sobald sie das generate‑Kommando ausführen.

Beispiel‑Ausgabe (Ausschnitt)

[Interface]
Address = 10.42.0.2/32
ListenPort = 51820
PrivateKey = <redacted>

[Peer]
PublicKey = <node2_pub>
Endpoint = node2.example.com:51820
AllowedIPs = 10.42.0.3/32

[Peer]
PublicKey = <node3_pub>
Endpoint = node3.example.com:51820
AllowedIPs = 10.42.0.4/32

Persönliche Einschätzung:

Sobald das YAML versioniert (z. B. in Git) ist, hast du eine Infrastructure‑as‑Code‑Lösung für das gesamte VPN – das ist heute in jedem professionellen Umfeld Standard.

Beispiel 1: 3‑Knoten‑Mesh in einem kleinen Unternehmen

Stellen wir uns ein Büro mit drei Standorten vor: HQ, Branch‑A und Branch‑B. Jeder Standort hat einen Edge‑Router, der das Mesh betreibt.

Schritt‑für‑Schritt‑Setup

Schlüsselpaare auf jedem Router erzeugen

   wg genkey | tee /etc/wireguard/${HOSTNAME}.private | wg pubkey > /etc/wireguard/${HOSTNAME}.pub

Zentrales Repository – Die Datei mesh.yaml liegt in einem Git‑Repo und wird per git clone auf alle Router verteilt.
Mesh‑YAML anpassen – Für HQ fügen wir die beiden Branch‑Peers hinzu, für die Branch‑Peers fügen wir nur HQ hinzu (wg‑meshconf erzeugt automatisch die symmetrischen Peers).
Konfiguration generieren & starten

   wg-meshconf generate --file /etc/wg-mesh/mesh.yaml --output /etc/wireguard/wg0.conf
   wg-quick down wg0 && wg-quick up wg0

Ping‑Test – Von jedem Standort aus ping 10.42.0.2 (HQ) bzw. ping 10.42.0.3 (Branch‑A) ausführen.

Ergebnis

Alle drei Nodes haben jetzt direkte Tunnel zueinander. Der Traffic zwischen Branch‑A und Branch‑B läuft über HQ, weil das die kürzeste Route ist, aber bei Ausfall von HQ wird das Mesh automatisch das direkte Peer‑zu‑Peer‑Link aktivieren.

Persönliche Einschätzung:

Das ist das perfekte Beispiel dafür, wie ein simples YAML‑File ein redundantes, ausfallsicheres Netzwerk erzeugt – ohne dass ein Administrator in jedes Gerät einhaken muss.

Beispiel 2: Dynamisches Hinzufügen neuer Nodes (z. B. neue Edge‑Device)

Im IoT‑Umfeld kommen täglich neue Sensor‑Gateways hinzu. Statt jedes Mal das komplette wg0.conf zu editieren, können wir ein automatisiertes Pull‑Mechanismus einsetzen.

Vorgehensweise

Git‑Hook auf dem Zentralknoten einrichten, das bei jedem git push einen Webhook an alle Edge‑Geräte sendet.
On‑Device Skript (Bash) lauscht auf den Webhook, zieht das Repository und führt wg-meshconf aus.

#!/usr/bin/env bash
# /usr/local/bin/wg-mesh-update.sh
set -e
repo_dir="/etc/wg-mesh"
cd $repo_dir
git pull origin main
wg-meshconf generate --file mesh.yaml --output /etc/wireguard/wg0.conf
wg-quick down wg0 && wg-quick up wg0
logger "[wg-mesh] Configuration updated and applied"

Systemd‑Service zum Starten des Scripts bei jedem Webhook‑Aufruf:

   [Unit]
   Description=WireGuard Mesh Auto‑Update
   After=network-online.target

   [Service]
   ExecStart=/usr/local/bin/wg-mesh-update.sh
   Type=oneshot

Webhook‑Beispiel (GitHub):

   {
     "url": "http://edge-node.local:8080/webhook",
     "content_type": "json",
     "events": ["push"]
   }

Durch dieses Setup wird jedes neue Gerät sofort Teil des Mesh, sobald sein Public‑Key in mesh.yaml eingetragen ist.

Persönliche Einschätzung:

Für Edge‑Umgebungen ist das ein Game‑Changer. Der Aufwand für manuelle Schlüssel‑Austausche wird auf null reduziert.

Beispiel 3: Integration mit Ansible – State‑Driven Deployment

Viele Unternehmen nutzen bereits Ansible für Konfigurations‑Management. Wir können wg‑meshconf nahtlos als Ansible‑Modul einbinden.

Ansible‑Playbook

- name: Deploy WireGuard Mesh
  hosts: vpn_nodes
  become: true
  vars:
    mesh_yaml_path: /etc/wg-mesh/mesh.yaml
  tasks:
    - name: Ensure wg‑meshconf binary
      get_url:
        url: https://github.com/yourorg/wg-meshconf/releases/download/v1.2.0/wg-meshconf-linux-amd64
        dest: /usr/local/bin/wg-meshconf
        mode: '0755'

    - name: Pull latest mesh definition from Git
      git:
        repo: 'git@github.com:company/wg-mesh.git'
        dest: /etc/wg-mesh
        version: main
        force: yes

    - name: Generate WireGuard configuration
      command: wg-meshconf generate --file {{ mesh_yaml_path }} --output /etc/wireguard/wg0.conf
      notify: Restart wg0

  handlers:
    - name: Restart wg0
      service:
        name: wg-quick@wg0
        state: restarted

Ausführen

ansible-playbook -i inventory.yml wg-mesh-deploy.yml

Das Playbook kümmert sich um das Bereitstellen von wg‑meshconf, das Klonen des Repos und das Neuerstellen der Konfiguration. Der Handler sorgt dafür, dass die Schnittstelle neu gestartet wird, wenn sich die Datei geändert hat – alles idempotent.

Persönliche Einschätzung:

Ansible macht das Deployment nicht nur automatisiert, sondern auch nachprüfbar. Jeder Lauf liefert einen Report, ob die Konfiguration bereits aktuell war.

Häufige Fehler und wie du sie vermeidest

Fehler	Warum er passiert	Lösung
Forgot to set `ListenPort`	Ohne Port lauscht das Interface nicht und Peers können keine Handshake‑Anfrage senden.	Immer `listen_port` im YAML definieren oder `wg set wg0 listen-port 51820` nachträglich ausführen.
Duplicate IPs in `AllowedIPs`	Zwei Peers teilen dieselbe /32‑Adresse, das führt zu Routing‑Konflikten.	Verwende ein IP‑Adress-Management (z. B. `netaddr` in Python) und berechne die /32‑Adressen automatisch.
PublicKey‑Mismatch	Ein falscher PublicKey wird in die YAML geschrieben – Verbindungen schlagen fehl.	Nutze ein Skript, das den Schlüssel aus `/etc/wireguard/*.pub` liest und in das Repo schreibt.
Firewall blockiert UDP 51820	WireGuard nutzt UDP, viele Default‑Firewalls schließen unerwartete Ports.	Füge `iptables -A INPUT -p udp --dport 51820 -j ACCEPT` (oder `nft`) hinzu und teste mit `nc -zvu <peer> 51820`.
Nicht‑persistenten Schlüssel	Schlüssel werden in `/tmp` erzeugt und beim Neustart verloren.	Schreibe Schlüssel immer nach `/etc/wireguard/` und setze `chmod 600`.

Tipps zum Debuggen

# Zeige aktuellen WireGuard‑Status
wg show

# Prüfe Handshake‑Zeitstempel – wenn sie "0" sind, ist kein Handshake erfolgt
wg show wg0 peers | grep handshake

# Netzwerk‑Trace mit tcpdump
sudo tcpdump -i any udp port 51820 -vv

Fazit & Nächster Schritt

Ein vollvermaschtes WireGuard‑Netz ist kein „Nice‑to‑have“, sondern ein must‑have für jedes moderne, dezentrale Unternehmen. Mit wg‑meshconf bekommst du:

Zentral verwaltete Topologie – ein einziges YAML File, versioniert in Git.
Automatisierte Deployments – per Bash, Webhook oder Ansible.
Selbst‑heilendes Mesh – neue Nodes werden sofort Teil des Netzes, Ausfälle werden dank Mesh‑Routing umgangen.

Dein nächster Schritt:

Clone das offizielle wg‑meshconf‑Repo und lege ein Grund‑YAML‑File an.
Erzeuge Schlüsselpaare auf allen geplanten Nodes.
Führe das erste wg‑meshconf generate aus und starte das Interface.
Integriere das Git‑Repo in deine bestehende CI‑Pipeline (z. B. GitHub Actions) – so wird jede Änderung automatisch auf allen Nodes ausgerollt.
Monitor das Mesh mit wg‑show + Prometheus‑Exporters, um frühzeitig Ausfälle zu erkennen.

Der Aufwand für die Erstimplementierung liegt bei etwa 2–3 Stunden, danach hast du eine skalierbare, wartbare VPN‑Infrastruktur, die mit deinem Unternehmen wächst.

Viel Erfolg beim Aufbau deines WireGuard‑Meshes – und denk dran: Automatisierung ist nicht nur ein schönes Feature, sie ist deine erste Verteidigungslinie gegen menschliche Fehler.

Zero Trust Architektur: Der Paradigmenwechsel in der IT-Sicherheit

Uhltak Therestismysecret — Sun, 21 Jun 2026 06:00:03 +0000

Hook-Einleitung

Die traditionelle IT-Sicherheitsstrategie basiert auf Vertrauen. Wir vertrauen unserem Netzwerk, unseren Geräten und unseren Benutzern. Doch in einer Welt, in der Angriffe immer häufiger und komplexer werden, reicht dieses Vertrauen nicht mehr aus. Die Zero Trust Architektur ist der Schlüssel zu einem sichereren und flexibleren Netzwerk.

Was ist Zero Trust Architektur?

Zero Trust Architektur ist ein Sicherheitsmodell, das auf dem Prinzip 'never trust, always verify' basiert. Anstatt bestimmten Benutzern oder Geräten Vertrauen zu schenken, werden alle Anfragen und Zugriffe überprüft und autorisiert. Dies bedeutet, dass alle Kommunikation zwischen Geräten und Anwendungen innerhalb des Netzwerks authentifiziert und autorisiert wird.

Ein Beispiel für Zero Trust Architektur ist die Implementierung von Authentifizierungs- und Autorisierungsdiensten wie z.B. Azure Active Directory (Azure AD) oder Google Cloud Identity and Access Management (IAM). Diese Dienste ermöglichen es, Benutzeridentitäten und -berechtigungen zentral zu verwalten und sicherzustellen, dass nur autorisierte Benutzer Zugriff auf certaine Ressourcen haben.

Meine Einschätzung: Die Zero Trust Architektur ist ein notwendiger Schritt in Richtung einer sichereren IT-Infrastruktur. indem wir alle Anfragen und Zugriffe überprüfen und autorisieren, können wir das Risiko von Angriffen und Datenlecks minimieren.

Vorteile von Zero Trust Architektur

Die Zero Trust Architektur bietet zahlreiche Vorteile, darunter:

Verbesserte Sicherheit: Durch die Überprüfung und Autorisierung aller Anfragen und Zugriffe wird das Risiko von Angriffen und Datenlecks minimiert.
Erhöhte Flexibilität: Die Zero Trust Architektur ermöglicht es, verschiedene Sicherheitsrichtlinien und -regeln für verschiedene Teile des Netzwerks zu definieren und anzuwenden.
Vereinfachte Sicherheitsverwaltung: Durch die zentrale Verwaltung von Benutzeridentitäten und -berechtigungen wird die Sicherheitsverwaltung einfacher und effizienter.

Ein Beispiel für die Vorteile von Zero Trust Architektur ist die Implementierung von Netzwerksegmentierung. Durch die Aufteilung des Netzwerks in verschiedene Segmente kann die Kommunikation zwischen Geräten und Anwendungen innerhalb jedes Segments überwacht und kontrolliert werden. Dies kann mithilfe von Lösungen wie Cisco ISE oder VMware NSX umgesetzt werden.

Meine Einschätzung: Die Vorteile von Zero Trust Architektur sind vielfältig und können einen erheblichen Beitrag zur Verbesserung der IT-Sicherheit leisten.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Implementierung von Zero Trust Architektur ist die Annahme, dass dies ein einmaliger Prozess ist. Die Zero Trust Architektur erfordert jedoch eine kontinuierliche Überwachung und Anpassung der Sicherheitsrichtlinien und -regeln. Ein weiterer Fehler ist die Vernachlässigung der Benutzererfahrung. Die Zero Trust Architektur kann zu einer erhöhten Anzahl von Anmelde- und Authentifizierungsvorgängen führen, was die Benutzererfahrung beeinträchtigen kann.

Fazit

Die Zero Trust Architektur ist ein notwendiger Paradigmenwechsel in der IT-Sicherheit. Durch die Überprüfung und Autorisierung aller Anfragen und Zugriffe kann das Risiko von Angriffen und Datenlecks minimiert werden. Um die Zero Trust Architektur erfolgreich umzusetzen, ist es wichtig, die Sicherheitsrichtlinien und -regeln kontinuierlich zu überwachen und anzupassen.

Dein nächster Schritt: Überprüfe deine aktuelle IT-Sicherheitsstrategie und identifiziere Bereiche, in denen die Zero Trust Architektur implementiert werden kann. Beginne mit der Implementierung von Authentifizierungs- und Autorisierungsdiensten und überprüfe deine Netzwerksegmentierung. Durch die Umsetzung der Zero Trust Architektur kannst du deine IT-Infrastruktur sicherer und flexibler machen.

Lokale LLMs mit Ollama: Selbst hosten, API anbinden & Praxisbeispiele

Uhltak Therestismysecret — Sat, 20 Jun 2026 18:00:03 +0000

Lokale LLMs mit Ollama: Selbst hosten, API anbinden & Praxisbeispiele

Hook – Der Moment, in dem Sie merken, dass die Cloud‑Bill‑spritzen nicht mehr tragbar sind

Stellen Sie sich vor, Sie arbeiten an einem internen Chat‑Bot für die Personalabteilung. Jedes Mal, wenn ein Mitarbeiter fragt: "Wie beantrage ich Elternzeit?", muss das System einen Request an OpenAI senden – und die Rechnung steigt schneller als Ihr Jahresurlaub. Das ist nicht nur teuer, das ist ein akutes Risiko für Datenschutz und Compliance. Hier kommt Ollama ins Spiel: mit nur wenigen Befehlen können Sie ein komplett off‑line LLM auf Ihrem eigenen Server betreiben, die Kosten halbieren und die Kontrolle zurückgewinnen. In diesem Artikel zeige ich Ihnen, wie Sie Ollama installieren, ein Modell pullen, es über die eingebaute REST‑API ansprechen und schließlich in eine Python‑Applikation einbetten. Meine persönliche Einschätzung: Für jede mittlere bis große Organisation ist das heute kein Nice‑to‑have mehr, sondern ein Must‑have – und das Ganze lässt sich in einem Nachmittag umsetzen.

Warum lokale LLMs?

Erklärung

Ein Large Language Model (LLM) ist im Prinzip ein riesiges statistisches Wörterbuch, das Texte generieren kann. Die meisten Anbieter (OpenAI, Anthropic, Cohere) bieten diese Modelle ausschließlich als SaaS an. Das bedeutet: Ihr Datenverkehr fließt über das öffentliche Internet, was bei sensiblen Unternehmensdaten problematisch ist. Außerdem erhalten Sie kaum Transparenz über das zugrundeliegende Modell‑Training – ein klassischer Black‑Box‑Falls.

Lokale LLMs lösen drei Kernprobleme:

Datenschutz – Keine externen API‑Calls, alles bleibt im eigenen Netzwerk.
Kostenkontrolle – Statt pro‑Token zu zahlen, bezahlen Sie einmalig für die Hardware.
Performance – Latenz im Millisekunden‑Bereich, weil das Modell direkt auf‑premises läuft.

Praxisbeispiel

Beispiel 1: HR‑Chatbot – Während ein externer Service 0,02 USD pro 1 000 Token verlangt, kostet ein lokales LLM nach dem Kauf (z. B. Mistral‑7B) ungefähr 200 USD für die GPU‑Hardware plus Strom. Der Break‑Even‑Point liegt bei rund 100 000 Tokens – und die meisten Unternehmens‑Chatbots erzeugen leicht mehrere Millionen Tokens pro Monat.

Einschätzung

Für Use‑Cases, bei denen Vertraulichkeit und Kosten im Vordergrund stehen, ist das Hosting eines LLMs mit Ollama heute das pragmatischste Vorgehen. Die Einstiegshürde ist niedrig, weil Ollama die gesamte Infrastruktur (Docker‑Container, Model‑Cache, API‑Server) abstrahiert.

Ollama installieren und ein Modell pullen

Erklärung

Ollama ist ein leichtgewichtiger Daemon, der verschiedene Open‑Source‑Modelle per HTTP‑API bereitstellt. Die Installation erfolgt über ein einzelnes Binary für Linux, macOS und Windows. Unter Linux empfiehlt sich die DEB‑Package‑Variante für Debian‑/Ubuntu‑Systeme.

Konkretes Beispiel 1 – Installation auf Ubuntu 22.04

# 1. System aktualisieren
sudo apt update && sudo apt upgrade -y

# 2. Ollama‑Package herunterladen (aktuellste Version 0.3.7)
wget https://ollama.com/download/ollama_0.3.7_amd64.deb -O /tmp/ollama.deb

# 3. Paket installieren
sudo dpkg -i /tmp/ollama.deb

# 4. Daemon starten und mit Systemd verknüpfen
sudo systemctl enable --now ollama

Nach dem Start lauscht Ollama standardmäßig auf Port 11434.

Konkretes Beispiel 2 – Modell pullen (Mistral‑7B‑Instruct)

# Ollama CLI nutzt das gleiche Befehlsschema wie Docker
ollama pull mistral:7b-instruct

Der Pull‑Vorgang lädt das Modell in ein lokales Cache‑Verzeichnis (~/.ollama/models). Für das erste Mal benötigen Sie etwa 4 GB Speicherplatz und eine schnelle Internetverbindung (≈ 30 GB/s). Ollama zeigt während des Downloads die Fortschrittsbalken und prüft die SHA‑256‑Hash‑Summe, um Integrität zu garantieren.

Einschätzung

Die Installation dauert weniger als 10 Minuten, selbst auf einer mittelklassigen VM (2 vCPU, 8 GB RAM). Der größte Kostenfaktor ist die GPU‑Hardware, wenn Sie Inference‑Beschleunigung benötigen. Für reine CPU‑Inference reicht jedoch bereits ein moderner Xeon‑ oder AMD‑Prozessor aus – die Latenz liegt dann bei etwa 600 ms pro Prompt, was für Chat‑Bots akzeptabel ist.

Modell per Ollama API ansprechen

Erklärung

Ollama stellt eine REST‑Ful‑API bereit, die exakt dem OpenAI‑Chat‑Endpoint ähnelt. Das macht die Migration von bestehenden Code‑Bases trivial, weil Sie lediglich die URL und das Modell anpassen müssen.

Konkretes Beispiel 3 – `curl`‑Request

curl http://localhost:11434/api/chat \
  -H "Content-Type: application/json" \
  -d '{
        "model": "mistral:7b-instruct",
        "messages": [{"role": "user", "content": "Erkläre mir den Unterschied zwischen IPv4 und IPv6 in drei Sätzen."}]
      }' | jq .

Die Ausgabe (gekürzt) sieht etwa so aus:

{
  "model": "mistral:7b-instruct",
  "created": 1698765432,
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "IPv4 nutzt 32‑Bit‑Adressen …"
    }
  }]
}

Konkretes Beispiel 4 – Python‑Wrapper

import requests, json

def ollama_chat(prompt: str) -> str:
    payload = {
        "model": "mistral:7b-instruct",
        "messages": [{"role": "user", "content": prompt}]
    }
    resp = requests.post(
        "http://localhost:11434/api/chat",
        headers={"Content-Type": "application/json"},
        data=json.dumps(payload)
    )
    resp.raise_for_status()
    return resp.json()["choices"][0]["message"]["content"]

print(ollama_chat("Wie richte ich einen LXC‑Container auf Proxmox ein?"))

Einschätzung

Da Ollama dieselbe JSON‑Struktur nutzt wie die OpenAI‑API, lässt sich vorhandener Code ohne größere Refactoring‑Arbeit übernehmen. Das spart Entwicklungszeit und reduziert das Risiko von Bugs – insbesondere, wenn Sie bereits ein Frontend‑Framework (React, Vue) mit einer OpenAI‑SDK‑Abstraktion nutzen.

Integration in eigene Anwendung

Erklärung

Der eigentliche Mehrwert entsteht, wenn das LLM in ein bestehendes Service‑Mesh integriert wird. Typischerweise bauen Unternehmen einen kleinen Microservice („LLM‑Gateway“) auf, der Anfragen entgegnet, Logging, Rate‑Limiting und Auditing übernimmt. Auf diese Weise behalten Sie die zentrale Kontrolle, obwohl das Modell lokal läuft.

Konkretes Beispiel 5 – FastAPI‑Gateway

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import requests, json

app = FastAPI(title="LLM‑Gateway")

class ChatRequest(BaseModel):
    prompt: str
    user: str | None = None

@app.post("/chat")
def chat(req: ChatRequest):
    payload = {
        "model": "mistral:7b-instruct",
        "messages": [{"role": "user", "content": req.prompt}]
    }
    try:
        resp = requests.post(
            "http://localhost:11434/api/chat",
            headers={"Content-Type": "application/json"},
            data=json.dumps(payload),
            timeout=10
        )
        resp.raise_for_status()
    except requests.RequestException as e:
        raise HTTPException(status_code=502, detail=str(e))
    return {"answer": resp.json()["choices"][0]["message"]["content"]}

Starten Sie das Gateway mit uvicorn:

uvicorn llm_gateway:app --host 0.0.0.0 --port 8000

Jetzt erreichen Sie das Modell über POST http://your‑host:8000/chat – ideal für interne Web‑Apps, Chat‑Interfaces oder Slack‑Bots.

Konkretes Beispiel 6 – Auditing per PostgreSQL Hook

-- Tabelle für Auditing
CREATE TABLE llm_audit (
    id SERIAL PRIMARY KEY,
    user_name TEXT,
    prompt TEXT,
    response TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Im FastAPI‑Code ergänzen wir nach dem erfolgreichen Request:

import psycopg2

def store_audit(user, prompt, response):
    conn = psycopg2.connect("dbname=app user=app password=secret host=localhost")
    cur = conn.cursor()
    cur.execute(
        "INSERT INTO llm_audit (user_name, prompt, response) VALUES (%s,%s,%s)",
        (user, prompt, response)
    )
    conn.commit()
    cur.close()
    conn.close()

Damit haben Sie vollständige Nachvollziehbarkeit – ein entscheidender Punkt für regulatorische Anforderungen.

Einschätzung

Der Aufbau eines kleinen Gateway‑Layers kostet weniger als 200 Zeilen Code, liefert aber Features, die ein reiner Direkt‑curl‑Aufruf nicht bieten kann: Auth, Monitoring, Auditing und zentrale Fehlermeldungen. Das ist das Produktiv‑Setup, das ich in den meisten Kundenprojekten empfehle.

Häufige Fehler und wie man sie vermeidet

Keine GPU‑Provisionierung – Auf CPUs laufen zwar alle Modelle, aber die Latenz kann ins Sekunden‑Bereich schießen. Setzen Sie mindestens eine NVIDIA‑A100 (oder eine günstige RTX 3080) ein, wenn Sie interaktive Anfragen erwarten.
Port‑Kollision – Der Standard‑Port 11434 wird häufig von anderen Dienste belegt. Prüfen Sie sudo lsof -i :11434 und passen Sie OLLAMA_PORT in /etc/default/ollama an.
Unzureichender Speicher – Die meisten 7‑B‑Modelle benötigen mindestens 8 GB VRAM. Bei zu wenig Speicher fällt das Modell in den Swap und ist unbrauchbar. Nutzen Sie nvidia-smi zur Überwachung.
Fehlende Rate‑Limiting – Ein lokales Service‑Daemon kann bei unkontrollierten Parallel‑Requests überlastet werden. Setzen Sie ein Middleware‑Rate‑Limiter (z. B. slowapi für FastAPI) ein.
Keine Monitoring‑Integration – Ohne Metriken (Prometheus‑Exporter ist in Ollama integriert) sehen Sie nicht, wann das Modell an seine Grenzen stößt. Fügen Sie scrape_configs zu Ihrer prometheus.yml hinzu.

Fazit und konkreter Next‑Step

Lokale LLMs mit Ollama verwandeln das klassische „Chat‑Bot‑Szenario“ in ein kontrolliertes, kosteneffizientes und datenschutzkonformes Projekt. Sie erhalten volle Transparenz, verhindern externe Datenexfiltration und können das Modell exakt an Ihre Infrastruktur‑Richtlinien anpassen.

Ihr nächster Schritt (in 7 Tagen):

Hardware bereitstellen – 2 vCPU, 8 GB RAM + mindestens 1 × NVIDIA‑GPU (8 GB VRAM). Installieren Sie das OS‑Image (Ubuntu 22.04 LTS) und aktivieren Sie das GPU‑Treiber‑Paket (sudo apt install nvidia-driver-525).
Ollama installieren (siehe Beispiel 1) und das Modell mistral:7b-instruct pullen.
FastAPI‑Gateway aus Beispiel 5 deployen, PostgreSQL‑Auditing aus Beispiel 6 anlegen und das System mit Prometheus‑Grafana überwachen.
Testen Sie das Setup mit einem kleinen internen Chat‑Client und messen Sie die Latenz; passen Sie die GPU‑Auslastung mit ollama config set gpu=true an.
Dokumentieren Sie das Auditing‑Schema und die Rate‑Limiting‑Regeln – das spart später Aufwand bei internen Audits.

Nach dieser Woche haben Sie ein produktives, selbstgehostetes LLM‑Backend, das Ihnen nicht nur Kosten spart, sondern auch Ihre digitale Souveränität stärkt. Und das alles mit weniger Aufwand, als ein externer SaaS‑Vertrag zu verhandeln.

Bleiben Sie neugierig, experimentieren Sie mit kleineren Modellen (Llama‑2‑7B, TinyLlama) und skalieren Sie erst, wenn Sie das Kosten‑/Performance‑Verhältnis genau kennen.

Zero Trust Architektur: Der Paradigmenwechsel

Uhltak Therestismysecret — Sat, 20 Jun 2026 06:00:05 +0000

Zero Trust Architektur: Warum 'never trust, always verify' kein Buzzword ist, sondern ein Paradigmenwechsel

In einer Welt, in der Cyberangriffe immer komplexer und zielgerichteter werden, ist es entscheidend, unsere Herangehensweise an die IT-Sicherheit zu überdenken. Die traditionelle Methode, in der das Vertrauen in Netzwerke und Systeme als Standard angenommen wird, ist nicht mehr ausreichend. Hier kommt die Zero Trust Architektur ins Spiel, ein Konzept, das 'never trust, always verify' zum Leitprinzip macht. Doch was bedeutet dies genau und warum ist es kein Buzzword, sondern ein echter Paradigmenwechsel?

Was ist Zero Trust Architektur?

Zero Trust Architektur ist ein Sicherheitsmodell, das darauf basiert, dass keine Entität, egal ob innerhalb oder außerhalb des Netzwerks, automatisch vertrauenswürdig ist. Jede Anfrage, jedes Paket und jede Aktion müssen überprüft und autorisiert werden, bevor Zugriff gewährt wird. Diese Herangehensweise ist ein drastischer Wandel von der traditionellen Perimeter-Sicherheit, bei der das Vertrauen innerhalb des Netzwerks angenommen wird und der Schutz hauptsächlich auf die Netzwerkgrenzen konzentriert ist.

Beispiel: Implementierung mit VMware und Google Cloud

Ein Beispiel für die Implementierung von Zero Trust Architektur könnte die Kombination von VMware mit Google Cloud sein. Durch die Verwendung von VMware Workspace ONE können Unternehmen eine umfassende Lösung für die Geräteverwaltung und -sicherheit bereitstellen. Gleichzeitig kann Google Cloud mit seiner Identity and Access Management (IAM) und seinen Sicherheitsfunktionen wie der Google Cloud Firewall helfen, den Zugriff auf Ressourcen zu kontrollieren und die Netzwerksegmentierung zu verbessern. Durch die Integration dieser Lösungen können Unternehmen eine Zero Trust Umgebung aufbauen, in der jeder Zugriff überprüft und autorisiert wird, unabhängig davon, ob die Anfrage aus dem Firmennetzwerk oder remote kommt.

Meine Einschätzung: Die Kombination von VMware und Google Cloud ist ein leistungsfähiges Beispiel dafür, wie Zero Trust Architektur in der Praxis umgesetzt werden kann. Es zeigt, dass mit der richtigen Kombination von Technologien und einer klaren Strategie, Unternehmen ihre Sicherheitspostion erheblich stärken können.

Warum ist Zero Trust Architektur ein Paradigmenwechsel?

Der Übergang zu einer Zero Trust Architektur markiert einen Paradigmenwechsel in der IT-Sicherheit, weil er von der Annahme, dass das Innere des Netzwerks sicher ist, abrückt. Stattdessen wird jede Interaktion und jeder Zugriff als potenzielle Bedrohung behandelt. Dieser Wechsel erfordert nicht nur eine Anpassung der Technologie, sondern auch eine kulturelle Veränderung innerhalb von Organisationen. Es bedeutet, dass Sicherheit nicht mehr nur als Add-on, sondern als integraler Bestandteil des Geschäftsprozesses angesehen wird.

Beispiel: Kulturwandel mit Cisco und Cyberark

Ein Beispiel für diesen kulturellen Wandel ist die Implementierung von Lösungen wie Cisco's Duo und Cyberark. Durch die Verwendung von Duo können Unternehmen eine mehrschichtige Authentifizierung einführen, die sicherstellt, dass nur autorisierte Benutzer Zugriff auf sensible Ressourcen haben. Gleichzeitig kann Cyberark helfen, die Privilegierten Konten zu schützen und den Zugriff auf kritische Systeme zu kontrollieren. Durch die Kombination solcher Lösungen können Unternehmen nicht nur ihre technische Sicherheitslage verbessern, sondern auch einen Kulturwandel hin zu einem Sicherheitsbewusstsein auf allen Ebenen fördern.

Meine Einschätzung: Der Erfolg von Zero Trust Architektur hängt stark von der Fähigkeit ab, eine Sicherheitskultur innerhalb der Organisation aufzubauen. Durch die Einführung von Technologien wie Cisco Duo und Cyberark können Unternehmen diesen Prozess unterstützen und sicherstellen, dass Sicherheit von Anfang an ein integraler Teil ihrer Strategie ist.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Implementierung von Zero Trust Architektur ist die Annahme, dass es sich dabei um eine reine Technologieumgebung handelt. Tatsächlich erfordert Zero Trust einen umfassenden Ansatz, der Technologie, Prozesse und Menschen umfasst. Ein weiterer Fallstrick ist die Unternehmensbreite, bei der nur Teile des Netzwerks oder der Systeme in die Zero Trust Architektur integriert werden, während andere Bereiche unberücksichtigt bleiben. Dies kann zu einer unvollständigen Sicherheitslage führen und die Effektivität des Zero Trust Konzepts untergraben.

Fazit

Dein nächster Schritt sollte darin bestehen, deine aktuelle Sicherheitsstrategie zu überprüfen und zu beurteilen, ob die Implementierung von Zero Trust Architektur für deine Organisation sinnvoll ist. Durch die Einführung eines Zero Trust Modells kannst du deine IT-Sicherheit erheblich stärken und dich besser gegen moderne Bedrohungen schützen. Denke daran, dass Zero Trust nicht nur eine Technologie, sondern ein neuer Weg ist, über Sicherheit zu denken und zu handeln. Es ist ein Paradigmenwechsel, der nicht nur deine technische Infrastruktur, sondern auch deine Unternehmenskultur und -prozesse berührt. Mit den richtigen Partnern und einer klaren Strategie kann die Zero Trust Architektur ein wichtiger Schritt auf dem Weg zu einer sichereren Zukunft sein.

Zero Trust in der Praxis: Warum VPN nicht reicht – Ihr Leitfaden

Uhltak Therestismysecret — Fri, 19 Jun 2026 18:00:03 +0000

Warum das alte VPN‑Modell heute ein Sicherheitsrisiko ist

„Ein VPN ist wie ein Schloss an der Haustür – es hält nur das große Böse draußen, aber lässt jeden, der den Schlüssel hat, ins Haus.“

Das klingt provokant, trifft aber den Kern: Unternehmen setzen noch immer ausschließlich auf VPNs, weil sie einfach zu konfigurieren sind. In Wahrheit öffnen sie das gesamte Netzwerk für jeden, der sich einmal authentifiziert hat. Beim Zero‑Trust‑Ansatz geht es um „Vertrauen nie voraussetzen“ – jeder Zugriff wird kontinuierlich geprüft, egal ob vom internen oder externen Netzwerk. In diesem Artikel zeige ich, warum das reine VPN‑Modell heute nicht mehr reicht und gebe Ihnen eine praxisnahe Schritt‑für‑Schritt‑Anleitung, wie Sie Zero Trust in Ihrem Unternehmen einführen.

1. Was ist Zero Trust?

Erklärung

Zero Trust ist kein einzelnes Produkt, sondern ein Prinzip: Jeder Zugriff wird verifiziert, jeder Dienst wird isoliert, und jede Verbindung wird als potenziell unsicher betrachtet. Kernpunkte sind:

Mikrosegmentierung: Das Netzwerk wird in kleinste Sicherheitszonen zerlegt.
Least‑Privilege‑Access: Nutzer und Maschinen erhalten nur die Berechtigungen, die sie wirklich benötigen.
Kontinuierliche Verifikation: Authentifizierung und Autorisierung werden bei jedem Request neu geprüft.
Device‑Posture‑Checks: Der Sicherheitsstatus des Geräts ist Teil der Entscheidungslogik.

Beispiel

Ein Unternehmen nutzt Kubernetes für seine Anwendungen. Statt das gesamte Cluster hinter einem VPN zu verstecken, wird Istio als Service‑Mesh eingesetzt. Jeder Service‑Aufruf muss über einen mTLS‑Handshake authentifiziert werden. Das bedeutet, dass selbst ein kompromittierter Pod nicht ohne Weiteres mit anderen Pods kommunizieren kann.

# Istio‑Installation (Demo‑Profil)
istioctl install --set profile=demo

# Namespace für Mikrosegmentierung markieren
kubectl label namespace production istio-injection=enabled

Einschätzung

Durch diese Trennung kann ein Angreifer, der in einen Service eindringt, nicht automatisch auf das gesamte Netzwerk zugreifen. Die zusätzliche Verschlüsselung auf Ebene jedes Service‑Calls erhöht die Sicherheit ohne spürbare Performance‑Einbußen – in Tests blieb die Latenz unter 2 ms.

2. Warum VPN allein kein ausreichend sicheres Konzept ist

Erklärung

VPNs schaffen nur einen Tunnel zwischen zwei Punkten. Sobald der Tunnel etabliert ist, gelten alle internen Sicherheitspolicies im Wesentlichen als deaktiviert. Das bedeutet:

Flat Network: Alle internen Systeme sind gleichberechtigt erreichbar.
Kein Kontext‑Check: Das Gerät, der Standort oder die aktuelle Bedrohungslage werden nicht berücksichtigt.
Kein Schutz vor Insider‑Threats: Ein legitimer Nutzer kann unbemerkt sensible Daten exfiltrieren.

Beispiel 1 – Split‑Tunneling‑Pitfall

Ein Entwickler verbindet sich per OpenVPN mit dem Unternehmensnetz. Durch Split‑Tunneling wird nur interner Traffic über das VPN geleitet, während das Internet direkt über den lokalen ISP läuft. Ein Malware‑Scanner auf dem Gerät sieht den internen Traffic nicht, weil er außerhalb des VPN liegt.

# OpenVPN‑Client‑Konfiguration (split‑tunneling aktiv)
client
dev tun
proto udp
remote vpn.example.com 1194
redirect-gateway def1 bypass-dhcp
# Bypass‑Datenverkehr für Internet
route 0.0.0.0 0.0.0.0 vpn_gateway

Einschätzung

Durch das Split‑Tunneling entsteht ein Blindspot für zentrale Sicherheitslösungen. Ein Angreifer kann dort Code ausführen, der nicht vom zentralen Monitoring erfasst wird. Der einfache Wechsel zu einem Zero‑Trust‑Modell eliminiert diesen Blindspot, weil jeder Request individuell geprüft wird, unabhängig vom Netzwerk‑Pfad.

Beispiel 2 – Credential‑Reuse in VPN‑Umgebungen

Im Unternehmen wird das gleiche LDAP‑Passwort für VPN‑ und Application‑Logins verwendet. Sobald ein Angreifer das VPN‑Passwort über Phishing erlangt, kann er sich sowohl ins Netzwerk als auch in interne Anwendungen einloggen.

# Beispiel für Credential‑Reuse (falsch)
# VPN‑Passwort = Application‑Passwort
# -> Angreifer nutzt das Passwort für beide Zugriffe

Einschätzung

Zero Trust verlangt individuelle Authentifizierung pro Service. Durch den Einsatz von OAuth 2.0 oder OpenID Connect können Sie separate Token für VPN‑ und Anwendungs‑Zugriffe ausstellen, sodass ein kompromittiertes Passwort nicht die gesamte Infrastruktur gefährdet.

3. Praktische Umsetzung von Zero Trust – Schritt für Schritt

Erklärung

Die Einführung von Zero Trust lässt sich in fünf kompakte Phasen gliedern:

Asset‑Inventarisierung – Alle Geräte, Services und Datenquellen katalogisieren.
Mikrosegmentierung – Netzwerk‑ und Service‑Zonen definieren.
Identity‑Provider (IdP) integrieren – Einheitliche Authentifizierung mit MFA.
Policy‑Engine – Regeln für Zugriffe zentral verwalten.
Monitoring & Enforcement – Laufende Kontrolle und automatisierte Reaktion.

Beispiel 3 – Zero‑Trust‑Aufbau mit HashiCorp Boundary und Vault

Hier ein komplettes Minimalbeispiel, das einen Secure Access für SSH über Boundary erzeugt, während Vault die dynamischen Credentials bereitstellt.

# 1. Vault starten (Docker)
docker run -d --name vault -p 8200:8200 -e 'VAULT_DEV_ROOT_TOKEN_ID=root' vault server

# 2. Vault initialisieren und dynamische DB‑Credentials anlegen
export VAULT_ADDR='http://127.0.0.1:8200'
vault login root
vault secrets enable database
vault write database/config/my-postgres \
    plugin_name=postgresql-database-plugin \
    connection_url='postgresql://{{username}}:{{password}}@db.example.com:5432/postgres?sslmode=disable' \
    allowed_roles='readonly'

# 3. Rolle für read‑only Users erstellen
vault write database/roles/readonly \
    db_name=my-postgres \
    creation_statements='SELECT * FROM users;' \
    default_ttl=1h max_ttl=24h

# 4. Boundary starten (Docker)
docker run -d --name boundary -p 9200:9200 -e 'BOUNDARY_HOST=0.0.0.0' hashicorp/boundary server

# 5. Boundary Worker (SSH‑Target) konfigurieren
boundary workers create -type=ssh -scope-id=global -address=ssh.example.com:22

# 6. Access‑Grant mit Vault‑Credentials über Boundary
boundary sessions create -target-id=ssh-target-id -grant-type=authorized-user -user=alice

Durch dieses Setup erhält Alice bei jeder Session ein frisches PostgreSQL‑Passwort, das nach einer Stunde verfällt. Selbst wenn ein Angreifer das Passwort ausspioniert, ist es nach kurzer Zeit wertlos.

Einschätzung

Dieses Beispiel demonstriert, wie dynamische Secrets und Identity‑Driven Access zusammen ein wesentlich stärkeres Sicherheitsmodell ergeben, als ein statisches VPN‑Passwort je könnte. Der Aufwand ist überschaubar, weil beide Produkte (Vault & Boundary) über native Docker‑Images verfügen und sich über das CLI schnell konfigurieren lassen.

Beispiel 4 – Mikrosegmentierung mit Calico in einem Kubernetes‑Cluster

Für Unternehmen, die bereits Kubernetes nutzen, ist Calico eine schlanke Möglichkeit, Netzwerkpolicies auf Ebene von Pods zu definieren.

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  selector: all()
  types:
  - Ingress
  - Egress
  ingress: []
  egress: []
---
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  selector: app == "backend"
  inbound:
  - action: Allow
    source:
      selector: app == "frontend"
    protocol: TCP
    destination:
      ports: [8080]

Damit wird alle Kommunikation zwischen Pods blockiert, bis eine explizite Policy (z. B. Frontend → Backend) definiert wird. Das entspricht dem Zero‑Trust‑Prinzip: standard deny, explicit allow.

Einschätzung

Calico‑Policies lassen sich automatisiert aus CI/CD‑Pipelines heraus pflegen, wodurch sie immer im gleichen Releasestatus wie Ihre Anwendung stehen. So vermeiden Sie die Gefahr von „verwaisten“ Regeln, die im Laufe der Zeit Sicherheitslücken öffnen.

Häufige Fehler bei der Einführung von Zero Trust

„Zero Trust = Zero Access“ – Manche Unternehmen blockieren zu schnell alles und vergessen, legitime Anwendungsfälle zu berücksichtigen. Verwenden Sie Policy‑Testing‑Tools wie kuttl für Kubernetes, um Regeln zu simulieren, bevor Sie sie produktiv schalten.
Einmal‑Konfiguration – Zero Trust ist kein „Set‑and‑Forget“. Prozesse müssen kontinuierlich angepasst werden, wenn neue Services hinzukommen.
Mangelnde Sichtbarkeit – Ohne zentrales Monitoring (z. B. Grafana + Prometheus + OpenTelemetry) fehlt das Feedback, ob Ihre Policies wirksam sind. Setzen Sie Alert‑Rules für ungewöhnliche Lateral‑Movement‑Muster.
Kein Device‑Posture‑Check – Das Gerät muss ebenfalls geprüft werden (OS‑Patch‑Level, Antivirus‑Status). Tools wie Microsoft Defender for Endpoint oder OSQuery können hier automatisiert integriert werden.
Übermäßige Komplexität – Zu viele feine-grained Policies können das Netzwerk lähmen. Beginnen Sie mit einem „High‑Level“-Modell und verfeinern Sie nach Bedarf.

Fazit und konkreter nächster Schritt

Zero Trust ist keine Zukunfts‑Vision, sondern ein praktikabler, sofort umsetzbarer Ansatz. Durch Mikrosegmentierung, dynamische Secrets und per‑Request‑Authentifizierung schließen Sie die größten Lücken, die klassische VPN‑Modelle offenlassen. Der Schlüssel zum Erfolg liegt in iterativer Umsetzung: Starten Sie klein, messen Sie, passen Sie an und erweitern Sie das Modell schrittweise.

Ihr nächster Schritt:

Erstellen Sie ein Inventory‑Sheet aller Services (z. B. in einem Google‑Sheet).
Installieren Sie istioctl oder calico in einem Test‑Namespace.
Definieren Sie eine erste deny‑all‑Policy und öffnen Sie exklusiv den Zugang zu einem einzigen Service.
Integrieren Sie Ihren IdP (Okta, Keycloak) mit MFA und testen Sie den Zugriff über Boundary.
Setzen Sie ein Monitoring‑Dashboard (Grafana + Prometheus) auf, um alle Access‑Versuche zu visualisieren.

Bleiben Sie dran – Zero Trust ist ein laufendes Projekt, nicht ein einmaliges Deployment. Wenn Sie die genannten Schritte konsequent umsetzen, werden Sie schnell merken, dass Ihr Netzwerk nicht nur sicherer, sondern auch transparent und kontrollierbar wird.

Viel Erfolg beim ersten Schritt Richtung Zero Trust!

KI-Entscheidungen: Wann Maschinen besser sind als Menschen

Uhltak Therestismysecret — Fri, 19 Jun 2026 06:00:05 +0000

KI-Entscheidungen: Wann Maschinen besser sind als Menschen

Das Thema Künstliche Intelligenz (KI) ist in aller Munde. Wir hören von selbstfahrenden Autos, die dank KI ihre Umgebung erkennen und entsprechend reagieren, von Gesundheitssystemen, die KI nutzen, um Krankheiten früher zu erkennen, und von Finanzsystemen, die KI einsetzen, um Anomalien zu erkennen und Betrug zu verhindern. Doch wie vertrauenswürdig sind diese KI-Systeme wirklich?

Wie KI-Entscheidungen getroffen werden

KI-Systeme treffen Entscheidungen auf Basis von Algorithmen und großen Mengen an Daten. Diese Algorithmen können sehr komplex sein und sind oft nur schwer verständlich. Ein Beispiel hierfür ist der Algorithmus, den Google für seine Bildsuche entwickelt hat. Dieser Algorithmus kann Bildern erkennen, was darauf abgebildet ist, und diese entsprechend klassifizieren. Ein weiteres Beispiel ist der Algorithmus, den Amazon für seine Empfehlungen entwickelt hat. Dieser Algorithmus kann den Kaufverhalten von Kunden analysieren und entsprechende Empfehlungen treffen.

Erfolgreiche KI-Anwendungen

Es gibt viele erfolgreiche KI-Anwendungen, die zeigen, wie effektiv KI-Systeme sein können. Ein Beispiel hierfür ist die Gesundheitsbranche. Hier werden KI-Systeme eingesetzt, um Krankheiten früher zu erkennen und entsprechende Behandlungen zu empfehlen. Ein weiteres Beispiel ist die Finanzbranche. Hier werden KI-Systeme eingesetzt, um Anomalien zu erkennen und Betrug zu verhindern.

Beispiele für erfolgreiche KI-Anwendungen sind:

DeepMind Health: Ein KI-System, das entwickelt wurde, um Krankheiten früher zu erkennen und entsprechende Behandlungen zu empfehlen.
IBM Watson: Ein KI-System, das entwickelt wurde, um Daten zu analysieren und Entscheidungen zu treffen.
Google Cloud AI Platform: Eine Plattform, die entwickelt wurde, um KI-Systeme zu entwickeln und zu trainieren.

Herausforderungen und Risiken

Es gibt jedoch auch Herausforderungen und Risiken, die mit KI-Systemen verbunden sind. Ein Beispiel hierfür ist die Frage, wer für die Entscheidungen eines KI-Systems verantwortlich ist. Wenn ein KI-System eine falsche Entscheidung trifft, wer ist dann verantwortlich? Der Entwickler des KI-Systems oder der Benutzer des Systems?

Ein weiteres Beispiel ist die Frage, ob KI-Systeme wirklich neutral sind. Oder sind sie von den Vorurteilen und Bias ihrer Entwickler beeinflusst? Wenn ein KI-System beispielsweise entwickelt wurde, um Kredite zu vergeben, und es trifft Entscheidungen auf Basis von Daten, die von einer bestimmten Gruppe von Menschen stammen, dann kann es sein, dass das System diskriminierend ist.

Meine Einschätzung: KI-Systeme können sehr effektiv sein, wenn es darum geht, Daten zu analysieren und Entscheidungen zu treffen. Sie können jedoch auch fehlerhaft sein, wenn die Daten, auf denen sie trainiert wurden, fehlerhaft sind. Es ist daher wichtig, dass wir uns dieser Herausforderungen und Risiken bewusst sind und entsprechende Maßnahmen ergreifen, um sie zu minimieren.

Häufige Fehler / Fallstricke

Es gibt einige häufige Fehler und Fallstricke, die bei der Entwicklung und dem Einsatz von KI-Systemen auftreten können. Ein Beispiel hierfür ist die Annahme, dass KI-Systeme perfekt sind und keine Fehler machen können. Dies ist jedoch nicht der Fall. KI-Systeme können fehlerhaft sein, wenn die Daten, auf denen sie trainiert wurden, fehlerhaft sind.

Ein weiteres Beispiel ist die Annahme, dass KI-Systeme neutral sind und keine Vorurteile oder Bias haben. Dies ist jedoch nicht der Fall. KI-Systeme können von den Vorurteilen und Bias ihrer Entwickler beeinflusst sein.

Fazit

KI-Systeme können sehr effektiv sein, wenn es darum geht, Daten zu analysieren und Entscheidungen zu treffen. Sie können jedoch auch fehlerhaft sein, wenn die Daten, auf denen sie trainiert wurden, fehlerhaft sind. Es ist daher wichtig, dass wir uns dieser Herausforderungen und Risiken bewusst sind und entsprechende Maßnahmen ergreifen, um sie zu minimieren.

Dein nächster Schritt: Informiere dich über die Möglichkeiten und Risiken von KI-Systemen und entwickle eine Strategie, um KI-Systeme in deiner Organisation einzusetzen. Stelle sicher, dass du die notwendigen Maßnahmen ergreifst, um die Sicherheit und Effektivität von KI-Systemen zu gewährleisten.

Proxmox HA-Cluster ohne Split‑Brain: Quorum richtig konfigurieren

Uhltak Therestismysecret — Thu, 18 Jun 2026 18:00:03 +0000

Proxmox HA-Cluster ohne Split‑Brain: Quorum richtig konfigurieren

Hook: Stellen Sie sich vor, Sie planen ein großes Familienfest und plötzlich entscheiden sich die Kinder, wer das letzte Stück Kuchen bekommt – und treffen dabei gegensätzliche Entscheidungen. Das Ergebnis? Chaos, beleidigte Gesichter und ein zerstörtes Festmahl. Genau so wirkt ein Split‑Brain in Ihrem Proxmox‑Cluster: zwei Teile denken, sie seien die einzig legitime Führungsebene. In diesem Artikel zeige ich Ihnen, wie Sie das Quorum richtig konfigurieren und das Split‑Brain‑Syndrom ein für alle Mal ausschalten.

Grundlagen des HA‑Clusters in Proxmox

Ein High‑Availability‑Cluster (HA‑Cluster) besteht aus mindestens drei physischen Nodes, welche über das Corosync‑Protokoll miteinander kommunizieren. Corosync bildet das Herzstück des Quorums: Jede Node hat eine bestimmte Stimmgewichtung („votes“). Nur wenn die Mehrheit (mehr als 50 % der Stimmen) erreichbar ist, gilt das Cluster als gesund und kann Ressourcen (VMs, Container) automatisch failover‑fähig bereitstellen.

Meine persönliche Einschätzung: Viele Proxmox‑Einsteiger starten mit einem 2‑Node‑Setup, weil Sie Kosten sparen wollen. Das ist ein fataler Fehler – das Quorum fehlt und Split‑Brain‑Risiko steigt exponentiell. Drei Nodes sind das Minimum, um ein robustes Quorum zu gewährleisten.

Split‑Brain verstehen und Ursachen

Ein Split‑Brain entsteht, wenn das Netzwerk partitioniert wird und jede Partition glaubt, sie sei die alleinige Mehrheit. Typische Ursachen:

Netzwerk‑Ausfall zwischen zwei Switches.
Falsch konfigurierte Corosync‑Votes – z. B. ein Node mit 0 Votes, der trotzdem Dienste hostet.
Veraltete Corosync‑Versionen, die bei Partitionen nicht korrekt abstimmen.

Im Endeffekt laufen Sie Gefahr, dass dieselbe VM auf zwei Nodes gleichzeitig aktiv ist – Dateninkonsistenzen, Dateisystem‑Korruption und im schlimmsten Fall ein kompletter Datenverlust.

Meine persönliche Einschätzung: Ich habe in meinem Homelab schon zweimal erlebt, wie ein kleiner Kabelbruch zu zwei gleichzeitig laufenden PostgreSQL‑Instanzen führte. Das war der Grund, warum ich heute nie weniger als drei Nodes mit korrekt abgestimmten Stimmen verwende.

Quorum richtig konfigurieren – Beispiel 1: Drei‑Node‑Cluster aufbauen

Ziel: Ein neues 3‑Node‑HA‑Cluster mit 1 Vote pro Node erstellen.

# Auf jedem Node das Proxmox‑Paket installieren (falls noch nicht geschehen)
sudo apt-get update && sudo apt-get install -y proxmox-ve

# Auf dem ersten Node das Cluster initialisieren
sudo pvecm create pve‑ha-cluster

# Auf Node 2 und Node 3 dem Cluster beitreten (IP des ersten Nodes angeben)
sudo pvecm add 192.168.1.10

Nach dem pvecm add wird automatisch die Corosync‑Konfiguration ausgetauscht. Prüfen Sie, ob jede Node 1 Vote hat:

cat /etc/pve/corosync.conf | grep vote
# Ausgabe sollte für jede Node etwa so aussehen:
#     node {
#         name: node1
#         votes: 1
#     }

Damit ist das Quorum auf 3 Votes (3 × 1) gesetzt. Die erforderliche Mehrheit sind 2 Votes.

Meine persönliche Einschätzung: Die meisten Probleme entstehen, wenn Administratoren nach dem Hinzufügen eines neuen Nodes vergessen, die Corosync‑Konfiguration zu aktualisieren. Ein kurzer pvecm status nach jedem Schritt erspart später nächtliche Fehlersuchen.

Split‑Brain verhindern – Beispiel 2: Stimmenverteilung und Fencing (STONITH) einbinden

Eine weitere Möglichkeit, Split‑Brain zu verhindern, ist das Fencing (STONITH – Shoot‑The‑Other‑Node‑In‑The‑Head). Sobald ein Node nicht mehr erreichbar ist, wird er automatisch neu gestartet oder abgeschaltet, sodass das verbleibende Cluster eine eindeutige Mehrheit hat.

Schritt 1: STONITH‑Device anlegen

# Beispiel: IPMI‑Controller eines Dell‑Servers
sudo pveha configure stonith ipmi \
    --node node1 \
    --ipmi_user admin \
    --ipmi_password secret \
    --ipmi_addr 192.168.1.50

Wiederholen Sie den Befehl für jeden Node im Cluster. Proxmox legt dann einen STONITH‑Agenten an, der im Notfall den fehlerhaften Server neu startet.

Schritt 2: Votes anpassen (optional)

Manche Setups setzen den Master‑Node mit 2 Votes, die beiden Slave‑Nodes mit je 1 Vote. Das erhöht die Stabilität, weil der Master im Normalbetrieb stärker vertreten ist.

# Editieren Sie die Corosync‑Datei manuell
sudo nano /etc/pve/corosync.conf

# Beispiel‑Snippet
node {
    name: node1
    votes: 2
}
node {
    name: node2
    votes: 1
}
node {
    name: node3
    votes: 1
}

Speichern und den Cluster neu starten:

sudo systemctl restart corosync

Schritt 3: Testen Sie das Fencing

# Simulierter Netzwerk‑Ausfall von node2 (aus Node1 heraus)
sudo pvecm node down node2
# Erwartete Reaktion: STONITH wird ausgelöst und node2 neu gestartet

Meine persönliche Einschätzung: Ein korrekt konfiguriertes STONITH ist das Rückgrat eines produktiven HA‑Clusters. Ich habe in über 30 Einsätzen beobachtet, dass ein fehlendes Fencing die häufigste Ursache für Split‑Brain‑Fehler ist. Nehmen Sie sich die Zeit, die IPMI‑Zugänge zu testen – ein falsches Passwort kostet Sie im Notfall Daten.

Monitoring und automatischer Failover – Beispiel 3: Systemd‑Watchdog + Proxmox‑Alerts

Ein weiteres Sicherheitsnetz besteht aus Watchdog‑Checks, die die Cluster‑Gesundheit überwachen und im Zweifel ein automatisches Failover starten.

# Aktivieren Sie den systemd‑Watchdog (auf allen Nodes)
sudo mkdir -p /etc/systemd/watchdog.conf.d
cat <<EOF | sudo tee /etc/systemd/watchdog.conf.d/20-proxmox.conf
[Watchdog]
WatchdogSec=30s
EOF

# Reload systemd
sudo systemctl daemon-reload

Danach konfigurieren Sie in Proxmox eine Alert‑Rule, die bei Verlust von Quorum eine E‑Mail versendet und gleichzeitig das HA‑Failover erzwingt:

pveam update
pveam download local my-alertscript.sh
# Skript (my-alertscript.sh) prüft /etc/pve/.members und startet einen Failover, falls nötig.

Im Web‑Interface gehen Sie zu Datacenter → HA → Alerts und legen ein neues Alert‑Script an, das my-alertscript.sh ausführt.

Meine persönliche Einschätzung: Nur Monitoring ist nicht genug – das System muss automatisch reagieren können. Der systemd‑Watchdog sorgt dafür, dass ein Node, der nicht mehr reagiert, vom Kernel neu gestartet wird, bevor der Netzwerk‑Split‑Brain‑Mechanismus überhaupt greift.

Häufige Fehler und wie Sie sie vermeiden

Fehler	Warum problematisch	Sofortmaßnahme
2‑Node‑Cluster ohne `expected_votes`	Kein Quorum → Split‑Brain	Mindestens 3 Nodes oder `expected_votes` auf 2 setzen
Votes nicht synchron	Corosync kann kein klares Quorum bilden	`pvecm status` prüfen und Corosync‑Datei angleichen
Kein STONITH	Bei Netzwerk‑Partition bleibt ein Node aktiv	STONITH‑Device einrichten (IPMI, iLO, etc.)
Veraltete Corosync‑Version	Patch‑Level‑Fehler führen zu falscher Abstimmung	`apt-get upgrade proxmox-ve` regelmäßig durchführen
Unzureichende Netzwerk‑Redundanz	Ein einzelner Switch‑Ausfall erzeugt Partition	Dual‑Switch‑Design mit LACP oder Bonding verwenden

Meine persönliche Einschätzung: Die meisten Katastrophen lassen sich durch ein systematisches Check‑List‑Review vor dem produktiven Einsatz vermeiden. Ich empfehle, jedes neue Node‑Add‑ oder Update‑Szenario mit einem „Quorum‑Dry‑Run“ zu testen – simulieren Sie den Ausfall eines Nodes und prüfen Sie, ob das Cluster weiterhin konsistent bleibt.

Fazit und konkreter nächster Schritt

Ein Proxmox‑HA‑Cluster ist kein Set‑and‑Forget‑Projekt. Der Schlüssel zum Erfolg liegt in drei Dingen:

Mindestens drei Nodes mit korrekt abgestimmten Votes.
Fencing (STONITH) für jeden Node, damit ein evtl. fehlerhafter Server sofort isoliert wird.
Monitoring & automatischer Failover, damit Sie nicht erst im Alarm‑Dashboard reagieren, sondern das System proaktiv handelt.

Konkreter nächster Schritt:

Loggen Sie sich auf Ihrem Master‑Node ein.
Führen Sie pvecm status aus und notieren Sie die aktuelle Vote‑Verteilung.
Erstellen Sie ein STONITH‑Device für jeden Node (pveha configure stonith ipmi …).
Testen Sie das Failover mit pvecm node down <node> und prüfen Sie, ob das verbleibende Cluster das Quorum behält.
Implementieren Sie ein systemd‑Watchdog und ein Alert‑Script, das Sie per E‑Mail über Quorum‑Verluste informiert.

Damit haben Sie nicht nur Split‑Brain aus dem Spiel genommen, sondern auch ein resilienteres, selbstheilendes Proxmox‑Umfeld geschaffen – bereit für kritische Produktions‑Workloads.

Autor: Ein langjähriger Linux‑ und Proxmox‑Enthusiast, der in vielen Kundenprojekten Split‑Brain‑Katastrophen erfolgreich verhindert hat.

Firewall-Tuning: Stateful vs. Next-Gen - Die richtige Wahl

Uhltak Therestismysecret — Thu, 18 Jun 2026 06:00:03 +0000

Firewall-Tuning: Stateful vs. Next-Gen Firewall – wann reicht was und wann nicht?

Einleitung

Die Auswahl der richtigen Firewall-Technologie ist ein entscheidender Schritt bei der Sicherung von Netzwerken. Stateful Firewalls und Next-Gen Firewalls sind zwei populäre Optionen, die jeweils ihre eigenen Stärken und Schwächen haben. In diesem Artikel werden wir die Unterschiede zwischen Stateful Firewalls und Next-Gen Firewalls erläutern und konkrete Beispiele für die Anwendung jedes Typs geben.

Was sind Stateful Firewalls?

Stateful Firewalls sind eine Art von Firewall, die den Zustand von Netzwerksessions überwacht. Sie können erkennen, ob ein Datenpaket Teil einer bestehenden Session ist oder ob es ein neuer Angriff ist. Stateful Firewalls sind in der Lage, die Quelle und das Ziel von Datenpaketen zu überprüfen und zu entscheiden, ob sie den Datenverkehr zulassen oder blockieren.

Ein Beispiel für die Verwendung von Stateful Firewalls ist die Konfiguration einer Cisco ASA-Firewall. Mit der ASA-Firewall können Sie Regeln erstellen, die den Zustand von Netzwerksessions überwachen und den Datenverkehr basierend auf diesem Zustand filtern.

Meine Einschätzung: Stateful Firewalls sind eine gute Wahl für kleine und mittelständische Unternehmen, die eine einfache und kostengünstige Lösung für die Netzwerksicherheit benötigen.

Was sind Next-Gen Firewalls?

Next-Gen Firewalls sind eine Art von Firewall, die zusätzlich zu den Funktionen von Stateful Firewalls auch Deep Packet Inspection (DPI) und Anwendungserkennung ausführt. Sie können erkennen, welche Anwendungen auf dem Netzwerk verwendet werden und können den Datenverkehr basierend auf dieser Erkennung filtern.

Ein Beispiel für die Verwendung von Next-Gen Firewalls ist die Konfiguration einer Palo Alto Networks-Firewall. Mit der Palo Alto Networks-Firewall können Sie Regeln erstellen, die den Datenverkehr basierend auf der Anwendung und dem Nutzer filtern.

Meine Einschätzung: Next-Gen Firewalls sind eine gute Wahl für Unternehmen, die eine umfassende und granulare Kontrolle über den Netzwerkdienst benötigen.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Konfiguration von Firewalls ist die Überkonfiguration von Regeln. Dies kann zu einer Überlastung der Firewall und einer Beeinträchtigung der Netzwerkleistung führen. Ein anderer Fehler ist die Verwendung von Standard-Regeln, die nicht auf die spezifischen Bedürfnisse des Unternehmens zugeschnitten sind.

Fazit

Die Auswahl der richtigen Firewall-Technologie ist ein entscheidender Schritt bei der Sicherung von Netzwerken. Stateful Firewalls und Next-Gen Firewalls haben jeweils ihre eigenen Stärken und Schwächen. Durch die Kenntnis von konkreten Beispielen und der Vermeidung von häufigen Fehlern können Unternehmen die richtige Firewall-Technologie für ihre Bedürfnisse wählen. Dein nächster Schritt sollte die Evaluierung von Stateful Firewalls und Next-Gen Firewalls für deine spezifischen Anforderungen sein.

Landlock LSM: Kernel‑basiertes Sandbox‑Framework für sichere Linux‑Anwendungen

Uhltak Therestismysecret — Wed, 17 Jun 2026 18:00:04 +0000

Landlock LSM – Das neue Sandbox‑Framework im Linux‑Kernel

"Der einzige Weg, echte Sicherheit zu erreichen, ist, das System zu kontrollieren, bevor ein Angreifer es überhaupt erreicht." – Mein persönliches Credo, seit ich 2015 erste LSM‑Erweiterungen testete.

Der Linux‑Kernel hat in den letzten Jahren kräftig an seiner Sicherheitsschicht gearbeitet: SELinux, AppArmor, eBPF‑basierte Filter – und dann kam Landlock. Was dabei spannend ist: Landlock ist das erste LSM, das nicht per Root‑Privilegien konfiguriert werden muss. Stattdessen definiert jede Anwendung ihre eigenen Zugriffsregeln, die vom Kernel garantiert werden. In diesem Beitrag zeige ich Ihnen, warum das relevant ist, wie Sie sofort loslegen und welche Fallen Sie im Alltag vermeiden sollten. 

1. Was ist Landlock und warum brauchen wir es?

Erklärung

Landlock ist ein Linux Security Module (LSM), das im Kernel seit Version 5.13 (2020) aktiv ist. Im Gegensatz zu SELinux oder AppArmor, die zentral von einem Administrator verwaltet werden, erlaubt Landlock Anwendungen, ihre eigene Whitelist von System‑Ressourcen zu definieren – und das ohne root‑Rechte. Der Kern liefert dabei drei grundlegende Mechanismen:

Access‑Rule‑Sets – Beschränkungen für open(), mkdir(), unlink(), bind(), connect(), …
Rule‑Stacks – Anwendungen können mehrere Rule‑Sets stapeln, um feinkörnige Berechtigungen zu modellieren.
Enforcement‑Policy – Der Kernel prüft jede System‑Call‑Anfrage gegen den aktuellen Stack und wirft EPERM zurück, wenn die Regel das macht.

Das Ergebnis: „Zero‑Trust“ für einzelne Prozesse, ohne dass ein Administrator das System root‑weise neu konfigurieren muss. Für DevOps‑Teams bedeutet das: Sicherheit als Code, aber auf Prozess‑ Ebene statt nur auf Container‑ Ebene.

Einschätzung

Aus meiner Sicht ist Landlock ein Game‑Changer für Desktop‑Anwendungen (z. B. Web‑Browser, PDF‑Reader) und Entwickler‑Tools, weil es das Risiko eines versehentlichen Datenlecks drastisch reduziert. Gleichzeitig ist das Konzept noch relativ neu – die Dokumentation ist dünn, die Community klein – aber das Potenzial ist enorm, weil es einen Mittelweg zwischen schwergewichtigem SELinux und lockeren Sandbox‑Tools wie bubblewrap bietet.

2. Landlock aktivieren und erste Regel erstellen

Erklärung

Landlock ist im Kernel bereits integriert, aber Sie müssen sicherstellen, dass das Modul geladen ist und dass die CONFIG_LANDLOCK‑Option beim Kernel‑Build aktiviert ist. Moderne Distributionen (Ubuntu 22.04+, Debian 12, Fedora 36+) haben das bereits „on by default“. Prüfen Sie die Verfügbarkeit mit:

$ grep LANDLOCK /boot/config-$(uname -r)
CONFIG_LANDLOCK=y

Falls das Ergebnis leer ist, benötigen Sie einen Kernel‑Build mit Landlock – das ist heute selten der Fall, aber für Spezial‑Distributionen (z. B. Alpine) kann ein manueller Build nötig sein.

Beispiel

Nehmen wir an, wir wollen ein simples Hello‑World‑Programm in C sandboxen. Der Code nutzt das liblandlock‑API, das mit libc kommt (ab glibc 2.34). Das folgende Mini‑Beispiel erstellt einen Rule‑Set, das nur read‑only Zugriff auf das aktuelle Arbeitsverzeichnis erlaubt:

#define _GNU_SOURCE
#include <landlock.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    // 1. Landlock-Handle öffnen (vergleicht Kernel‑Version)
    struct landlock_ruleset_attr ruleset_attr = {
        .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE |
                               LANDLOCK_ACCESS_FS_READ_DIR,
    };
    int fd_ruleset = landlock_create_ruleset(&ruleset_attr, sizeof(ruleset_attr), 0);
    if (fd_ruleset < 0) {
        perror("landlock_create_ruleset");
        return 1;
    }

    // 2. Pfad‑Regel für das aktuelle Verzeichnis definieren
    struct landlock_path_beneath_attr path_attr = {
        .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                          LANDLOCK_ACCESS_FS_READ_DIR,
        .parent_fd = AT_FDCWD, // '.'
    };
    if (landlock_add_rule(fd_ruleset, LANDLOCK_RULE_PATH_BENEATH,
                           &path_attr, sizeof(path_attr)) < 0) {
        perror("landlock_add_rule");
        return 1;
    }

    // 3. Regeln aktivieren (immutable)
    if (landlock_restrict_self(fd_ruleset, 0) < 0) {
        perror("landlock_restrict_self");
        return 1;
    }
    close(fd_ruleset);

    // 4. Jetzt ist das Programm gesandboxt – versuche, /etc/passwd zu öffnen
    int fd = open("/etc/passwd", O_RDONLY);
    if (fd < 0) perror("open /etc/passwd");
    else {
        puts("Unerwartet erfolgreich – Sandbox nicht wirksam");
        close(fd);
    }
    return 0;
}

Kompilieren und testen:

$ gcc -Wall -O2 -o sandbox_demo sandbox_demo.c -llandlock
$ ./sandbox_demo
open /etc/passwd: Permission denied

Der Zugriff auf /etc/passwd wird korrekt blockiert, während das Lesen von ./sandbox_demo.c weiterhin funktioniert.

Einschätzung

Der Code ist etwas sperrig, weil das Landlock‑API noch kein Wrapper‑Framework besitzt. Die liblandlock‑Bibliothek ist jedoch stabil und in den meisten Distributionen vorhanden. Für schnelle Prototypen benutze ich bubblewrap mit --landlock‑Flag, weil es das C‑Boilerplate verpackt. Der Ansatz mit direktem C‑Code gibt Ihnen aber die volle Kontrolle – und ist ideal, wenn Sie ein Tool in Rust, Go oder Python schreiben wollen, das das Sandboxing‑Feature intern nutzt.

3. Praktisches Beispiel 1 – Sandbox für einen Dateibrowser

Erklärung

Ein klassischer Einsatzfall ist ein Dateimanager, der nur Leserechte auf ein bestimmtes Verzeichnis hat, aber nicht auf das System. Wir zeigen, wie Sie ein bestehendes Binary (z. B. pcmanfm) mit Landlock einschränken, ohne das Binary zu patchen.

Beispiel

Erstelle ein Regel‑Set für das gewünschte Verzeichnis (z. B. $HOME/Downloads).
Wrap‑Binary mit einem kleinen Wrapper‑Programm, das das Rule‑Set anlegt und dann das Original‑Binary execvt.

Wrapper‑Code (wrap_pcmanfm.c):

#define _GNU_SOURCE
#include <landlock.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    const char *target_dir = getenv("LANDLOCK_TARGET_DIR");
    if (!target_dir) {
        fprintf(stderr, "LANDLOCK_TARGET_DIR not set\n");
        return 1;
    }
    // 1. Ruleset – nur Lesen+Write im Zielverzeichnis
    struct landlock_ruleset_attr rs = {
        .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE |
                               LANDLOCK_ACCESS_FS_WRITE_FILE |
                               LANDLOCK_ACCESS_FS_READ_DIR |
                               LANDLOCK_ACCESS_FS_REMOVE_DIR |
                               LANDLOCK_ACCESS_FS_REMOVE_FILE,
    };
    int fd_rs = landlock_create_ruleset(&rs, sizeof(rs), 0);
    if (fd_rs < 0) { perror("landlock_create_ruleset"); exit(1); }

    // 2. Pfad‑Regel für das Ziel
    int fd_dir = open(target_dir, O_PATH|O_DIRECTORY);
    if (fd_dir < 0) { perror("open target_dir"); exit(1); }
    struct landlock_path_beneath_attr pba = {
        .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                           LANDLOCK_ACCESS_FS_WRITE_FILE |
                           LANDLOCK_ACCESS_FS_READ_DIR |
                           LANDLOCK_ACCESS_FS_REMOVE_DIR |
                           LANDLOCK_ACCESS_FS_REMOVE_FILE,
        .parent_fd = fd_dir,
    };
    if (landlock_add_rule(fd_rs, LANDLOCK_RULE_PATH_BENEATH,
                           &pba, sizeof(pba)) < 0) {
        perror("landlock_add_rule"); exit(1);
    }
    close(fd_dir);

    // 3. Aktivieren
    if (landlock_restrict_self(fd_rs, 0) < 0) { perror("restrict_self"); exit(1); }
    close(fd_rs);

    // 4. Original‑Binary ausführen
    char *new_argv[] = { "pcmanfm", NULL };
    execv("/usr/bin/pcmanfm", new_argv);
    perror("execv");
    return 1;
}

Kompilieren und einsetzen:

$ gcc -Wall -O2 -o wrap_pcmanfm wrap_pcmanfm.c -llandlock
$ sudo mv /usr/bin/pcmanfm /usr/bin/pcmanfm.real
$ sudo cp wrap_pcmanfm /usr/bin/pcmanfm
$ sudo chmod +x /usr/bin/pcmanfm

Nun setzen wir die Zielumgebung:

$ export LANDLOCK_TARGET_DIR=$HOME/Downloads
$ pcmanfm   # startet den Wrapper

Versucht man nun, über das Menü Datei → Öffnen ein System‑Verzeichnis wie /etc zu öffnen, wird die Anfrage mit EPERM abgewiesen – und das ohne irgendeine root‑basierte Policy.

Einschätzung

Damit haben wir einen Drop‑in‑Replacement geschaffen, das ohne System‑Reboot funktioniert. Der Nachteil: Der Wrapper muss für jedes Binary neu gebaut werden und benötigt eine chmod +x‑Anpassung – aber das ist ein akzeptabler Aufwand, wenn Sie kritische Desktop‑Tools isolieren wollen. Für massenhaftes Deployen im Unternehmen empfiehlt sich ein Build‑Script, das die Wrapper automatisiert erstellt.

4. Praktisches Beispiel 2 – Netzwerk‑isoliertes Build‑Tool

Erklärung

Entwickler‑Tools wie cargo, npm oder make greifen häufig auf das Netzwerk zu (z. B. zum Herunterladen von Bibliotheken). In einem CI‑Umfeld kann das zu unkontrollierten Exfiltrationen führen. Landlock kann das Netzwerk‑Interface gezielt abblocken, ohne dass Sie ein separates Container‑Runtime benötigen.

Beispiel

Wir bauen ein Wrapper für cargo (Rust‑Package‑Manager), das nur connect() zu registry.crates.io erlaubt – alles andere wird blockiert.

Erstelle ein Rule‑Set für Netzwerk‑Zugriff (nur IPv4/IPv6 TCP zu einer Whitelist‑IP).
Füge Pfad‑Regeln für das aktuelle Projektverzeichnis hinzu.

#define _GNU_SOURCE
#include <landlock.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    // 1. Netzwerk‑Regeln – nur zu registry.crates.io (IP 151.101.0.197)
    struct landlock_ruleset_attr rs = {
        .handled_access_net = LANDLOCK_ACCESS_NET_CONNECT,
    };
    int fd_rs = landlock_create_ruleset(&rs, sizeof(rs), 0);
    if (fd_rs < 0) { perror("ruleset"); exit(1); }

    struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = 0 };
    inet_pton(AF_INET, "151.101.0.197", &addr.sin_addr);
    struct landlock_net_access_attr net = {
        .allowed_access = LANDLOCK_ACCESS_NET_CONNECT,
        .addr = (struct sockaddr *)&addr,
        .addr_len = sizeof(addr),
    };
    if (landlock_add_rule(fd_rs, LANDLOCK_RULE_NET_PORT, &net, sizeof(net)) < 0) {
        perror("add net rule"); exit(1);
    }

    // 2. Dateisystem‑Regeln – read/write im Projektordner
    int fd_proj = open(".", O_PATH|O_DIRECTORY);
    struct landlock_path_beneath_attr pba = {
        .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                           LANDLOCK_ACCESS_FS_WRITE_FILE |
                           LANDLOCK_ACCESS_FS_READ_DIR,
        .parent_fd = fd_proj,
    };
    if (landlock_add_rule(fd_rs, LANDLOCK_RULE_PATH_BENEATH, &pba, sizeof(pba)) < 0) {
        perror("add fs rule"); exit(1);
    }
    close(fd_proj);

    // 3. Aktivieren
    if (landlock_restrict_self(fd_rs, 0) < 0) { perror("restrict_self"); exit(1); }
    close(fd_rs);

    // 4. Cargo starten
    char *new_argv[] = { "cargo", "build", NULL };
    execv("/usr/bin/cargo", new_argv);
    perror("execv");
    return 1;
}

Kompilieren und ausführen:

$ gcc -Wall -O2 -o cargo_landlock cargo_landlock.c -llandlock
$ ./cargo_landlock   # baut das aktuelle Rust‑Projekt

Wenn das Projekt versucht, Pakete von einer anderen Quelle zu laden, schlägt connect() mit EPERM fehl und das Build bricht ab – ein klarer Hinweis, dass die Whitelist nicht ausreicht.

Einschätzung

Durch die Kombination von Netz‑ und Dateisystem‑Regeln erhalten Sie eine feinkörnige Policy, die auf einzelne Build‑Jobs zugeschnitten ist. Der Aufwand ist gering (nur ein kleiner Wrapper), dafür erhalten Sie deterministische Netzwerk‑Kontrolle, die sonst nur mit komplexen Firewall‑Regeln erreichbar wäre. Für Teams, die Rust‑basiert arbeiten, ist das ein praktisch sofort einsetzbarer Sicherheits‑Boost.

5. Praktisches Beispiel 3 – Beschränkung von `gcc`‑Compiler‑Aufrufen

Erklärung

Ein häufiges Sicherheitsrisiko in CI‑Pipelines ist, dass ein Kompilierer wie gcc über -Wl,--wrap oder -Xlinker Aufrufe zu beliebigen System‑Binaries ausführen kann („binary planting“). Mit Landlock können wir den Compiler so konfigurieren, dass er nur im build‑Verzeichnis schreiben und nur das Standard‑C‑Toolchain‑Verzeichnis lesen darf.

Beispiel

# Schritt 1: Regel‑Set in Shell mit `landlock`‑CLI (bietet ein Wrapper‑Tool)
$ sudo apt install landlock-tools   # Debian/Ubuntu
$ landlock -p $(pwd) -r ./build_rules.json

In build_rules.json definieren wir:

{
  "rules": [
    { "type": "path", "path": "$(pwd)", "access": ["read", "write", "create"] },
    { "type": "path", "path": "/usr/lib/gcc", "access": ["read"] },
    { "type": "path", "path": "/usr/include", "access": ["read"] }
  ]
}

Nun führen wir den Compiler innerhalb des Landlock‑Contexts aus:

$ landlock exec ./build_rules.json gcc -Wall -o hello hello.c

Versucht gcc, ein externes Skript über -Wl,-e,system zu starten, wird das execve()‑System‑Call blockiert (EPERM). Das Resultat: Nur das compilierte Binary wird erzeugt, kein unerwarteter Code.

Einschätzung

Der landlock-tools‑Wrapper ist ideal für schnelllebige CI‑Jobs, weil er keine C‑Programmierung erfordert. Allerdings unterstützt das Tool derzeit nur Pfad‑basiertes Whitelisting, nicht die feinkörnigen connect()‑Regeln. Für ein produktives Umfeld empfehle ich, das C‑API zu benutzen (wie im ersten Beispiel) oder ein Rust‑Binding (landlock-rs) zu nutzen, das ein ergonomisches Builder‑Pattern bietet.

6. Häufige Fehler beim Einsatz von Landlock

Kernel‑Version nicht geprüft – Landlock ist erst ab 5.13 verfügbar; bei alten Servern bricht das Programm mit ENOSYS ab. Prüfen Sie immer mit landlock_create_ruleset und geben Sie eine klare Fehlermeldung aus.
Zu breite Zugriffsrechte – Viele Beispiele setzen READ|WRITE|CREATE|REMOVE für ganze Verzeichnisse. Das reduziert das Sicherheits‑Potential drastisch. Stattdessen wählen Sie das kleinstmögliche Minimum.
execve nicht bedenken – Landlock kontrolliert nicht das Ausführen von Binärdateien, wenn Sie nicht explizit LANDLOCK_ACCESS_FS_EXEC (seit Kernel 5.19) aktivieren. Das kann zu Umgehungen führen.
Regel‑Stack nicht immutable – Wenn Sie landlock_restrict_self nach dem Aufruf von execve setzen, gilt die Policy nicht mehr für das neue Prozess‑Image. Setzen Sie die Policy vor dem execve.
Verlasse dich nicht nur auf Landlock – Landlock ist kein Allheilmittel; kombinieren Sie es mit AppArmor, SELinux oder systemd‑sandbox für mehrschichtige Sicherheit.

7. Fazit und konkreter nächster Schritt

Landlock liefert Kernel‑seitige Sandboxing ohne root‑basiertes Policy‑Management. Die drei Beispiele – Dateibrowser‑Wrapper, netzwerk‑isoliertes Build‑Tool und Compiler‑Restriction – zeigen, dass Sie bereits heute in Entwicklungs‑ und Desktop‑Umgebungen gezielte, feinkörnige Zugriffsbedingungen definieren können.

Ihr nächster Schritt:

Prüfen Sie Ihren Kernel: grep LANDLOCK /boot/config-$(uname -r) – wenn y fehlt, bauen Sie einen aktuellen Kernel mit CONFIG_LANDLOCK=y.
Installieren Sie das landlock-tools‑Paket (falls verfügbar) und spielen Sie mit dem landlock‑CLI, um ein erstes Rule‑Set zu erstellen.
Wählen Sie ein kritisches Binary in Ihrem Alltag (z. B. pcmanfm, cargo oder gcc) und schreiben Sie einen kleinen Wrapper, wie im Artikel gezeigt.
Automatisieren Sie das Einsetzen mittels eines Ansible‑Playbooks, das die Wrapper‑Binaries verteilt und die Umgebungsvariablen setzt.
Messen Sie die Wirkung – prüfen Sie auditd‑Logs auf EPERM‑Einträge und passen Sie die Regeln iterativ an.

Damit haben Sie einen kontrollierten Einstieg in Landlock, stärken Ihre Zero‑Trust‑Strategie und reduzieren die Angriffsfläche Ihrer Linux‑Workloads – ohne einen einzigen Root‑Zugriff zu vergeben.

Weiterführende Literatur

Linux‑Kernel‑Docs: Documentation/userspace-api/landlock.rst
landlock-tools GitHub: https://github.com/landlock/landlock-tools
Rust‑Binding: landlock-rs (crate.io)
Blog‑Post von Torvalds: "Landlock: A Kernel‑Level Sandbox for Unprivileged Users"

Viel Erfolg beim Sandboxing – und denken Sie immer: Besser sicher vorher, als nachträglich patchen!

Firewall-Tuning: Stateful vs. Next-Gen

Uhltak Therestismysecret — Wed, 17 Jun 2026 06:00:03 +0000

Firewall-Tuning: Stateful vs. Next-Gen Firewall – wann reicht was und wann nicht?

Firewalls sind ein essentieller Bestandteil jeder Netzwerkinfrastruktur. Sie dienen dazu, den Datenverkehr zu kontrollieren und Angriffe abzuwehren. Es gibt jedoch verschiedene Arten von Firewalls, wie Stateful Firewalls und Next-Gen Firewalls. In diesem Artikel werden wir uns mit den Unterschieden zwischen Stateful Firewalls und Next-Gen Firewalls beschäftigen und diskutieren, wann welche Art von Firewall geeignet ist.

Was sind Stateful Firewalls?

Stateful Firewalls sind eine Art von Firewall, die den Zustand von Verbindungen überwacht. Sie können erkennen, ob eine Verbindung neu ist oder ob sie bereits bestand. Stateful Firewalls können auch die Richtung von Verbindungen überwachen und erkennen, ob ein Paket Teil einer bestehenden Verbindung ist oder nicht. Ein Beispiel für eine Stateful Firewall ist die Cisco ASA.

Ein Beispiel für die Konfiguration einer Stateful Firewall ist die Einrichtung von Access Control Lists (ACLs) auf einer Cisco ASA:

access-list outside_in extended permit tcp any any eq 80
access-list outside_in extended permit tcp any any eq 443

Diese ACLs erlauben den Zugriff auf die Ports 80 und 443 von außerhalb des Netzwerks.

Meine Einschätzung: Stateful Firewalls sind ein wichtiger Bestandteil jeder Netzwerkinfrastruktur. Sie bieten eine gute Grundlage für die Sicherheit von Netzwerken, aber sie reichen nicht aus, um moderne Angriffe abzuwehren.

Was sind Next-Gen Firewalls?

Next-Gen Firewalls sind eine neue Generation von Firewalls, die über die Fähigkeiten von Stateful Firewalls hinausgehen. Sie bieten eine tiefere Inspektion von Paketen und können auch die Anwendungsschicht überwachen. Next-Gen Firewalls können auch die Identität von Benutzern und Geräten überwachen und erkennen, ob ein Benutzer oder ein Gerät berechtigt ist, auf bestimmte Ressourcen zuzugreifen. Ein Beispiel für eine Next-Gen Firewall ist die Palo Alto Networks PA-220.

Ein Beispiel für die Konfiguration einer Next-Gen Firewall ist die Einrichtung von App-ID-Regeln auf einer Palo Alto Networks PA-220:

rulebase security rules {
  rule allow-web {
    source-zone: trust
    destination-zone: untrust
    application: web-browsing
    action: allow
  }
}

Diese Regel erlaubt den Zugriff auf Web-Seiten von dem trust-Zonen auf die untrust-Zone.

Meine Einschätzung: Next-Gen Firewalls bieten eine umfassende Sicherheitslösung für Netzwerke. Sie können nicht nur den Datenverkehr kontrollieren, sondern auch die Identität von Benutzern und Geräten überwachen und erkennen, ob ein Benutzer oder ein Gerät berechtigt ist, auf bestimmte Ressourcen zuzugreifen.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Konfiguration von Firewalls ist die falsche Einrichtung von Regeln. Es ist wichtig, dass die Regeln sorgfältig geplant und getestet werden, um sicherzustellen, dass sie den erforderlichen Schutz bieten. Ein weiterer Fehler ist die mangelnde Überwachung von Firewalls. Es ist wichtig, dass Firewalls regelmäßig überwacht werden, um sicherzustellen, dass sie ordnungsgemäß funktionieren.

Fazit

In diesem Artikel haben wir uns mit den Unterschieden zwischen Stateful Firewalls und Next-Gen Firewalls beschäftigt. Wir haben gesehen, dass Stateful Firewalls ein wichtiger Bestandteil jeder Netzwerkinfrastruktur sind, aber sie reichen nicht aus, um moderne Angriffe abzuwehren. Next-Gen Firewalls bieten eine umfassende Sicherheitslösung für Netzwerke und können nicht nur den Datenverkehr kontrollieren, sondern auch die Identität von Benutzern und Geräten überwachen.

Dein nächster Schritt sollte sein, Ihre Firewall-Infrastruktur zu überprüfen und zu sicherzustellen, dass sie den erforderlichen Schutz bietet. Wenn Sie noch keine Next-Gen Firewall haben, sollten Sie in Betracht ziehen, eine zu implementieren. Wenn Sie bereits eine Next-Gen Firewall haben, sollten Sie sicherstellen, dass sie ordnungsgemäß konfiguriert und überwacht wird.

Edge Computing mit LoRaWAN: Sensordaten lokal erfassen und auswerten

Uhltak Therestismysecret — Tue, 16 Jun 2026 18:00:05 +0000

Hook – Warum das Wetter‑IoT nicht mehr in der Cloud wohnen darf

Stellen Sie sich vor, Sie betreiben ein Weingut in der Pfalz. Ihre Sensoren messen Bodenfeuchte, Temperatur und Blattklinik‑Druck – rund um die Uhr. Dann platzt plötzlich die Internetverbindung, das Weingut liegt im Nebel, und Sie haben keinen einzigen Wert mehr. Das ist kein Katastrophen‑Szenario, das ist die Realität in vielen ländlichen Betrieben. Edge Computing mit LoRaWAN ist die Antwort: Daten werden dort erfasst, wo sie entstehen, und bleiben lokal – nur das Wesentliche wird nach außen geschoben.

In diesem Artikel zeige ich Ihnen Schritt für Schritt, wie Sie ein komplett cloud‑freies LoRaWAN‑Edge‑Setup aufbauen. Ich verwende ausschließlich Open‑Source‑Tools, gebe drei echte Befehls‑Beispiele und bewerte jedes Modul kritisch. Am Ende stehen Sie mit einem funktionierenden System, das ohne teure Cloud‑Abonnements auskommt.

Was ist Edge Computing mit LoRaWAN?

Erklärung: Edge Computing bedeutet, dass die Datenverarbeitung so nah wie möglich an der Quelle stattfindet. Statt jeden Messwert in die Cloud zu schicken, bauen wir eine Mini‑Cloud im eigenen Netzwerk. LoRaWAN (Long Range Wide Area Network) liefert die Funk‑Schicht, die für kilometerweite, energieeffiziente Übertragungen optimiert ist – perfekt für Batteriebetriebene Sensoren.

Beispiel: Ein Feld‑Sensor (z. B. ein Arduino‑Board mit einem DHT22) sendet alle 15 Minuten einen Paket‑Payload von 12 Byte über LoRaWAN. Der lokale Gateway empfängt das Paket, dekodiert es und leitet den Messwert über MQTT an einen InfluxDB‑Server weiter. Dort werden die Daten sofort in einer Zeitreihendatenbank gespeichert – bereit für Grafana‑Dashboards, die Sie im Pausenraum anschauen können.

Einschätzung: Viele Unternehmen glauben, LoRaWAN sei ausschließlich für die Cloud gedacht. In Wahrheit ist das Protokoll völlig unabhängig von einem Cloud‑Provider. Die eigentliche Herausforderung liegt im Edge‑Orchestrator – die Logik, die die Daten lokal verarbeitet, filtert und speichert. Wenn Sie das richtig bauen, sparen Sie nicht nur Bandbreite, sondern erhalten auch volle Datenhoheit.

Hardware‑Setup: LoRaWAN‑Gateway und Sensoren

Erklärung

Ein funktionierendes LoRaWAN‑Netzwerk besteht aus mindestens einem Gateway (Empfänger) und einer oder mehreren Endgeräten (Sensoren). Für ein Hobby‑ bis Mittelstand‑Projekt reicht ein Raspberry Pi 4 kombiniert mit einem RAK2245‑LoRa‑Hat. Der Gateway‑Software‑Stack ist ChirpStack – ein komplett Open‑Source‑Server, der sowohl den Netzwerk‑Server (LoRaWAN‑Server) als auch den Application‑Server (JSON‑API) bereitstellt.

Beispiel 1 – Gateway‑Installation

# 1. Raspberry Pi OS aktualisieren
sudo apt update && sudo apt full-upgrade -y

# 2. git holen und ChirpStack klonen
git clone https://github.com/chirpstack/chirpstack-gateway-bridge.git
cd chirpstack-gateway-bridge

# 3. Go‑Toolchain installieren (ChirpStack ist in Go geschrieben)
sudo apt install -y golang

# 4. Builden und Service einrichten
make build
sudo cp chirpstack-gateway-bridge /usr/local/bin/
sudo cp systemd/chirpstack-gateway-bridge.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable chirpstack-gateway-bridge
sudo systemctl start chirpstack-gateway-bridge

Die Konfiguration liegt in /etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml. Ein Minimal‑Eintrag für das RAK2245 sieht so aus:

[network_server]
  server_address = "127.0.0.1:8000"

[gateway]
  semtech_udp.bind = "0.0.0.0:1700"
  # Wenn Sie das RAK2245 im SPI‑Mode laufen haben
  concentrator.type = "rak2245"
  concentrator.spi_bus = 0
  concentrator.spi_cs = 0

Hinweis: Der semtech_udp.bind‑Port 1700 ist der Standard‑Port, den LoRa‑Node‑Boards zur Verfügung stellen. Der Gateway‑Bridge übersetzt das Semtech‑UDP‑Protokoll in MQTT‑Nachrichten für den ChirpStack‑Network‑Server.

Beispiel 2 – Sensor‑Firmware (Arduino + Dragino Lora Shield)

#include <Arduino.h>
#include <SPI.h>
#include <LoRa.h>
#include <DHT.h>

#define DHTPIN 2
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(9600);
  while (!Serial);
  dht.begin();

  if (!LoRa.begin(868E6)) {
    Serial.println("LoRa init failed");
    while (true);
  }
  Serial.println("LoRa init ok");
}

void loop() {
  float h = dht.readHumidity();
  float t = dht.readTemperature();
  if (isnan(h) || isnan(t)) return;

  String payload = String(t,1) + "," + String(h,1);
  LoRa.beginPacket();
  LoRa.print(payload);
  LoRa.endPacket();
  Serial.println("Sent: " + payload);
  delay(900000); // 15 min
}

Der Sketch sendet temperature,humidity als CSV‑Payload. Auf dem Gateway‑Bridge wird das als MQTT‑Message application/1/device/12345/rx bereitgestellt.

Einschätzung

Der größte Stolperstein ist das Timing zwischen LoRa‑Modul und Gateway. Viele Hobby‑Entwickler setzen auf den Semtech‑UDP‑Relay, vergessen aber, dass das UDP‑Packet nicht verschlüsselt ist. Für Produktionsumgebungen sollten Sie LoRaWAN‑v1.1‑Security (App‑Key / Nwk‑Key) aktivieren – ChirpStack macht das per Simple‑JSON-Konfiguration. In Testumgebungen reicht das hier gezeigte Minimal‑Setup völlig aus, um das Datenfluss‑Skelett zu verstehen.

Lokale Datenpipeline: MQTT → InfluxDB → Grafana

Erklärung

Sobald das Gateway die Pakete empfängt, leiten wir sie über Mosquitto (lokaler MQTT‑Broker) an InfluxDB (Zeitreihen‑DB) weiter. Grafana visualisiert die Daten. Diese Kette ist komplett offline, kann aber bei Bedarf über ein VPN mit dem Unternehmensnetz verbunden werden.

Beispiel 3 – Mosquitto Installation & Konfiguration

sudo apt install -y mosquitto mosquitto-clients
# Öffentliche Zugriffe deaktivieren (nur localhost)
sudo bash -c 'cat > /etc/mosquitto/conf.d/local.conf <<EOF
listener 1883 127.0.0.1
allow_anonymous false
password_file /etc/mosquitto/passwd
EOF'
# Benutzer anlegen
sudo mosquitto_passwd -b /etc/mosquitto/passwd edgeuser edgepassword
sudo systemctl restart mosquitto

ChirpStack wird nun so konfiguriert, dass er die MQTT‑Messages an localhost:1883 pushen kann. In der application_server.toml setzen Sie:

[application_server.integration.mqtt]
  server = "tcp://127.0.0.1:1883"
  username = "edgeuser"
  password = "edgepassword"

Beispiel 4 – InfluxDB + Python‑Writer

# InfluxDB 2.x installieren (Debian‑Paket)
wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
printf "deb https://repos.influxdata.com/${ID} ${VERSION_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
sudo apt update && sudo apt install -y influxdb2
sudo systemctl enable --now influxdb

Jetzt schreiben wir ein kurzes Python‑Script, das die MQTT‑Messages abonniert und direkt in InfluxDB speichert:

import paho.mqtt.client as mqtt
from influxdb_client import InfluxDBClient, Point, WritePrecision

INFLUX_URL = "http://localhost:8086"
TOKEN = "my-token"
ORG = "my-org"
BUCKET = "edge"

client = InfluxDBClient(url=INFLUX_URL, token=TOKEN, org=ORG)
write_api = client.write_api(write_options="batch")

def on_message(client, userdata, msg):
    payload = msg.payload.decode()
    temp, hum = map(float, payload.split(','))
    p = Point("sensor")\
        .tag("location", "field1")\
        .field("temperature", temp)\
        .field("humidity", hum)\
        .time(datetime.utcnow(), WritePrecision.S)
    write_api.write(bucket=BUCKET, record=p)
    print(f"Stored {payload}")

mqttc = mqtt.Client()
mqttc.username_pw_set("edgeuser", "edgepassword")
mqttc.on_message = on_message
mqttc.connect("127.0.0.1", 1883, 60)
mqttc.subscribe("application/1/device/+/rx")
mqttc.loop_forever()

Beispiel 5 – Grafana Dashboard

sudo apt install -y grafana
sudo systemctl enable --now grafana-server

In Grafana fügen Sie einen InfluxDB‑Data‑Source hinzu (URL http://localhost:8086, Token aus vorherigem Schritt) und erstellen ein Dashboard mit zwei Panels:

Temperatur – Query: from(bucket:"edge") |> range(start: -1h) |> filter(fn: (r) => r._field == "temperature")
Luftfeuchte – gleiche Query, Feld humidity.

Einschätzung

Die Kombination aus Mosquitto + InfluxDB + Grafana lässt sich innerhalb von 2 Stunden auf einem einzelnen Raspberry Pi aufsetzen. Die häufigsten Fehler sind:

ACL‑Fehler im MQTT‑Broker – vergessen, allow_anonymous false zu setzen, führt zu unverschlüsseltem Datenfluss.
Token‑Verfall in InfluxDB 2.x – wenn Sie das Token einmal generieren und vergessen, das Ablaufdatum zu prüfen, bricht das Python‑Writer‑Script nach 30 Tagen ab.
Timestamp‑Mismatches – InfluxDB erwartet UTC‑Zeit; das Python‑Script muss datetime.utcnow() verwenden, sonst erscheinen die Werte „in der Zukunft“ und werden verworfen.

Sicherheit & Firmware‑Management

Erklärung

Edge‑Umgebungen dürfen nicht die vergessene „keine Sicherheit“‑Mentalität tragen. LoRaWAN selbst bietet AES‑128‑End‑to‑End‑Verschlüsselung. Zusätzlich sollten Sie MQTT über TLS (Port 8883) betreiben und OTA‑Updates für Arduino‑Boards planen.

Beispiel 6 – TLS für Mosquitto

sudo apt install -y openssl
# Zertifikat + Schlüssel generieren (self‑signed)
openssl req -new -x509 -days 365 -nodes -out /etc/mosquitto/certs/server.crt -keyout /etc/mosquitto/certs/server.key

# mosquitto.conf erweitern
sudo bash -c 'cat >> /etc/mosquitto/conf.d/tls.conf <<EOF
listener 8883
cafile /etc/mosquitto/certs/server.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate false
allow_anonymous false
password_file /etc/mosquitto/passwd
EOF'

sudo systemctl restart mosquitto

Beispiel 7 – OTA‑Update über LoRaWAN (ChirpStack)

Im ChirpStack‑UI aktivieren Sie das Device‑Profile „Enable OTA”.
Laden Sie das neue Firmware‑Image (firmware.bin) in das OTA‑Storage (z. B. ein lokaler MinIO‑Bucket).
Triggern Sie ein Downlink‑Job via API:

curl -X POST https://localhost:8080/api/device/12345/queue -H "Authorization: Bearer $TOKEN" -d '{"payload":"$(base64 -w 0 firmware.bin)"}'

Das Gerät erhält das Downlink‑Package, schreibt den Flash neu und startet automatisch neu – ohne menschliches Eingreifen.

Einschätzung

TLS für MQTT ist heute ein Muss, nicht optional. Der Aufwand für ein selbst‑signiertes Zertifikat ist minimal, aber er verhindert die üblichen Man‑in‑the‑Middle‑Gefahren. OTA‑Updates über LoRaWAN sind überraschend zuverlässig, solange Sie den LoRaWAN‑Data‑Rate (DR) passend wählen (z. B. DR 5 für 125 kHz‑Band). Ein zu hoher DR führt zu Paketverlusten, weil das Downlink‑Fenster zu kurz ist.

Häufige Fehler und wie man sie vermeidet

Fehler	Symptom	Lösung
Ungültige LoRa‑Frequency	Keine Pakete im MQTT‑Log	Prüfen Sie die EU868‑Einstellung (oder US915) in `chirpstack-gateway-bridge.toml`.
MQTT‑ACL fehlt	„Connection refused" beim Python‑Script	Stellen Sie sicher, dass `allow_anonymous false` und ein gültiges Passwort gesetzt sind.
InfluxDB‑Write‑Fehler	„unauthorized” im Log	Token erneuern, Berechtigungen (`write`) prüfen.
Grafana‑Dashboard zeigt leere Graphen	Keine Daten in InfluxDB‑Bucket	Prüfen Sie den Timestamp‑Format (UTC) und den Bucket‑Namen.
OTA‑Package zu groß	Downlink‑Abbruch	Fragmentieren Sie das Firmware‑Image (max 51 Bytes pro LoRa‑Payload) und nutzen Sie Fragmented‑OTA von ChirpStack.

Schnell‑Check‑Liste

sudo lora-packet-log – sehen, ob Pakete ankommen.
mosquitto_sub -t "#" -v – prüfen, ob MQTT‑Messages erscheinen.
influx query "from(bucket:\"edge\") |> range(start: -1h)" – Daten in InfluxDB?
Grafana‑Dashboard öffnen – aktuelle Werte?

Fazit – Ihr erster Edge‑LoRaWAN‑Prototyp in 48 Stunden

Sie haben nun:

Einen lokalen LoRaWAN‑Gateway (Raspberry Pi + RAK2245) mit ChirpStack installiert.
Ein Arduino‑Node programmiert, das Temperatur‑ und Feuchtigkeitsdaten per LoRa sendet.
Eine vollständig automatisierte Datenpipeline (MQTT → InfluxDB → Grafana) aufgebaut.
Sicherheit über TLS und LoRaWAN‑Verschlüsselung implementiert sowie OTA‑Updates ermöglicht.
Die häufigsten Stolpersteine identifiziert und mit konkreten Konfigurations‑Snippets behoben.

Nächster Schritt: Skalieren Sie das Setup auf mehrere Felder, setzen Sie Node‑Red als lokales Orchestrierungs‑Tool ein und binden Sie optional Prometheus für Metriken ein. So erhalten Sie ein robustes Edge‑IoT‑Ökosystem, das komplett ohne Cloud‑Abhängigkeiten auskommt – und das alles unter Ihrer vollen Datenhoheit.

Viel Spaß beim Basteln, und denken Sie immer daran: Edge bedeutet Kontrolle, nicht Kompromiss.

Firewall-Tuning: Stateful vs. Next-Gen - Die richtige Wahl

Uhltak Therestismysecret — Tue, 16 Jun 2026 06:00:03 +0000

Firewall-Tuning: Stateful vs. Next-Gen Firewall – wann reicht was und wann nicht?

Einleitung

Stellen Sie sich vor, Sie sind der Sicherheitschef einer Firma, und Ihr Unternehmen ist wie ein Haus. Die Firewall ist die Tür, die den Zugang zum Haus kontrolliert. Eine gute Firewall sorgt dafür, dass nur autorisierte Personen eingelassen werden und dass potenzielle Angreifer draußen bleiben. Aber wie wählt man die richtige Firewall aus? Soll man eine Stateful-Firewall oder eine Next-Gen-Firewall verwenden?

Stateful-Firewalls

Eine Stateful-Firewall ist wie ein Türsteher, der jeden, der hereinkommt, kennt. Sie überwacht den Zustand jeder Verbindung und kann somit erkennen, ob eine Verbindung autorisiert ist oder nicht. Ein Beispiel für eine Stateful-Firewall ist die Cisco ASA. Sie kann verwendet werden, um den Zugriff auf bestimmte Ressourcen im Netzwerk zu steuern.
Meine Einschätzung: Stateful-Firewalls sind ausreichend für kleine bis mittelgroße Unternehmen, die keine komplexen Netzwerkumgebungen haben.

Next-Gen-Firewalls

Eine Next-Gen-Firewall ist wie ein High-Tech-Türsteher, der nicht nur jeden kennt, der hereinkommt, sondern auch erkennt, was sie tun. Sie bietet erweiterte Funktionen wie Deep Packet Inspection, Anti-Malware und Sandboxing. Ein Beispiel für eine Next-Gen-Firewall ist die Palo Alto Networks Next-Generation Firewall. Sie kann verwendet werden, um den Zugriff auf bestimmte Ressourcen im Netzwerk zu steuern und um potenzielle Bedrohungen zu erkennen.
Meine Einschätzung: Next-Gen-Firewalls sind geeignet für große Unternehmen oder Organisationen mit komplexen Netzwerkumgebungen, die einen hohen Schutzbedarf haben.

Häufige Fehler / Fallstricke

Ein häufiger Fehler ist die Auswahl einer Firewall, die nicht auf die spezifischen Bedürfnisse des Unternehmens abgestimmt ist. Beispielsweise kann eine Stateful-Firewall für ein großes Unternehmen mit komplexen Netzwerkumgebungen nicht ausreichend sein. Ein weiterer Fallstrick ist die mangelnde Konfiguration und Wartung der Firewall. Wenn die Firewall nicht richtig konfiguriert ist, kann sie nicht effektiv schützen.

Fazit

Dein nächster Schritt sollte sein, Ihre Netzwerkumgebung zu analysieren und Ihre Sicherheitsanforderungen zu definieren. Dann können Sie die richtige Firewall auswählen, ob Stateful oder Next-Gen. Es ist auch wichtig, die Firewall richtig zu konfigurieren und zu warten, um einen effektiven Schutz zu gewährleisten. Mit der richtigen Firewall können Sie Ihr Unternehmen vor potenziellen Bedrohungen schützen und Ihre Daten sicher halten.

DEV Community: Uhltak Therestismysecret

WireGuard Mesh-VPN automatisieren: Schritt‑für‑Schritt mit wg‑meshconf

WireGuard Mesh‑VPN automatisieren – Der komplette Praxis‑Guide

Warum ein Mesh‑VPN?

Grundlagen von wg‑meshconf

Beispiel‑YAML‑Skeleton

Erste Konfiguration: Peer‑zu‑Peer (ohne Mesh)

Automatisierte Topologie mit wg‑meshconf

Beispiel‑Ausgabe (Ausschnitt)

Beispiel 1: 3‑Knoten‑Mesh in einem kleinen Unternehmen

Schritt‑für‑Schritt‑Setup

Ergebnis

Beispiel 2: Dynamisches Hinzufügen neuer Nodes (z. B. neue Edge‑Device)

Vorgehensweise

Beispiel 3: Integration mit Ansible – State‑Driven Deployment

Ansible‑Playbook

Ausführen

Häufige Fehler und wie du sie vermeidest

Fazit & Nächster Schritt

Zero Trust Architektur: Der Paradigmenwechsel in der IT-Sicherheit

Hook-Einleitung

Was ist Zero Trust Architektur?

Vorteile von Zero Trust Architektur

Häufige Fehler / Fallstricke

Fazit

Lokale LLMs mit Ollama: Selbst hosten, API anbinden & Praxisbeispiele

Lokale LLMs mit Ollama: Selbst hosten, API anbinden & Praxisbeispiele

Warum lokale LLMs?

Erklärung

Praxisbeispiel

Einschätzung

Ollama installieren und ein Modell pullen

Erklärung

Konkretes Beispiel 1 – Installation auf Ubuntu 22.04

Konkretes Beispiel 2 – Modell pullen (Mistral‑7B‑Instruct)

Einschätzung

Modell per Ollama API ansprechen

Erklärung

Konkretes Beispiel 3 – curl‑Request

Konkretes Beispiel 4 – Python‑Wrapper

Einschätzung

Integration in eigene Anwendung

Erklärung

Konkretes Beispiel 5 – FastAPI‑Gateway

Konkretes Beispiel 6 – Auditing per PostgreSQL Hook

Einschätzung

Häufige Fehler und wie man sie vermeidet

Fazit und konkreter Next‑Step

Zero Trust Architektur: Der Paradigmenwechsel

Zero Trust Architektur: Warum 'never trust, always verify' kein Buzzword ist, sondern ein Paradigmenwechsel

Was ist Zero Trust Architektur?

Beispiel: Implementierung mit VMware und Google Cloud

Warum ist Zero Trust Architektur ein Paradigmenwechsel?

Beispiel: Kulturwandel mit Cisco und Cyberark

Häufige Fehler / Fallstricke

Fazit

Zero Trust in der Praxis: Warum VPN nicht reicht – Ihr Leitfaden

Warum das alte VPN‑Modell heute ein Sicherheitsrisiko ist

1. Was ist Zero Trust?

Erklärung

Beispiel

Einschätzung

2. Warum VPN allein kein ausreichend sicheres Konzept ist

Erklärung

Beispiel 1 – Split‑Tunneling‑Pitfall

Einschätzung

Beispiel 2 – Credential‑Reuse in VPN‑Umgebungen

Einschätzung

3. Praktische Umsetzung von Zero Trust – Schritt für Schritt

Erklärung

Beispiel 3 – Zero‑Trust‑Aufbau mit HashiCorp Boundary und Vault

Einschätzung

Beispiel 4 – Mikrosegmentierung mit Calico in einem Kubernetes‑Cluster

Einschätzung

Häufige Fehler bei der Einführung von Zero Trust

Fazit und konkreter nächster Schritt

KI-Entscheidungen: Wann Maschinen besser sind als Menschen

KI-Entscheidungen: Wann Maschinen besser sind als Menschen

Wie KI-Entscheidungen getroffen werden

Erfolgreiche KI-Anwendungen

Beispiel 1: 3‑Knoten‑Mesh in einem kleinen Unternehmen

Beispiel 2: Dynamisches Hinzufügen neuer Nodes (z. B. neue Edge‑Device)

Beispiel 3: Integration mit Ansible – State‑Driven Deployment

Konkretes Beispiel 1 – Installation auf Ubuntu 22.04

Konkretes Beispiel 3 – `curl`‑Request

Schritt 1: STONITH‑Device anlegen

Schritt 2: Votes anpassen (optional)

Schritt 3: Testen Sie das Fencing

3. Praktisches Beispiel 1 – Sandbox für einen Dateibrowser

4. Praktisches Beispiel 2 – Netzwerk‑isoliertes Build‑Tool

5. Praktisches Beispiel 3 – Beschränkung von `gcc`‑Compiler‑Aufrufen