DEV Community: Uhltak Therestismysecret

Monitoring & Observability: Warum Logs nicht reichen – Tracing im Fokus

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

Monitoring & Observability – Warum Logs allein nicht reichen und wie Tracing Ihr System rettet

Hook: Sie sitzen nachts im Rechenzentrum, das Dashboard blinkt rot und Sie fragen sich, ob das Problem ein einfacher "logrotate"-Fehler ist oder doch ein tieferliegendes Architektur‑Problem. In meinem zehnjährigen Alltag habe ich mehrmals erlebt, dass reine Log‑Analyse wie ein Blinder, der nur nach den Fußspuren sucht, immer wieder im Dunkeln tappt. Heute zeige ich Ihnen, warum Sie Logs, Metrics und Tracing gemeinsam brauchen und wie Sie das mit realen Tools sofort umsetzen.

Warum reine Log‑Analyse nicht ausreicht

Logs sind das traditionelle Gold der Fehlersuche: Textzeilen, die alles erzählen – oder zumindest das, was das System entschieden hat, zu protokollieren. Das Problem: Logs sind retrospektiv, sie geben Ihnen einen Schnappschuss, aber keinen Kontext über wie ein Request durch das System wanderte.

Beispiel 1: Der klassische `grep`‑Befehl

# Suchen Sie nach einem Fehler im Syslog
sudo grep -i "error" /var/log/syslog | tail -n 20

Das Ergebnis liefert Ihnen Zeilen, die das Wort error enthalten. Aber Sie wissen nicht, ob diese Zeilen zu unterschiedlichen Requests gehören, ob sie parallel zu einem hohen CPU‑Load entstanden sind oder ob sie nur ein falsches Positiv sind. Die Log‑Zeile allein sagt nichts über die Kausalität.

Persönliche Einschätzung

In meiner ersten Position als Systemadministrator dachte ich, ich hätte jedes Problem gelöst, sobald ich die Fehlermeldung gefunden hatte. Das war ein Illusion of control – ich sah nur das Symptom, nicht die Ursache. Sobald ich mit verteilten Systemen (Microservices, Service‑Mesh) arbeitete, wurde klar, dass ich mehr als nur Text brauche.

Tracing verstehen und einsetzen

Tracing ist das Gegenstück zu Logs, aber proaktiv und kontextuell: Jeder Request erhält eine eindeutige Trace‑ID, die über alle beteiligten Komponenten hinweg propagiert wird. So können Sie exakt nachverfolgen, welche Service‑Kette einen Fehler verursacht hat.

Beispiel 2: OpenTelemetry + Jaeger in einem Go‑Microservice

Bibliothek einbinden (go.mod):

require (
    go.opentelemetry.io/otel v1.9.0
    go.opentelemetry.io/otel/exporters/trace/jaeger v1.9.0
)

Tracer initialisieren:

import (
    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/exporters/trace/jaeger"
    "go.opentelemetry.io/otel/sdk/trace"
)

func initTracer() {
    exporter, _ := jaeger.New(jaeger.WithCollectorEndpoint("http://jaeger-collector:14268/api/traces"))
    tp := trace.NewTracerProvider(trace.WithSyncer(exporter))
    otel.SetTracerProvider(tp)
}

Instrumentierung im Handler:

func handler(w http.ResponseWriter, r *http.Request) {
    ctx, span := otel.Tracer("my-service").Start(r.Context(), "handler")
    defer span.End()
    // ... Geschäftlogik ...
    w.Write([]byte("OK"))
    // Span-Attribute setzen
    span.SetAttributes(attribute.String("http.method", r.Method))
    // Fehler aufnehmen
    if err != nil {
        span.RecordError(err)
    }
    _ = ctx // weiterreichen
}

Collector‑Konfiguration (otel‑collector.yaml):

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"
exporters:
  jaeger:
    endpoint: "jaeger-collector:14250"
    insecure: true
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [jaeger]

Jaeger UI öffnen: http://jaeger-ui:16686/search – dort sehen Sie die komplette Request‑Route, Latenz pro Hop und eventuelle Fehler.

Persönliche Einschätzung

Der erste Deploy von Tracing in meinem Unternehmen war ein Game‑Changer. Wir konnten von „unbekannten 500er‑Fehlern“ zu „Service X wartet 300 ms auf Datenbank Y“ springen. Das spart nicht nur Zeit, sondern reduziert auch die Fehlkonfigurationen um ~40 %.

Kombinieren von Metrics, Logs und Traces – das Observability‑Triad

Nur wenn Sie alle drei Datenformen zusammenführen, erhalten Sie ein vollständiges Bild. Metrics geben Ihnen quantitative Werte (CPU‑Auslastung, Request‑Rate), Logs liefern Detailinformationen, und Traces schließen die Lücken zwischen den beiden.

Beispiel 3: Prometheus + Loki + Grafana‑Dashboard

Prometheus Scrape‑Config (prometheus.yml):

scrape_configs:
  - job_name: 'my-service'
    static_configs:
      - targets: ['my-service:9100']

Loki‑Input für Logs (loki.yaml):

server:
  http_listen_port: 3100
positions:
  filename: /tmp/positions.yaml
scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
    pipeline_stages:
      - docker: {}
    relabel_configs:
      - source_labels: [__path__]
        regex: /(var/log/.*\.log)
        target_label: __path__

Grafana Dashboard – Ein Panel, das Prometheus‑Metric http_request_duration_seconds_bucket mit Loki‑Log‑Query kombiniert:

{job="my-service"}
|~ "ERROR"

Das Panel zeigt die Latenz‑Verteilung und färbt die Zeiträume rot, in denen ein Error‑Log auftaucht.

Persönliche Einschätzung

Ein einziger Satz: Ohne ein zentrales Observability‑Backend haben Sie 3 × die Arbeit. Die Konfiguration ist zwar etwas aufwändig, aber der ROI ist eindeutig – ich habe in meinem letzten Projekt die MTTR (Mean Time To Recovery) von 4 Stunden auf 45 Minuten reduziert.

Häufige Fehler bei Monitoring & Observability

Fehler	Warum problematisch	Wie man ihn vermeidet
Logs ohne Struktur	Textbasierte Suche ist langsam und fehleranfällig.	JSON‑Logs (`logrus` + `json`‑Formatter) einsetzen.
Zu viele Metriken	Overhead, unübersichtliche Dashboards.	„Goldilocks‑Prinzip“ – nur geschäftskritische Metriken sammeln.
Tracing nur in Produktion	Fehlende Basis in Staging → kein Vergleich.	Tracing in allen Umgebungen aktivieren, aber Sample‑Rate anpassen.
Kein Correlation‑Key	Logs und Traces lassen sich nicht verbinden.	Trace‑ID in Log‑Einträgen einbetten (`logrus.WithField("trace_id", traceID)`).
Ignorieren von Alert‑Fatigue	Zu viele Alerts führen zu Blindheit.	Alert‑Richtlinien definieren, nur kritische Zustände alarmieren.

Fazit & konkreter nächster Schritt

Logs sind unverzichtbar, aber sie zeigen nur das Was.
Metrics geben das Wie viel, aber nicht das Warum.
Tracing liefert das Warum – es verbindet die Punkte.

Ihr Handlungsplan für die nächsten 30 Tage:

Installieren Sie einen OpenTelemetry‑Collector in Ihrem Kubernetes‑Cluster (Helm‑Chart opentelemetry-collector).
Instrumentieren Sie mindestens einen kritischen Service (z. B. Ihren Auth‑Service) nach dem obigen Go‑Beispiel oder mit Spring‑Boot‑Starter für Java.
Deployen Sie Jaeger, Prometheus und Loki via docker‑compose oder Helm und verbinden Sie sie mit Grafana.
Erstellen Sie ein Dashboard, das Request‑Latenz (Prometheus) und Error‑Logs (Loki) kombiniert und setzen Sie eine Alert‑Rule, wenn die durchschnittliche Latenz > 500 ms und ein Error‑Log innerhalb von 2 Minuten erscheint.
Überprüfen Sie wöchentlich die Alert‑Menge und passen Sie die Schwellenwerte an – das ist die eigentliche Observability‑Schleife.

Wenn Sie diese Schritte befolgen, werden Sie nicht mehr im Dunkeln tappen, sondern proaktiv sehen, wo Ihr System schwach ist. Und das ist das Herzstück moderner Observability: Frühzeitiges Erkennen, gezielte Behebung und kontinuierliche Optimierung.

Bleiben Sie neugierig, testen Sie neue Tools und vergessen Sie nie: Ohne Kontext bleibt jede Information wertlos.

Zero Trust Architektur: Der neue Standard für die IT-Sicherheit

Uhltak Therestismysecret — Mon, 01 Jun 2026 06:00:04 +0000

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

Einführung in die Zero Trust Architektur

Die Zero Trust Architektur ist ein Sicherheitskonzept, das auf dem Prinzip 'never trust, always verify' basiert. Dies bedeutet, dass keine Komponente innerhalb eines Netzwerks automatisch vertrauenswürdig ist, sondern vielmehr kontinuierlich authentifiziert und autorisiert werden muss. Dieser Ansatz ist besonders wichtig in einer Welt, in der Bedrohungen immer komplexer und schwerer zu erkennen sind.

Beispiel: Ein Unternehmen wie Google hat bereits vor Jahren begonnen, Zero Trust in seiner Infrastruktur umzusetzen. Durch die Implementierung von Lösungen wie BeyondCorp hat Google seine Mitarbeiter in die Lage versetzt, sicher von überall auf die Unternehmensressourcen zuzugreifen, ohne dass ein VPN erforderlich ist.

Meine Einschätzung: Die Zero Trust Architektur ist ein notwendiger Schritt in die Richtung einer verbesserten IT-Sicherheit. Durch die kontinuierliche Überprüfung und Authentifizierung aller Komponenten kann das Risiko von Angriffen und Datenlecks erheblich reduziert werden.

Implementierung der Zero Trust Architektur

Die Implementierung einer Zero Trust Architektur erfordert eine umfassende Überprüfung der bestehenden IT-Infrastruktur. Dazu gehören die Identifizierung der zu schützenden Ressourcen, die Ermittlung der Zugriffsanforderungen und die Auswahl geeigneter Sicherheitslösungen.

