Seit Ende 2023 in der Entwicklung, liegt das Putzprogramm BleachBit endlich in der Version 5.0.0 vor.

Seit Ende 2023 in der Entwicklung, liegt das Putzprogramm BleachBit endlich in der Version 5.0.0 vor.

Am 31. Mai 2025 endet der reguläre Support für Ubuntu 20.04 LTS. Unternehmen, die weiterhin auf diese Version setzen, sollten dringend handeln. Mit Expanded Security Maintenance (ESM) erhalten Ubuntu Instnazen auch nach dem offiziellen Ende wichtige Sicherheitsupdates. So bleiben Server und Anwendungen zuverlässig geschützt. Doch reine Sicherheitsupdates decken nicht alle Risiken ab. Wenn ein Paket […]

Der Beitrag Ubuntu 20.04 LTS: Support endet bald – jetzt besteht Handlungsbedarf erschien zuerst auf fosstopia.

In einem längeren Essay  skizziert Anthropic-Mitgründer und CEO Dario Amodei die Fortschritte bei der Interpretierbarkeit von KI.

In diesem Text dokumentiere ich, wie ein Tang-Server auf Debian installiert werden kann und wie man den Zugriff auf diesen auf eine bestimmte IP-Adresse einschränkt.

Wer mit dem Begriff Tang-Server noch nichts anfangen kann und dies ändern möchte, dem empfehle ich: Network Bound Disk Encryption im Überblick.

Installation und Konfiguration

Installiert wird der Tang-Server mit folgendem Befehl:

sudo apt install tang

Standardmäßig lauscht der Tang-Server auf Port 80. Da dieser Port auf meinem Server bereits belegt ist, erstelle ich mit dem Befehl sudo systemctl edit tangd.socket eine Override-Datei mit folgendem Inhalt:

:~# cat /etc/systemd/system/tangd.socket.d/override.conf 
[Socket]
ListenStream=
ListenStream=7500

Mit den folgenden Kommandos wird die geänderte Konfiguration eingelesen, die Konfiguration kontrolliert und der Dienst gestartet:

:~# systemctl daemon-reload
:~# systemctl show tangd.socket -p Listen
Listen=[::]:7500 (Stream)
:~# systemctl enable tangd.socket --now

Zugriff auf eine IP-Adresse beschränken

Ich möchte den Zugriff auf den Tang-Server auf eine IP-Adresse beschränken, nämlich auf die IP-Adresse des einen Clevis-Clients, der diesen Server verwenden wird. Dazu führe ich die folgenden Schritte durch.

:~# iptables -A INPUT -p tcp -s 203.0.113.1 --dport 7500 -j ACCEPT
:~# iptables -A INPUT -p tcp --dport 7500 -j DROP
:~# mkdir /etc/iptables
:~# iptables-save >/etc/iptables/rules.v4

Damit die in der Datei /etc/iptables/rules.v4 gespeicherten Regeln nach einem Neustart wieder geladen werden, erstelle ich ein Systemd-Service:

:~# cat /etc/systemd/system/load-iptables.service 
[Unit]
Description=Load iptables rules
Before=network.target

[Service]
Type=oneshot
ExecStart=/sbin/iptables-restore < /etc/iptables/rules.v4
#ExecStart=/sbin/ip6tables-restore < /etc/iptables/rules.v6

[Install]
WantedBy=multi-user.target

:~# systemctl daemon-reload
root@vmd54920:~# systemctl enable load-iptables.service
Created symlink /etc/systemd/system/multi-user.target.wants/load-iptables.service → /etc/systemd/system/load-iptables.service.

Test

Um zu überprüfen, ob der Tang-Server wie gewünscht arbeitet, setze ich auf meinem Clevis-Client den folgenden Befehl ab. Dabei muss nach der Ver- und Entschlüsselung der gleiche Text ‚test‘ ausgegeben werden.

~]$ echo test | clevis encrypt tang '{"url":"tang1.example.com:7500"}' -y | clevis decrypt
test

Fertig.

In den letzten Tagen, musste ich hier im Blog leider beobachten, wie sich ein Spammer an den wachsamen Augen der Antispam Bee vorbeigeschlichen hat und einzelne SPAM-Kommentare unter einem älteren Artikel aus dem Jahr 2015 hinterlassen hat.

