Rustdesk(top) (Teil 1/3) Installation eigener Relay-Server

RustDesk ist eine freie Software für die grafische Fernsteuerung von Computern. Die Daten werden dabei verschlüsselt übertragen, und die Möglichkeit einen eigenen Relay-Server zu betreiben, macht einen weitgehend unabhängig davon, seine Datenübertragung über fremde Server laufen lassen zu müssen. Damit stellt RustDesk eine der wenigen Open-Source-Lösungen in diesem Bereich dar, welche ohne Zusatzlösungen wie VPNs oder Portweiterleitungen hinter Firewalls oder NATs funktioniert. Um dies zu erreichen, setzt die Software auf einen „Relay-Server“ der die Anfragen des Clients der gesteuert werden soll, und die des Clients der die Steuerung übernehmen soll, vermittelt.

Es existiert ein Fork namens Hoptodesk.

Grundabsicherung des Systems

Ich schränke als erstes die Kommunikation mit dem Server etwas ein. Dazu nutzt ich das Firewalltool „ufw“.

apt -y install ufw

Als erstes gebe ich hier die Ports für Rustdesk frei

ufw allow 21115:21119/tcp
ufw allow 8000/tcp
ufw allow 21116/udp

Wenn man den Zugriff via ssh und via ipv4 von einer bestimmten IP-Adresse aus zulassen will, kann man dies mittels

ufw allow proto tcp from 130.180.xxx.xxx to any port 22

Alternativ erlaubt man den Zugriff via ssh allgemein, und setzt fail2ban ein, oder man nutzt zur weiteren Absicherung noch zusätzlich die Hetzner Firewall, wie im Abschnitt „kleine weitere Absicherung“ beschrieben.

ufw allow ssh

Danach nur noch die Firewall aktivieren,

ufw enable

und abschließend fail2ban installieren. Entweder als echten „Schutz“ und zur Kontrolle, ob die Firewallregeln richtig funktionieren.

apt install fail2ban

Rustdesk installieren

Die folgenden zweiBefehle stoßen nun die Vorbereitung für den Installationsprozess an.

apt install sudo

wget https://raw.githubusercontent.com/dinger1986/rustdeskinstall/master/install.sh
chmod +x install.sh

Jetzt noch das Skript ausführen und den Anweisungen folgen.

./install.sh

Das Skript stellt nun im folgenden einige Fragen. Bei der ersten Frage geht es darum, ob der Server in Zukunft via IP oder DNS Name angesprochen werden soll. Ich wähle hier DNS als Zugriffsmethode. Zur Auswahl gibt man 1 (IP) oder 2 (DNS) ein. Ich wähle hier DNS, um später entsprechende Zertifikate erzeugen lassen zu können.

1) IP
2) DNS/Domain
Choose your preferred option, IP or DNS/Domain:2
Enter your preferred domain/dns address : rdesk.bloy.at

Folgende Ausgabe folgt

Creating /opt/rustdesk
Installing Rustdesk Server
--2023-03-18 10:00:27--  https://github.com/rustdesk/rustdesk-server/releases/download/1.1.7-2/rustdesk-server-linux-amd64.zip
Resolving github.com (github.com)... 140.82.121.4
Connecting to github.com (github.com)|140.82.121.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/299354666/340d84d0-698f-4fbd-9f0c-4a5670797811?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230318%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230318T100028Z&X-Amz-Expires=300&X-Amz-Signature=71b590833e0a5fd4f7ff04bdf88229bc328c436950745b1f2dd7617b913bf5d7&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=299354666&response-content-disposition=attachment%3B%20filename%3Drustdesk-server-linux-amd64.zip&response-content-type=application%2Foctet-stream [following]
--2023-03-18 10:00:28--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/299354666/340d84d0-698f-4fbd-9f0c-4a5670797811?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230318%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230318T100028Z&X-Amz-Expires=300&X-Amz-Signature=71b590833e0a5fd4f7ff04bdf88229bc328c436950745b1f2dd7617b913bf5d7&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=299354666&response-content-disposition=attachment%3B%20filename%3Drustdesk-server-linux-amd64.zip&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.110.133, 185.199.111.133, 185.199.108.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.110.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8219105 (7.8M) [application/octet-stream]
Saving to: ‘rustdesk-server-linux-amd64.zip’