Beispiel: Die Firma Cisco bietet Lösungen wie Cisco ISE (Identity Services Engine) an, die die Implementierung von Zero Trust in Netzwerken erleichtern. Cisco ISE ermöglicht die zentrale Verwaltung von Identitäten und Zugriffsrechten sowie die Anwendung von Richtlinien basierend auf Benutzer- und Geräteattributen.

Meine Einschätzung: Die Auswahl der richtigen Sicherheitslösungen ist entscheidend für den Erfolg einer Zero Trust Implementierung. Es ist wichtig, Lösungen zu wählen, die flexibel sind und sich an die spezifischen Bedürfnisse des Unternehmens anpassen lassen.

Vorteile der Zero Trust Architektur

Die Zero Trust Architektur bietet eine Vielzahl von Vorteilen, darunter eine verbesserte Sicherheit, eine reduzierte Angriffsfläche und eine erhöhte Transparenz. Durch die kontinuierliche Überwachung und Authentifizierung aller Komponenten kann das Risiko von Angriffen und Datenlecks erheblich reduziert werden.

Beispiel: Die Firma Microsoft hat mit Azure Active Directory (Azure AD) und Microsoft Intune Lösungen entwickelt, die Unternehmen bei der Implementierung von Zero Trust unterstützen. Durch die Kombination von Identitäts- und Zugriffsverwaltung mit Bedrohungsschutz und Endgerätemanagement können Unternehmen ihre Sicherheitslage erheblich verbessern.

Meine Einschätzung: Die Zero Trust Architektur ist nicht nur ein Sicherheitskonzept, sondern auch ein wichtiger Schritt in Richtung einer modernen und agilen IT-Infrastruktur. Durch die Implementierung von Zero Trust können Unternehmen ihre Sicherheit erhöhen, ihre Effizienz steigern und ihre Mitarbeiter in die Lage versetzen, sicher und produktiv zu arbeiten.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Implementierung von Zero Trust ist die Annahme, dass es sich um ein einfaches Sicherheitsprodukt handelt, das einfach installiert und konfiguriert werden kann. Tatsächlich erfordert Zero Trust eine umfassende Überprüfung der bestehenden IT-Infrastruktur und eine sorgfältige Planung.

Ein weiterer Fallstrick ist die mangelnde Berücksichtigung der Benutzererfahrung. Zero Trust sollte nicht dazu führen, dass Benutzer unnötig eingeschränkt oder behindert werden. Stattdessen sollte es darauf abzielen, eine sichere und benutzerfreundliche Umgebung zu schaffen.

Fazit

Die Zero Trust Architektur ist ein wichtiger Schritt in Richtung einer verbesserten IT-Sicherheit. Durch die kontinuierliche Überprüfung und Authentifizierung aller Komponenten kann das Risiko von Angriffen und Datenlecks erheblich reduziert werden. Es ist wichtig, dass Unternehmen die richtigen Sicherheitslösungen wählen und eine sorgfältige Planung und Implementierung durchführen.

Dein nächster Schritt sollte sein, Ihre bestehende IT-Infrastruktur zu überprüfen und die ersten Schritte in Richtung Zero Trust zu unternehmen. Dazu gehört die Identifizierung der zu schützenden Ressourcen, die Ermittlung der Zugriffsanforderungen und die Auswahl geeigneter Sicherheitslösungen. Durch die Implementierung von Zero Trust können Sie Ihre Sicherheit erhöhen, Ihre Effizienz steigern und Ihre Mitarbeiter in die Lage versetzen, sicher und produktiv zu arbeiten.

DNS-Sicherheit: DoT, DoH & DNSSEC im Vergleich – Was schützt wirklich?

Uhltak Therestismysecret — Sun, 31 May 2026 18:00:03 +0000

Hook – Warum wir alle schon blind unserem DNS vertrauen (oder nicht)

Stellen Sie sich vor, Sie bestellen ein Pizzaservice, geben Ihre Adresse per Telefon durch und jeder Anruf wird abgehört. Genau das passiert jeden Tag mit Ihrem DNS: Ohne Verschlüsselung kann ein Angreifer sehen, welche Webseiten Sie ansteuern, Antworten manipulieren und Sie zu Phishing‑Seiten umleiten. Die meisten Nutzer glauben, ihr ISP sei neutral, doch das ist ein Trugschluss – der DNS-Resolver kann jederzeit Antworten fälschen. Deshalb ist DNS‑Sicherheit kein Nice‑to‑have, sondern ein Muss. In diesem Artikel zerlegen wir die drei zentralen Bausteine der modernen DNS‑Abwehr – DoT, DoH und DNSSEC – und prüfen, welche Schutzmechanismen sie tatsächlich bieten.

DNS over TLS (DoT) – Der alte Klassiker im neuen Gewand

Was ist DoT?

DNS over TLS (DoT) encapsuliert die klassische DNS‑Abfrage (Port 53/UDP) in einen TLS‑Tunnel (Port 853/TCP). Der Client baut eine TLS‑Verbindung zu einem Resolver auf, verifiziert das Server‑Zertifikat und sendet danach DNS‑Pakete verschlüsselt. Der Vorteil: Der gesamte DNS‑Verkehr ist vor Schnüffel- und Manipulationsversuchen geschützt – solange das Zertifikat vertrauenswürdig ist.

Praktisches Beispiel: DoT mit systemd‑resolved auf Ubuntu 22.04

# 1. TLS‑Resolver hinzufügen (Cloudflare)
sudo bash -c 'cat > /etc/systemd/resolved.conf.d/99-cloudflare-dns.conf <<EOF
[Resolve]
DNS=1.1.1.1#853
DNS=1.0.0.1#853
DNSOverTLS=yes
EOF'

# 2. systemd‑resolved neu starten
sudo systemctl restart systemd-resolved

# 3. Prüfen, ob DoT aktiv ist
resolvectl status | grep "DNSOverTLS"

Der Befehl resolvectl status zeigt DNSOverTLS=yes – das bedeutet, sämtliche DNS‑Abfragen des Systems laufen jetzt über den verschlüsselten Port 853.

Persönliche Einschätzung

DoT ist ein solides Fundament, weil es das bestehende Resolver‑Modell unverändert lässt. Es lässt sich in praktisch jedem Linux‑Stack aktivieren, benötigt keine extra Software und funktioniert mit bekannten Resolvern wie Cloudflare, Quad9 oder den eigenen ISP‑Servern. Der Haken: DoT nutzt ausschließlich TCP, weshalb in restriktiven Firewalls (z. B. Legacy‑Proxy‑Umgebungen) der Port 853 oft blockiert wird. Außerdem bleibt das eigentliche DNS‑Antworten‑Authentizitätsproblem ungelöst – das ist DNSSEC’s Spielplatz.

DNS over HTTPS (DoH) – Der hippe Cousin aus der Browserwelt

Was ist DoH?

DoH verlagert DNS‑Abfragen in das HTTP/2‑ oder HTTP/3‑Protokoll und kapselt sie in HTTPS (Port 443/TCP). Das Ergebnis: DNS‑Traffic sieht aus wie normaler Web‑Traffic und kann daher von Netzwerk‑Middleboxes kaum mehr unterschieden werden. DoH ist besonders populär bei Browsern (Firefox, Chrome) und mobilen Apps, die bereits HTTPS‑Verbindungen aufbauen.

Praktisches Beispiel: DoH mit cloudflared als lokaler Resolver

# 1. cloudflared (DoH‑Client) herunterladen
device=$(uname -m); curl -L -o cloudflared https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-${device}
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/

# 2. System‑d Service für cloudflared erstellen
sudo bash -c 'cat > /etc/systemd/system/cloudflared.service <<EOF
[Unit]
Description=Cloudflare DNS over HTTPS proxy
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/cloudflared proxy-dns --port 5053 --address 127.0.0.1
Restart=on-failure
User=nobody
Group=nogroup

[Install]
WantedBy=multi-user.target
EOF'

# 3. Service starten und aktivieren
sudo systemctl daemon-reload
sudo systemctl enable --now cloudflared

# 4. Localhost‑Resolver in /etc/resolv.conf eintragen
sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolv.conf'

# 5. Testen
dig @127.0.0.1 example.com +short

Die Ausgabe bestätigt, dass Anfragen über den lokalen DoH‑Proxy laufen. Der eigentliche DNS‑Verkehr wird via HTTPS zu https://dns.cloudflare.com/dns-query geschickt.

Persönliche Einschätzung

DoH ist der Chamäleon‑Modus des DNS: Er tarnt DNS‑Traffic als normaler HTTPS‑Datenstrom und umgeht Deep‑Packet‑Inspection leicht. Das ist ein starkes Argument in Unternehmensnetzen, wo man sonst nur über dedizierte TLS‑Ports gehen kann. Der Preis: Komplexität. Man muss einen zusätzlichen Proxy‑Dienst betreiben, und die Integration in das bestehende Resolver‑Framework (systemd‑resolved, NetworkManager) ist nicht immer nahtlos. Außerdem kann DoH das klassische DNS‑Caching im System unterlaufen, weil das lokale Proxy‑Programm eigene Caches verwaltet – das kann zu Inkonsistenzen führen.

DNSSEC – Der digitale Fingerabdruck für DNS‑Antworten

Was ist DNSSEC?

DNSSEC (Domain Name System Security Extensions) fügt kryptografische Signaturen zu DNS‑Einträgen hinzu. Jeder Zone‑Owner signiert seine Records mit einem privaten Schlüssel; Resolver prüfen die Signatur mit dem zugehörigen öffentlichen Schlüssel, der in einer übergeordneten Zone (meist die Root‑Zone) verankert ist. Das Prinzip heißt: Authentizität, nicht Vertraulichkeit. DNSSEC verhindert, dass ein Angreifer gefälschte Antworten (Cache‑Poisoning) einschleusen kann – die Signatur würde nicht passen.

Praktisches Beispiel: DNSSEC‑Validierung mit unbound

# 1. Unbound installieren (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y unbound