Was mit einzelnen Kommentaren begann, erweiterte sich dann zu einer kleinen SPAM-Attacke, die in der Nacht vom 10.04.2025 weitere 129 SPAM-Kommentare unter den Artikel spülte. Dabei wurden 30 unterschiedliche IP-Adressen verwendet, die alle in der Russischen Föderation registriert sind.

Nach einer Sichtung weiterer blockierter SPAM-Kommentare stelle ich fest, dass der überwiegende Teil des SPAMs aus der Russischen Föderation und China kommt. IP-Adressen aus diesen Regionen werden auch regelmäßig durch fail2ban blockiert.

Da der letzte Spammer durch den Wechsel der IP-Adressen, bestehende Mechanismen jedoch unterlaufen konnte, baue ich nun eine weitere Verteidigungslinie auf. Zukünftig werden Zugriffe von IP-Adressen aus der Russischen Föderation und China von Iptables blockiert.

Update 2025-04-10T18:40+02: Ich habe die Maßnahme vorerst wieder ausgesetzt und prüfe, ob angepasste Kommentar-Einstellungen ausreichen, um dem Kommentar-SPAM zu begegnen. Ich lasse die folgende Lösung als Dokumentation online. Evtl. muss ich doch wieder darauf zurückfallen.

Hier ist eine iptables-Lösung zum Blockieren von IP-Adressen aus Russland und China:

Vorbereitung: GeoIP-Modul installieren

~# apt install xtables-addons-common geoip-bin libtext-csv-xs-perl
~# /usr/libexec/xtables-addons/xt_geoip_dl
~# /usr/libexec/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip RU CN

Iptables-Regel erstellen und für persistenz speichern

~# iptables -A INPUT -m geoip --src-cc RU,CN -j DROP
~# iptables-save > /etc/iptables/rules.v4

Automatische Updates der Geo-IP-Daten einrichten

~# cat /usr/local/bin/geoip_update.sh 
# /usr/local/bin/geoip_update.sh
#!/bin/bash
wget -O /tmp/GeoIPCountryCSV.zip https://dl.miyuru.lk/geoip/maxmind/country/maxmind4.dat.zip
unzip -o /tmp/GeoIPCountryCSV.zip -d /usr/share/xt_geoip/
/usr/libexec/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip RU CN
rm /tmp/GeoIPCountryCSV.zip

~# crontab -l
# Cronjob täglich um 3 Uhr
4 3 * * * /usr/local/bin/geoip_update.sh

Test und Logging aktivieren

# Zuerst in der Firewall-Chain testen
~# iptables -L -n -v | grep 'DROP.*geoip'

# Logging aktivieren (optional für Debugging)
~# iptables -I INPUT -m geoip --src-cc RU,CN -j LOG --log-prefix "[GEOIP BLOCK]"

Hinweis: Den Vorschlag für obige Lösung habe ich mir von perplexity.ai generieren lassen. Dabei musste ich lediglich den Pfad zu /usr/libexec/xtables-addons korrigieren, welcher fälschlicherweise auf /usr/lib/ zeigte.

Fazit

Das Internet ist kaputt. Die Zeiten in denen die Nutzer respektvoll und umsichtig miteinander umgingen, sind lange vorbei.

Mir ist bewusst, dass auch eine Sperrung von IP-Adressen basierend auf Geolokation keine absolute Sicherheit bietet und man mit dieser groben Maßnahme auch mögliche legitime Zugriffe blockiert. Allerdings prasseln aus diesen Teilen der Welt so viele unerwünschte Zugriffsversuche auf meinen kleinen Virtual Private Server ein, dass ich hier nun einen weiteren Riegel vorschiebe.

Welche Maßnahmen ergreift ihr, um unerwünschte Besucher von euren Servern fernzuhalten? Teilt eure Maßnahmen und Erfahrungen gern in den Kommentaren oder verlinkt dort eure Blog-Artikeln, in denen ihr darüber geschrieben habt.

Die Bibliothek OpenSSL implementiert die Verschlüsselungsprotokolle TLS, DTLS und QUIC.

Die Bibliothek OpenSSL implementiert die Verschlüsselungsprotokolle TLS, DTLS und QUIC.

Git, das heute als der Standard für Versionskontrollsysteme gilt, wurde vor 20 Jahren, am 7. April 2005, von Linus Torvalds mit einem ersten Commit ins Leben gerufen.