rustdesk-server-linux-amd64.zip                                                100%[====================================================================================================================================================================================================>]   7.84M  --.-KB/s    in 0.1s

2023-03-18 10:00:28 (70.5 MB/s) - ‘rustdesk-server-linux-amd64.zip’ saved [8219105/8219105]

Archive:  rustdesk-server-linux-amd64.zip
  inflating: amd64/hbbr
  inflating: amd64/hbbs
  inflating: amd64/rustdesk-utils
Creating /var/log/rustdesk
Created symlink /etc/systemd/system/multi-user.target.wants/rustdesksignal.service → /etc/systemd/system/rustdesksignal.service.
Created symlink /etc/systemd/system/multi-user.target.wants/rustdeskrelay.service → /etc/systemd/system/rustdeskrelay.service.
Rustdesk Relay not ready yet...
Tidying up install

Als nächstes die Frage, ob man die Konfiguration für einen Webserver und ebendiesen herunterladen und installieren mag.

1) Yes
2) No
Please choose if you want to download configs and install HTTP server: 1

Tidying up Go HTTP Server Install
Created symlink /etc/systemd/system/multi-user.target.wants/gohttpserver.service → /etc/systemd/system/gohttpserver.service.
Your IP/DNS Address is rdesk.bloy.at
Your public key is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Install Rustdesk on your machines and change your public key and IP/DNS name to the above
You can access your install scripts for clients by going to 
Username is admin and password is xxxxxxxxxxxxxxxx
Press any key to finish install

Damit ist die Installation nun abgeschlossen. Die dort angezeigten Zugangsdaten sollten man gut aufheben (z.B. in Keepass).

Admin-Passwort vergessen

Sollte man die Zugangsdaten vergessen haben, sind sie auch in der Datei /etc/systemd/system/gohttpserver.service hinterlegt.

nano /etc/systemd/system/gohttpserver.service

Inhalt der Datei

ExecStart=/opt/gohttp/gohttpserver -r ./public --port 8000 --auth-type http --auth-http admin:xxxxxxxxxxxxxxxx

erste Funktionsprüfung

Um zu schauen, ob der Webserver richtig läuft, kann man einmal den Zugriff darauf wagen. Es sollte dann wie folgt aussehen. Wenn man sich hier anmelden würde, was ich jedoch in diesem Stadium nicht getan habe, da hier dass Anmeldepasswort im Klartext übertragen worden wäre, könnte man folgendes Bild sehen.

Weitere Absicherung des Systems

Die Übertragung der Konfigurationsdateien via http, aber ebenso die Übertragungung eines Passwortes im Klartest, würde ich jedoch gern umgehen. Fernabdavon finde ich es auch immer schön, wenn so viele Komponenten wie möglich, die von außen direkt erreichbar sind, über die Paketverwaltung der jeweiligen Distrubution aktuell gehalten werden.
Ich werde daher im Folgenden erst den direkten Zugriff auf die Seite sperren, und danach einen Reversproxy mit dem Apache einrichten, über den dann später zugegriffen wird.

Zuerst sperre ich den Zugriff auf Port 8000 von außen. Dazu lasse ich mir anzeigen, inkl. Nummerierung, welche Firewallregeln derzeit aktiv sind.

# ufw status numbered

Ausgabe ist folgende Liste.

[ 1] 22/tcp                     ALLOW IN    130.180.87.141
[ 2] 21115:21119/tcp            ALLOW IN    Anywhere
[ 3] 8000/tcp                   ALLOW IN    Anywhere
[ 4] 21116/udp                  ALLOW IN    Anywhere
[ 5] 21115:21119/tcp (v6)       ALLOW IN    Anywhere (v6)
[ 6] 8000/tcp (v6)              ALLOW IN    Anywhere (v6)
[ 7] 21116/udp (v6)             ALLOW IN    Anywhere (v6)

Hier suche ich nun die Regeln heraus, welche Port 8000 betreffen (ipv4 und ipv6), und lösche zuerst die Regel mit der höchsten Zahl. Ansonsten verschieben sich die jeweils folgenden Regeln und ich muss sehr aufpassen, nicht ausversehen die falschen Regeln zu entfernen.

Im Beispiel hier sind es die Regeln 3 und 6

ufw delete 6

Ausgabe ist

Deleting:
 allow 8000/tcp
Proceed with operation (y|n)? y

Reverse Proxy Einrichtung