# 2. Grundkonfiguration aktivieren
sudo bash -c 'cat > /etc/unbound/unbound.conf.d/dnssec.conf <<EOF
server:
  root-hints: "/var/lib/unbound/root.hints"
  auto-trust-anchor-file: "/var/lib/unbound/root.key"
  do-ip4: yes
  do-udp: yes
  do-tcp: yes
  hide-identity: yes
  hide-version: yes
  prefetch: yes
  prefetch-key: yes
  qname-minimisation: yes
  validator:
    trust-anchor-file: "/var/lib/unbound/root.key"
EOF'

# 3. Root‑Hints herunterladen (falls noch nicht vorhanden)
sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache

# 4. Unbound starten
sudo systemctl restart unbound

# 5. DNSSEC‑Abfrage testen (dig +dnssec)
 dig @127.0.0.1 dnssec-failed.org +dnssec +short

dnssec-failed.org liefert ein SERVFAIL, weil die Zone bewusst falsche Signaturen hat – das beweist, dass unser Resolver DNSSEC korrekt prüft.

Persönliche Einschätzung

DNSSEC ist der einzige echte Schutz gegen gefälschte DNS‑Antworten. Es garantiert, dass die erhaltene IP‑Adresse wirklich vom autorisierten Inhaber stammt. Der Nachteil ist, dass DNSSEC allein die Vertraulichkeit nicht schützt – das macht DoT/DoH nötig. Außerdem erfordert DNSSEC, dass alle Zonen korrekt signiert sind; das ist in der Praxis noch nicht überall der Fall. Auch das Management von Schlüssel‑Rollovern (KSK/ZSK) kann für kleine Betreiber aufwändig sein.

Gemeinsamer Vergleich – Was schützt wirklich?

Merkmal	DoT	DoH	DNSSEC
Ziel	Vertraulichkeit (Verschlüsselung)	Vertraulichkeit + Tarnung	Authentizität (Signatur)
Transportlayer	TLS über TCP (Port 853)	HTTPS über TCP (Port 443)	Kein zusätzlicher Transportlayer
Kompatibilität	Breite Unterstützung in System‑Daemons	Browser‑first, aber Proxy‑Lösungen nötig	Nur von Resolvern geprüft, nicht von Clients
Performance‑Impact	gering (ein TLS‑Handshake pro Session)	leicht höher (HTTPS‑Header)	minimal (Zusatz‑Verifizierung)
Deploy‑Komplexität	niedrig (config Datei)	mittel (extra Service/Proxy)	mittel‑bis‑hoch (Schlüsselmanagement)

Takeaway: Für reine Vertraulichkeit reicht DoT aus, wenn Ihr Netzwerk den Port 853 offen lässt. Wenn Sie Netzwerk‑Inspektoren austricksen wollen, ist DoH das elegante Mittel. Wenn Sie jedoch sicherstellen wollen, dass die erhaltene Antwort wirklich von der legitimen Zone stammt, benötigen Sie DNSSEC – idealerweise kombiniert mit DoT oder DoH, damit Sie sowohl Vertraulichkeit als auch Authentizität erhalten.

Häufige Fehler – Warum die meisten Implementierungen trotzdem unsicher bleiben

Nur DoT/DoH einsetzen, DNSSEC ignorieren – Der Traffic ist verschlüsselt, aber ein Angreifer kann immer noch gefälschte Antworten einspielen, wenn der Resolver DNSSEC‑validiert. Ohne DNSSEC kann ein Man‑in‑The‑Middle die verschlüsselte Verbindung aufbauen und legitime Antworten mit eigenen IPs zurückschicken.
Unterschätzte Firewall‑Restriktionen – Viele Unternehmensfirewalls blockieren Port 853, weil er als „nicht‑standard“ gilt. Das führt dazu, dass DoT‑Clients auf das unverschlüsselte System‑Resolver‑Fallback zurückfallen – ein klassischer fallback‑to‑insecure.
Fehlende Schlüssel‑Rollover‑Strategie bei DNSSEC – Ignoriert man das regelmäßige Erneuern von KSK/ZSK, läuft man Gefahr, dass veraltete Schlüssel nicht mehr vertrauenswürdig sind und legitime Anfragen fehlschlagen.
Duplizierte Caches – DoH‑Proxies (z. B. cloudflared) besitzen eigene Caches, die nicht mit dem System‑Cache synchronisiert werden. Das kann zu verwirrenden Ergebnissen führen, besonders bei TTL‑Änderungen.
Keine Integritätsprüfung des TLS‑Zertifikats – Wenn Sie DoT zu einem privaten Resolver mit selbst‑signiertem Zertifikat verbinden, sollten Sie das Zertifikat in trusted-ca importieren; sonst akzeptiert der Client potenziell kompromittierte Zertifikate.

Fazit & nächster Schritt – So sichern Sie Ihr DNS jetzt sofort

Implementieren Sie DoT auf allen Servern: Ändern Sie /etc/systemd/resolved.conf.d/99-dns.conf und aktivieren Sie DNSOverTLS=yes. Testen Sie mit resolvectl query example.com und prüfen Sie, dass DNSOverTLS aktiv ist.
Setzen Sie einen lokalen DoH‑Proxy (cloudflared) ein, wenn Ihr Netzwerk keine TLS‑Ports zulässt. Das ist ein schneller Win‑Win für Home‑Lab‑ und Small‑Biz‑Umgebungen.
Aktivieren Sie DNSSEC‑Validierung in Ihrem bevorzugten Resolver (unbound, bind9, systemd‑resolved). Der Aufwand ist minimal – ein kurzer Eintrag in der Konfiguration reicht.
Überwachen Sie die DNS‑Logs: Nutzen Sie journalctl -u systemd-resolved bzw. unbound -vv für detaillierte Fehlermeldungen, um Fehlkonfigurationen sofort zu entdecken.
Dokumentieren Sie den Schlüssel‑Rollover‑Plan – Erstellen Sie ein kleines Playbook (z. B. mit Ansible), das das Ersetzen von KSK/ZSK automatisiert und dabei das dnssec-keymgr‑Tool nutzt.

Kurzfassung: Die Kombination aus DoT + DoH (Vertraulichkeit) und DNSSEC (Authentizität) liefert den umfassendsten Schutz für Ihren DNS‑Traffic. Entscheiden Sie je nach Netzwerk‑Policy, welchen Teil Sie zuerst aktivieren – das Ergebnis ist stets besser als das ungesicherte Standard‑DNS.

Nächster Praxis‑Schritt: Öffnen Sie Ihre Server‑Shell, führen Sie das DoT‑Beispiel aus und prüfen Sie mit resolvectl status. Anschließend installieren Sie cloudflared für DoH und testen Sie die lokale Auflösung. Abschließend aktivieren Sie DNSSEC in Unbound, verifizieren Sie mit dig +dnssec. In weniger als einer Stunde haben Sie Ihren DNS‑Stack massiv gehärtet – denn das ist das wahre „What‑really‑protects‑you“-Gefühl.

Firewall-Tuning: Stateful vs. Next-Gen - Die ultimative Entscheidung

Uhltak Therestismysecret — Sun, 31 May 2026 06:00:03 +0000

Firewall-Tuning: Die ultimative Entscheidung

Firewalls sind die erste Verteidigungslinie gegen Angriffe auf Ihr Netzwerk. Aber welche Art von Firewall ist die richtige für Ihr Unternehmen? Stateful Firewalls oder Next-Gen Firewalls? Meine Einschätzung: Beide haben ihre Vor- und Nachteile.

Was sind Stateful Firewalls?

Stateful Firewalls sind die traditionelle Art von Firewalls. Sie überwachen den Zustand von Verbindungen und entscheiden, ob ein Datenpaket durchgelassen wird oder nicht. Sie sind wie ein Wächter, der den Ein- und Ausgang zu Ihrem Haus überwacht.

Beispiel: Cisco ASA

Ein Beispiel für eine Stateful Firewall ist die Cisco ASA. Sie bietet eine grundlegende Sicherheit für Ihr Netzwerk und ist relativ einfach zu konfigurieren. Mit der Cisco ASA können Sie Regeln erstellen, um den Datenverkehr zu steuern und sicherzustellen, dass only autorisierte Verbindungen zulässig sind.

Meine Einschätzung: Stateful Firewalls wie die Cisco ASA sind eine gute Wahl, wenn Sie ein kleines bis mittleres Unternehmen haben und Ihre Netzwerksicherheit auf einfache Weise überwachen möchten.

Was sind Next-Gen Firewalls?

Next-Gen Firewalls sind eine neue Generation von Firewalls, die nicht nur den Zustand von Verbindungen überwacht, sondern auch den Inhalt von Datenpaketen analysiert. Sie sind wie ein intelligenter Wächter, der nicht nur den Ein- und Ausgang zu Ihrem Haus überwacht, sondern auch den Inhalt von Taschen und Koffern überprüft.

Beispiel: Palo Alto Networks

Ein Beispiel für eine Next-Gen Firewall ist die Palo Alto Networks. Sie bietet eine umfassende Sicherheit für Ihr Netzwerk und kann sogar Bedrohungen wie Malware und Phishing-Angriffe erkennen und blockieren. Mit der Palo Alto Networks können Sie auch Ihre Netzwerksicherheit aufGranularitätsebene überwachen und steuern.

Meine Einschätzung: Next-Gen Firewalls wie die Palo Alto Networks sind eine gute Wahl, wenn Sie ein großes Unternehmen haben oder Ihre Netzwerksicherheit auf sehr hohem Niveau überwachen möchten.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Konfiguration von Firewalls ist, dass sie nicht richtig konfiguriert werden. Dies kann dazu führen, dass Ihre Netzwerksicherheit gefährdet wird. Ein weiterer Fehler ist, dass Sie nicht regelmäßig Ihre Firewalls aktualisieren und patchen.

Fazit

Dein nächster Schritt sollte sein, Ihre Netzwerksicherheit zu überprüfen und zu entscheiden, ob Stateful Firewalls oder Next-Gen Firewalls die richtige Wahl für Ihr Unternehmen sind. Meine Empfehlung ist, dass Sie sich für eine Next-Gen Firewall entscheiden, wenn Sie ein großes Unternehmen haben oder Ihre Netzwerksicherheit auf sehr hohem Niveau überwachen möchten. Wenn Sie jedoch ein kleines bis mittleres Unternehmen haben, können Stateful Firewalls eine gute Wahl sein.