Quelle

Sophos X-Ops warnt: Böswillige Mutation des weit verbreiteten nginx-Webservers erleichtert bösartige Adversary-in-the-Middle-Attacken.

Quantencomputer können bestimmte komplexe Aufgaben in einer Geschwindigkeit lösen, die alle herkömmlichen Supercomputer um viele Größenordnungen übertrifft.

Die an Pentester und Sicherheitsexperten gerichtete Distribution Kali Linux frischt die Optik leicht auf, schraubt dezent an den Images für den Raspberry Pi und trägt ungewöhnlicherweise ein „a“…

Die an Pentester und Sicherheitsexperten gerichtete Distribution Kali Linux frischt die Optik leicht auf, schraubt dezent an den Images für den Raspberry Pi und trägt ungewöhnlicherweise ein „a“…

Das neueste Feature-Release Git v2.49.0 ist verfügbar.  460 Nicht-Merge-Commits seit v2.48.0 sind von 89 Personen beigesteuert worden.

Wer Quellcode mit dem Editor Zed bearbeitet, kann jetzt direkt aus der Benutzeroberfläche heraus die Versionsverwaltung Git steuern.

Wer Quellcode mit dem Editor Zed bearbeitet, kann jetzt direkt aus der Benutzeroberfläche heraus die Versionsverwaltung Git steuern.

Das altehrwürdige Startsystem SysVinit kommt immer noch zum Einsatz und wird stetig weiterentwickelt.

Das altehrwürdige Startsystem SysVinit kommt immer noch zum Einsatz und wird stetig weiterentwickelt.

Die Distribution ParrotOS richtet sich mit ihren vorinstallierten Werkzeugen primär an Sicherheitsexperten und Pentester. Die neue Ausgabe aktualisiert zahlreiche Pakete und korrigiert Fehler.

Die Distribution ParrotOS richtet sich mit ihren vorinstallierten Werkzeugen primär an Sicherheitsexperten und Pentester. Die neue Ausgabe aktualisiert zahlreiche Pakete und korrigiert Fehler.

Die EU-Kommission hat einen europäischen Aktionsplan zur Stärkung der Cybersicherheit von Krankenhäusern und Gesundheitsdienstleistern auf den Weg gebracht.

Eine Gruppe von Google-Forschern und Aleksei Gorban haben gravierende Sicherheitslücken im Dateisynchronisationswerkzeug Rsync entdeckt.

Eine Gruppe von Google-Forschern und Aleksei Gorban haben gravierende Sicherheitslücken im Dateisynchronisationswerkzeug Rsync entdeckt.

Das Open-Source-Projekt Git hat Git 2.48 mit Funktionen und Fehlerkorrekturen von über 93 Mitwirkenden veröffentlicht. Das Git-Projekt kann bei diesen Beitragenden 35 neue zählen.

In der letzten Episode des Risikozone-Podcasts habe ich ganz kurz das Thema der verkürzten Hashwerte und auftretenden Kollisionen angesprochen. Jetzt gibt es ein Proof of Concept zu der Thematik.

Worum es geht

Ein kurzer Refresher, worum es in der Thematik überhaupt geht: Als Git entwickelt wurde, musste ein Weg gefunden werden, wie man die Referenzen auf Commits, die Dateien und die Dateibäume realisiert. In vielen Systemen wie z. B. Issue-Trackern werden aufsteigende Indizes verwendet. In einem verteilten System wie Git ist das aus verschiedenen Gründen der Synchronisation nicht so einfach möglich, da sonst Kollisionen, also gleiche IDs für unterschiedliche Objekte entstehen könnten. Eine Alternative wäre UUIDs, da die IDs einen randomisierten Anteil haben und die Wahrscheinlichkeit für Kollisionen gesenkt wird.

Noch besser als UUIDs ist allerdings Content-adressable Storage, bei dem Inhalte einzig durch ihren Inhalt adressiert werden. Das ist so, als würde man den gesamten Inhalt der Datei nochmal in den Dateinamen schreiben. Der Clou dabei ist jedoch, dass der gesamten Dateiinhalt gar nicht in den Dateinamen geschrieben werden muss, um die Datei durch ihren Inhalt identifizierbar zu machen.

