Grundkonfiguration einer Lightning Node & Best Practices

Hallo,
es scheint ja sehr viele neue Node-Besitzer zu geben. Deswegen würde ich hier gerne eine Sammlung von Infos und Quellen rund um die saubere Konfiguration einer Lightning-Node anlegen. Das ist ein Thema, wo es scheinbar auch nicht so viele gute Dokumentation gibt.

Worum es mir hier nicht geht sind Grundlagen, wie Lightning funktioniert oder auch der Channel-Aufbau. Ein guter Post zu diesem Theam ist Lightning - Erfahrungen [Liquidität, Gebühren].

Ich bin noch relativ am Anfang meiner Lightning-Erfahrung. Habe seit kurzem eine Node (RaspiBlitz) und habe mich die letzten Wochen viel mit diversen Lightning-Themen behandelt. Was ich allerdings nirgends gefunden habe, sind Tipps und Tricks für die saubere Konfiguration einer Node. Es gibt viele Grundlagen-Tutorials, aber die Konfiguration ist ja immer auch etwas individuelles. Da müssen Entscheidungen getroffen werden, die aus den eigenen Zielen, die man mit der Node hat, abgeleitet werden müssen. Da hilft kein One-Size-Fits all.

Hier sind ein paar Themen, die meiner Meinung nach am Anfang für eine grundlegende Konfiguration wichtig sind: (Disclaimer: vermutlich fehlen hier noch viele genauso wichtige Themen)

Hardware: Natürlich gibt es schon bei der Hardware einiges zu beachten.

  • RAM bei Raspberry Pi 4: 2 GB RAM reicht für Bitcoin (aber Sync wird länger dauern), 4GB RAM reicht für Bitcoin + LND, 8GB RAM ist empfehlenswert, wenn man mehr machen will (beispielsweise mempool.space)
  • USV / Unabhängige Stromversorgung ist sehr zu empfehlen. Ein Stromausfall kann schnell zu Datenverlust führen und wenn man bei den Channels ein Fehler passiert, könnte man im schlimmsten Fall sogar Satoshis verlieren. Ich nutze derzeit eine Eaton Ellipse ECO 650 USB DIN (Amazon). Wie die Konfiguration funktioniert, habe ich hier im Thread erklärt: Unabhängige Stromversorgung
  • Zusätzlichen Kühler beim Raspi: Braucht es meiner Meinung nach nicht, meine Node langweilt sich derzeit und hat max. 60°C.

Sicherheit: Wie konfiguriere ich meine Node möglichst sicher, um sie (u.a.) vor Hackern zu schützen?

  • Auf dem Raspiblitz sind standardmäßig mehr Dienste von außen zugreifbar als eigentlich nötig. Es ist einfach die Firewall zu so konfigurieren, dass nur die wirklich benötigten Ports offen sind. Wie das geht habe ich in dem Post über die Firewall erklärt.
  • SSH zur Konfiguration sollte von außern nur über ein Tor-Hidden-Service laufen, siehe mein Post hier
  • Wallet: Bringt eine Hardware-Wallet genug zusätzliche Sicherheit? Was auf jeden Fall empfehlenswert ist, „LND Auto-Unlock“ nicht zu verwenden (Raspiblitz: Menü „Node Settings & Options“). Dafür muss man dann aber bei jedem Hochfahren das Passwort per SSH neu eingeben.