Der Revers-Proxy soll in Zukunft alle Anfragen von extern annehmen und an den inneren kleinen Webserver weiterleiten. Mehr zum Prinzip kann man in Artikel Revers Proxy bei wikipedia nachlesen.

Als erstes installiere ich dazu den Webserver,

apt install apache2

aktiviere das entsprechende Modul,

a2enmod proxy proxy_http

und erstelle die Konfiguration für die Webseite.

nano /etc/apache2/sites-available/rdesk.bloy.at.conf

Der Inhalt der Datei ist in meinem Fall folgender:

<VirtualHost *:80>
ServerName rdesk.bloy.at
        ServerAdmin patrick@bloy.at
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/ 

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Nun aktivieren ich noch die entsprechende Seite,

a2ensite rdesk.bloy.at

deaktiviere die Default-Seite,

a2dissite 000-default

und starte den Webserver das erste mal (neu).

systemctl start apache2

Soweit wäre der Zugriff noch unverschlüsselt. Für den verschlüsselten Zugriff installiere ich nun certbot, um letsencrypt Zertfikate zu erzeugen.

apt -y install python3-certbot-apache

Damit Letsencrypt jedoch Zertifikate erzeugen kann, und man später auf die Webseiten zugreifen kann, muss ich in der Firewall als ersten Schritt noch die entsprechenden Ports freigeben.

ufw allow http
ufw allow https

Erst jetzt kann ich das Programm aufrufen, und mir ein gültiges Zertifikat erstellen. Dafür führe ich

Jetzt zuerst die entsprechenden Ports freigeben

#ufw allow http

certbot –apache

aus.

Das Programm fragt mich nach einer Mailadresse, die ich eingebe, und über die ich, falls es Probleme mit der Zertfikat gibt(z.B. baldiger Ablauf), erreicht werden kann.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices)
 (Enter 'c' to cancel): Emailadresse@Toplevel-Domain.org

Als nächstes stimme ich den Lizenzbestimmungen zu.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

Ich lege einen entsprechenden Account an,

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y
Account registered.

und lege den DNS-Namen für das Zertifikat fest.

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: rdesk.bloy.at
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for rdesk.bloy.at
Performing the following challenges:
http-01 challenge for rdesk.bloy.at

Nach einen Neustart des Webservers, sollte die Seiten dann verfügbar sein

systemctl start apache2

Abschluss Einrichtung des Cronjobs.

Letsencrypt Zertifikate sind nicht sehr lange gültig, sodass es praktisch ist an diesem Punkt gleich einen Cronjob einzurichten, der in regelmäßigen Zeitabständen (hier zweimal im Monat) der Zertifikat erneuert.

Dazu rufe ich zuerst via

crontab -e

den entsprechenden Editor auf.

Bei den ersten Aufrufen habe ich hier die Wahl.

Select an editor.  To change later, run 'select-editor'.

  1. /bin/nano        <---- easiest

  2. /usr/bin/vim.tiny

Und ergänze folgende Zeite, damit die Befehle je am 15 und am 30 des Monats laufen und alle Ausgaben via „> /dev/null 2>&1“ verwerfen werden.

0 0 */15 * * /bin/bash /usr/bin/certbot renew --post-hook "systemctl reload apache2" > /dev/null 2>&1

Verlasse ich den Editor erhalte ich folgende Meldung, dass der Cronjob erfolgreich beendet wurde.

crontab: installing new crontab

kleine weitere Absicherung

Den Zugang via ssh begrenze ich noch zusätzlich über die Firewall der Hetzner Cloud. Hier trage ich ein, dass nur anfragen von bestimmten IP-Adressen durchgelassen werden.

Dies geschieht über das Webinterface der Cloud im Unterpunkt „Firewall“ des jeweiligen Servers.
Es kann z.B. wie folgt aussehen

Muss ich jetzt einmal von einer anderen IP-Adresse auf das System via ssh Zugreifen, muss ich hier nur einen Eintrag ändern, und habe nicht das Problem, dass ich zuerst via ssh auf das System zugreifen müsste, um mir den Zugriff via ssh zu erlauben. Die Installation von fail2ban ist ab diesem Punkt dann eigentlich nicht mehr notwendig.

Quellen

https://gnulinux.ch/rustdesk-eigenen-relay-server-betreiben

https://rustdesk.com/docs/en/self-host/