Für Administratoren von MikroTik-Netzwerkhardware herrscht höchste Alarmstufe. Wie das polnische CSIRT (CERT Polska) berichtet, nutzen Angreifer seit Anfang September 2026 eine Kette von neu entdeckten Sicherheitslücken aktiv aus, um MikroTik-Router im großen Stil zu kapern. Unter der Bezeichnung MikroTrick kombinieren Kriminelle mehrere Schwachstellen in der RouterOS-Firmware, um unauthentifiziert die vollständige administrative Kontrolle über betroffene Systeme zu erlangen.

Nach Einschätzung von IT-Sicherheitsdiensten sind weltweit über 100.000 über das Internet erreichbare Router potenziell von der Welle bedroht.

Funktionsweise der „MikroTrick“-Attacke

Das Forscherteam von CERT Polska hat insgesamt sechs Schwachstellen in der Zertifikats- und Diensteverarbeitung von RouterOS identifiziert. Der gefährlichste Angriffsvektor kombiniert zwei spezifische Fehler im SSH-Server und -Client von RouterOS:

1. Authentication Bypass: Eine Lücke erlaubt es Angreifern, die reguläre Anmeldung am SSH-Dienst zu umgehen.

2. Privilege Escalation: Eine verknüpfte zweite Schwachstelle verschafft dem Angreifer umgehend uneingeschränkte Administratorrechte (CVSS-Score: 9.2).

Nicht nur SSH-Dienste sind anfällig

Obwohl die aktiven Angriffe primär über exponierte SSH-Ports ablaufen, beschränkt sich das Risiko keineswegs nur auf die Konsole. Das Lücken-Set betrifft auch weitere Systemkomponenten von RouterOS:

• Das Web-Management WebFig

• Den internen Bandbreitentest-Dienst

• Die Verarbeitung von X.509-TLS-Zertifikaten

Selbst wenn SSH extern geschlossen ist, sollten RouterOS-Instanzen daher dringend aktualisiert werden, da auch ausgehende TLS-Verbindungen oder interne Verwaltungsdienste ausnutzbar sind.

Welche Versionen sichern das System ab?

MikroTik hat umgehend reagiert und geflickte Releases für die jeweiligen Update-Kanäle veröffentlicht. Betreiber sollten ihre Geräte unverzüglich auf folgende oder neuere Firmware-Stände heben:

• v7 Stable Branch: Aktualisierung auf 7.16 (oder höher)

• v7 Long-Term Branch: Aktualisierung auf 7.15.3 (beachte: falls Version 7.23.4 / 7.23.5 im Einsatz ist, ebenfalls aktualisieren)

• v6 Long-Term / Legacy: Aktualisierung auf 6.49.15

• Development / Testing: Aktualisierung auf 7.25beta3

Empfohlener Incident-Response-Plan für Admins

1. Sofortiges Firmware-Update

Spielt die gepatchte RouterOS-Version über den Mikrotik-Update-Mechanismus, WinBox oder WebFig ein.

2. Verwaltungszugänge vom WAN trennen

Verwaltungsdienste wie SSH, WinBox und WebFig gehören grundsätzlich niemals ungeschützt an das öffentliche Internet.

• Schränkt den Zugriff über IP-Firewall-Regeln strikt auf interne Management-VLANs ein.

• Nutzt für den Fernzugriff ausschließlich verschlüsselte VPN-Tunnel (z. B. WireGuard).

3. Prüfen auf Kompromittierung (IoCs)

Da Angreifer Hintertüren im System verankern können, reicht ein reines Update bei bereits infizierten Geräten oft nicht aus.

• Kontrolliert die Scheduler-Tasks, Scripts und angelegten Admin-Nutzer auf unautorisierte Einträge.

• Bei konkretem Verdacht: Trennt das Gerät vom Netz, sichert Logs und Konfigurationen, führt einen vollständigen Netinstall / Factory Reset durch und spielt eine saubere Konfiguration neu ein.

Fazit

„MikroTrick“ zeigt erneut, wie verheerend die Kombination aus schwachen Schnittstellen-Konfigurationen und ungepatchter Edge-Hardware ist. Wer MikroTik-Geräte im Einsatz hat, muss jetzt handeln, um seine Netzwerkgrenzen wirksam abzusichern.

Quelle & Weiterführende Berichterstattung: https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/

Der Beitrag MikroTrick: Kritische RouterOS-Lücken werden aktiv ausgenutzt erschien zuerst auf Ivan Ivanov.

Der Einsatz generativer KI gehört an Universitäten, Fachhochschulen und in der beruflichen Bildung längst zum Alltag. Ob beim Zusammenfassen umfangreicher Vorlesungsskripte, der Recherche für Seminararbeiten oder dem Erstellen von Programmcode: Leistungsfähige Sprachmodelle sparen wertvolle Zeit. Mit einer neuen Sonderaktion richtet sich Google gezielt an Lernende und verschenkt ein volles Jahr des Google One AI Pro-Abos.

