[PROLOG]
IP-Blocklisten sind für jeden von großem Interesse, sobald man die Möglichkeit gesehen hat, diese zu verwenden. Dass man sowas aber nicht aus dem Ärmel schütteln kann, sondern dass man sich ein paar Gedanken machen muss, habe ich erst jüngst erfahren. Daher habe ich spontan diese kleine Anleitung verfasst, die im Wesentlichen aufzeigen soll, dass man ein IP-basiertes Blocklisting nicht „mal eben so“ macht, und dass man hier nicht strikt nach Anleitung gehen kann, sondern diese allenfalls als Leitfaden betrachten darf. Das Verständnis wie sich die jeweilige Blocklist auswirken kann und ob diese überhaupt für den jeweiligen Zweck angemessen ist, muss jeder selbst aufbauen, und das ist wahrlich nicht einfach. Ich möchte im Folgenden mein (!) Basic-Setup darstellen und erläutern, warum ich so gehandelt habe. Ich hoffe damit etwas Verständnis für die Auswirkungen zu schaffen und dass es hier nichts von der Stange gibt.
[SINN UND ZWECK VON IP-BLOCKLISTEN]
Das Internet ist voll von bösen Seiten, Servern und Hackern, da möchte man zurecht vermeiden, dass Geräte im Netzwerk Zugriff darauf bekommen, sei es versehentlich durch Unachtsamkeit oder absichtlich durch z.B. einen Virus. Auch möchte man vermeiden, dass die bösen Buben durch ein Schlupfloch in das heimische LAN gelangen können.
Dafür gibt es IP-Blocklisten, sowohl kostenlose als auch kostenpflichtige, in denen teilweise mehrere Hundertmillionen bösartige IPs gelistet sind. Diese Listen kann man nun verwenden um Firewall-Regeln darauf zu basieren, sodass mit nur einem Firewall-Eintrag alle gelisteten IPs blockiert werden. Je nachdem für welche der vielen Listen man sich entscheidet, wird diese in bestimmten Abständen von wenigen Stunden bis mehreren Tagen automatisch aktualisiert.
[DIE WAHL DER BLOCKLISTEN]
Wie immer ist die Vorarbeit das Schwierigste, also die Überlegung wovor man sich schützen will. In diesem Fall demnach die Frage, welche Blocklisten man anwenden soll, denn es steht wirklich ein Vielzahl an Anbietern mit unterschiedlichen Listen zur Verfügung.
Ganz wichtig: Viel hilft nicht viel! Die Auswahl sollte also sehr sorgfältig getroffen werden, dabei ist auch zu beachten, dass mehrere verwendete Listen nicht allesamt die gleichen Einträge beinhalten, denn jeder Eintrag belastet die Firewall. Auch kann man sich durch falsche Anwendung Probleme einhandeln, sodass man sich z.B. selbst vom Internet aussperrt.
Eine richtig gute Seite zum Informieren ist http://iplists.firehol.org.
Dort sind nicht nur viele Listen beschrieben, sondern es kann auch verglichen werden, welche Liste identische Einträge mit anderen Listen hat, damit man sich nicht unnötig viel Ballast ranholt.
Ein sehr guter Basisschutz für das Heimnetz ist (meiner Meinung und Erfahrung nach) eine Kombination aus den FireHOL-Listen sowie den Spamhaus-Listen. Mit diesen werden wir im Folgenden arbeiten, explizit verwenden wir folgende 7 Listen:
- FireHOL Level 1-3 und webclient
- Spamhaus DROP, EDROP und DROP6
[STEP 1 – URL DER BLOCKLISTEN SUCHEN]
Um an die Blocklisten zu kommen gibt es viele Wege, die sich je nach Anbieter unterscheiden. FireHOL stellt die Listen z.B. auf GitHub bereit, Spamhaus hingegen verlinkt die Listen direkt auf deren Homepage (https://www.spamhaus.org/drop). Bei GitHub ist wichtig, dass die „RAW-Listen“ genommen werden, also nicht „https://github.com“ sondern „raw.githubusercontent.com“.
Glücklicherweise habe ich Euch die Suche aber schon abgenommen, die URL zu den Listen lauten wie folgt:
- FireHOL L1: https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level1.netset
- FireHOL L2: https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level2.netset
- FireHOL L3: https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level3.netset
- FireHOL webclient: https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_webclient.netset
- Spamhaus DROP: https://www.spamhaus.org/drop/drop.txt
- Spamhaus EDROP: https://www.spamhaus.org/drop/edrop.txt
- Spamhaus DROP6: https://www.spamhaus.org/drop/dropv6.txt
Durch den Aufruf der Links könnt ihr übrigens direkt sehen, was in den Listen alles enthalten ist. Aber nicht wundern: Oft sind ganze Adressbereiche aufgeführt. DROP6 sieht mit seinen paar Einträgen demnach zwar sehr mager aus, beinhaltet dadurch aber extrem viele IPs. An der Stelle auch ein kleiner Wermutstropfen: DROP6 ist bisher die einzige Liste, die auch IPv6 Adressen beinhaltet.
[STEP 2 – ALIASE ERSTELLEN]
Ein Alias kann für diese Anwendung als „Sammlung von IP Adressen“ bezeichnet werden und wird benötigt um eine Blockliste, die im Internet als Textdatei bereitgestellt wird, einzubinden.
Wir beginnen also auf der OPNsense unter Firewall > Aliases und klicken unten rechts auf das Plus-Symbol um den ersten Alias zu erstellen.
Im darauffolgenden Fenster geben wir dem Alias einen Namen, wählen „URL Table“, geben an wie oft die Liste neu eingelesen (aktualisiert) werden soll und fügen dann bei „Content“ die URL ein. Zum Schluss bekommt der Alias noch eine Beschreibung, die bei mir in diesem Fall dem Namen entspricht, nur halt schöner geschrieben.
Dies speichern wir nun und wiederholen das für alle gewünschten Blocklisten, sodass die Liste der Aliase wie folgt aussieht (es mag natürlich Abweichungen bei den bestehenden Aliasen geben):
Dabei achten wir auch mal oben rechts auf die Anzeige, welche hier die Auslastung der Table Entries aktuell 0% angibt. Um die Listen anzuwenden klicken wir unten auf „Apply“ und sehen auch, dass die Table Entries ansteigen. Diese Anzeige ist wichtig, vor allem wenn man mit vielen Listen arbeitet oder auch auf Basis von Geo-IPs blockt. Sollten die max. Table Entries erreicht werden, können manche Listen nicht mehr geladen werden, daher sollte der Wert in den erweiterten Firewalleinstellungen ggf. erhöht werden. Ich fahre bislang ganz gut mit einem Wert von 4 Millionen.
[STEP 3 – FIREWALL REGELN ERSTELLEN]
Jetzt wird es spannend, denn wir können die Blocklisten nicht einfach wahllos auf jedes Interface anwenden, denn es wäre sehr wahrscheinlich, dass ihr euch damit vom Internet oder sogar von der Firewall aussperrt. Leider kann ich das an dieser Stelle nicht pauschal beschreiben, denke aber, dass mein Setting ein gutes Beispiel dafür ist, wo welche Liste Anwendung finden darf. Entscheidend ist es dabei zu wissen, was genau die Blocklisten enthalten. In unserem Fall liegt das Hauptaugenmerk dabei auf der FireHOL Level 1, denn diese Liste enthält auch „Full Bogons“, also IPs aus dem privaten Adressbereich, sprich auch die von eurem LAN. Diese dürfen wir natürlich nicht einfach überall blockieren, schon klar, oder? Warum, wieso, weshalb beschreibe ich im weiteren Verlauf am Beispiel meines Settings. Dieses beinhaltet zwei interne Netze (LAN und Guest), zwei Internet Netze (WAN und LTE) sowie ein VPN. Damit nicht für jedes Netz eine eigene Regel erstellt werden muss, verwenden wir hier Floating Rules, die auf alle ausgewählten Netze angewendet werden.
Wir navigieren zu Firewall > Rules > Floating und beginnen mit der Erstellung der ersten Regel durch Klick auf das Plus-Symbol oben rechts.
Eingehende Verbindungen blockieren - FireHOL Level 1
Diese Regel soll für den eigehenden Datenverkehr gelten, wir wollen also Zugriffe von den gelisteten IPs auf unser Heimnetz verhindern. Dazu machen wir folgende Einstellungen und speichern die Einstellungen anschließend:
Erläuterung:
Um eingehende Verbindungen zu blockieren muss die Regel für Internet-Interfaces erstellt und die Blockliste bei Source (Quelle) angegeben werden.
In meinem Fall darf ich das LTE-Interface hier aber nicht verwenden, da es sich hierbei um einen weiteren Router handelt, der an dem Interface angeschlossen ist. Die Kommunikation zwischen LTE-Router und OPNsense erfolgt also über ein privates Netz, welches durch FireHOL Level 1 blockiert werden würde. Auch bei CGNAT-Anschlüssen ist Vorsicht geboten, da hier ebenfalls eine Kommunikation im privaten Adressbereich erforderlich sein kann. In meinem Fall (Deutsche Glasfaser) hat das Blockieren hier aber keine negativen Auswirkungen.
FireHOL Level 1 darf im Gegensatz zu den anderen hier behandelten Blocklisten niemals auf einem internen Netz angewendet werden!
Eingehende Verbindungen blockieren - Die anderen Listen
Das gleiche Spiel machen wir nun nochmal für die anderen Blocklisten, ausgenommen Spamhaus DROP und EDROP, allerdings mit zwei kleinen Änderungen:
- Diese Listen dürfen auf alle Internet-Interfaces wirken, in meinem Fall wähle ich hier bei „Interface“ also WAN und LTE.
- Für Spamhaus DROP6 muss bei TCP/IP Version „IPv6“ gewählt werden.
Spamhaus DROP und EDROP finden hier keine Anwendung, da diese Listen bereits zu 100% in FireHOL Level 1 enthalten sind. Doppelt hält hier nicht besser.
Die Liste der Floating Rules sollte nun so aussehen:
Ausgehende Verbindungen blockieren - Alle Listen außer FireHOL Level 1 und 3
Diese Regeln sollen für den ausgehenden Datenverkehr gelten, wir wollen also Zugriffe von den Geräten in unserem Heimnetz auf die gelisteten IPs verhindern. Dazu machen wir für alle Blocklisten folgende Einstellungen und speichern die Einstellungen anschließend:
Erläuterung:
Für die ausgehenden Verbindungen wird die Liste bei „Destination“ (Ziel) angegeben und nicht bei „Source“ wie es für die eingehenden Verbindungen erforderlich ist.
Außerdem verwenden wir bei internen Interfaces (freundlicherweise) keine Block-Regel, sondern eine Reject-Regel.
Die Regeln dürfen auf alle gewünschten internen Netze angewendet werden, auch aufs VPN.
Weshalb FireHOL Level 1 hier nicht angewendet werden darf, habe ich oben bereits geschrieben. FireHOL Level 3 darf hier durchaus angewendet werden, allerdings kommt es vor, dass hiermit auch mal etwas blockiert wird, was man nicht blockieren möchte. Ganz besonders Github ist hier oft betroffen, weshalb ich die Liste hier nicht mehr verwende.
Für Spamhaus DROP6 ist klar: hier muss das Protokoll wieder auf IPv6 gestellt werden.
Die Liste der Floating Rules sollte nun so aussehen:
Die Reihenfolge ist übrigens nicht relevant, ich habe dennoch einen Grund sie so anzuordnen:
Erstens ist es übersichtlicher, da eingehende und ausgehende Regeln optisch getrennt voneinander stehen und zweitens greift als erstes die Liste mit den meisten Einträgen. Ist ein Eintrag nicht vorhanden, greift die Liste mit den zweitmeisten Einträgen, usw. Das ist also eher so eine Kopfsache.
Durch einen Klick auf „Apply Changes“ oben rechts werden die Regeln nun übernommen und angewendet. Möchte man blockierte Verbindungen auch geloggt haben, muss das Loggin bei den Regeln natürlich aktiviert werden, was bei den Screenshots nicht der Fall ist. An dieser Stelle merkt man, wie wichtig es ist, eine Anleitung erstmal ganz zu lesen, bevor man loslegt 😉.
[EPILOG]
Das war es dann auch schon wieder. Wer das Logging aktiviert hat, wird sich wundern, was da so alles blockiert wird, vor allem bei eingehenden Verbindungen. Aber… war man vorher so schlecht abgesichert, wenn diese Verbindungen erst seit Kurzem blockiert werden? Nein, nicht zwingend, denn die Masse wurde bereits zuvor standardmäßig blockiert. Hat man allerdings offene Ports für z.B. das VPN oder einen Webserver, dann erhalten die IPs auf der Blocklist fortan keinen Zugriff mehr darauf, was ein Plus an Sicherheit bringt.
Mir ist hierbei besonders das Blockieren von ausgehenden Verbindungen wichtig, da somit (unter Umständen zumindest) die Gefahr verringert wird sich Schadsoftware einzufangen oder, wenn man es doch mal geschafft hat, dass keine kritischen Daten an die Server der Hacker gesendet werden können. Letzteres habe ich live miterlebt, als ich mir eine Malware in einer VM eingefangen habe (die VM ist dafür da, um genau solche gefährlichen Experimente zu machen). Die Malware hat nicht nur die Daten meiner VM verschlüsselt, sondern wollte auch noch Passwörter und diverse andere Dinge an die Hacker übermitteln. Dank den Blocklisten konnte das aber nicht passieren, zumindest nicht vollständig, denn die Listen haben so einige Verbindungen blockiert. Im Log sah das dann so aus:
Also dann, frohes Gelingen und denkt daran: Prüft, was genau in den Listen steckt, bevor ihr sie anwendet!
[NACHTRAG]
Sicherlich ist euch schon aufgefallen, dass FireHOL Level 1 mit besonderer Vorsicht zu genießen ist, daher dieser Nachtrag, der insbesondere für Heimanwender von Bedeutung sein kann.
Oft werden die IP Adressen auf den WAN-Interfaces mittels DHCP bezogen, die erforderlichen Regeln werden automatisch auf dem (WAN)-Interface angelegt, sobald hier DHCP als Verbindungsart gewählt wurde.
Da die Floating Rules allerdings vor den Interface Rules wirken, könnte FireHOL Level 1 unter folgenden Umständen die DHCP-Kommunikation unterbinden:
- bei CGNAT Anschlüssen (der DHCP Server besitzt eine private IP die durch FireHOL L1 geblockt wird).
- bei einem vorgeschalteten Router/FW, wobei die OPNsense die IP per DHCP bezieht (auch hier besitzt der DHCP Server eine private IP).
Auch wenn es bei mir bislang keine Auswirkungen hatte, dass FireHOL Level 1 hier blockiert, möchte ich kurz aufzeigen wie man etwaigen Problemen vorbeugen kann.
Dazu übernehmen wir im Wesentlichen die beiden automatisch generierten Regeln vom WAN-Interface bei den Floating Rules, mit der Ausnahme, dass diese nicht auf „last match“ sondern auf „first match“ („quick“) gesetzt werden. Das sieht dann so aus, wobei die beiden Regeln hinter allen Blocklisten stehen:
Die Regel von FireHOL Level 1 wird nun noch von „first match“ („quick“) auf „last match“ gesetzt, damit diese erst zum Schluss (der Floating Rules) angewendet wird, sofern keine andere Regel etwas Anderes vorgibt. Alternativ könnte man die FireHOL Level 1 auch einfach hinter die beiden DHCP Regeln setzen, was mir aus Gründen der Übersichtlichkeit aber nicht gefallen würde, außerdem kann man so problemlos weitere, eventuell erforderliche Regeln anlegen, ohne dass man auf die FireHOL Level 1 große Acht geben muss.
Übrigens:
Da FireHOL Level 1 wie die meisten anderen Listen nur IPv4 Adressen beinhaltet, könnten die beiden DHCP auch lediglich für IPv4 erstellt werden, aber wer weiß, ob nicht irgendwann mal weitere Blocklisten für IPv6 eingepflegt werden, und was diese dann blockieren würden?!
---
Vielen Dank an den User tiermutter für diese Anleitung!