Self‑Hosting vs. Cloud: Kostentransparenz, Praxisbeispiele und worauf Sie wirklich achten sollten

Uhltak Therestismysecret — Sat, 30 May 2026 18:00:03 +0000

Self‑Hosting vs. Cloud – Warum das alte Modell plötzlich günstiger wirft

Hook: Wer kennt das nicht – das monatliche Cloud‑Rechnungspapier liegt wieder im Briefkasten, das Geld für Compute, Storage und Datenverkehr schleicht sich leise zusammen und das ganze „Flexibel. Skalierbar. Wartung inklusive.“ klingt plötzlich nach einem teuren All‑You‑Can‑Eat‑Buffet. Ich habe das Jahr 2024 mit drei eigenen Self‑Hosting‑Projekten abgeschlossen und will Ihnen jetzt zeigen, warum das alte Modell nicht nur ein Hobby mehr ist, sondern unter den richtigen Bedingungen echte Kostenvorteile bringt – und wo die Schattenseiten lauern.

Was ist Self‑Hosting?

Self‑Hosting bedeutet, dass Sie Infrastruktur, Betriebssystem und Anwendungen selbst betreiben – sei es im Keller, im eigenen Büro‑Rechenraum oder auf gemieteten Bare‑Metal‑Servern. Im Kern geht es um die Kontrolle über Hardware, Netzwerk und Daten. Statt Ressourcen von AWS, GCP oder Azure zu leasen, kaufen Sie physische Geräte oder mieten dedizierte Server und verwalten alles selbst.

Beispiel 1 – Raspberry Pi 4 als Mini‑Server

# Raspberry Pi OS installieren und Docker setzen
echo "deb [arch=arm64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" \
    | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt-get update && sudo apt-get install -y docker-ce docker-ce-cli containerd.io

# Nextcloud‑Container starten
sudo docker run -d \
  -e MYSQL_PASSWORD=secret \
  -e MYSQL_DATABASE=nextcloud \
  -e MYSQL_USER=nextcloud \
  -e MYSQL_HOST=db \
  -p 8080:80 \
  --name nextcloud \
  nextcloud:latest

Einschätzung: Auf einem Pi‑Board liegen die Anfangsinvestitionen bei ~80 €, die Betriebskosten (Strom, 5 V·A) sind vernachlässigbar. Für private Nutzung (bis 5 TB Daten) ist das ein echter Geldsparer gegenüber einem vergleichbaren S3‑Bucket (ca. 30 €/Monat).

Kostenvergleich – Self‑Hosting vs. Public Cloud

1. Hardware‑Investition vs. Pay‑As‑You‑Go

Szenario	Anschaffungskosten (einmalig)	Monatliche Betriebs‑ & Stromkosten	Gesamtkosten 24 Monate
Raspberry Pi 4 + 2 TB SSD	120 € (Pi + Gehäuse + SSD)	5 € (Strom ≈ 12 W)	150 €
Hetzner Dedicated (CX31)	0 € (Miete)	39 € (CPU, RAM, Storage)	936 €
AWS EC2 t3.medium + 2 TB EBS	0 € (Miete)	73 € (Compute) + 25 € (EBS)	2.352 €

Einschätzung: Selbst‑gehostete Bare‑Metal‑Server (z. B. Hetzner) brechen bereits nach 12‑18 Monaten mit den Cloud‑Kosten ein. Der Hauptfaktor: Daten‑Transfer‑Kosten – Public Cloud verlangt Geld für jeden ausgehenden Gigabyte.

2. Personal‑ und Sicherheitsaufwand

Kostenfaktor	Self‑Hosting	Public Cloud
Monitoring	Open‑Source‑Tools (Prometheus, Grafana) – Zeitaufwand ≈ 4 h/Monat	Managed‑Services (CloudWatch) – Kosten inkl. Service‑Gebühr
Backup	Deduplizierung mittels Proxmox Backup Server – 0 € (Software)	S3‑Versionierung – 0,023 €/GB/Monat
Security Patches	Manuell/automatisiert (apt‑cron) – 1 h/Monat	In‑place vom Anbieter (keine direkte Arbeit)

Einschätzung: Der Aufwand ist messbar, aber planbar. Während Cloud‑Anbieter das Patch‑Management übernehmen, erhalten Sie volle Transparenz und können kritische Updates zeitnah ausrollen – ein klarer Vorteil für Datenschutz‑bewusste Unternehmen.

Praktische Umsetzung – Drei reale Self‑Hosting‑Projekte

2.1 Nextcloud auf einem Home‑Server (Docker‑Compose)

# docker-compose.yml
version: "3.8"
services:
  db:
    image: mariadb:10.11
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: supersecret
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: nextcloud
    volumes:
      - db-data:/var/lib/mysql

  app:
    image: nextcloud:28-fpm
    restart: unless-stopped
    depends_on:
      - db
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: nextcloud
    ports:
      - "8080:80"
    volumes:
      - nextcloud-data:/var/www/html

volumes:
  db-data:
  nextcloud-data:

Einschätzung: Mit einer einzigen docker‑compose up -d erhalten Sie ein vollständig funktionierendes Filesharing‑Portal. Der monatliche Preis für das Gerät (inkl. SSD, 2 TB) liegt bei ~5 €, was im Vergleich zu einem vergleichbaren OneDrive‑Business‑Plan (≈ 10 €/Monat) ein deutlicher Vorteil ist.

2.2 GitLab CE auf Hetzner (Bare‑Metal, Ansible)

# ansible/playbook.yml
- hosts: gitlab
  become: true
  tasks:
    - name: Install Docker
      apt:
        name: docker.io
        state: present
    - name: Pull GitLab image
      docker_image:
        name: gitlab/gitlab-ce
        tag: latest
    - name: Start GitLab container
      docker_container:
        name: gitlab
        image: gitlab/gitlab-ce:latest
        env:
          GITLAB_OMNIBUS_CONFIG: |
            external_url 'http://gitlab.example.com'
        ports:
          - "80:80"
          - "22:22"
        volumes:
          - /srv/gitlab/config:/etc/gitlab
          - /srv/gitlab/logs:/var/log/gitlab
          - /srv/gitlab/data:/var/opt/gitlab
        restart_policy: always

Einschätzung: Der ganze Stack lässt sich mit einem einzigen Ansible‑Durchlauf automatisieren. Die monatlichen Kosten für den Hetzner‑Server (CX31) betragen 39 €, während ein vergleichbarer GitLab‑Premium‑Plan in AWS leicht über 100 € kostet.

2.3 Kubernetes‑Cluster auf günstigen VPS (k3s + Helm)

# 3‑Node k3s mit Rancher
for i in 1 2 3; do
  ssh root@node${i} "curl -sfL https://get.k3s.io | sh -"
done
# Install Helm
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
# Deploy Prometheus
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prom prometheus-community/kube-prometheus-stack

Einschätzung: Drei günstige VPS (je 5 €/Monat) ergeben ein produktives K8s‑Cluster für 15 €/Monat – inkl. Monitoring. Im Vergleich zu einem verwalteten GKE‑Cluster (ab 70 €/Monat) spart man mehr als 50 % bei vergleichbarer Skalierbarkeit.

Häufige Fehler beim Self‑Hosting

Unterschätzung der Netzwerk‑Bandbreite – Externe Zugriffe über DSL können bei 100 Mbps schnell zur Flaschenhals werden. Lösung: QoS‑Regeln und ggf. ein dedizierter Business‑Internet‑Anschluss.
Kein Backup‑Plan – Oft werden Snapshots im Schlafmodus vergessen. Nutzen Sie dedizierte Backup‑Software (z. B. restic + rclone zu einem günstigen S3‑Kompatibel‑Anbieter).
Mangelnde Sicherheitsupdates – Ein veraltetes Kernel kann Angreifer öffnen. Automatisieren Sie unattended-upgrades und führen Sie wöchentliche apt-get update && apt-get upgrade durch.
Fehlende Monitoring‑Alarme – Ohne Metriken bleibt ein Ausfall unsichtbar. Installieren Sie Prometheus‑Alertmanager und konfigurieren Sie Slack‑ oder E‑Mail‑Benachrichtigungen.
Überdimensionierung – Viele starten mit zu viel RAM/CPU, weil Cloud‑Preise irreführend sind. Beginnen Sie klein, messen Sie Auslastung und skalieren Sie dann gezielt.

Fazit & nächster Schritt

Selbst‑hosting kann – bei richtiger Planung – deutlich günstiger sein als jede Public‑Cloud‑Option, weil Sie Hardware‑Kosten, Daten‑Transfer‑Gebühren und Service‑Gebühren kontrollieren. Der größte Mehrwert liegt jedoch in Transparenz und Daten‑Souveränität: Sie entscheiden, wo Ihre Daten landen und wer sie sehen darf.

Mein persönlicher Rat: Starten Sie mit einem kleinen, aber produktiven Use‑Case (z. B. Nextcloud auf einem alten NAS). Dokumentieren Sie Strom‑ und Bandbreiten‑Kosten für einen Monat, vergleichen Sie diese mit Ihrer aktuellen Cloud‑Rechnung und entscheiden Sie dann, ob Sie das Setup ausbauen wollen.

Konkreter nächster Schritt für Sie

Inventarisieren – Erstellen Sie eine Liste aller Cloud‑Dienste, die Sie derzeit nutzen, inkl. Monatskosten.
Pilot‑Projekt – Setzen Sie innerhalb von 48 Stunden einen Docker‑Compose‑Stack (Nextcloud) auf einem Raspberry Pi oder einer VM auf.
Kosten‑Tracking – Nutzen Sie telegraf + influxdb für Strom‑ und Netzwerk‑Metriken und visualisieren Sie das Ergebnis in Grafana.
Entscheidung – Wenn die Pilot‑Kosten 30 % unter Ihren Cloud‑Kosten liegen, planen Sie die Migration der nächsten beiden Services (z. B. GitLab, Prometheus) in Ihr Self‑Hosting‑Umfeld.

Durch konsequente Messung und schrittweisen Roll‑out vermeiden Sie Überraschungen und sichern sich langfristig finanzielle und datenschutztechnische Vorteile.