Was bietet das Google One AI Plus-Paket?

Das Paket gehört regulär zu den umfangreichsten Angeboten auf dem Markt und kostet üblicherweise 4,99 Euro im Monat. Im Rahmen der Aktion entfallen diese Gebühren für 12 Monate vollständig. Bei den weiteren Pro Varianten vom Abo gibt es kräftige Rabate für 4 Jahre! Dort ist mehr Speicher enthalten 2+TB sowie höhere Limits.

Die wichtigsten Features im Überblick:

• Zugriff auf Gemini Advanced: Nutzung der aktuellsten und leistungsfähigsten Modell-Iterationen von Google mit erweitertem Denkvermögen (Reasoning) und riesigem Kontextfenster.

• Erweiterter Cloud-Speicher (400 GB): Ausreichend Speicherplatz auf Google Drive, Google Fotos und Gmail für Projektarbeiten, Datensicherungen und Medien.

• Nahtlose Workspace-Integration: Gemini lässt sich direkt in Google Docs, Präsentationen, Tabellen und Gmail nutzen, um Entwürfe zu generieren oder Daten zu strukturieren.

• Code- und Analyse-Tools: Fortgeschrittene Funktionen zum Erstellen, Erklären und Debuggen von Quellcode in verschiedenen Programmiersprachen.

Wer ist teilnahmeberechtigt und wie läuft die Aktivierung?

Das Angebot richtet sich an alle eingeschriebenen Studierenden an staatlich anerkannten Hochschulen sowie an Auszubildende. Die Verifizierung erfolgt während des Anmeldeprozesses in der Regel über einen externen Verifizierungsdienstleister unter Verwendung der offiziellen Hochschul-E-Mail-Adresse oder entsprechender Nachweisdokumente.

Tipp zur Kündigung: Um zu verhindern, dass sich das kostenlose Probejahr nach Ablauf der 12 Monate automatisch in ein kostenpflichtiges Monatsabo umwandelt, kann die automatische Verlängerung direkt nach der Aktivierung in den Google One-Kontoeinstellungen deaktiviert werden. Das Gratismonat-Kontingent bleibt dabei bis zum Ende der Laufzeit vollständig erhalten.

Fazit

Für Auszubildende und Studierende ist die Aktion eine hervorragende Gelegenheit, ein KI-Kauf-Abo der Spitzenklasse ohne finanzielles Risiko auf Herz und Nieren im Alltag zu testen.

Zur Aktionsseite: Google One AI Student Angebot

Der Beitrag 1 Jahr Gemini Plus gratis: Google Aktion für Studenten & Azubis erschien zuerst auf Ivan Ivanov.

cd /opt/paperless

docker compose stop

# Datenbank (Beispiel PostgreSQL)
docker compose exec -T db pg_dump -U paperless paperless > /opt/backup/paperless-db-$(date +%F).sql

# Volumes sichern
sudo tar -czf /opt/backup/paperless-data-$(date +%F).tar.gz ./data
sudo tar -czf /opt/backup/paperless-media-$(date +%F).tar.gz ./media

# Compose-Files sichern
cp docker-compose.yml /opt/backup/docker-compose.yml.bak
cp docker-compose.env /opt/backup/docker-compose.env.bak

docker compose run --rm webserver document_exporter ../export

openssl rand -base64 64

PAPERLESS_SECRET_KEY: "<generierter-wert>"

# v2 (PostgreSQL wurde aus PAPERLESS_DBHOST abgeleitet)
PAPERLESS_DBHOST: postgres

# v3 (Engine muss explizit gesetzt sein)
PAPERLESS_DBENGINE: postgresql
PAPERLESS_DBHOST: postgres

PAPERLESS_DB_OPTIONS: "sslmode=require,pool.max_size=20"

services:
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:2.20.15

services:
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:3.0.4

docker compose pull
docker compose up -d

docker compose logs -f webserver

docker compose down

docker compose up -d

Der Beitrag Paperless-ngx Docker Upgrade: von 2.20.15 auf 3.0.4 erschien zuerst auf Ivan Ivanov.

Debian 12 Bookworm auf 13 Trixie upgraden, direkt im LXC Container auf Proxmox. Fertiges Script zum Copy & Paste, plus Backup und Verifikation.

Vorher: Snapshot

Vor jedem Major-Upgrade einen Snapshot des Containers erstellen. Einzige einfache Rückfallebene bei Problemen.

pct snapshot <CTID> pre-debian13-upgrade

Das Upgrade-Script

Im Container als root ausführen:

cat <<EOF >/etc/apt/sources.list
deb http://ftp.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian trixie-backports main contrib non-free non-free-firmware
EOF

apt-get update
DEBIAN_FRONTEND=noninteractive apt-get -o Dpkg::Options::="--force-confold" dist-upgrade -y

