#Absichern Ihres Knotens

Das Ziel dieser Anleitung ist es, Sie durch Schritte zu führen, die Sie unternehmen können, um Ihren Knoten gegen böswillige Akteure abzusichern. Egal, ob Sie einen lokalen Server zu Hause oder einen VPS-Server / eine virtuelle Maschine in der Cloud betreiben, die hier gegebenen Tipps werden Ihnen helfen, Ihren Knoten gegen externe Angriffe zu härten und ihn während seiner Lebensdauer zu schützen.

Dieser Abschnitt beschreibt sowohl wesentliche Aktionen, die Sie durchführen müssen, als auch empfehlenswerte Aktionen, die hilfreich, aber nicht erforderlich sind.

#Annahmen in dieser Anleitung

Diese Anleitung geht davon aus, dass Ihr Knoten Ubuntu 20.04 LTS ausführt. Die Konzepte lassen sich auf andere Systeme übertragen, aber die Beispielbefehle möglicherweise nicht.

Wie bei allen Befehlen in dieser Anleitung gehen wir davon aus, dass Sie sich remote mit dem Kommandozeilenterminal Ihres Knotens über ssh verbinden. Wenn Sie eine Auffrischung zur Verwendung von ssh benötigen, werfen Sie zuerst einen Blick auf die Einführung in Secure Shell Anleitung.

#WESENTLICH: Halten Sie Ihre Client-Maschine sicher

Die meisten Smartnode-Betreiber interagieren remote mit ihrem Knoten, indem sie sich von einem anderen Computer aus mit dessen Terminal über ssh verbinden:

• Die Maschine, mit der Sie sich verbinden zu (in diesem Fall Ihre Knotenmaschine) wird als Server bezeichnet.
• Die Maschine, von der Sie sich verbinden von (wie Ihr Laptop, Desktop oder sogar Ihr Telefon) ist der Client.

Eine der wichtigsten Maßnahmen, die Sie ergreifen können, um Ihren Smartnode zu sichern, ist es, Ihre Client-Maschine sicher zu halten. Wenn Ihre Client-Maschine kompromittiert ist und Sie sie verwenden, um sich bei Ihrem Knoten anzumelden, können die meisten Sicherheitseinstellungen, die Sie auf den Knoten anwenden, umgangen werden.

Zum Beispiel: Wenn Sie einen Laptop als SSH-Client verwenden und er einen Keylogger installiert hat, werden alle geheimen Dinge, die Sie auf dem Knoten eingeben (wie Ihr Passwort oder Ihre Wiederherstellungs-Mnemonic), wenn Sie über SSH verbunden sind, gestohlen.

Es gibt keinen definitiven Leitfaden, um Ihre Client-Maschine sicher zu halten, aber sich bewusst zu sein, dass sie ein Faktor in Ihrer Sicherheit ist, ist ein guter erster Schritt. Stellen Sie sicher, dass Ihre Client-Maschine so sicher wie möglich ist.

Hier sind ein paar Tipps:

• Verwenden Sie Ihre Client-Maschine nicht für riskante Aktivitäten (wie den Besuch nicht vertrauenswürdiger Websites oder die Installation unnötiger Programme)
• Halten Sie Ihre Client-Maschine mit den neuesten Sicherheitspatches auf dem neuesten Stand
• Verwenden Sie, wenn möglich, ein Malware- und Antivirenschutzprogramm für Ihr Betriebssystem

Für maximale Sicherheit möchten Sie möglicherweise eine dedizierte Maschine als Ihren SSH-Client verwenden, obwohl dies für Sie möglicherweise nicht praktikabel ist.

#WESENTLICH: Sichern Sie Ihren SSH-Zugang

Ob Sie Ihren Smartnode zu Hause betreiben oder einen VPS in einem entfernten Rechenzentrum verwenden, es ist wahrscheinlich, dass Sie entweder über SSH darauf zugreifen oder dass SSH aktiviert ist, auch wenn Sie es nicht verwenden.