Hinweis: Selbst‑Hosting ist kein Allheilmittel. Für extreme Lastspitzen, globale CDN‑Bedarfe oder regulatorisch festgeschriebene Zertifizierungen (z. B. ISO 27001‑Audits) bleibt die Public‑Cloud oft die bessere Wahl. Das Ziel ist ein ausgewogenes Hybrid‑Modell, bei dem Sie die Kern‑Workloads selbst betreiben und nur seltene, burst‑intensive Prozesse in die Cloud auslagern.

Firewall-Tuning: Stateful vs. Next-Gen

Uhltak Therestismysecret — Sat, 30 May 2026 06:00:03 +0000

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

Einleitung

Firewalls sind ein essentielles Tool für die Netzwerk-Sicherheit. Sie kontrollieren den Datenverkehr zwischen Netzwerken und schützen vor unerwünschtem Zugriff. Es gibt jedoch verschiedene Arten von Firewalls, darunter Stateful Firewalls und Next-Gen Firewalls. In diesem Artikel werden wir uns mit der Frage auseinandersetzen, wann Stateful Firewalls ausreichen und wann Next-Gen Firewalls erforderlich sind.

Stateful Firewalls

Stateful Firewalls sind die traditionelle Art von Firewalls. Sie überprüfen den Datenverkehr und erlauben oder verwehren ihn basierend auf den Regeln, die in der Firewall-Konfiguration definiert sind. Stateful Firewalls können auch den Zustand von Verbindungen verfolgen und somit sicherstellen, dass nur autorisierte Verbindungen zugelassen werden.
Ein Beispiel für eine Stateful Firewall ist die Cisco ASA. Die Cisco ASA ist eine beliebte Wahl für Unternehmen, da sie eine Vielzahl von Funktionen bietet, einschließlich Stateful Inspektion, VPN-Unterstützung und Intrusion-Prävention.
Meine Einschätzung: Stateful Firewalls sind eine gute Wahl für kleine bis mittelgroße Unternehmen, die einfache Netzwerk-Sicherheitsanforderungen haben.

Next-Gen Firewalls

Next-Gen Firewalls sind eine neue Generation von Firewalls, die eine Vielzahl von Funktionen bietet, einschließlich Stateful Inspektion, Intrusion-Prävention, Web-Filtering und Malware-Schutz. Next-Gen Firewalls sind in der Lage, den Datenverkehr auf Anwendungsebene zu analysieren und somit einen besseren Schutz vor modernen Bedrohungen wie Malware und Advanced Persistent Threats (APTs) bieten.
Ein Beispiel für eine Next-Gen Firewall ist die Palo Alto Networks Next-Generation Firewall. Diese Firewall bietet eine Vielzahl von Funktionen, einschließlich App-ID, User-ID und Content-ID, die es ermöglichen, den Datenverkehr auf Anwendungsebene zu analysieren und somit einen besseren Schutz vor modernen Bedrohungen zu bieten.
Meine Einschätzung: Next-Gen Firewalls sind eine gute Wahl für große Unternehmen oder Organisationen mit komplexen Netzwerk-Sicherheitsanforderungen.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Implementierung von Firewalls ist die falsche Konfiguration der Regeln. Dies kann zu Sicherheitslücken führen und den Schutz des Netzwerks beeinträchtigen. Ein weiterer Fehler ist die mangelnde Überwachung des Datenverkehrs, was es Angreifern ermöglichen kann, unbemerkt in das Netzwerk einzudringen.

Fazit

In diesem Artikel haben wir uns mit der Frage auseinandergesetzt, wann Stateful Firewalls ausreichen und wann Next-Gen Firewalls erforderlich sind. Stateful Firewalls sind eine gute Wahl für kleine bis mittelgroße Unternehmen mit einfacheren Netzwerk-Sicherheitsanforderungen, während Next-Gen Firewalls eine bessere Wahl für große Unternehmen oder Organisationen mit komplexen Netzwerk-Sicherheitsanforderungen sind.
Dein nächster Schritt: Überprüfe deine aktuelle Firewall-Konfiguration und stelle fest, ob du eine Stateful Firewall oder eine Next-Gen Firewall benötigst. Wenn du unsicher bist, zögere nicht, einen Sicherheitsexperten zu konsultieren, um sicherzustellen, dass dein Netzwerk angemessen geschützt ist.

AI Agents und MCP: Warum autonome Agenten scheitern und wie Sie die Kontrolle behalten

Uhltak Therestismysecret — Fri, 29 May 2026 18:00:04 +0000

AI Agents und MCP – Warum autonome Agenten oft scheitern und wie Sie das Ruder übernehmen

„Man gibt einem Computer ein Ziel, er geht in die Küche, kauft sich ein Sandwich und bricht das Haus ab.“ – Das ist das Bild, das viele von uns beim Stichwort autonome Agenten im Kopf haben. In der Praxis jedoch stellt sich häufig heraus, dass diese „Küchen‑Bots“ mehr Chaos als Ordnung produzieren. In diesem Artikel zerlegen wir das Problem Stück für Stück, zeigen drei echte Code‑Beispiele und geben ein persönliches Fazit, das Sie sofort umsetzen können.

1. Was sind AI Agents und was hat das mit MCP zu tun?

Erklärung: Ein AI Agent ist ein Software‑Konstrukt, das basierend auf einem Large Language Model (LLM) eigenständig Entscheidungen trifft – zum Beispiel, ein Tool aufzurufen, Daten zu verarbeiten oder einen Task zu delegieren. MCP (Machine‑Code‑Proxy) ist dabei das Bindeglied zwischen dem LLM‑Agenten und den System‑Tools. MCP stellt eine standardisierte Schnittstelle bereit, über die der Agent Befehle in einer strukturierten Form (z. B. JSON) sendet, die dann vom Proxy in System‑Calls übersetzt werden.

Beispiel‑Snippet (MCP‑Schema):

{
  "action": "run_command",
  "args": {
    "cmd": "ls -l /var/log",
    "timeout": 30
  }
}

Der Agent liefert dieses JSON an den MCP‑Daemon, der dann ls -l /var/log ausführt und das Ergebnis zurückgibt.

Persönliche Einschätzung: Viele Entwickler glauben, dass das reine Vorhandensein eines MCP automatisch zuverlässige Tool‑Aufrufe ergibt. Das ist ein Trugschluss – der eigentliche Stolperstein liegt in der Semantik der übermittelten Befehle und der Sicherheits‑Policies, die selten von Grund auf definiert werden.

2. Der technische Ablauf – vom Prompt zum Systemaufruf

Erklärung: Der klassische Flow sieht so aus:

Der Nutzer gibt einen Prompt (z. B. "Erstelle ein Backup von /etc") ein.
Das LLM interpretiert die Absicht und generiert ein MCP‑Payload.
Der MCP‑Daemon validiert das Payload gegen ein Policy‑Set.
Der Daemon führt den Befehl aus und leitet die Ausgabe zurück.

Beispiel‑Code (Python‑Agent + MCP‑Client):

import json, requests

prompt = "Zeige die aktiven Prozesse, die mehr als 200 MB RAM verbrauchen"
# 1️⃣ LLM‑Aufruf (hier mit Ollama als lokales Modell)        
resp = requests.post(
    "http://localhost:11434/api/generate",
    json={"model": "llama2", "prompt": prompt}
)
payload = json.loads(resp.text)['payload']   # → MCP‑JSON

# 2️⃣ MCP‑Client‑Aufruf
mcp_resp = requests.post(
    "http://localhost:8080/execute",
    json=payload
)
print(mcp_resp.json())

Dieses Minimalbeispiel zeigt bereits, wo die Vertrauenszonen liegen: Das LLM liefert das Payload, das MCP‑Backend prüft es – aber nur, wenn die Policies korrekt definiert sind.

Persönliche Einschätzung: In meinem täglichen Homelab habe ich das Schema ein einziges Mal ohne Policy verfasst und sofort endlose fork bomb‑Muster beobachtet. Ohne eine klare Allow‑List laufen die Agents schnell in unvorhergesehene Systemzustände.

3. Beispiel 1 – Ein CLI‑Tool per Subprocess starten

Erklärung: Das einfachste Szenario ist, dass ein Agent ein lokales Kommando ausführt – zum Beispiel dig für DNS‑Abfragen. Der MCP‑Daemon übersetzt das JSON in einen subprocess.run‑Aufruf.

Konkretes Beispiel (Docker‑Compose‑Setup):

version: "3.9"
services:
  mcp:
    image: ghcr.io/mcp-proxy/mcp:latest
    ports:
      - "8080:8080"
    environment:
      - "ALLOWED_COMMANDS=dig,nslookup"
  agent:
    image: ollama/llama2:latest
    depends_on: [mcp]
    command: "sleep infinity"

Agent‑Payload:

{
  "action": "run_command",
  "args": {
    "cmd": "dig +short example.com",
    "timeout": 10
  }
}

MCP‑Log‑Auszug:

[INFO] Incoming request: run_command
[DEBUG] Validated command against policy – allowed
[TRACE] Executing: dig +short example.com
[INFO] Command finished, exit code 0, runtime 0.12s

Damit erhalten wir die IP von example.com zurück.

Persönliche Einschätzung: Das Ganze klingt simpel, bis der Agent plötzlich dig -x 0.0.0.0 ausführt und unser internes Netzwerk scannt. Ohne Rate‑Limiting kann ein gut gemeinter Agent leicht zu einer DoS‑Situation werden.

4. Beispiel 2 – REST‑API‑Aufruf über MCP

Erklärung: Moderne Tools bieten HTTP‑APIs (z. B. GitHub, JIRA). Hier muss der MCP nicht nur curl ausführen, sondern auch Header, Auth und JSON‑Body korrekt handhaben.

MCP‑Payload für GitHub‑Issue‑Erstellung:

{
  "action": "http_request",
  "args": {
    "method": "POST",
    "url": "https://api.github.com/repos/me/me/issues",
    "headers": {
      "Authorization": "Bearer {{$GITHUB_TOKEN}}",
      "Accept": "application/vnd.github+json"
    },
    "json": {
      "title": "Automatischer Bug‑Report",
      "body": "Erzeugt von AI‑Agent am $(date)"
    }
  }
}

MCP‑Daemon‑Konfiguration (policy.yaml):