# Disable services that break in LXC / containers (harmless if not present)
systemctl disable --now systemd-networkd-wait-online.service || true
systemctl disable --now systemd-networkd.service || true
systemctl disable --now ifupdown-wait-online || true

# Install ifupdown2 (better networking stack for LXC/VMs)
apt-get install -y ifupdown2

# Cleanup
apt-get autoremove --purge -y
apt-get clean

reboot

Was das Script macht

• Sources.list: ersetzt Bookworm-Quellen durch Trixie-Quellen, inklusive Security und Backports.
• dist-upgrade: zieht alle Pakete auf Trixie, –force-confold behält bestehende Config-Dateien bei Konflikten.
• Service-Disables: systemd-networkd-wait-online, systemd-networkd und ifupdown-wait-online können im LXC-Kontext beim Boot hängen bleiben, da sie auf Netzwerk-Hardware warten, die im Container nicht existiert. Deaktivieren verhindert das. || true sorgt dafür, dass das Script nicht abbricht, falls ein Dienst gar nicht installiert ist.
• ifupdown2: modernerer Networking-Stack, funktioniert zuverlässiger in LXC/VM-Umgebungen als das klassische ifupdown.
• Cleanup: entfernt nicht mehr benötigte Pakete und den apt-Cache.
• Reboot: notwendig, damit Kernel-Userspace-Tools, systemd und Netzwerkstack sauber auf Trixie laufen.

Danach: Verifikation

cat /etc/debian_version
lsb_release -a
apt list --upgradable
ip a
systemctl --failed

• debian_version sollte 13.x zeigen.
• apt list –upgradable sollte leer sein.
• ip a prüft, ob die Netzwerkschnittstelle nach dem Reboot korrekt hochgekommen ist.
• systemctl –failed zeigt fehlgeschlagene Dienste nach dem Upgrade.

Bekannte Stolperfallen

• Container-Config auf Proxmox-Host prüfen: sehr alte LXC-Templates können mit Trixie inkompatible Cgroup- oder AppArmor-Profile mitbringen.
• Bei gepinnten Paket-Repos (Docker, PostgreSQL, etc.) müssen deren eigene sources.list-Einträge separat auf trixie umgestellt werden, das Script deckt nur die Debian-Basisquellen ab.
• Nach dem Upgrade Dienste einzeln prüfen, die auf spezifische Paketversionen angewiesen sind (z. B. PHP, Python, Datenbanken).

Rollback

Bei Problemen: Container stoppen, Snapshot aus dem ersten Schritt zurückspielen.

pct rollback <CTID> pre-debian13-upgrade

Der Beitrag Debian 12 auf 13 Upgrade im Proxmox LXC Container erschien zuerst auf Ivan Ivanov.

Paperless-ngx 3.0 bringt Breaking Changes. Diese Anleitung zeigt das Bare-Metal-Upgrade auf einer Debian-VM unter Proxmox, Schritt für Schritt.

Voraussetzung: Ausgangsversion muss 2.20.15 sein. Nur von dort aus ist der Sprung auf 3.0 offiziell unterstützt. Ältere Versionen zuerst auf 2.20.15 bringen.

Was sich in 3.0 ändert

• Suchindex wechselt von Whoosh zu Tantivy (Rust). Volltextindex muss neu aufgebaut werden.
• PAPERLESS_SECRET_KEY ist jetzt Pflicht.
• PAPERLESS_DBENGINE ist bei PostgreSQL/MariaDB jetzt Pflicht (vorher aus PAPERLESS_DBHOST abgeleitet).
• Diverse SSL-/Timeout-/Pooling-Variablen der DB entfallen zugunsten von PAPERLESS_DB_OPTIONS.
• API-Version 1 fällt weg.
• Dokument-Prüfsummen wechseln auf SHA-256.
• Consumer-/OCR-Variablen teils umbenannt, OCR_MODE=skip-Verhalten ändert sich.
• Datenbankmigrationen sind nicht rückwärtskompatibel. Ohne Backup kein Rollback.

Schritt 1: Snapshot der Proxmox-VM

Vor allem anderen: VM-Snapshot in Proxmox erstellen. Das ist der schnellste Rollback-Weg, unabhängig vom Applikations-Backup. Backup wichtig! Es kann immer was schief laufen!

qm snapshot <VMID> pre-paperless-3-0-4

Schritt 2: Anwendungs-Backup

Zusätzlich zum Snapshot ein Paperless-eigenes Backup, da die DB-Migration nicht reversibel ist.

sudo systemctl stop paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue

# Datenbank (Beispiel PostgreSQL)
sudo -u postgres pg_dump paperless > /opt/backup/paperless-db-$(date +%F).sql

# Daten- und Medienverzeichnisse
sudo tar -czf /opt/backup/paperless-media-$(date +%F).tar.gz /opt/paperless/media
sudo tar -czf /opt/backup/paperless-data-$(date +%F).tar.gz /opt/paperless/data