Tor vs. Clearnet:

  • Die Node nur unter Tor laufen zu lassen ist praktisch, weil man sich um keine Port-Weiterleitungen kümmern muss und es auch mit dynamischen IPs funktioniert. Außerdem erhält man ein wenig Sicherheit (aber auch nicht so viel wie manche denken, zu dem Thema Sicherheit hat mir dieser Artikel geholfen: https://medium.com/@BtcpayServer/about-tor-and-btcpay-server-2ec1e4bd5e51).
  • Was ich noch nicht verstanden habe: Wie richtet man seine Node ein, sodass sie sowohl unter Tor als auch ohne zu erreichen ist?
  • Wie erstelle ich SSL-Zertifikate?

URIs:

  • Wenn das Tor/Clearnet gelöst ist, leitet sich daraus der URI ab. Der Public-Key for dem @ bleibt natürlich gleich, aber der Socket (meist IP + Port) dahinter ändert sich.
  • Was ich noch nicht verstanden habe: Ist es möglich später den Socket zu ändern ohne dass, Channels geschlossen werden? Wäre es nicht besser mit Domains zu arbeiten, um die Namensauflösung an das DNS zu delegieren? Viele große Nodes geben ja ihre Domainnamen im Alias an, aber der URI enthält immer die IP-Adresse.

Weitere LND-Konfiguration

Watchtower: Gehört irgendwie auch zum Thema Sicherheit, ist aber vermutlich als eigenes Thema sinnvoll.

Ich würde mich freuen, wenn wir hier Best-Practices (oder offene Punkte) sammeln könnten. Ich kann auch gerne den Ausgangspost immer wieder ergänzen, oder wir machen ein Wiki daraus, wenn das Thema genug Anklang findet.

Verbindet euch mit meiner 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 ~1500 auf Terminal Web und hat dort 5/6 Häkchen. Das 6. Häkchen kommt bestimmt bald dazu. :slight_smile:

20 „Gefällt mir“

So, hier mal die erste Ergänzung.

Unabhängige Stromversorgung / USV / UPS

Man soll ja von Computern nicht einfach so den Stecker ziehen, das lernt man ja früh. Im besten Fall passiert nix, aber leider kann es auch zu Datenverlust kommen bzw. sogar die Harddisk (oder die SD-Karte im Raspi) kaputt werden.
Bei einer Lightning-Node können noch folgende Unanehmlichkeiten dazu kommen:

  • Ein neuer Block wurde gerade verabeitet, dann könnte das neuerliche Hochfahren länger dauern. Möglicherweise muss sogar die gesamte Blockchain neu gesynct werden.
  • Wenn gerade eine Lightning-Transaktionen stattgefunden haben, könnten die Daten nicht korrekt abgespeichert werden. Das könnte im schlimmsten Fall zu einem Verlust von Bitcoin in Kanälen führen, wenn der Channel-Partner das als Betrug wertet und sich den gesamten Kanal holt.

Deswegen ist eine USV absolut empfehlenswert!

Ich nutze derzeit eine Eaton Ellipse ECO 650 USB DIN (Amazon) für ca. 100€.

Hier sind ein paar Einrichtungstipps – in meinem Fall für einen Raspberry Pi 4 mit RaspiBlitz v.1.7.0:

Stufe 1: Einfach anstecken

Eine USV einfach anzuschließen verbessert schon die Situation: Es werden Spannungsschwankungen (Gewitter!) ausgeglichen und natürlich kurze Stromausfälle überbrückt.

Stufe 2: Automatischer Shutdown

Besser ist allerdings, wenn der Status der USV permanent vom Raspi überwacht wird. Fällt der Strom aus, wartet die Überwachung so lange, bis die Batterie der USV fast leer ist. Dann wird automatisch der Raspi sicher heruntergefahren. Wenn der Strom dann wieder da ist, wird der Raspi wieder hochgefahren.

Dafür muss die USV eine Kommunikationsschnittstelle anbieten. Beim EATON sind das die Modelle mit der Bezeichnung „USB“.

Das ganze funktioniert unter Linux beispielsweise mit NUT, den Network UPS Tools: https://networkupstools.org/

Bei der Einrichtung bin ich eigentlich fast 1:1 diesem Tutorial gefolgt:

An dieser Stelle möchte ich mich bei @mrsieb für den Link-Tipp bedanken!

Die Konfiguration unterscheidet sich ein wenig für das EATON-Gerät und den Raspiblitz, aber im Grunde ist das Tutorial fast perfekt geeignet. Lediglich den USV-Namen habe ich natürlich anders gewählt, natürlich die Passwörter und bei den Schreibrechten habe ich mich an den bestehenden Rechten im /etc/nut Ordner orientiert.

Ich habe das Tutorial bis zur Überschrift „Email notifications“ bei mir angewendet.

Stufe 3: Benachrichtigungen

Im Tutorial ist auch noch beschrieben, wie man beispielsweise E-Mail-Benachrichtigungen einstellen kann bei USV-Events, aber das habe ich (noch) nicht getestet. Wird hier ev. noch nachgeliefert.

Der Test

Um sicher zu gehen, dass das Ganze auch funktioniert, habe ich einen Test durchgeführt. Wer sicher gehen möchte, dass nichts kaputt wird, fährt den Raspi herunter, steckt ihn wieder an eine normale Steckdose an, fährt ihn wieder hoch und legt an die USV einen anderen Verbraucher mit ähnlicher Leistung an. Dann wird die USV vom Netz genommen und der Test beginnt.

Der Raspi ist trotzdem noch per USB verbunden und bekommt die Signale der USV. Das sieht beispielsweise so aus:

Broadcast message from nut@raspberrypi (Fri Jul 2 19:57:31 2021):
UPS eaton@localhost on battery

Bei meinem Raspi wurde dann bei einem Akkustand vom EATON von 20% der Shutdown-Prozess eingeläutet:

Broadcast message from nut@raspberrypi (Fri Jul 2 20:27:36 2021):
UPS eaton@localhost battery is low

Broadcast message from nut@raspberrypi (Fri Jul 2 20:27:36 2021):
Executing automatic power-fail shutdown

Broadcast message from nut@raspberrypi (Fri Jul 2 20:27:36 2021):
Auto logout and shutdown proceeding

Ich habe den Test direkt mit dem Raspi und keinem eigenen Verbraucher gemacht. Wenn der Raspi heruntergefahren wurde, bekommt die USV die letzte Anweisung, den Strom zu kappen, der Raspi wird stromlos und schaltet sich ab.

Dann habe ich den Strom der USV wieder angesteckt und der Raspi fährt automatisch wieder hoch.

Wenn alles hochgefahren ist, fängt die Bitcoin-Blockchain fängt gleich wieder zu syncen an, nur die LND-Wallet muss noch per Passwort aktiviert werden (außer man hat „LND Auto-Unlock“ aktiviert, was ich nicht empfehlen würde).

Damit man das Passwort auch bei einem Stromausfall wieder eingeben kann, wenn man nicht zuhause ist, empfiehlt es sich eine E-Mail-Notification einzurichten.

Bei meinem Test mit dem EATON 650 USB hat der Akku (mit einer Kapazität von 84Wh) ziemlich genau 30min gehalten, bevor die 20%-Schwelle erreicht wurde. Allerdings hängt bei mir nicht nur der Raspi an der USV sondern zusätzlich auch ein Router. Ohne Router hätte die USV also noch etwas länger gehalten.

Ich hoffe, dass euch dieser Erfahrungsbericht hilft, es ist nicht so kompliziert.
Ich freue mich, wenn ihr hier auch Tipps & Tricks für die sichere Konfiguration eurer Lightning-Node teilt.

Happy stacking!

19 „Gefällt mir“

Danke für deine Gedankengänge. Den RaspiBlitz aufzusetzen ist kein Hexenwerk, allerdings ist alles was folgt erstmal überwältigent.
Ich bin auch noch ganz am Anfang. Mittlerweile habe ich den RaspiaBlitz soweit konfiguriert, dass ich ihn mit ersten Sats befüllen könnte. Allerdings bin ich mir noch nicht im klaren, wie ich meine eigene Netwerkkonfiguration gestalten soll, insbesondere in Bezug auf Sicherheit.
Ich hatte vor meinen RaspiBlitz in einer DMZ laufen zu lassen, aber das schützt ja nicht meinen Blitz, sondern nur mein Netzwerk falls der Blitz gehackt würde. Dazu kommt noch (zumindest für mich) die herrausfordernde Portforwarding Konfiguration.
Ich denke, den Blitz nur im Tor-Netzwerk angebunden zu haben und eventuell die Lightning-Firewall (Circuitbreaker) zu aktivieren, sollten ausreichend Sicherheit garantieren. Clearnet ist keine Option für mich.

Vieleicht hat jemand anders in der Hinsicht ein paar Tips.

Sicherheits-1x1 für Linux

Unsere Nodes sind 7x24h online und deswegen permanent möglichen Hackern ausgeliefert. Deswegen ist es wichtig, sich ein paar Gedanken über die Sicherheit zu machen und die eigene Node entsprechend zu konfigurieren. Das Thema ist riesig, hier sind ein paar wichtige Dinge, die ich jedem Node-Betreiber empfehlen kann.

1. Linux-Basics aneignen

Ich weiß, es ist sehr verlockend alles über eine Weboberfläche zu administrieren, aber um euer System wirklich sicher zu bekommen, müsst ihr euch ein paar Linux-Kenntnisse aneignen. Lest ein Buch oder diverse Tutorials dazu im Internet. Ohne Kommandozeile geht es nicht. Punkt. Ihr habt einen Server im Internet, nicht mit Katzenvideos sondern mit wertvollen Bitcoin, also bitte nicht die Augen verschließen und „wird schon nix passieren“ denken…

Aber hier sind ein paar konkrete Empfehlungen:

2. Sichere Passwörter verwenden

Ein Passwort-Manager ist schon mal ein guter Weg, allerdings würde ich für eine Node auch folgendes Konzept überlegen: Merkbare Passwörter + diese nur auf Papier zur Sicherheit aufschreiben und an einem sicheren Ort aufbewahren (natürlich nicht in der Schublade neben der Node).

Ein gutes Passwort ist übrigens nicht „pAssw0rt!#“ – auch wenn es aus Groß- und Kleinbuchstaben, Zahlen und Zeichen besteht. Mal abgesehen davon, dass es sich wohl in jeder Brute-Force-Liste befindet, ist die Entropie sehr gering und merken kann man es sich auch nicht besonders gut. Besser ihr macht es ähnlich wie die Wortliste bei eurem Bitcoin-Wallet. Nur nehmt zufällige Wörter und keine aus der Liste (bspw. aus einem Zeitungsartikel) und überlegt euch eine Geschichte dazu.

Beispiel: Null - Sehen - Zwang - Leiter. Das resultierende Passwort könnte dann sein „NullSehenZwangLeiter“ und ist sogar deutlich sicherer als das obige mit den Zahlen und Sonderzeichen.Und dann überlegt ihr euch dazu einen Satz, bspw. „wenn ich null sehen kann, sollte mich niemand zwingen eine Leiter hinaufzugehen“. Das ergibt gerade so viel Sinn, dass sich das Passwort nach 3x eintippen ins Hirn eingebrannt hat.

Hier ist übrigens ein Comic, dass die Sache schön auf den Punkt bringt:

3. SSH-Zugang als Tor-Hidden-Service

Ihr braucht die Kommandozeile um euren Server zu administrieren, am besten auch von unterwegs – aber nur abgesichert. Das SSH-Service offen (also via TCP/IP erreichbar) im Internet zu haben, ist nicht so gut. Hier sind ein paar Vorschläge:

  • Standard-Port ändern (ist aber nicht wirklich sicher)
  • VPN nutzen, falls euer Router das unterstützt. Also zuerst verbindet ihr euch per VPN mit eurem Router und erst aus dem lokalen Netz heraus greift ihr per SSH auf eure Node.
  • SSH über ein Tor-Hidden-Service anbieten

Diese letzte Option funktioniert wie folgt: Eure Node läuft bereits mit Tor, wenn eure UI mit …onion endet. Das ist beispielsweise der URI zu meiner Node:
0313118036b611e729633e125cec1a911b9d0de42a676781b8c0940926726f685a@4o7o23vucbrf2gtfkfwetvgs6zcqvb3xjx3hfirylvs656o42q7sutyd.onion:9735
Hinter dieser Adresse läuft ein Tor-Hidden-Service und zwar der LND-Daemon.

Genau so etwas könnt ihr auch für SSH einrichten.
Dazu müsst ihr eigentlich nur die Datei /etc/tor/torrc ändern und ein neues Service registrieren. Ihr solltet euch dabei an die Konvention eures System richtigen. Beim Raspiblitz sieht eine neue Konfiguration z.B. wie folgt aus:

# Hidden Service for SSH
HiddenServiceDir /mnt/hdd/tor/ssh
HiddenServiceVersion 3
HiddenServicePort 22

Dann startet ihr Tor neu: sudo systemctl restart tor
Tor erzeugt dann automatisch in dem angegeben Verzeichnis die nötigen Konfigurationsdateien. Mit dem Befehl sudo cat /mnt/hdd/tor/ssh/hostname wird euch die URI des SSH-Hidden-Service „…onion“ ausgegeben. Aber diese bitte mit niemandem Teilen, schon gar nicht im Internet!

Auf dem Computer, mit dem ihr euch dann von außerhalb mit eurer Node verbinden möchtet, muss natürlich ssh und tor installiert sein. Je nach Betriebssystem geht das unterschiedlich.

Wer einen Mac hat kann sich die Programm mit brew installieren. Nach der Installation von brew lädt man sich folgende Komponenten nach:
brew install tor torsocks socat
Dann startet man den tor-Dienst:
brew services start tor
ssh -o ProxyCommand='socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050' admin@hidden-service-uri.onion

Das letzte Kommando verbindet sich mit dem lokal laufenden TOR-SOCKS-Proxy, ev. läufter der auf einem anderen Port (9050), natürlich muss am Ende die richtige URI eingetragen werden.

Es gibt natürlich noch viel mehr bezüglich Sicherheit

Aber der Post ist eh schon lange genug. Wenn ihr mehr solche Tutorials haben möchtet, dann schenkt mir ein Like und es gibt es bald ein Update! :wink:

Verbindet euch mit meiner 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.

16 „Gefällt mir“

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:

  1. 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.
  2. 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.
  3. 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“.
  4. 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.
  5. 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:

  1. Thunderhub über HTTP (ohne SSL)
  2. 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:

  • RTL 3000
  • Thunderhub 3010

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.

14 „Gefällt mir“

Hey @GLN, erstmal danke für die super Einführung! Deine Beiträge sind wirklich immer ausführlich!
Vielleicht kennst du das ja schon aber für Optimierung des Terminal Scores gibt es diesen tollen Service:

1 „Gefällt mir“

Vielen Dank für dein immer sehr lehrreichen Content!! :slightly_smiling_face:

Ich bin dabei meine Firewall entsprechend aufzuräumen.
Dabei habe ich mich mit einzelnen Ports beschäftigt. Als Noch-IT-Laie sind mir zum Beispiel bei dem PORT 10006 (v4)/(v6) zusammenhänge mit Watchtower aufgefallen.

Ich möchte gerne meine Node mit Watchtower einrichten - Zwecks Sicherheit.
Auch habe ich die REST API adresse im zusammenhang mit anderen Services gefunden.

Zusammengefasst meine Frage: Wenn man nicht gerade bestimmte Services verwenden möchte, kann man alle bis auf die 4 oben genannten Ports löschen.

Sprich die oben beschriebene konfiguration der Firewall ist für einen Node-Betreiber gedacht, der sich ausschließlich per SSH einlogged und über RTL und Thunderhub wartet/steuert und pflegt, richtig?

Hey GLN,

Danke für den ausführlichen Post. Ich werde heute Abend meine USV einrichten und bin über diesen Punkt gestolpert:

E-Mail Notification ist klar, aber wie kann ich dann von einem iPhone von unterwegs auf den Raspiblitz zugreifen um das PW einzugeben?

Grüße
Jan

Ja genau, die konkrete Konfiguration hängt von den Services ab, die du nutzen möchtest.

Genau genommen benötigst du für lnd nur den lnd Port 9735, den SSH Port 22 solltest du auch nie blocken, sonst kommst du nicht per SSH rein. Alle anderen Port kann man im Zweifelsfall ja auch später hinzufügen, wenn etwas nicht mehr wie erwartet funktioniert.

Wenn du die folgenden Services von deinem lokalen LAN aus nutzen möchtest, benötigst du die beispielsweise auch noch die folgenden Ports:

  • mempool space: 4081
  • Electrum Rust Server: 50002
  • lnd GRPC: 10009

Das ist nur ein kleine Auswahl, je nachdem welche Services du nutzen möchtest, brauchst du noch mehr Ausnahmen. Aber generell würde ich eben alles verbieten, was du nicht nutzen möchtest.

Der Watchtower lauscht normalerweise auf 9911 – aber nur, wenn du in Clearnet unterwegs bist. Wenn du ausschließlich Tor nutzt, musst du diesen Port nicht freigeben. 10006 sagt mir eigentlich nichts, aber man kann natürlich beliebige Ports nutzen, es gibt zwar übliche Standardwerte, aber jeder kann davon abweichen!

1 „Gefällt mir“

Es gibt auch ssh-Terminals für das iPhone! Aber ich habe eigentlich fast immer ein Notebook dabei, zumindest wenn ich länger weg bin…

Danke, da mach ich mich mal schlau.
Bin eher selten mal länger weg, höchstens vielleicht der Klassiker Urlaub 1x im Jahr

Schau mal hier gibt es eine Anleitung für den Fernzugriff. Über Cmd klappt es bei mir nicht, dafür aber mit dem SSH Client „PuTTY“.

Das ist lieb gemeint aber es geht in der Anleitung explizit zum Android, das hilft mir nicht weiter :slight_smile: