Im letzten Beitrag haben wir die Firewall installiert. Falls dies noch nicht geschehen ist, prüfen Sie die dort beschriebenen Schritte.
Basisinstallation auf dem Server
Um nun auf unseren neu-installierten Server komfortabel zuzugreifen, installieren wir OpenSSH. Mit SSH verschlüsselt man Verbindungen zwischen zwei Rechnern und kann Konsolen bedienen, Dateitransfers durchführen usw.
Von der Hosterkonsole aus installieren wir nach erfolgtem Login OpenSSH und öffnen den Port 22 in der Firewall:
sudo apt update
sudo apt install openssh-server
sudo ufw allow 22
Um die IP-Adresse Ihres Server heraus zu bekommen, geben Sie folgendes ein:
ip addr show
Für Ihre Verbindungen zu Ihrem Server finden Sie die IP Adresse und geben schließlich auf Ihrem PC zu Hause ein:
ssh <ihrBenutzername>@<serverIP>
Installation der Windows Powershell
Falls Sie Windows-Nutzer sind, installieren Sie sich am besten die Windows Power-Shell. Gehen Sie unter Windows 10 dazu in die Suche und geben “Features hinzufügen” ein und klicken Sie auf “Windows Features aktivieren und deaktivieren”. Wählen Sie dann die Powershell an:
Öffnen Sie nun die Powershell als Adminstrator und geben ein:
Add-WindowsCapability -Online -Name OpenSSH.Client
Jetzt sind wir wieder zusammen im Boot und können gemeinsam die ssh-Verbindung aufbauen. Wir starten hierzu jedoch eine Powershell ohne Admin-Rechten:
ssh <ihrName>@<serverIP>
Schutz des OpenSSH Servers
Um unberechtigte Zugriffe auf unseren Server zu minimieren und bestimmte Sicherheitsprobleme auszuschließen, werden wir noch ein paar Ergänzungen vornehmen.
Root sperren
Zunächst soll sich root nicht einloggen dürfen. Unter Ubuntu 20.04 LTS passen wir die entsprechende Konfiguration “/etc/ssh/sshd_config” an:
sudo nano /etc/ssh/sshd_config
Wir suchen nach
#PermitRootLogin no
Und ändern dies zu:
PermitRootLogin no
Um den OpenSSH Dienst neu zu starten und die Effekte zu aktivieren:
sudo systemctl restart sshd
Der Server fragt ab jetzt zwar noch artig nach dem root-Passwort, lässt den Angreifer aber am langen Haken verhungern. Jede auch korrekte Passworteingabe wird ab sofort abgelehnt.
UFW Firewall auf Heimnetz beschränken
Eine ziemlich sichere Methode um sich vor Angreifern zu schützen ist das Aussperren von 99,9% der Rechner im Internet. Falls Sie Ihren Server ohnehin nur von zuhause administrieren oder falls Sie über Ihre Mobilgerät eine VPN-Verbindung zu sich nach Hause aufbauen können, dann empfiehlt sich diese Methode.
Nach erfolgter Konfiguration der Server-Firewall akzeptiert Ihr Server auf Port 22 lediglich Verbindungen aus dem Netz Ihres DSL-Anbieters. Aus anderen Netzen erscheint der Port als geschlossen. Um die Netze Ihres DSL-Anbieters freizuschalten prüfen wir zunächst den IP-Adress-Bereich, den wir erlauben müssen. Entweder Sie schauen in Ihrem Router nach oder googlen nach “wie ist meine IP”. Mit der IP gehen wir auf einen “whois”-Anbieter, z.B. whois.com. Die IP-Adresse geben wir in das Suchfeld ein und bekommen den Auszug des IP-Adress-Bereiches unseres DSL-Anbieters.
Beispiel: 67.45.128.0 – 67.45.156.0
Die ersten beiden Stellen bleiben also gleich, egal welche IP-Adresse unser Router täglich bekommt, diese wird immer mit 67.45.x.x beginnen. Diesen Bereich, genannt “Subnetz”, schalten wir frei.
sudo ufw allow from 67.45.0.0/16 to any port 22
Mit einem “Rule added” belohnt uns UFW für unsere Mühen.
Zugegeben, wir öffnen damit etwas mehr als wir müssten. Der Einfachheit halber beschränken wir jedoch nur die ersten beiden Stellen. Die “/16” gibt an, dass die ersten 16 Bit fest stehen (1. Byte: 67, 2. Byte: 45) und definiert das eigentliche Subnetz. “to any port” ist missverständlich. Die Angabe der “22” definiert aber bestimmt nur Port 22 für ssh. Keine Sorge, alle anderen Ports bleiben davon unberührt.
Um nochmal zu prüfen ob alles stimmt:
sudo ufw status verbose
Der Output sieht zunächst gut aus:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN Anywhere
22 ALLOW IN 67.45.0.0/16
22 (v6) ALLOW IN Anywhere (v6)
Jedoch dürfen wir nicht vergessen, Port 22 für den Rest der Welt zu schließen. Damit wir unsere neu, hinzugefügte Regel nicht wieder löschen, lassen wir uns mit:
sudo ufw status numbered
die Gesamtkonfiguration im durchnumerierten Zustand anzeigen:
Status: active
To Action From
-- ------ ----
[ 1] 22 ALLOW IN Anywhere
[ 2] 22 ALLOW IN 67.45.0.0/16
[ 3] 22 (v6) ALLOW IN Anywhere (v6)
und löschen gezielt die 1. Regel in diesem Beispiel:
sudo ufw delete 1
Doch vorsichtig! Die zuvor dritte Regel für IPv6 wollen wir auch löschen. Diese rückte jedoch nun auf Platz 2 hoch:
Status: active
To Action From
-- ------ ----
[ 1] 22 ALLOW IN 67.45.0.0/16
[ 2] 22 (v6) ALLOW IN Anywhere (v6)
Also:
sudo ufw delete 2
Jetzt stimmt es:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN 67.45.0.0/16
Den SSH-Server mit Publickey noch sicherer machen
Wir haben weiter oben den root bereits aus dem Spiel genommen. Falls ein Angreifer unseren OpenSSH-Zugang knacken möchte, muss er durch die Tür des Standard-Nutzers gehen, den wir zuvor angelegt haben. Dieser besitzt noch Zugriff jedoch mit eingeschränkten Rechten.
Dieser Abschnitt beschreibt die Abschaltung der Benutzername/Passwort-Zugänge und die Umstellung auf das Publickey-Verfahren. Insbesondere wenn Ihr Server direkt am Internet zu erreichen ist, finden pro Tag mehrere hunderte Scans und Einbruchsversuche statt. Wir haben zwar den Port 22 bereits für einen erlesenen Kreis von IP-Adressen eingeschränkt, das Publickey-Verfahren erfordert jedoch zusätzlich ein “Public”-Zertifikat von Ihrem PC zu Hause auf Ihrem Server. Ihr Server wird ausschließlich Verbindungen von Ihrem PC akzeptieren.
Auf unserem PC/Mac zuhause erstellen wir den Private- und Publickeys (Linux, Windows, Mac). Der Privatekey wird durch ein Passwort geschützt, der Schlüsselregistrierungsagent gestartet und zum Schluss wird der Schlüssel lokal angemeldet:
ssh-keygen -o -a 100 -t ed25519
eval "$(ssh-agent -s)"
ssh-add .ssh/id_ed25519
Ab jetzt nutzt das Programm “ssh” automatisch den von uns registrierten Schlüssel.
Achtung: Falls Sie einen anderen Namen bei ssh-keygen gewählt haben, dann müssen Sie bei dem dritten Aufruf den Dateinamen entsprechend anpassen.
Wir sind aber noch nicht ganz fertig. Schließlich muss unser Server noch etwas von unserem Publickey-Verfahren wissen. Wir kopieren das Zertifikat nun auf unseren Server (Linux/Mac):
ssh-copy-id -i .ssh/id_ed25519.pub <ihrName>@<serverIP>
Bei Windows ist es etwas komplizierter, da Windows “ssh-copy-id” nicht versteht. Wir kopieren hierzu den Inhalt der Datei unter .ssh/id_ed25519 in die Zwischenablage. Das Format sieht in etwa so aus:
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBeywaqgxi3fwjE1LDcfte8gSv13ayWaMEz9VvYhXg3N hugo@meinWindows
Per ssh bauen wir eine Verbindung noch konventionell per Nutzername/Passwort zu unserem Server auf und kopieren den Text.
mkdir -p ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBeywaqgxi3fwjE1LDcfte8gSv13ayWaMEz9VvYhXg3N hugo@meinWindows" >> ~/.ssh/authorized_keys
Achten Sie darauf, dass Sie den Key mit der rechten Maustaste in die Konsole an der korrekten Stelle hinein kopieren.
Last but not least aktivieren wir das Publickey-Verfahren bei unserem OpenSSL-Server. Wir gehen dazu unter /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_config
und ändern:
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
zu
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
und starten den Dienst neu:
sudo systemctl restart sshd
Loggen wir uns bei ssh mit “exit” wieder aus und wieder ein. Der Server sollte nicht mehr nach dem Passwort fragen.
Nun ist die Passwortauthentifizierung natürlich nicht abgeschaltet. Unser Server fragte uns nur nicht danach, weil unser ssh-Client bereitwillig sein Publickey angeboten hatte und dieser “zufällig” auf dem Server bekannt war. Um die Passwortauthentifizierung komplett aubzuschalten gehen wir nochmal mit nano in die Datei /etc/ssh/sshd_config und ändern die Zeile
#PasswordAuthentication yes
zu
PasswordAuthentication no
Das war’s, wir haben unseren Server mit ssh eingerichtet, die weltweiten Zugriffe unterbunden und mit Publickeys bestimmte Hackerattacken (“Brute Force”) ausgeschlossen.
Tipp: Falls Sie zwischendurch weitere Geräte hinzufügen wollen, können Sie kurzzeitig natürlich “PasswordAuthentification yes” setzen. Das macht den Schlüsselaustausch zumindest bei nicht-Windows-Machinen etwas leichter.
Hier geht es weiter zur Einrichtung von Docker – unserer Basis für unseren Webserver usw. >>>