# Konfiguration
sudo cp /opt/paperless/paperless.conf /opt/backup/paperless.conf.bak

Bei SQLite genügt eine Kopie der .sqlite3-Datei aus dem Datenverzeichnis.

Schritt 3: Version prüfen

cd /opt/paperless
sudo -Hu paperless git describe --tags

Muss v2.20.15 zeigen. Falls nicht: erst dorthin updaten, dann weiter.

Schritt 4: Secret Key sichern/setzen

Falls bisher kein PAPERLESS_SECRET_KEY gesetzt war, lief 2.x mit einem eingebauten Default-Key. Für 3.0 wird ein expliziter Key Pflicht.

python3 -c "import secrets; print(secrets.token_urlsafe(64))"

Wert in paperless.conf eintragen:

PAPERLESS_SECRET_KEY=<generierter-wert>

Wichtig: Wird ein neuer, zufälliger Key gesetzt statt des alten Default-Keys, werden bestehende Sessions und API-Tokens ungültig. Nutzer müssen sich neu anmelden.

Schritt 5: Datenbank-Engine explizit setzen

Nur bei PostgreSQL oder MariaDB nötig, nicht bei SQLite.

PAPERLESS_DBENGINE=postgresql
PAPERLESS_DBHOST=postgres

Zulässige Werte: postgresql oder mariadb. Bisherige einzelne SSL-/Timeout-/Pooling-Variablen durch PAPERLESS_DB_OPTIONS ersetzen, falls verwendet, z. B.:

PAPERLESS_DB_OPTIONS=sslmode=require,pool.max_size=20

Alte Variablen funktionieren übergangsweise weiter, loggen aber eine Deprecation-Warnung beim Start.

Schritt 6: Systemabhängigkeiten aktualisieren

sudo apt update
sudo apt install --only-upgrade python3 python3-pip python3-dev imagemagick fonts-liberation \
  gnupg libpq-dev default-libmysqlclient-dev pkg-config libmagic-dev mime-support \
  libzbar0 poppler-utils unpaper ghostscript icc-profiles-free qpdf liblept5 \
  libxml2 pngquant zlib1g tesseract-ocr

Ergänzend benötigte OCR-Sprachpakete (tesseract-ocr-deu etc.) prüfen, falls sich Sprachvorgaben geändert haben.

Schritt 7: Dienste stoppen

Falls Schritt 2 nicht schon erledigt:

sudo systemctl stop paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue

Schritt 8: Quellcode auf 3.0.4 bringen

cd /opt/paperless
sudo -Hu paperless git fetch --all --tags
sudo -Hu paperless git checkout tags/v3.0.4

Schritt 9: Python-Abhängigkeiten aktualisieren

Venv aktivieren und Requirements neu installieren:

sudo -Hu paperless bash -c '
  source /opt/paperless/venv/bin/activate
  pip install --upgrade pip
  pip install -r requirements.txt
'

Danach die installierten Pakete gegen die neue requirements.txt abgleichen und nicht mehr benötigte Pakete entfernen, um Konflikte zu vermeiden.

Schritt 10: Datenbankmigration

cd /opt/paperless/src
sudo -Hu paperless ../venv/bin/python3 manage.py migrate

Schritt 11: Statische Dateien und Suchindex

sudo -Hu paperless ../venv/bin/python3 manage.py collectstatic --clear --no-input
sudo -Hu paperless ../venv/bin/python3 manage.py document_index reindex --if-needed

Der --if-needed-Flag prüft Schema-Version und Sprach-Sentinels und baut den Tantivy-Index nur neu, wenn nötig. Bei größeren Archiven (mehrere zehntausend Dokumente) dauert das spürbar; Fortschritt im Log beobachten.

Schritt 12: Dienste starten

sudo systemctl start paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue
sudo systemctl status paperless-webserver

Schritt 13: Verifikation

• Version in der Weboberfläche prüfen (Systemstatus zeigt 3.0.4).
• Volltextsuche testen, auch nach Umlauten und mehreren Suchbegriffen (Tantivy verknüpft Begriffe standardmäßig mit OR statt AND wie zuvor Whoosh).
• Ein Testdokument einscannen/konsumieren lassen, OCR-Ergebnis prüfen.
• Download und Vorschau eines bestehenden Dokuments prüfen.
• Login/API-Token testen, falls der Secret Key neu gesetzt wurde.
• Log auf Fehler prüfen: journalctl -u paperless-webserver -n 200.

Rollback

Bei Problemen: Dienste stoppen, VM-Snapshot aus Schritt 1 zurückspielen. Alternativ Git-Checkout auf v2.20.15, DB-Dump aus Schritt 2 einspielen, altes paperless.conf zurückkopieren, Venv-Requirements der 2.20.15 neu installieren.

Bekannte Stolperfallen