Mit kryptographischen Hashfunktionen wie SHA-1 oder SHA-256 existiert ein Mittel, um einen beliebig langen Dateiinhalt zu einem immer gleich langen Wert, dem Hash, umzuwandeln. Dabei sind kryptographische Hashfunktionen so konstruiert, dass die Wahrscheinlichkeit für Kollisionen durch verschiedene Mechanismen stark minimiert wird. Ein SHA-1-Hash für den Dateiinhalt "Hallo Welt" wäre z. B. 28cbbc72d6a52617a7abbfff6756d04bbad0106a. Ein netter Nebeneffekt ist, dass Dateien mit gleichem Inhalt im Content-adressable Storage auch nur einmal abgespeichert werden, wodurch sogar Deduplikation ermöglicht wird.

Git nutzt dieses Verfahren, um die eingechekten Dateien abzuspeichern. Diese Dateien werden dann in Trees zusammengebunden und in Commits mit den jeweiligen Vorgänger-Commits (parents) in einem sog. Merkle-Tree verheiratet.

Commits werden somit auch durch einen SHA-1-Hash identifiziert, der im hexadezimalen Format 40 Zeichen lang ist.

Das Problem

Das Problem bei dem Verfahren liegt jetzt darin, dass dieser Hash üblicherweise noch weiter abgekürzt wird, um ihn benutzerfreundlicher in Oberflächen oder E-Mails darzustellen. Damit wird natürlich die Wahrscheinlichkeit für Kollisionen erhöht.

Habe ich einen Hash 28cbbc72d6a52617a7abbfff6756d04bbad0106a und nutze nur 28cbbc zur Referenz, reicht das in den meisten kleinen Repositories aus, um einen Commit eindeutig zu referenzieren. In großen Repositories mit vielen Dateien und Commits kann es auf einmal passieren, dass ein weiterer Commit 28cbbcc00aa8ef4e80596c16ecfdb4bc92656cd3 auftaucht, sodass 28cbbc nicht mehr eindeutig einen Commit beschreibt.

Um das Risiko zu verringern, sollte die Mindestanzahl der Zeichen für einen abgekürzten Commit erhöht werden.

Das Kernel-Repository

Genau darum geht es in der aktuellen Diskussion. Aktuell nutzen die Linux-Entwickler zur Referenz von Commits in ihren E-Mails 12 Zeichen lange Hashes. Die Diskussion dreht sich um die Frage, ob die Zahl weiter erhöht werden sollte. Linus Torvalds ist bisher dagegen, weil er das Risiko für Kollisionen gering sieht und er die Position vertritt, dass ein Commit immer mit dem Commit Message Title angegeben werden sollte, was ungewollte Kollisionen ausreichend verhindere.

Gestern veröffentlichte Kees Cook einen Blogpost, indem er eine Commit-Kollision mit dem Werkzeug lucky-commit bewusst herbeiführte, um darauf aufmerksam zu machen, dass die Git- und Kernel-Entwicklungstools mit solchen Situationen klarkommen sollten. Es ist unwahrscheinlich, dass solche Kollisionen bei 12 Zeichen versehentlich entstehen, aber ein Angreifer könnte dies ausnutzen.

Dies sollte ein Apell an alle Entwickler sein, deren Tooling auf abgekürzte Commit-Hashes setzt. Schauen wir mal, wie sich das weiterentwickelt.

Ein Kommentar zu SHA-1

Abschließend ein Kommentar noch zu SHA-1. Wie viele von euch wissen, ist SHA-1 selbst nicht mehr vertretbar kollisionssicher. Das bedeutet, es kann passieren, dass auf einmal zwei Dateiinhalte sich doch den gleichen Hash teilen könnten, wenn ein Angreifer es drauf anlegt.

Da dies natürlich Git massiv stören könnte, gibt es schon Bestrebungen, das Verfahren auf SHA-2 zu aktualisieren, wodurch sich die Hashlänge auch vergrößert. Das ist aber gar nicht so einfach, da SHA-1 an vielen Stellen in die Struktur eines Git-Repos hartkodiert wurde.

Hier geht es aber nicht um das unsichere SHA-1. Durch die Abkürzung des Hashes von 40 auf 12 Zeichen wird die Kollisionssicherheit bewusst und massiv zugunsten der Benutzerfreundlichkeit geschwächt. Und das erfordert immer eine regelmäßige Evaluation, welches Niveau noch vertretbar ist.