Normale Ansicht

Received before yesterday

Zugriffe von IP-Adressen aus der Russischen Föderation und China werden blockiert

10. April 2025 um 12:20

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.

Sicherheit von Accounts und Passwörtern: Welche Maßnahmen sollte man ergreifen?

10. April 2025 um 09:00

Viele Menschen unterschätzen, wie viel ihre Zugangsdaten über sie verraten – oder ermöglichen. Wer mit simplen Passwörtern durchs Netz geht, riskiert nicht nur den Zugriff auf E-Mail-Konten, sondern auch auf Bankdaten, private Fotos oder Cloud-Inhalte. Gute Passwortsicherheit ist kein Luxus, sondern digitaler Selbstschutz. Welche Maßnahmen lohnen sich wirklich für deinen Alltag?

Der Beitrag Sicherheit von Accounts und Passwörtern: Welche Maßnahmen sollte man ergreifen? erschien zuerst auf Linux Abos.

Die Online-Sicherheit im neuen Jahr: So bleiben Sie auch 2025 sicher und geschützt

23. Dezember 2024 um 08:30

Mit zunehmender Digitalisierung wächst auch das Risiko von Cyberangriffen. Vom Schutz sensibler Daten über Zwei-Faktor-Authentifizierung bis hin zu sicherem Umgang mit Online-Inhalten – es gibt viele effektive Strategien, um die Online-Sicherheit zu gewährleisten. Wie können moderne Technologien und bewährte Praktiken dazu beitragen, den Alltag im Internet sicherer zu gestalten?

Der Beitrag Die Online-Sicherheit im neuen Jahr: So bleiben Sie auch 2025 sicher und geschützt erschien zuerst auf Linux Abos.

Sicherheit über alles: Windows oder Linux?

10. März 2025 um 07:30

Bei der Wahl des Betriebssystems spielen verschiedene Faktoren eine Rolle, wobei Sicherheit ein entscheidendes Kriterium ist. Während viele Nutzer aus Gewohnheit oder Bequemlichkeit auf Windows setzen, bietet Linux oft ein höheres Sicherheitsniveau. Ist Linux wirklich so viel sicherer als Windows, oder gibt es Schwachstellen, die leicht übersehen werden?

Der Beitrag Sicherheit über alles: Windows oder Linux? erschien zuerst auf Linux Abos.

OpenSSH-Sicherheitslücke RegreSSHion

01. Juli 2024 um 20:16

Dem Forscherteam von Qualys ist es gelungen, eine ältere Sicherheitslücke in OpenSSH, die schon eigentlich längst geschlossen war, erneut auszunutzen. Die neue Lücke wird als CVE-2024-6387 geführt und ist deswegen brisant, weil Sie bei Erfolg dem Angreifer Root-Rechte ohne vorherige Authentifizierung ermöglicht. Die nötigen Bedingungen für ein Ausnutzen der Lücke sind allerdings nicht ganz trivial.

Die gesamte Erläuterung der Sicherheitslücke ist im Bericht von Qualys umfangreich erläutert wollen. Wenn wir es schaffen, werden wir diesen schon Mittwoch im Risikozone-Podcast detaillierter erläutern.

So viel sei gesagt: die Lücke existierte schon mal als CVE-2006-5051, wurde dann gefixt und konnte jetzt (erstmals) ausgenutzt werden, da der eigentlich kritische Teil 2020 wieder versehentlich eingebaut wurde. Der Fehler selber baut darauf, dass syslog() zur Protokollierung asynchron aufgerufen wird, obwohl die Funktion nicht "async-signal-safe" ist. Kann ein Angreifer Timingeigenschaften ausnutzen, wird er in die Lage versetzt, Code einzuschleusen, der in einem privilegierten Teil von OpenSSH ausgeführt wird. Der Zeitaufwand ist allerdings hierfür nicht zu unterschätzen, da das Codefragment nur bei einem Verbindungstimeout aufgerufen wird.

Es ist gemäß des Qualys-Berichtes hervorzuheben:

  • Die OpenSSH-Versionen vor 4.4p1 (2006) sind angreifbar, sofern sie nicht explizit gepatcht wurden.
  • Die OpenSSH-Versionen zwischen 4.4p1 und 8.5p1 (2021) hatten nicht den besagten Code drin.
  • Die OpenSSH-Versionen ab 8.5p1 hatten den Code wieder drin.
  • Mit OpenSSH 9.8p1 wurde die Lücke gepatcht.

Mit anderen Worten: abhängig von eurem System ist die Schwachstelle vorhanden, weswegen ihr in eure Distribution schauen solltet, ob es Updates gibt.

OpenSSH ist nichtsdestotrotz im Hinblick auf seine Rolle und Exposition eines der sichersten Programme der Welt. Die Software ist ein sehr stringent abgesicherter Dienst, der u. a. auf Sandboxing-Mechansimen setzt, um den Umfang der Codesegmente, die als root ausgeführt werden, gering zu halten. Diese Lücke ist eine der seltenen Situationen, in der trotzdem ein Security-Bug vorhanden ist. Dabei ist eine Ausnutzung vergleichsweise aufwändig.

❌