• Fehlender PAPERLESS_SECRET_KEY bricht den Start ab.
• PAPERLESS_DBENGINE vergessen bei PostgreSQL/MariaDB führt zu Verbindungsfehlern.
• Veraltete Syntax in globalen Dateinamensvorlagen kann nach dem Upgrade Fehler werfen.
• Zusätzliche, nicht mehr benötigte Container/Prozesse aus älteren Setups können mit dem neuen Consumer kollidieren.

Der Beitrag Paperless-ngx Upgrade: von 2.20.15 auf 3.0.4 (Debian-VM auf Proxmox) erschien zuerst auf Ivan Ivanov.

Direkt im Anschluss an das große v2.1.0-Release hat das Entwicklerteam von PatchMon mit den Versionen v2.1.1, v2.1.2 und v2.1.3 drei schnelle Bugfix-Updates veröffentlicht. Während das Hauptrelease v2.1.0 massive Architektur- und Performance-Änderungen mit sich brachte, kümmern sich die Point-Releases um die Beseitigung von Unschärfen bei Single Sign-On (SSO), Benachrichtigungen und der Compliance-Infrastruktur.

Die beste Nachricht für Betreiber: Bei allen drei Versionen handelt es sich um reine In-Place-Updates. Es sind keine Änderungen an der docker-compose.yml und keine manuellen Updates der Agents erforderlich.

Die zentralen Verbesserungen in den Updates

1. SSO-Stabilisierung für ADFS und Microsoft Entra ID

Beim OIDC-basierten Single Sign-On kam es bei spezifischen Anbietern zu Login-Abbrüchen:

• Microsoft ADFS: ADFS übermittelt Einzelwerte in Claims (wie E-Mails) häufig als JSON-Array. PatchMon akzeptierte bisher nur Strings und brach den Login ab. Dies wurde korrigiert.
• Microsoft Entra ID (Azure AD): Da Entra ID standardmäßig keinen email_verified-Claim mitsendet, schlug die Auto-Erstellung von Accounts fehl. PatchMon wertet nun das Microsoft-Signal xms_edov (Email Domain Owner Verified) aus, was das Setup ohne Sicherheitskompromisse ermöglicht.

2. Webhooks für Mattermost & Rocket.Chat

Webhooks an Plattformen wie Mattermost oder Rocket.Chat quittierte der Server bisher mit einem HTTP 400 Error. PatchMon erkennt diese Endpunkte ab v2.1.3 automatisch anhand des /hooks/-Pfads in der URL und passt das Payload-Format an. Generische Webhooks wurden zudem um ein Top-Level-text-Feld ergänzt, um out-of-the-box mit Slack-kompatiblen Ingest-Servern zu harmonieren.

3. Compliance-Fixes für Proxmox LXC

Bei Instanzen außerhalb des offiziellen Docker-Containers (insbesondere bei der Nutzung des populären Proxmox LXC-Installationsskripts) meldete die Plattform fälschlicherweise leere Verzeichnisse für Compliance-Regelwerke und antwortete mit einem HTTP 503. Ab v2.1.3 werden die Versionsdaten direkt aus den Datastreams gelesen, sodass die Auswertung auf LXC-Containern wieder reibungslos funktioniert.

4. Beseitigung des „Stale“-Status bei Laptops

Clients, die in den Energiesparmodus versetzt wurden (z. B. Notebooks im Feierabend), wurden vom Server nach dem Aufwachen tagelang als inaktiv/veraltet („stale“) geführt. Der Server prüft nun beim Reconnect des Agents, ob das Update-Intervall überschritten wurde, und fordert im Bedarfsfall sofort einen frischen Statusbericht an.

5. Wiederherstellung der Supply-Chain-Attestierung

Aufgrund eines Fehlers im Build-Prozess wurden die Releases v2.1.0, v2.1.1 und v2.1.2 ohne SHA256-Prüfsummen, SBOMs (Software Bill of Materials) und Provenance-Attestierungen ausgeliefert. Mit Version v2.1.3 sind sämtliche Signatur- und Lieferketten-Sicherheitsdateien wieder regulär in den GitHub-Downloads enthalten.

Fazit & Update-Empfehlung

Die Point-Releases v2.1.1 bis v2.1.3 unterstreichen das hohe Tempo, mit dem das PatchMon-Projekt Kinderkrankheiten nach großen Versionssprüngen behebt. Allen Betreibern von v2.1.0 wird ein zügiges Update auf v2.1.3 empfohlen, um von den SSO- und Alerting-Fixes zu profitieren.

Offizielle Release-Übersicht: GitHub PatchMon Releases

Der Beitrag PatchMon v2.1.1 – v2.1.3: Fixes für SSO, Webhooks & Compliance erschien zuerst auf Ivan Ivanov.