SSH-Verbindungen basieren auf sicherer Kryptographie, aber wie bei jedem sicheren System kommt die eigentliche Sicherheit von der korrekten Verwendung. Es gibt zwei Hauptdinge für Ihre SSH-Einstellungen zu tun:

1. Verwenden Sie einen SSH-Schlüssel für die Remote-Anmeldung anstelle eines Benutzernamens und Passworts
2. Deaktivieren Sie die passwortbasierte Authentifizierung vollständig, sodass SSH-Schlüssel die einzige Option für die Remote-Anmeldung sind

Wie Sie wahrscheinlich inzwischen vertraut sind, ist die Standardmethode, sich über SSH bei Ihrem Knoten anzumelden, mit einem Benutzernamen und Passwort. Der Nachteil dabei ist, dass Ihr Passwort typischerweise etwas eher "kurz" ist und anfällig für Brute-Force-Angriffe.

Glücklicherweise gibt es eine alternative Möglichkeit, sich über SSH anzumelden: ein SSH-Schlüsselpaar.

SSH-Schlüsselpaare funktionieren ähnlich wie Blockchain-Wallets; sie bestehen aus einem öffentlichen Teil (wie Ihre Wallet-Adresse) und einem privaten Teil (dem privaten Schlüssel für Ihre Wallet-Adresse):

• Sie stellen den öffentlichen Teil Ihrem Knoten zur Verfügung. Auf diese Weise weiß der Knoten, dass Sie berechtigt sind, sich mit ihm zu verbinden, und er weiß, dass Sie es wirklich sind, die versuchen, sich zu verbinden.
• Sie behalten den privaten Teil für sich auf Ihrer Client-Maschine. Auf diese Weise können Sie (und nur Sie) sich mit Ihrem Knoten verbinden.
  • Sie können (und sollten!) den privaten Teil mit einem Passwort schützen, sodass jemand, der Ihren Schlüssel stiehlt, ihn nicht verwenden kann.
• Aus der Perspektive eines Computers ist der private Schlüssel exponentiell schwerer zu knacken als ein Passwort. Dies mindert das Risiko eines Brute-Force-Angriffs gegen Ihren Knoten.

#Erstellen eines SSH-Schlüsselpaars

Beginnen wir damit, ein neues SSH-Schlüsselpaar auf Ihrer Client-Maschine zu erstellen. Es gibt viele Arten von Schlüsseln, aber wir werden einen Schlüsseltyp namens ed25519 verwenden, der hervorragende Sicherheit bietet.

Führen Sie den folgenden Befehl auf Ihrer Client-Maschine aus (d.h. Sie sollten dies nicht ausführen, während Sie bereits über SSH mit Ihrer Knotenmaschine verbunden sind - wenn Sie es sind, beenden Sie zuerst SSH):

ssh-keygen -t ed25519 -C "your_email@example.com"

Sie werden Folgendes sehen:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519):

Dies fragt Sie, wo Sie Ihre private Schlüsseldatei speichern möchten. SSH ist mit der bereitgestellten Standardeinstellung kompatibel und wird sie automatisch für Sie verwenden, wenn Sie sie auswählen. Sie haben jedoch die Möglichkeit, sie in etwas anderes zu ändern, wenn Sie möchten.

Wenn Sie mit der Standardeinstellung zufrieden sind, drücken Sie einfach Enter.

Andernfalls geben Sie Ihren gewünschten Speicherort für den Schlüssel ein. Es muss ein absoluter Pfad sein (z.B. /home/username/.ssh/rocketpool_key unter Linux oder /Users/username/.ssh/rocketpool_key unter OSX). Drücken Sie Enter, wenn Sie fertig sind.

Nach dem Drücken von Enter werden Sie Folgendes sehen:

Enter passphrase (empty for no passphrase):