http_requests:
  - domain: "api.github.com"
    methods: ["GET", "POST"]
    max_body_size: 10KB
    auth_required: true

Ausgabe (nach erfolgreichem Aufruf):

{
  "status": 201,
  "response": {
    "html_url": "https://github.com/me/me/issues/42",
    "number": 42
  }
}

Persönliche Einschätzung: Der Knackpunkt ist die Credential‑Injection. Wenn das LLM den Token aus einem Prompt ableitet, endet das Projekt in einer Sicherheitskatastrophe. In meiner Praxis habe ich deshalb strikt die Token‑Übergabe über die MCP‑Umgebungsvariablen und niemals im Prompt erlaubt.

5. Beispiel 3 – Kombination aus LangChain, lokalem LLM und Tool‑Orchestrierung

Erklärung: Fortgeschrittene Agents nutzen Bibliotheken wie LangChain oder CrewAI, um mehrere Schritte hintereinander zu planen. Der Agent baut dann einen Chain aus mehreren MCP‑Aufrufen.

Python‑Beispiel (LangChain‑Chain):

from langchain.agents import initialize_agent, Tool
from langchain.llms import Ollama
import requests, json

# ---- MCP‑Wrapper ----
class MCPTool(Tool):
    name = "MCP"
    description = "Executes a system command via MCP"
    def _run(self, cmd: str) -> str:
        payload = json.dumps({"action": "run_command", "args": {"cmd": cmd, "timeout": 20}})
        r = requests.post("http://localhost:8080/execute", data=payload)
        return r.json().get("output", "")

# ---- LLM + Agent ----
llm = Ollama(model="llama2")
agent = initialize_agent([MCPTool()], llm, agent="zero-shot-react-description", verbose=True)

# Prompt: Prüfe das Disk‑Layout und erstelle ein Report‑PDF
result = agent.run("run df -h && generate a PDF report with the output")
print(result)

Erwartete MCP‑Aufrufe:

df -h
pandoc -f markdown -t pdf -o /tmp/report.pdf

Persönliche Einschätzung: Das Szenario zeigt, warum Komposability ein zweischneidiges Schwert ist. Jeder Zwischenschritt erhöht das Risiko einer Fehlkonfiguration. Ich habe deshalb in allen meinen produktiven Chains ein Fallback‑Mechanismus eingebaut, der bei unbekannten Befehlen die Ausführung stoppt und eine Fehlermeldung zurückgibt.

6. Typische Fehler – Warum viele Projekte im Chaos enden

Fehler	Warum er passiert	Konsequenz
Ungeprüfte Payloads	Agent liefert beliebige JSON‑Strukturen	Arbiträrer Code‑Execution
Fehlende Rate‑Limits	Keine Beschränkung der Aufrufe	DoS‑Angriffe, Ressourcen‑Exhaustion
Offene Credential‑Weitergabe	Tokens im Prompt eingebettet	Kompromittierte Secrets
Keine Output‑Sanitization	Rückgabe wird direkt weiterverarbeitet	Injection‑Angriffe (z. B. Shell‑Injection)
Zu breite Allow‑List	`ALLOWED_COMMANDS=*`	Unkontrollierter Zugriff auf System‑Tools

Kurz‑Checkliste:

Definieren Sie eine Whitelist aller erlaubten Aktionen.
Setzen Sie Timeouts und Memory‑Limits im MCP‑Daemon.
Verwenden Sie Vault‑ähnliche Mechanismen für Secrets.
Loggen Sie jedes MCP‑Payload + Response für Auditing.

Persönliche Einschätzung: In meinem letzten Projekt habe wir alle fünf Punkte vernachlässigt – das Resultat war ein nicht mehr stoppbarer Crash‑Loop, der das gesamte Netzwerk lahmlegte. Ein kurzer Blick auf den MCP‑Log hätte das sofort aufgezeigt.

7. Best Practices – So halten Sie die Kontrolle wieder zurück

Policy‑First‑Ansatz – Schreiben Sie das Policy‑File bevor Sie einen Agenten bauen.
Sandbox‑Umgebung – Führen Sie MCP zunächst in einem isolierten Container (--security-opt=no-new-privileges) aus.
Auditable Logging – Integrieren Sie structured-logging (JSON) und schicken Sie die Logs an Elastic Stack.
Fail‑Open vs. Fail‑Secure – Standardmäßig fail‑secure: Wenn ein Payload nicht eindeutig ist, wird es verworfen.
Versionierung – Taggen Sie sowohl das LLM‑Modell als auch das MCP‑Binary, damit Sie bei Rollbacks exakt dieselben Versionen wiederherstellen können.

Beispiel‑Docker‑Run (sichere MCP‑Instanz):

docker run -d \
  --name mcp-secure \
  --restart unless-stopped \
  --read-only \
  --tmpfs /run \
  -e ALLOWED_COMMANDS="dig,nslookup" \
  -e POLICY_FILE="/etc/mcp/policy.yaml" \
  -v $(pwd)/policy.yaml:/etc/mcp/policy.yaml:ro \
  ghcr.io/mcp-proxy/mcp:latest

Damit ist das Dateisystem schreibgeschützt und nur die definierte Policy ist einsehbar.

8. Fazit und konkreter nächster Schritt

AI‑Agents in Kombination mit MCP besitzen ein enormes Potenzial: Sie können Routine‑Tasks automatisieren, komplexe Workflows orchestrieren und sogar in Bereichen wie Incident‑Response glänzen. Aber das gleiche Potenzial birgt das Risiko, dass ein schlecht konfigurierter Agent das gesamte System destabilisiert oder kritische Secrets preisgibt.

Mein Fazit:

Trust but verify – Vertrauen Sie dem LLM, prüfen Sie aber jedes generierte Payload.
Policy First – Lassen Sie das Policy‑File das Herzstück Ihrer Sicherheitsstrategie sein.
Iteratives Testing – Beginnen Sie mit einem Minimal‑Set an Befehlen, erweitern Sie schrittweise und beobachten Sie das Logging.

Konkreter nächster Schritt für Sie:

Erstellen Sie eine policy.yaml mit einer White‑List der wirklich benötigten Befehle.
Deployen Sie den MCP‑Daemon in einem isolierten Docker‑Container (Beispiel‑Befehl oben).
Implementieren Sie einen einfachen Python‑Agenten, der das Policy‑File nutzt, und testen Sie ihn mit dem dig‑Beispiel.
Analysieren Sie die Logs, passen Sie Timeout‑ und Rate‑Limits an und erweitern Sie die Whitelist nur nach Bedarf.

Auf diese Weise verwandeln Sie die anfängliche Küchen‑Katastrophe in ein kontrolliertes, nachvollziehbares System – und können die echten Vorteile von autonomen AI‑Agents genießen, ohne dem Chaos zu erliegen.

Firewall-Tuning: Stateful vs. Next-Gen - Der ultimative Leitfaden

Uhltak Therestismysecret — Fri, 29 May 2026 06:00:06 +0000

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

Hook-Einleitung: Stellen Sie sich vor, Sie sind der Sicherheitschef einer großen Firma und müssen die Netzwerksicherheit sicherstellen. Eine der wichtigsten Entscheidungen, die Sie treffen müssen, ist die Wahl der richtigen Firewall. Aber welche Art von Firewall ist die richtige für Ihr Unternehmen? Stateful oder Next-Gen? In diesem Artikel werden wir diese Frage beantworten und Ihnen zeigen, wie Sie Ihre Firewall für maximale Sicherheit und Leistung optimieren können.

Was ist eine Stateful Firewall?

Eine Stateful Firewall ist eine Art von Firewall, die den Zustand von Netzwerkverbindungen überwacht und basierend auf diesem Zustand Entscheidungen trifft, ob Datenpakete durchgelassen oder blockiert werden sollen. Dies bedeutet, dass die Firewall nicht nur den Ursprung und das Ziel von Datenpaketen überprüft, sondern auch den Kontext der Kommunikation.

Beispiel: Die Cisco ASA-Serie ist ein Beispiel für eine Stateful Firewall. Mit der ASA können Sie Regeln erstellen, die den Datenverkehr basierend auf dem Zustand von Netzwerkverbindungen steuern.

Meine Einschätzung: Stateful Firewalls sind eine gute Wahl, wenn Sie eine einfache und effektive Lösung für die Netzwerksicherheit benötigen. Sie sind jedoch nicht immer in der Lage, komplexe Angriffe zu erkennen und zu verhindern.

Was ist eine Next-Gen Firewall?

Eine Next-Gen Firewall ist eine Art von Firewall, die über die Funktionen einer Stateful Firewall hinausgeht und zusätzliche Funktionen wie Intrusion-Prävention, Anwendungserkennung und -steuerung sowie SSL/TLS-Inspektion bietet. Dies ermöglicht es der Firewall, nicht nur den Datenverkehr zu überwachen, sondern auch die Anwendungen und Inhalte zu analysieren.

Beispiel: Die Palo Alto Networks Next-Gen Firewall ist ein Beispiel für eine Next-Gen Firewall. Mit dieser Firewall können Sie Regeln erstellen, die den Datenverkehr basierend auf Anwendungen, Benutzern und Inhalten steuern.

Meine Einschätzung: Next-Gen Firewalls sind eine gute Wahl, wenn Sie eine umfassende Lösung für die Netzwerksicherheit benötigen. Sie bieten eine Vielzahl von Funktionen, die es ermöglichen, komplexe Angriffe zu erkennen und zu verhindern.

Häufige Fehler / Fallstricke

Ein häufiger Fehler bei der Konfiguration von Firewalls ist die Annahme, dass eine Stateful Firewall ausreicht, um die Netzwerksicherheit zu gewährleisten. Dies kann jedoch zu Problemen führen, wenn komplexe Angriffe auftreten. Ein anderer Fehler ist die mangelnde Überwachung und Wartung der Firewall, was zu Sicherheitslücken führen kann.

Fazit mit Dein nächster Schritt