Das Entwicklerteam hinter dem Open-Source-Patch-Management-Tool PatchMon hat die Version v2.1.0 freigegeben. Das Release legt den Fokus primär auf Skalierbarkeit, Zuverlässigkeit bei großen Serverflotten (1.000+ Hosts) und eine grundlegende Überarbeitung der Agent-Kommunikation sowie der Sicherheitsarchitektur.

Achtung beim Upgrade: Manuelle Anpassung der docker-compose.yml

Da PatchMon die eigene docker-compose.yml nicht automatisch überschreibt, müssen Betreiber vor dem Ausführen von docker compose pull && docker compose up -d drei Zeilen manuell anpassen:

1. Server-Port-Mapping: - "${PORT:-3000}:${PORT:-3000}" (bisher: "3000:3000")

2. Server-Hostname: hostname: patchmon-server (neu hinzufügen)

3. Guacd-Image-Tag: image: guacamole/guacd:1.6.0 (bisher: :latest)

Hinweis zur Datenbank-Migration: Beim ersten Start nach dem Update führen große Host-Flotten Index-Rebuilds durch. Auf langsamen Datenträgern kann der Bootvorgang einige Minuten dauern, in denen PatchMon keine Anfragen entgegennimmt.

Die wichtigsten Neuerungen in PatchMon v2.1.0

1. Extrem reduzierte Network-Payloads (2 MB ➔ 1 KB)

Bisher übermittelten Agents bei jedem Check-in den kompletten Inventarbestand. Ab v2.1.0 senden aktualisierte Agents nur noch deltabasierte Änderungen. Der Datenverkehr pro Routine-Check-in sinkt dadurch von 2 MB auf ca. 1 KB. Zur Nachverfolgung ersetzt die neue Agent Activity Timeline die alten Tabs für Paketberichte und Warteschlangen.

2. Präzisere Host-Zustände und Live-Uptime

Das Dashboard trennt den Systemstatus nun in vier eindeutige Indikatoren:

• Connection: Verbindung zum Server (reagiert nun innerhalb von Sekunden via WSS).

• Reporting: Frische der übermittelten Daten.

• Reboot Pending: Ausstehender Systemneustart.

• Updates: Ausstehende Sicherheitspatches oder normale Updates.

Zudem wurde der Zustand Awaiting Data eingeführt: Hosts ohne Paketdaten verfälschen nicht mehr die Kategorie „Up to date“.

3. Zuverlässige Patch-Ausführung (Keine Hänger mehr)

Stalled Patch-Runs gehören der Vergangenheit an. Über den neuen Umgebungsparameter PATCH_RUN_STALL_TIMEOUT_MIN (Standard: 30 Minuten) werden blockierte Updates automatisch beendet. Der Button Stop Run bricht den Prozess nun auch dann garantiert ab, wenn der Agent offline ist oder blockierte Child-Prozesse im Hintergrund hängen.

4. Umfassende Fixes für Windows & Linux-Paketmanager

• Windows Registry-Fix: Ein einziges Null-Byte-Zeichen in der Registrierung (oft erzeugt durch Drittanbieter-Agents wie MeshCentral) führte bisher dazu, dass der gesamte Bericht verworfen wurde. Dies wurde gefixt.

• Linux/BSD-Anpassungen:

  • RHEL/Fedora/Rocky: Korrekte Handling von DNF-Bannern, Erfassung von RLSA-Sicherheitsmeldungen.

  • Debian/Ubuntu: Volle Unterstützung für deb822-Sources und korrekte Handhabung von Kernel-Meta-Paketen.

  • Arch/Manjaro: Funktionsfähig ohne installiertes pacman-contrib.

  • LXC-Container: Uptime zeigt nun die echte Container-Laufzeit anstelle der Laufzeit des Proxmox-Hosts.

5. Sicherheits-Härtung (Security & SSO)

• IP-Spoofing-Schutz: Über TRUSTED_PROXY_RANGES lässt sich festlegen, welchen Upstream-Reverse-Proxies (z. B. Cloudflare hinter Nginx Proxy Manager) vertraut wird, um echte Client-IPs für Rate-Limiting und Lockouts auszuwerten.

• Session-Binding & Revocation: Ausgestellte Tokens sind strikt an Sitzungen gebunden. Das Abmelden, Ändern von Passwörtern oder Deaktivieren von Konten greift ab sofort unverzüglich.

• E-Mail / SMTP: Explizite Auswahlmöglichkeiten für TLS (STARTTLS, SSL/TLS, None, Auto) verhindern das ungesicherte Versenden von Benachrichtigungen über fehlerhafte Relays.

Neue Umgebungsvariablen (.env)

Fazit

Mit dem Update auf v2.1.0 beweist das PatchMon-Team rund um Lead-Entwickler Iby, dass die Software reif für den anspruchsvollen Enterprise-Einsatz ist. Wer eine performante On-Premise-Alternative zu kommerziellen Patch-Management-Lösungen sucht, sollte das Update zeitnah einspielen.

Offizielle Release-Notes & Discussion: GitHub PatchMon Tag v2.1.0