Dies wird das Passwort für den privaten Schlüssel selbst. Wann immer Sie den Schlüssel verwenden, um sich mit Ihrem Knoten zu verbinden, müssen Sie zuerst dieses Passwort eingeben.

Sobald Sie das Passwort eingegeben haben, drücken Sie Enter. Es wird Sie bitten, es zur Bestätigung erneut einzugeben.

Danach werden Sie eine Ausgabe wie die folgende sehen:

Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:CASbPZETiQ83lLhpUO2aoT05TxMVLwqiWtdsRtoPt4s your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
| .o*==..         |
|. +=O...         |
|..+B++o .        |
|..=.+X o         |
|.+.=+.O S        |
|o.B.oo + .       |
|.  = .  o        |
|    .  . .       |
|      E .        |
+----[SHA256]-----+

Die erste Zeile gibt den Speicherort des privaten Schlüssels an, der standardmäßig id_ed25519 genannt wird (beachten Sie, dass er keine Dateierweiterung hat). Ubuntu lädt diesen Schlüssel automatisch für Sie, wenn Sie ssh verwenden, wenn diese private Schlüsseldatei am Standardspeicherort liegt.

Die zweite Zeile gibt den Speicherort des öffentlichen Schlüssels an, der standardmäßig id_ed25519.pub genannt wird. Wir werden den öffentlichen Schlüssel für den nächsten Schritt benötigen.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

alias loadkey='ssh-add $HOME/.ssh/id_ed25519'

#Hinzufügen des öffentlichen Schlüssels zu Ihrem Knoten

Sobald Sie Ihr SSH-Schlüsselpaar haben, können Sie nun den öffentlichen Schlüssel zu Ihrem Knoten hinzufügen. Dies ermöglicht es Ihnen, sich über ssh mit dem privaten Schlüssel, den Sie gerade generiert haben, zu verbinden, anstatt mit Ihrem Benutzernamen und Passwort.

Es gibt zwei Möglichkeiten, dies zu tun - wenn eine nicht funktioniert, versuchen Sie die andere:

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub username@node.ip.address

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub staker@192.168.1.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine with:   "ssh 'username@node.ip.address'"
and check to make sure that only the key(s) you wanted were added.

cat ~/.ssh/id_ed25519.pub

type %USERPROFILE%\.ssh\id_ed25519.pub

type $ENV:UserProfile\.ssh\id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGUgU3a6mNjy3N1TyWOwY+VA/nifAeABl2Ch2yIl1bGa your_email@example.com

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

Sie sollten nun in der Lage sein, sich wie gewohnt über ssh bei dem Knoten anzumelden, aber jetzt müssen Sie nicht mehr das Passwort des Benutzerkontos eingeben.

Stattdessen müssen Sie das Passwort Ihres privaten SSH-Schlüssels eingeben. Abhängig von Ihren Systemeinstellungen müssen Sie dies möglicherweise nur einmal pro Neustart tun, oder Sie müssen es jedes Mal tun, wenn Sie den Schlüssel verwenden, um sich mit Ihrem Knoten zu verbinden.

#Anmeldung per Passwort deaktivieren

Auch wenn Sie ein SSH-Schlüsselpaar eingerichtet haben, erlaubt Ihr Knoten anderen Maschinen immer noch, zu versuchen, sich mit der Benutzername-und-Passwort-Methode anzumelden. Dies macht den gesamten Zweck der Verwendung von SSH-Schlüsseln zunichte, daher besteht der nächste Schritt darin, diese zu deaktivieren.

Beginnen Sie damit, sich wie gewohnt mit ssh bei Ihrer Maschine anzumelden:

ssh user@your.node.ip.address

Zur Erinnerung, Sie sollten dies zweimal in zwei separaten Terminals tun, damit Sie eine Backup-Sitzung für alle Fälle haben. Sie können die Backup-Sitzung vorerst ignorieren - wir sagen Ihnen, wann Sie sie brauchen. Führen Sie die folgenden Befehle nur in der ersten Sitzung aus.