In diesem Artikel haben wir die Unterschiede zwischen Stateful- und Next-Gen-Firewalls besprochen und gezeigt, wie Sie Ihre Firewall für maximale Sicherheit und Leistung optimieren können. Dein nächster Schritt sollte sein, Ihre aktuelle Firewall-Konfiguration zu überprüfen und zu prüfen, ob sie den Anforderungen Ihrer Netzwerksicherheit entspricht. Wenn Sie eine Stateful Firewall verwenden, sollten Sie prüfen, ob eine Next-Gen Firewall eine bessere Wahl für Ihr Unternehmen wäre. Wenn Sie bereits eine Next-Gen Firewall verwenden, sollten Sie sicherstellen, dass sie ordnungsgemäß konfiguriert und gewartet wird.

Zero Trust: Revolution im Netzwerkschutz

Uhltak Therestismysecret — Thu, 28 May 2026 06:00:04 +0000

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

Einleitung

Die Welt der IT-Sicherheit ist ständig in Bewegung. Neue Bedrohungen tauchen auf, und die alten Methoden scheinen nicht mehr ausreichend. Eine Lösung, die in den letzten Jahren immer mehr an Bedeutung gewinnt, ist die Zero Trust Architektur. Doch was ist Zero Trust, und warum ist es mehr als nur ein Buzzword?

Was ist Zero Trust?

Zero Trust ist ein Sicherheitskonzept, das auf dem Prinzip 'never trust, always verify' basiert. Das bedeutet, dass kein Benutzer, kein Gerät und keine Anwendung automatisch vertrauenswürdig ist, sondern dass jede Interaktion überprüft wird. Dieser Ansatz ist notwendig, da die traditionellen Sicherheitsmethoden, wie Firewalls und VPNs, nicht mehr ausreichend sind, um die modernen Bedrohungen abzuwehren.

Beispiel: Zero Trust in der Praxis

Ein Beispiel für die Implementierung von Zero Trust ist die Nutzung von Identity and Access Management (IAM)-Lösungen wie Okta oder Microsoft Azure Active Directory. Diese Lösungen ermöglichen es, den Zugriff auf Anwendungen und Ressourcen basierend auf den Identitäten der Benutzer und ihrer Geräte zu kontrollieren. Ein weiteres Beispiel ist die Nutzung von Next-Gen Firewalls wie Palo Alto Networks, die eine granulare Kontrolle über den Datenverkehr ermöglichen.

Meine Einschätzung: Die Implementierung von Zero Trust ist ein wichtiger Schritt, um die IT-Sicherheit zu verbessern. Es ist jedoch wichtig, dass die Lösungen sorgfältig ausgewählt und konfiguriert werden, um sicherzustellen, dass sie den Anforderungen des Unternehmens entsprechen.

Vorteile von Zero Trust

Die Vorteile von Zero Trust sind zahlreich. Einige der wichtigsten Vorteile sind:

Verbesserung der IT-Sicherheit: Durch die Überprüfung jeder Interaktion kann das Risiko von Cyberangriffen minimiert werden.
Erhöhung der Transparenz: Durch die Überwachung aller Aktivitäten kann ein Unternehmen besser verstehen, was in seinem Netzwerk passiert.
Reduzierung der Angriffsfläche: Durch die Einschränkung des Zugriffs auf Anwendungen und Ressourcen kann die Angriffsfläche reduziert werden.

Beispiel: Vorteile in der Praxis

Ein Beispiel für die Vorteile von Zero Trust ist die Reduzierung der Angriffsfläche. Durch die Implementierung von Zero Trust kann ein Unternehmen den Zugriff auf sensitive Daten und Anwendungen einschränken, was das Risiko von Cyberangriffen minimiert. Ein weiteres Beispiel ist die Verbesserung der IT-Sicherheit durch die Überprüfung jeder Interaktion. Dies kann durch die Nutzung von Lösungen wie Cisco Umbrella erfolgen, die eine cloud-basierte Sicherheitslösung bietet.

Meine Einschätzung: Die Vorteile von Zero Trust sind offensichtlich. Es ist jedoch wichtig, dass die Lösungen sorgfältig ausgewählt und konfiguriert werden, um sicherzustellen, dass sie den Anforderungen des Unternehmens entsprechen.

Häufige Fehler / Fallstricke

Einige der häufigsten Fehler bei der Implementierung von Zero Trust sind:

Unzureichende Planung: Die Implementierung von Zero Trust erfordert eine sorgfältige Planung, um sicherzustellen, dass die Lösungen den Anforderungen des Unternehmens entsprechen.
Fehlende Schulung: Die Schulung der Mitarbeiter ist wichtig, um sicherzustellen, dass sie die Lösungen korrekt nutzen können.
Unzureichende Überwachung: Die Überwachung aller Aktivitäten ist wichtig, um sicherzustellen, dass die Lösungen korrekt funktionieren.

Fazit

Die Zero Trust Architektur ist ein wichtiger Schritt, um die IT-Sicherheit zu verbessern. Durch die Überprüfung jeder Interaktion kann das Risiko von Cyberangriffen minimiert werden. Es ist jedoch wichtig, dass die Lösungen sorgfältig ausgewählt und konfiguriert werden, um sicherzustellen, dass sie den Anforderungen des Unternehmens entsprechen. Dein nächster Schritt sollte sein, die Implementierung von Zero Trust in Deinem Unternehmen zu überdenken und die geeigneten Lösungen auszuwählen.

Proxmox HA-Cluster: Erfolgreich über Wartungsperioden und Split-Brain

Uhltak Therestismysecret — Tue, 26 May 2026 18:00:01 +0000

Einleitung

Wenn Sie ein Proxmox-Setup betreiben, ist das Ziel wahrscheinlich die maximale Verfügbarkeit Ihrer Virtualisierungs-Lösung. Ein häufig verwendetes Tool zur Erreichung dieser Ziele ist das Proxmox High Availability Cluster (HA-Cluster). Dieses ermöglicht es Ihnen, ihre KVM-VMs über mehrere Proxmox-Server zu verteilen und so ihre Gesamtleistung zu verbessern. In diesem Artikel geht es darum, wie Sie ein Proxmox HA-Cluster sicher einrichten und was Sie dabei beachten müssen, um Split-Brain-Ereignisse sowie falsche Quorum-Konfigurationen zu vermeiden.

In diesem Beispiel setzen wir an, dass Sie bereits ein Proxmox Cluster-Szenario eingerichtet haben und nun die Details verbessern wollen.

1.1 Split-Brain-Verhinderung

Ein häufiges Problem bei Proxmox Clustern ist die sogenannte Split-Brain-Verhinderung. Dies tritt auf, wenn zwei oder mehrere Knoten des Clusters ohne die Zustimmung aller anderen Netzwerkkomponenten in den Failover-Zustand wechseln. Dies führt dazu, dass die VMs und der Datenverkehr an die falsche Stelle umgeleitet werden. Dadurch können wichtige Ressourcen verloren gehen und wichtige Services möglicherweise nicht mehr verfügbar sein.

Dieses Szenario kann sehr leicht bei einer nicht-direkten Netzwerkkonfiguration eintreten. Die Lösung dafür? Eine direkte Netzwerkkonfiguration im 2. Wahl. 2. Wahl ermöglicht ein direktes, sicheres Networking zwischen Clustern und der Reduzierung der Netzwerkbelastung.

Sie sollten sich nun fragen: Was ist eine direkte Netzwerkkonfiguration? Bei einer direkten Netzwerkkonfiguration müssen alle Server im Cluster immer direkt miteinander verbunden sein. Versteht man aber nicht sofort, was das in der Praxis bedeutet. Direkte Verbindungen werden von Proxmox also einfach so durch Proxmox im Cluster mit allen anderen Node direkt verbunden. Durch Proxmox werden die Knoten also direkt an einander gesteckt - oder andersausgedrückt: Eine direkte Verbindung ist keine indirekte Verbindung zu einem anderen Proxmox-Node. Durch eine

Zero Trust Architektur: Die Zukunft der Netzwerksicherheit

Uhltak Therestismysecret — Tue, 26 May 2026 06:00:04 +0000

Zero Trust Architektur: Die Zukunft der Netzwerksicherheit

Einleitung

Die traditionelle Sicherheitsarchitektur basiert auf dem Vertrauen in die Authentifizierung von Benutzern und Geräten. Wenn ein Benutzer authentifiziert wird, erhält er Zugriff auf das gesamte Netzwerk. Diese Herangehensweise ist jedoch anfällig für Angriffe, wenn ein Angreifer Zugriff auf die Authentifizierung erhält. Die Zero Trust Architektur (ZTA) ist ein neues Paradigma, das auf dem Prinzip 'never trust, always verify' basiert. Dies bedeutet, dass jeder Zugriff auf das Netzwerk und seine Ressourcen ständig überwacht und verifiziert wird, unabhängig von der Authentifizierung.

Warum ist Zero Trust Architektur notwendig?

In der heutigen Welt ist die traditionelle Sicherheitsarchitektur nicht mehr ausreichend, um die komplexen Bedrohungen zu bekämpfen. Mit der zunehmenden Verbreitung von Cloud-Diensten, IoT-Geräten und mobilen Anwendungen sind die Netzwerke nicht mehr klar definiert. Ein Angreifer kann leicht in das Netzwerk eindringen, indem er schwache Passwörter oder ungesicherte Schnittstellen ausnutzt. Die Zero Trust Architektur ist notwendig, um diese Lücken zu schließen und das Netzwerk zu schützen.

Meine Einschätzung: Die Zero Trust Architektur ist ein notwendiger Schritt in Richtung einer sichereren Netzwerkinfrastruktur. Durch die ständige Überwachung und Verifizierung kann man die Angriffsfläche minimieren und die Sicherheit erhöhen.

Wie funktioniert Zero Trust Architektur?

Die Zero Trust Architektur basiert auf drei Hauptkomponenten:

Identität: Jeder Benutzer und jedes Gerät muss identifiziert werden, bevor es Zugriff auf das Netzwerk erhält.
Authentifizierung: Die Authentifizierung erfolgt durch eine Kombination von Faktoren, wie z.B. Benutzername und Passwort, Zwei-Faktor-Authentifizierung oder biometrische Authentifizierung.
Autorisierung: Die Autorisierung definiert, welche Ressourcen der Benutzer oder das Gerät Zugriff auf hat.