Der Beitrag PatchMon v2.1.0: Neues Release bringt massives Performance-Tuning erschien zuerst auf Ivan Ivanov.

Das Sicherheitsteam von Qualys hat eine weitere gravierende Schwachstelle in einer zentralen Komponente gängiger Linux-Distributionen analysiert. Unter der Kennung CVE-2026-8933 führt ein Logikfehler in snap-confine dem Unterbau des Paketmanagers Snap zu einer lokalen Rechteausweitung (Local Privilege Escalation, LPE). Da Snap auf modernen Ubuntu-Systemen standardmäßig installiert ist, ist das Schadpotenzial für Multi-User-Systeme und Cloud-Instanzen hoch.

Wie die Schwachstelle in snap-confine funktioniert

snap-confine ist eine hochprivilegierte SUID-Binärdatei (root), die beim Start eines Snap-Pakets aufgerufen wird. Seine Aufgabe ist es, eine isolierte Sicherheits-Sandbox (unter Nutzung von AppArmor, Cgroups und Mount-Namespaces) aufzubauen.

Die Forschenden von Qualys entdeckten eine Schwachstelle bei der Abfolge, in der snap-confine Dateisystem-Pfade prüft und Mounts innerhalb des temporären Namespaces durchführt. Durch gezieltes Timing und das Platzieren präparierter symbolischer Links (Symlinks) im Benutzerverzeichnis kann ein lokaler Angreifer die Sicherheitsprüfungen umgehen. Dies ermöglicht das Einschleusen und Ausführen von eigenem Code im Kontext des Root-Benutzers.

Wer ist von CVE-2026-8933 betroffen?

• Ubuntu Desktop & Server: Alle unterstützten Releases, bei denen das Paket snapd nicht auf dem neuesten Stand ist.

• Derivate: Linux-Distributionen, die snapd aus den offiziellen Repositories verwenden und SUID-Rechte für snap-confine vergeben.

Empfohlene Maßnahmen für Administratoren

1. Schnelles Update über den Paketmanager

Canonical hat das Problem analysiert und korrigierte Pakete für alle unterstützen Ubuntu-Versionen veröffentlicht. Das Update kann direkt über apt eingespielt werden:

sudo apt update
sudo apt install --only-upgrade snapd

Anschließend lässt sich die installierte Version überprüfen, um sicherzustellen, dass die geflickte Variante von snapd aktiv ist.

2. Überwachung lokaler Benutzeraktivitäten

Da es sich um eine LPE-Lücke handelt, ist ein bereits vorhandener lokaler Systemzugriff Voraussetzung. Administratoren sollten Logfiles (wie /var/log/auth.log oder Auditd-Protokolle) auf ungewöhnliche Aufrufe von snap-confine oder verdächtige Manipulationen im Verzeichnis /tmp prüfen.

Bedeutung für die Praxis

Schwachstellen in SUID-Helferprogrammen wie snap-confine zeigen erneut, wie komplex das Zusammenspiel von Sandbox-Infrastrukturen und Linux-Berechtigungen ist. Für IT-Abteilungen unterstreicht der Vorfall die Notwendigkeit von automatisierten Patch-Management-Prozessen auf allen Ebenen der Server-Infrastruktur.

Quelle: Qualys Threat Research Blog – CVE-2026-8933

Der Beitrag CVE-2026-8933: Root-Lücke in Ubuntu durch snap-confine erschien zuerst auf Ivan Ivanov.

Der Open-Source-Cloud-Spezialist Nextcloud steht nach einem Sicherheitsvorfall in der Kritik. Obwohl der eigentliche Cyberangriff auf die Infrastruktur des Unternehmens glimpflich ausging und nach aktuellem Kenntnisstand weder Kundendaten noch der Kern-Quellcode der Software manipuliert wurden, sorgt das Krisenmanagement des Anbieters für erhebliche Unruhe in der IT-Community.

Zugriff auf private Entwickler-Infrastruktur

Der Angreifer nutzte kompromittierte Zugangsdaten, um Zugriff auf ein privates, internes Entwicklungs-Repository von Nextcloud zu erlangen. Das Unternehmen leitete nach dem Bemerken des unbefugten Zugriffs umgehend technische Gegenmaßnahmen ein: Die betroffenen Zugänge wurden gesperrt, Passwörter zurückgesetzt und die Server-Infrastruktur eingehend forensisch untersucht.

Die wichtigste technische Entwarnung für Administratoren und Betreiber von Nextcloud-Instanzen:

• Der öffentliche Quellcode von Nextcloud blieb unberührt.

• Es wurden keine Backdoors oder schädliche Modifikationen in bestehende Releases eingeschleust.

• Ein Zugriff auf Daten von Endnutzern oder Cloud-Kunden fand nicht statt.

Das PR-Desaster nach dem Angriff

