So, hier ist die Fortsetzung zum Theme Sicherheit. Diesmal geht es um die Firewall.
Für die Eiligen – TL;DR
Der Raspiblitz ist im Grundzustand gut konfiguriert, aber ich empfehle Thunderhub und RTL auf den Nicht-SSL Ports nicht zuzulassen.
4. Firewall konfigurieren
Zuallererst: Wenn ihr eure Node ohne externe IP-Adresse mit NAT hinter einem Router betreibt, dann sind die meisten Punkte in diesem Post nicht so wichtig. Aber trotzdem könnte ihr durch ein paar Konfigurationen eure Node noch sicherer machen, insbesondere gegen einen Angriff aus dem eigenen Netz. Das könnte z.B. passieren, wenn sich in einem Computer in eurem Netzzwerk ein Trojaner eingeschlichen hat, oder wenn der Angriff auf der Straße in Reichweite eures WLAN-Netzwerks befindet.
Netzwerk-Grundlagen
Eine Firewall schützt euere Node vor ungewollten Netzwerkzugriffen. Linux – und damit auch eure Node – hat standardmäßig eine Firewall mit dabei. Beim Raspiblitz ist diese auch schon vorkonfiguriert und aktiviert. Damit ihr versteht, was ihr da macht, sind ein paar Netzwerkgrundlagen nötig:
- Computer können über unterschiedliche Protokolle miteinander sprechen, bei unserer Lightning Node ist das z.B. TCP/IP. Das Internet Protocol (IP) bildet die Grundlage des ganzen Internets.
- Euer Computer hat dabei eine IP-Adresse. Üblicherweise wird dies in eurem Heimnetzwerk eine lokale IP-Adresse sein, beispielsweise 192.168.0.23, möglicherweise beginnt sie auch mit 10.x.x.x oder 172.16.x.x. Euer Router wird in den meisten fällen die interne Adresse 192.168.0.1 und zusätzlich eine externe Adresse haben und vermittelt Anfragen in euer Netzwerk.
- Ein Programm auf einem Computer, kann aber auch mit einem anderen Programm auf dem selben Computer kommunizieren, in diesem Fall nutzt es die „Loopback“ Adresse 127.0.0.1 oder den hostnamen „localhost“.
- Wenn ein Programm eine solche Kommunikation (egal ob von außerhalb des privaten Netzes, von innerhalb oder auf dem selben Computer) anbieten will, dann spricht man meist von einem Dienst, der auf einem sog. Port lauscht. Das ganze ist im Transmission Control Protocol (TCP) definiert. Ein Service lauscht also auf einem Port, as eine bestimmte Nummer hat, die meist einem Standard folgen. HTTP hat üblicherweise den Port 80, HTTPS 443, SSH 22, Bitcoin 8333 und Lightning 9735.
- Eine Kommunikation findet nun von einer IP-Adresse zu einer anderen IP-Adresse + Port statt. Beispielsweise greift eine andere Node (mit einer externen IP-Adresse) auf eure Node über den Port 9735 zu. Oder ihr greift selbst von eurem lokalen Netzwerk per SSH auf Port 22 eurer Node zu.
Und genau hier greift eine Firewall ein: Mit der Firewall wird genau definiert, von wo aus ein Dienst auf einen bestimmten Port zugreifen darf.
iptables und ufw
Unter Linux heißt die Firewall „iptables“, die sehr mächtig ist. Bei einem Raspiblitz wird deswegen das Programm „ufw“ (auf deutsch „unkomplizierte Firewall“) zur einfachen Konfiguration eingesetzt.
Um zu prüfen, ob die Firewall läuft nutzt auf dem Terminal den Befehl sudo systemctl status ufw.service das sollte ein paar Zeilen ausgeben inklusive einem Active: active – dann läuft der Dienst.
Wenn ihr nur Tor verwendet ist alles etwas einfacher
Vermutlich ist eure Node nur im Tor-Netzwerk angebunden. In dem Fall nutzt ihr nicht TCP/IP sondern TCP/Tor. Das heißt die ganzen IP-Adressen für den Zugriff von außen gibt es nicht, sondern das Tor-Netzwerk kümmert sich um alles, inklusiver versteckter Service-Adressen statt IP-Adressen. Erst lokal auf eurer Node wird die Kommunikation übersetzt und an einen TCP-Port gebunden. D.h. für eure Firewall sieht es so aus, als würde ein Programm auf eurer Node (der Tor-Dienst) mit einem anderen Programm (der Lightning-Daemon) sprechen, also von der Adresse 127.0.0.1 (localhost) auf einen Port, bei Lightning eben 9735.
Im Raspiblitz ist ufw automatisch so konfiguriert, dass alle Loopback-Zugriff erlaubt werden.
Wenn ihr das prüfen wollte, sollte sich in der Konfigurationsdatei /etc/ufw/before.rules der folgende Abschnitt befinden:
# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT
Der Abschnitt sagt im Grunde, dass alle eingehende und ausgehenden Verbindungen, die über „Loopback“ gehen akzeptiert werden.
Nicht benötigte Services aussperren
Für den laufenden Betrieb eurer Node könnt ihr eigentlich alle anderen Zugriff verbieten, weil alles über Tor läuft.
Allerdings benötigt ihr vermutlich zur Administration Zugriff von außen (außer ihr verwendet an eurer Node nur einen Bildschirm + Tastatur).
Bei einer Lightning-Node wie dem Raspiblitz sind das üblicherweise:
- SSH (für den Zugriff über die Kommandozeile)
- RTL (Browser GUI)
- Thunderhub (Browser-GUI)
Das Ziel der folgenden Anleitung ist nun alle Zugriff von außern zu verbieten, außer für diese 3 Dienste.
Zuerst müsst ihr mal prüfen, wie die Firewall derzeit konfiguriert ist. Das geht mit diesem Befehl sudo ufw status verbose.
Die Ausgabe auf einem unveränderten Raspiblitz sieht ca. so aus:
sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
8333 ALLOW IN Anywhere # bitcoin mainnet
9333 ALLOW IN Anywhere # litecoin mainnet
19735 ALLOW IN Anywhere # lightning testnet
9735 ALLOW IN Anywhere # lightning mainnet
10009 ALLOW IN Anywhere # lightning gRPC
8080 ALLOW IN Anywhere # lightning REST API
49200:49250/tcp ALLOW IN Anywhere # rtorrent
80 ALLOW IN Anywhere # allow public web HTTP
443 ALLOW IN 10.0.0.0/8 # allow local LAN HTTPS
443 ALLOW IN 172.16.0.0/12 # allow local LAN HTTPS
443 ALLOW IN 192.168.0.0/16 # allow local LAN HTTPS
Anywhere ALLOW IN 10.0.0.0/8 1900/udp # allow local LAN SSDP for UPnP discovery
Anywhere ALLOW IN 172.16.0.0/12 1900/udp # allow local LAN SSDP for UPnP discovery
Anywhere ALLOW IN 192.168.0.0/16 1900/udp # allow local LAN SSDP for UPnP discovery
3000 ALLOW IN Anywhere # RTL HTTP
3001 ALLOW IN Anywhere # RTL HTTPS
3010 ALLOW IN Anywhere # allow ThunderHub HTTP
3011 ALLOW IN Anywhere # allow ThunderHub HTTPS
22/tcp (v6) ALLOW IN Anywhere (v6)
18333 (v6) ALLOW IN Anywhere (v6) # bitcoin testnet
8333 (v6) ALLOW IN Anywhere (v6) # bitcoin mainnet
9333 (v6) ALLOW IN Anywhere (v6) # litecoin mainnet
19735 (v6) ALLOW IN Anywhere (v6) # lightning testnet
9735 (v6) ALLOW IN Anywhere (v6) # lightning mainnet
10009 (v6) ALLOW IN Anywhere (v6) # lightning gRPC
8080 (v6) ALLOW IN Anywhere (v6) # lightning REST API
49200:49250/tcp (v6) ALLOW IN Anywhere (v6) # rtorrent
80 (v6) ALLOW IN Anywhere (v6) # allow public web HTTP
3000 (v6) ALLOW IN Anywhere (v6) # RTL HTTP
3001 (v6) ALLOW IN Anywhere (v6) # RTL HTTPS
3010 (v6) ALLOW IN Anywhere (v6) # allow ThunderHub HTTP
3011 (v6) ALLOW IN Anywhere (v6) # allow ThunderHub HTTPS
Wie ist das ganze zu lesen? Die Zeile
Default: deny (incoming), allow (outgoing), disabled (routed)
bedeutet, dass alle eingehenden Verbindungen nicht erlaubt werden („deny incoming“) und alle ausgehenden Verbindungen erlaubt werden.
Dann folgt die lange Liste an Ports, die trotzdem erlaubt werden und zwar einmal für IPv4 und einmal für IPv6.
Eine andere Ansicht mit Regel-Nummern ermöglicht der Befehl sudo ufw status numbered:
sudo ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 18333 ALLOW IN Anywhere # bitcoin testnet
[ 3] 8333 ALLOW IN Anywhere # bitcoin mainnet
[ 4] 9333 ALLOW IN Anywhere # litecoin mainnet
[ 5] 19735 ALLOW IN Anywhere # lightning testnet
[ 6] 9735 ALLOW IN Anywhere # lightning mainnet
[ 7] 10009 ALLOW IN Anywhere # lightning gRPC
[ 8] 8080 ALLOW IN Anywhere # lightning REST API
[ 9] 49200:49250/tcp ALLOW IN Anywhere # rtorrent
[10] 80 ALLOW IN Anywhere # allow public web HTTP
[11] 443 ALLOW IN 10.0.0.0/8 # allow local LAN HTTPS
[12] 443 ALLOW IN 172.16.0.0/12 # allow local LAN HTTPS
[13] 443 ALLOW IN 192.168.0.0/16 # allow local LAN HTTPS
[14] Anywhere ALLOW IN 10.0.0.0/8 1900/udp # allow local LAN SSDP for UPnP discovery
[15] Anywhere ALLOW IN 172.16.0.0/12 1900/udp # allow local LAN SSDP for UPnP discovery
[16] Anywhere ALLOW IN 192.168.0.0/16 1900/udp # allow local LAN SSDP for UPnP discovery
[17] 3000 ALLOW IN Anywhere # RTL HTTP
[18] 3001 ALLOW IN Anywhere # RTL HTTPS
[19] 3010 ALLOW IN Anywhere # allow ThunderHub HTTP
[20] 3011 ALLOW IN Anywhere # allow ThunderHub HTTPS
[21] 22/tcp (v6) ALLOW IN Anywhere (v6)
[22] 18333 (v6) ALLOW IN Anywhere (v6) # bitcoin testnet
[23] 8333 (v6) ALLOW IN Anywhere (v6) # bitcoin mainnet
[24] 9333 (v6) ALLOW IN Anywhere (v6) # litecoin mainnet
[25] 19735 (v6) ALLOW IN Anywhere (v6) # lightning testnet
[26] 9735 (v6) ALLOW IN Anywhere (v6) # lightning mainnet
[27] 10009 (v6) ALLOW IN Anywhere (v6) # lightning gRPC
[28] 8080 (v6) ALLOW IN Anywhere (v6) # lightning REST API
[29] 49200:49250/tcp (v6) ALLOW IN Anywhere (v6) # rtorrent
[30] 80 (v6) ALLOW IN Anywhere (v6) # allow public web HTTP
[31] 3000 (v6) ALLOW IN Anywhere (v6) # RTL HTTP
[32] 3001 (v6) ALLOW IN Anywhere (v6) # RTL HTTPS
[33] 3010 (v6) ALLOW IN Anywhere (v6) # allow ThunderHub HTTP
[34] 3011 (v6) ALLOW IN Anywhere (v6) # allow ThunderHub HTTPS
Wie man sieht, ist in jeder Zeile eine Regel definiert, zum Beispiel:
22/tcp ALLOW IN Anywhere
Das bedeutet auf den SSH-Dienst mit dem Port 22 dürfen eingehende Verbindungen („IN“) von überall „Anywhere“ angenommen werden. Also von 127.0.0.1, von einer Adresse im lokalen Netz (z.B: 192.168.0.23) oder auch von extern (wenn es nicht der Router mit NAT sowieso nicht ermöglicht).
Wenn wir nur die drei Services SSH, RTL und Thunderhub erlauben wollen, müssen wir alle anderen Services löschen. Das geht am einfachsten mit dem Befehl sudo ufw delete <Nr>.
Ein Beispiel:
sudo ufw delete 9
Deleting:
allow 8080 comment 'lightning REST API'
Proceed with operation (y|n)?
Das Programm fragt also zur Sicherheit nochmal nach und nach einem „y“ wird die Regel gelöscht. So kann man mit jeder Regel verfahren, die man löschen möchte.
Im übrigen ist es nicht notwendig, den Dienst ufw neu zu starten. Die Änderungen gelten sofort.
Achtung: Die Nummern ändern sich nach jedem Löschvorgang, also am besten mit der höchsten Nummer beginnen oder jedes mal neu die Nummern abfragen.
Zur Erinnerung: Der Zugriff über Tor wird von diesen Regeln nicht erfasst, deswegen können eigentlich fast alle Regeln gelöscht werden. Was auf jeden Fall benötigt wird:
- Der Port 9735 für Lightning Mainnet
- Der Port 22 für SSH
- Der Port 3001 für RTL über SSH
- Der Port 3011 für Thunderhub über SSH
Wichtig: Ports für RTL und Thunderhub können auf eurem System von meinem Beispiel abweichen.
Einige der Regeln in der UFW-Konfiguration sind eigentlich irrelevant, beispielsweise für den Port 18333 (bitcoin testnet). Vermutlich ist euer System sowieso so konfiguriert, dass der Bitcoin-Dienst gar nicht auf diesem Port lauscht, es kann also sowieso kein Zugriff stattfinden. Ich finde es aber trotzdem besser, wenn auch die entsprechende Firewall-Regel gar nicht existieren.
Welche Services in jedem Fall ausgesperrt gehören
Eigentlich ist die Firewall nicht so wichtig, wenn sich die Node hinter einem Router mit NAT befindet und viele Ports sowieso nicht in Verwendung sind. Es gibt aber einige Services, die mich sehr wohl stören:
- Thunderhub über HTTP (ohne SSL)
- RTL über HTTP (ohne SSL)
Warum? Ihr könnte diese Dienst ohne Verschlüsselung im internen LAN aufrufen. Dabei wird das RPC-Passwort unverschlüsselt (!) übertragen. Es ist auf jeden Fall empfehlenswert die beiden Dienst nur über HTTPS aufzurufen. Dabei kommt im Normalfall zwar ein selbstsigniertes Zertifikat zur Anwendung, aber wenn ihr den Fingerprint des Zertifikats einmalig manuell prüft, ist das genauso sicher wie in normal signiertes Zertifikat.
Aber wenn ihr einmal unabsichtlich die HTTP-Seite ohne SSL aufruft, übertragt ihr euer Passwort im Klartext in eurem Netz. Ein Angreifer, der sich in Funkreichweite eures WLAN befindet, kann dieses einfach aufzeichnen, sich im WLAN anmelden (auch relativ einfach möglich) und über Thunderhub/RTL eure Node leerräumen.
Also, wenn das oben alles zu viel war, sperrt einfach die folgenden Ports raus:
und zwar swowhl für IPv4 als auch IPv6, also in Summe in meinem Beispiel die Regeln 33, 31, 19 und 17.
Ein paar Sonderfälle für die Profis:
- Wenn ihr mit der Software von Ledger auf eure Node zugreifen wollt, müsst ihr möglicherweise zusätzliche Ports erlauben, aber das habe ich nicht getestet. Hier geht’s zu einer Anleitung für Bitbox, danke für den Tipp @osito!
- Wenn ihr eine zweite Bitcoin-Node betreibt und die beiden Nodes die Blockchain untereinander synchronisieren sollen, müsst ihr den Port 8333 erlauben.
Verbindet euch mit meiner (gut abgesicherten) Node!
Ihr könnt euch auch gerne einen Kanal mit meiner Node aufmachen: GLN auf amboss.space . Bitte mind. 2M, kleinere Kanäle ergeben keinen Sinn, da die Open & Close-Kosten sonst in keinem Verhältnis zu den möglichen Gebühreneinnahmen stehen, nur kleine Beträge transferiert werden können und dauernd ein Rebalancing nötig wäre.
Meine Node wird zukünftig einige Online-Shops anbinden und ist mittlerweile auf Platz ~700 auf Terminal Web und hat dort 6/6 Häkchen.
, ich tippe auf „es hat grad keiner Bock“ oder Channel inaktiv.