Öffnen Sie die Konfigurationsdatei für den SSH-Server:

sudo nano /etc/ssh/sshd_config

Wie bei allen Befehlen, die mit sudo beginnen, werden Sie nach dem Passwort Ihres Benutzerkontos gefragt. Dies ist eine große Datei, daher müssen Sie mit den Pfeiltasten auf Ihrer Tastatur oder Page Up / Page Down durch sie navigieren.

Nehmen Sie die folgenden Änderungen vor:

1. Entkommentieren Sie #AuthorizedKeysFile, falls es kommentiert ist (indem Sie die # davor entfernen)
2. Ändern Sie KbdInteractiveAuthentication yes zu KbdInteractiveAuthentication no und entkommentieren Sie (indem Sie die # davor entfernen) - beachten Sie, dass ältere Versionen von SSH diese Option ChallengeResponseAuthentication statt KbdInteractiveAuthentication nennen
3. Ändern Sie PasswordAuthentication yes zu PasswordAuthentication no und entkommentieren Sie (indem Sie die # davor entfernen)
4. Ändern Sie PermitRootLogin yes zu PermitRootLogin prohibit-password, es sei denn, es ist bereits darauf eingestellt und hat eine # davor

Sobald Sie fertig sind, speichern Sie mit Ctrl+O und Enter, dann beenden Sie mit Ctrl+X.

Führen Sie schließlich sudo sshd -T | grep -i passwordauthentication aus und stellen Sie sicher, dass es passwordauthentication no ausgibt. Wenn nicht, müssen Sie möglicherweise sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf ausführen und PasswordAuthentication yes auf PasswordAuthentication no auch in dieser Datei setzen. Speichern und beenden Sie wie zuvor mit Ctrl+O und Enter, dann Ctrl+X

Starten Sie als Nächstes den SSH-Server neu, damit er die neuen Einstellungen übernimmt:

sudo systemctl restart ssh.service

Danach sollte die Anmeldung bei SSH über einen Benutzernamen und ein Passwort deaktiviert sein.

#(Optional) Zwei-Faktor-Authentifizierung aktivieren

Bei der Zwei-Faktor-Authentifizierung wird zusätzlich zu Ihrem Passwort oder SSH-Schlüssel eine zweite Sicherheitsmaßnahme erforderlich, normalerweise auf einem separaten Gerät von Ihrem primären Gerät.

Sie kennen sich möglicherweise damit aus, sich auf einer Website wie einer Krypto-Börse sowohl mit einem Passwort als auch einem Google Authenticator-Code (oder einem SMS-Code) anzumelden. Dieser zweistufige Prozess ist ein Beispiel für Zwei-Faktor-Authentifizierung.

SSH kann auch so konfiguriert werden, dass ein Google Authenticator-Code erforderlich ist, was bedeutet, dass ein Angreifer, der irgendwie Ihren SSH-Schlüssel und seine Passphrase kompromittiert hat, immer noch das Gerät mit der Authenticator-App darauf benötigen würde (vermutlich Ihr Telefon). Dies fügt Ihrem System eine zusätzliche Sicherheitsebene hinzu.

Beginnen Sie damit, Google Authenticator (oder eine kompatible Alternative) auf Ihrem Telefon zu installieren, falls Sie es nicht bereits haben. Für Android-Benutzer sollten Sie andOTP in Betracht ziehen, eine Open-Source-Alternative, die Passwortschutz und bequeme Backups unterstützt.

Installieren Sie als Nächstes das Google Authenticator-Modul auf Ihrem Knoten mit diesem Befehl:

sudo apt install -y libpam-google-authenticator

Sagen Sie nun dem PAM (Pluggable Authentication Modules), dieses Modul zu verwenden. Öffnen Sie zuerst die Konfigurationsdatei:

sudo nano /etc/pam.d/sshd

Finden Sie @include common-auth (es sollte ganz oben sein) und kommentieren Sie es aus, indem Sie eine # davor setzen, sodass es so aussieht:

# Standard Un*x authentication.
#@include common-auth

Fügen Sie als Nächstes diese Zeilen am Anfang der Datei hinzu:

# Enable Google Authenticator
auth required pam_google_authenticator.so

Speichern und beenden Sie dann die Datei mit Ctrl+O, Enter und Ctrl+X.

Da PAM nun weiß, dass Google Authenticator verwendet werden soll, besteht der nächste Schritt darin, sshd zu sagen, dass es PAM verwenden soll. Öffnen Sie die sshd-Konfigurationsdatei:

sudo nano /etc/ssh/sshd_config

Ändern Sie nun die Zeile KbdInteractiveAuthentication no zu KbdInteractiveAuthentication yes, sodass es so aussieht:

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication yes

(Ältere Versionen von SSH nennen diese Option ChallengeResponseAuthentication statt KbdInteractiveAuthentication.)

Fügen Sie die folgende Zeile am Ende der Datei hinzu, die sshd anzeigt, dass sowohl ein SSH-Schlüssel als auch der Google Authenticator-Code erforderlich sind:

AuthenticationMethods publickey,keyboard-interactive:pam

Speichern und beenden Sie dann die Datei mit Ctrl+O, Enter und Ctrl+X.

Da sshd nun eingerichtet ist, müssen wir unsere 2FA-Codes erstellen. Führen Sie in Ihrem Terminal aus:

google-authenticator

Zuerst wird es Sie nach zeitbasierten Token fragen. Sagen Sie y zu dieser Frage:

Do you want authentication tokens to be time-based: y

Sie werden nun einen großen QR-Code auf Ihrem Bildschirm sehen; scannen Sie ihn mit Ihrer Google Authenticator-App, um ihn hinzuzufügen. Sie werden auch Ihr Geheimnis und einige Backup-Codes sehen, die so aussehen:

Your new secret key is: IRG2TALMR5U2LK5VQ5AQIG3HA4
Your verification code is 282436
Your emergency scratch codes are:
  29778030
  86888537
  50553659
  41403052
  82649596

Schließlich wird es Sie nach einigen weiteren Parametern fragen; die empfohlenen Standardwerte sind wie folgt:

Do you want me to update your "/<username>/.google_authenticator" file: y
Do you want to disallow multiple uses of the same authentication token: y
By default... < long story about time skew > ... Do you want to do so: n
Do you want to enable rate-limiting: y

Sobald Sie fertig sind, starten Sie sshd neu, damit es die neuen Einstellungen übernimmt:

sudo systemctl restart sshd

Wenn Sie versuchen, sich mit Ihren SSH-Schlüsseln per SSH bei Ihrem Server anzumelden, sollten Sie jetzt auch nach einem 2FA-Verifizierungscode gefragt werden, aber nicht nach einem Passwort.

#WESENTLICH: Automatische Sicherheitsupdates aktivieren

Betriebssystemanbieter veröffentlichen regelmäßig Updates und Sicherheitskorrekturen, daher ist es wichtig, dass Sie Ihr System mit den neuesten Patches auf dem neuesten Stand halten. Der einfachste Weg, dies zu tun, ist, automatische Updates zu aktivieren.

Führen Sie die folgenden Befehle auf Ihrer Knotenmaschine aus:

sudo apt update
sudo apt install -y unattended-upgrades update-notifier-common

Sie können die Auto-Update-Einstellungen ändern, indem Sie /etc/apt/apt.conf.d/20auto-upgrades bearbeiten:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Dies ist ein Beispiel für vernünftige Auto-Update-Einstellungen:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

# This is the most important choice: auto-reboot.
# This should be fine since Rocketpool auto-starts on reboot.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Wenn Sie mit dem Hinzufügen Ihrer Änderungen fertig sind, speichern Sie mit Ctrl+O und Enter, dann beenden Sie mit Ctrl+X.

Stellen Sie danach sicher, die neuen Einstellungen zu laden:

sudo systemctl restart unattended-upgrades

#WESENTLICH: Eine Firewall aktivieren

Im Allgemeinen sollte Ihre Maschine nur Netzwerkverkehr auf Ports akzeptieren, die Ihr Execution-Client, Consensus-Client und Smartnode-Stack verwenden. Um dies durchzusetzen und unerwarteten oder unerwünschten Verkehr zu verhindern, können wir eine Firewall auf dem Knoten installieren.

Ubuntu wird standardmäßig mit ufw geliefert (der unkomplizierte Firewall), ein praktisches Dienstprogramm zur Verwaltung der Firewall-Einstellungen Ihres Knotens.

Die folgenden Befehle richten ufw mit einer guten Standardkonfiguration für Ihren Smartnode ein. Führen Sie diese auf Ihrer Knotenmaschine aus.

Deaktivieren Sie Verbindungen, es sei denn, sie sind durch spätere Regeln ausdrücklich erlaubt:

sudo ufw default deny incoming comment 'Deny all incoming traffic'

Erlauben Sie SSH:

sudo ufw allow "22/tcp" comment 'Allow SSH'

Erlauben Sie Execution-Client (früher als ETH1 bezeichnet):

sudo ufw allow 30303/tcp comment 'Execution client port, standardized by Rocket Pool'
sudo ufw allow 30303/udp comment 'Execution client port, standardized by Rocket Pool'

Erlauben Sie Consensus-Client (früher als ETH2 bezeichnet):

sudo ufw allow 9001/tcp comment 'Consensus client port, standardized by Rocket Pool'
sudo ufw allow 9001/udp comment 'Consensus client port, standardized by Rocket Pool'

Wenn Sie Lighthouse-Client v4.5.0+ ausführen, können Sie das QUIC-Protokoll verwenden, um die Latenz zu reduzieren / die Bandbreite zu erhöhen. Das QUIC-Protokoll verwendet standardmäßig den Port von Lighthouse + 1, um QUIC-Nachrichten zu empfangen: https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

sudo ufw allow 8001/udp comment 'Consensus client port, standardised by Rocket Pool'

Aktivieren Sie schließlich ufw:

sudo ufw enable

#(Optional) Brute-Force- und DDoS-Schutz aktivieren

Um Ihren Server vor DDoS-Angriffen und Brute-Force-Verbindungsversuchen zu schützen, können Sie fail2ban installieren. Dieses Programm überwacht eingehende Verbindungen und blockiert IP-Adressen, die wiederholt versuchen, sich mit falschen Anmeldeinformationen anzumelden.

Weitere Informationen zum Schutz vor Eindringlingen finden Sie in dieser Anleitung.

Führen Sie die folgenden Befehle auf Ihrer Knotenmaschine aus:

Installieren Sie den Dienst:

sudo apt install -y fail2ban

Öffnen Sie als Nächstes /etc/fail2ban/jail.d/ssh.local:

sudo nano /etc/fail2ban/jail.d/ssh.local

Fügen Sie folgende Inhalte hinzu:

[sshd]
enabled = true
banaction = ufw
port = 22
filter = sshd
logpath = %(sshd_log)s
maxretry = 5

Sie können die maxretry-Einstellung ändern, die die Anzahl der Versuche ist, die sie zulässt, bevor die beleidigende Adresse gesperrt wird.

Sobald Sie fertig sind, speichern und beenden Sie mit Ctrl+O und Enter, dann Ctrl+X.

Starten Sie schließlich den Dienst neu:

sudo systemctl restart fail2ban

Und damit haben Sie gerade die Sicherheitslage Ihres Knotens erheblich verbessert. Herzlichen Glückwunsch!