Beispiel: Die Firma Google verwendet eine Zero Trust Architektur, um ihre Mitarbeiter und Geräte zu schützen. Jeder Mitarbeiter muss sich mit seinem Benutzernamen und Passwort authentifizieren, bevor er Zugriff auf die Google-Netzwerke erhält. Die Autorisierung erfolgt durch eine Kombination von Faktoren, wie z.B. der Rolle des Mitarbeiters und den Ressourcen, auf die er Zugriff benötigt.

Meine Einschätzung: Die Implementierung einer Zero Trust Architektur kann komplex sein, aber die Vorteile sind es wert. Durch die ständige Überwachung und Verifizierung kann man die Sicherheit erhöhen und die Angriffsfläche minimieren.

Beispiele für Zero Trust Architektur

Es gibt viele Beispiele für Zero Trust Architektur in der Praxis. Einige Beispiele sind:

Microsoft Azure Active Directory (Azure AD): Azure AD ist ein cloudbasiertes Identitäts- und Zugriffsverwaltungssystem, das eine Zero Trust Architektur implementiert.
Google Cloud Identity and Access Management (IAM): Google Cloud IAM ist ein Dienst, der eine Zero Trust Architektur implementiert, um die Identität und den Zugriff auf Google Cloud-Ressourcen zu verwalten.
Cisco ISE: Cisco ISE ist ein Netzwerkzugriffskontrollsystem, das eine Zero Trust Architektur implementiert, um den Zugriff auf das Netzwerk zu verwalten.

Meine Einschätzung: Diese Beispiele zeigen, dass die Zero Trust Architektur nicht nur ein Buzzword ist, sondern eine reale Lösung für die Sicherheitsherausforderungen der heutigen Welt.

Häufige Fehler / Fallstricke

Es gibt einige häufige Fehler und Fallstricke, die man bei der Implementierung einer Zero Trust Architektur vermeiden sollte:

Unzureichende Identifizierung: Die Identifizierung von Benutzern und Geräten ist entscheidend für die Zero Trust Architektur. Wenn die Identifizierung unzureichend ist, kann die Sicherheit nicht garantiert werden.
Unzureichende Authentifizierung: Die Authentifizierung muss stark und mehrfach sein, um die Sicherheit zu garantieren.
Unzureichende Autorisierung: Die Autorisierung muss klar definiert sein, um die Ressourcen zu schützen.

Meine Einschätzung: Die Implementierung einer Zero Trust Architektur erfordert eine sorgfältige Planung und Umsetzung. Es ist wichtig, alle Aspekte der Sicherheit zu berücksichtigen, um die Angriffsfläche zu minimieren.

Fazit

Die Zero Trust Architektur ist ein notwendiger Schritt in Richtung einer sichereren Netzwerkinfrastruktur. Durch die ständige Überwachung und Verifizierung kann man die Angriffsfläche minimieren und die Sicherheit erhöhen. Es gibt viele Beispiele für Zero Trust Architektur in der Praxis, und es ist wichtig, alle Aspekte der Sicherheit zu berücksichtigen, um die Implementierung erfolgreich umzusetzen.

Dein nächster Schritt: Informieren Sie sich über die verschiedenen Lösungen und Tools, die eine Zero Trust Architektur implementieren können. Berücksichtigen Sie die spezifischen Sicherheitsanforderungen Ihres Unternehmens und planen Sie die Implementierung sorgfältig, um die Angriffsfläche zu minimieren und die Sicherheit zu erhöhen.

CI/CD ohne YAML-Hölle: Dagger.io revolutioniert die DevOps-Welt

Uhltak Therestismysecret — Mon, 25 May 2026 18:00:01 +0000

CI/CD ohne YAML-Hölle: Dagger.io revolutioniert die DevOps-Welt

Einige Jahre zurück war es noch eine Selbstverständlichkeit: CI/CD-Maßnahmen bestanden aus einer zermürbenden Schleife von Code-Commits, Pull-Requests, Code-Reviews und schließlich der manuellen Durchführung von Build- und Deployment-Operationen. Was genau bedeutet das? Die Entwickler steckten ihr Wissen in einen Code-Editor, der Developer auf der anderen Seite war verantwortlich für die Durchführung der Build-Prozesse und schließlich gab es noch die DevOps-Team Member*, die sich um die Containerisierung und Deployment-Schnittstellen kümmerten. Diese Praxis war mühsam und nicht mehr zeitgemäß. Doch dank Dagger-IO gibt es nun Hoffnung bei Entwicklungsteams weltweit.

CI/CD mit Dagger.io

Dagger.io ist ein leistbares, Python-basiertes Framework, das Continuous Integration und Continuous Deployment auf eine einfache, intuitive Weise löst. Genauer gesagt kombiniert es Code-First Pipelines und DevOps-Maßnahmen in einer verschmolzenen Unity, um alle Beteiligten umständlose Arbeitsplätze zu ermöglichen.

Wie funktioniert es?

Um beispielsweise ein Deployment der eigenen Anwendung durchzuführen, müssen Sie lediglich einen simple Daggerio-Workshop erstellen:


python
tasks:
- name: build
  action: /usr/bin/docker-compose build

- name: test
  action: /usr/bin/docker-compose run --rm app python -m unittest tests

- name: deploy
  action: /usr/bin/kubectl apply -f k8s/deployment.yaml 

  on succeed:
    output:

DEV Community: Uhltak Therestismysecret

Monitoring & Observability: Warum Logs nicht reichen – Tracing im Fokus

Monitoring & Observability – Warum Logs allein nicht reichen und wie Tracing Ihr System rettet

Warum reine Log‑Analyse nicht ausreicht

Beispiel 1: Der klassische grep‑Befehl

Persönliche Einschätzung

Tracing verstehen und einsetzen

Beispiel 2: OpenTelemetry + Jaeger in einem Go‑Microservice

Persönliche Einschätzung

Kombinieren von Metrics, Logs und Traces – das Observability‑Triad

Beispiel 3: Prometheus + Loki + Grafana‑Dashboard

Persönliche Einschätzung

Häufige Fehler bei Monitoring & Observability

Fazit & konkreter nächster Schritt

Zero Trust Architektur: Der neue Standard für die IT-Sicherheit

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

Einführung in die Zero Trust Architektur

Implementierung der Zero Trust Architektur

Vorteile der Zero Trust Architektur

Häufige Fehler / Fallstricke

Fazit

DNS-Sicherheit: DoT, DoH & DNSSEC im Vergleich – Was schützt wirklich?

Hook – Warum wir alle schon blind unserem DNS vertrauen (oder nicht)

DNS over TLS (DoT) – Der alte Klassiker im neuen Gewand

Was ist DoT?

Praktisches Beispiel: DoT mit systemd‑resolved auf Ubuntu 22.04

Persönliche Einschätzung

DNS over HTTPS (DoH) – Der hippe Cousin aus der Browserwelt

Was ist DoH?

Praktisches Beispiel: DoH mit cloudflared als lokaler Resolver

Persönliche Einschätzung

DNSSEC – Der digitale Fingerabdruck für DNS‑Antworten

Was ist DNSSEC?

Praktisches Beispiel: DNSSEC‑Validierung mit unbound

Persönliche Einschätzung

Gemeinsamer Vergleich – Was schützt wirklich?

Häufige Fehler – Warum die meisten Implementierungen trotzdem unsicher bleiben

Fazit & nächster Schritt – So sichern Sie Ihr DNS jetzt sofort

Firewall-Tuning: Stateful vs. Next-Gen - Die ultimative Entscheidung

Firewall-Tuning: Die ultimative Entscheidung

Was sind Stateful Firewalls?

Beispiel: Cisco ASA

Was sind Next-Gen Firewalls?

Beispiel: Palo Alto Networks

Häufige Fehler / Fallstricke

Fazit

Self‑Hosting vs. Cloud: Kostentransparenz, Praxisbeispiele und worauf Sie wirklich achten sollten

Self‑Hosting vs. Cloud – Warum das alte Modell plötzlich günstiger wirft

Was ist Self‑Hosting?

Beispiel 1 – Raspberry Pi 4 als Mini‑Server

Kostenvergleich – Self‑Hosting vs. Public Cloud

1. Hardware‑Investition vs. Pay‑As‑You‑Go

2. Personal‑ und Sicherheitsaufwand

Praktische Umsetzung – Drei reale Self‑Hosting‑Projekte

2.1 Nextcloud auf einem Home‑Server (Docker‑Compose)

2.2 GitLab CE auf Hetzner (Bare‑Metal, Ansible)

2.3 Kubernetes‑Cluster auf günstigen VPS (k3s + Helm)

Häufige Fehler beim Self‑Hosting

Fazit & nächster Schritt

Konkreter nächster Schritt für Sie

Firewall-Tuning: Stateful vs. Next-Gen

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

Einleitung

Stateful Firewalls

Next-Gen Firewalls

Häufige Fehler / Fallstricke

Fazit

AI Agents und MCP: Warum autonome Agenten scheitern und wie Sie die Kontrolle behalten

AI Agents und MCP – Warum autonome Agenten oft scheitern und wie Sie das Ruder übernehmen

1. Was sind AI Agents und was hat das mit MCP zu tun?

2. Der technische Ablauf – vom Prompt zum Systemaufruf

3. Beispiel 1 – Ein CLI‑Tool per Subprocess starten

4. Beispiel 2 – REST‑API‑Aufruf über MCP

5. Beispiel 3 – Kombination aus LangChain, lokalem LLM und Tool‑Orchestrierung

6. Typische Fehler – Warum viele Projekte im Chaos enden

7. Best Practices – So halten Sie die Kontrolle wieder zurück

8. Fazit und konkreter nächster Schritt

Firewall-Tuning: Stateful vs. Next-Gen - Der ultimative Leitfaden

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

Was ist eine Stateful Firewall?

Beispiel 1: Der klassische `grep`‑Befehl

Beispiel 3: Prometheus + Loki + Grafana‑Dashboard

Praktisches Beispiel: DoT mit systemd‑resolved auf Ubuntu 22.04

Beispiel 1 – Raspberry Pi 4 als Mini‑Server

3. Beispiel 1 – Ein CLI‑Tool per Subprocess starten

4. Beispiel 2 – REST‑API‑Aufruf über MCP

5. Beispiel 3 – Kombination aus LangChain, lokalem LLM und Tool‑Orchestrierung