Während das technische Sicherheitsteam adäquat reagierte, leistete sich die PR-Abteilung von Nextcloud schwere Schnitzer. Auf erste Anfragen von IT-Sicherheitsforschern und Fachmedien wie heise online reagierte das Unternehmen ausweichend und spielte das Ausmaß des Zugriffs herunter. In ersten Stellungnahmen war die Rede von bloßen „Auffälligkeiten“ oder internen Tests.

Erst als unwiderlegbare Belege über den erfolgten Datenabfluss aus dem privaten Repository vorlagen, korrigierte Nextcloud seine Berichterstattung schrittweise und räumte den Vorfall transparent ein.

Fazit: Transparenz als Pflicht in der Open-Source-Welt

Der Vorfall unterstreicht eine zentrale Lektion des modernen IT-Sicherheitsmanagements: Ein funktionierender Incident-Response-Plan muss zwingend eine ehrliche und direkte Krisenkommunikation beinhalten. Insbesondere im Open-Source-Sektor, wo das Vertrauen der Anwender und Administratoren das Fundament des gesamten Ökosystems bildet, führt Taktieren bei Sicherheitsvorfällen zu unnötigem Reputationsschaden.

Quelle: https://help.nextcloud.com/t/nextcloud-com-offline/247123/18

Der Beitrag Cyberangriff auf Nextcloud: Technische Details & PR-Kritik erschien zuerst auf Ivan Ivanov.

Für Nutzer mit extremen Anforderungen an die Privatsphäre und IT-Sicherheit ist Tails (The Amnesic Incognito Live System) seit Jahren der Goldstandard. Das System hinterlässt keine Spuren auf dem Host-Computer und leitet jeglichen Datenverkehr zwingend über das Tor-Netzwerk. Das aktuelle Release Tails 7.10 bringt zwei tiefgreifende funktionale Änderungen mit sich, die den Schutz vor physischen und digitalen Angriffen noch einmal drastisch erhöhen.

Der neue Shutdown-Prozess: Amnesia in Perfektion

Die wichtigste Eigenschaft von Tails ist seine „Amnesie“. Sobald das System heruntergefahren wird – oder der USB-Stick im Notfall einfach aus dem Rechner gezogen wird –, löscht Tails den gesamten Arbeitsspeicher (RAM). Dadurch wird sichergestellt, dass Angreifer keine kryptografischen Schlüssel oder Fragmente von Dokumenten durch sogenannte Cold Boot Attacks rekonstruieren können.

Mit Version 7.10 wurde dieser Shutdown-Prozess grundlegend neu geschrieben. Das System geht nun wesentlich aggressiver und schneller beim Überschreiben des Arbeitsspeichers vor. Zudem wurden Kompatibilitätsprobleme mit modernen UEFI-Systemen und spezifischen RAM-Architekturen behoben, bei denen der Löschvorgang in der Vergangenheit ins Stocken geraten konnte. Ein schnellerer Shutdown bedeutet in kritischen Situationen schlichtweg mehr physische Sicherheit für den Anwender.

Neuer Videoplayer schützt vor Media-Exploits

Eine oft unterschätzte Gefahr für die Anonymität stellen präparierte Mediendateien (wie MP4- oder MKV-Videos) dar. Angreifer verstecken regelmäßig Schadcode in Videos, der Pufferüberläufe in schlecht isolierten Playern provoziert.

Tails 7.10 reagiert auf diese Bedrohungslage mit der Integration eines neuen Videoplayers. Der Fokus liegt hierbei auf einer strengen Isolierung (Sandboxing) und der Reduzierung der Angriffsfläche. Der neue Player kann zwar problemlos offline Videos abspielen, wird aber durch strikte Systemrichtlinien daran gehindert, Netzwerkverbindungen aufzubauen. Selbst wenn ein Video einen Zero-Day-Exploit enthalten sollte, ist es dem Angreifer dadurch nahezu unmöglich, die echte IP-Adresse des Nutzers nach außen zu funken (IP Leak).

Aktualisierte Kernkomponenten

Neben diesen funktionalen Meilensteinen enthält Tails 7.10 routinemäßige, aber essenzielle Security-Updates. Der integrierte Tor Browser wurde auf die neueste Basis gehoben und auch der E-Mail-Client Thunderbird profitierte von wichtigen Sicherheitspatches.

Fazit: Pflicht-Update für sensible Einsätze

Das Tails 7.10 Update zeigt, dass die Entwickler nicht nur Software aktualisieren, sondern die konzeptionelle Sicherheit des Live-Systems konsequent weiterdenken. Wer auf Anonymität angewiesen ist, sollte seinen USB-Stick schnellstmöglich über die integrierte Update-Funktion auf den neuesten Stand bringen.

Download: https://tails.net/install/download/index.en.html

Der Beitrag Tails 7.10: Anonymes Linux mit neuem Shutdown und Videoplayer erschien zuerst auf Ivan Ivanov.