Fernzugriff auf den Raspberry Pi – Teil 7 (Die sicherere Verbindung mit HTTPS/SFTP)

0
0

Werbung:

Was kann ich tun um Zugriffe auf meine Dateien zu erschweren?

Zunächst einmal kann keiner auf Daten zugreifen, wenn er nicht an die entsprechenden Passwörter kommt. Über den herkömmlichen Weg sich mit dem Raspberry Pi aus der „ferne“ (was ja auch schon ein anderer Rechner im lokalen Netzwerk sein kann) zu verbinden, werden die Daten(ströme) in der Regel unverschlüsselt übertragen. Ein potentieller Angreifer muss also eigentlich nur den Netzwerkverkehr „mithören“ um nach und nach an Dateien oder sogar Benutzername/Passwortkombinationen zu kommen.

Wie verhindere ich das?

Bisher haben wir den Zugriff auf unseren Raspberry Pi mittels SSH ermöglicht. Weiter bieten wir einen Apache 2 Webserver und einen FTP-Serverdienst an. SSH ist schon relativ sicher, aber die anderen beiden Dienste sind aus Sicherheitsbetrachtungen gesehen offene Scheunentore. Um die Sicherheit zu erhöhen kann man die Daten ab sofort nur noch SSL verschlüsselt übertragen. Je besser/größer der zum Verschlüsseln gewählte Schlüssel ist, umso eher wird sich ein potentieller Angreifer abwehren lassen.

Werbung:

Relativ schnell kann man diesen Schutz durch Verwendung von Zertifikaten erlangen. Diese kann man käuflich erwerben, was den Vorteil besitzt, dass sie von einer Vertrauenswürdigen Zertifizierungsstelle kommen und somit von gängigen Browsern ohne Warnung akzeptiert werden (die Browser haben Listen eingearbeitet, die die Zertifizierungsstellen verifizieren). Eine andere Möglichkeit ist es, sich selbst als Zertifizierungsstelle zu betätigen und sich selbst ein Zertifikat auszustellen. Hier erfolgt dann zwar eine Warnung im Browser, diese kann man aber ignorieren. Plant man seine Dienste nicht privat oder nicht ausschließlich privat anzubieten, ist dies sicherlich keine sehr vertrauenserweckende Methode.

Wie werde ich Zertifikatherausgeber / CA (Certificate Authority)?

Nichts einfacher als dass:

Wir müssen ein Verzeichnis erstellen in dem wir einen CA-Schlüssel erzeugen:

sudo mkdir -p /etc/ssl/apache2/certs

sudo openssl genrsa -des3 -out /etc/ssl/apache2/certs/caprivat.key 4096

Soweit so gut. Das hier verwendete Passwort sollte möglichst lang, schwer zu erraten und geheim sein. Wir werden es noch öfter benötigen, nämlich immer dann, wenn wir ein neues Zertifikat austellen möchten.

Mit diesem Schlüssel, wird im nächsten Schritt die eigentliche CA erstellt:

sudo openssl req -new -x509 -days 3650 -key /etc/ssl/apache2/certs/caprivat.key -out /etc/ssl/apache2/certs/caprivat.crt

Man weist also openssl an eine CA zu erstellen und diese mit dem (zuvor erstellten) Schlüssel zu signieren. Hierbei muss erneut das Passwort angegeben werden. Der Schalter „days 3650“ sorgt dafür, dass unsere CA für die nächsten 10 Jahre gilt. (Danach müssen wir eine neue erstellen).

Als nächstes wird man auf Englisch dazu aufgefordert ein paar Daten zu der Zertifizierungsstelle anzugeben. Da man es ja nur für sich selbst erstellt, erscheint dies etwas amüsant, ist aber dennoch notwendig:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:MeinBundesland
Locality Name (eg, city) []:MeineStadt
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Privat
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:egal.privat.de
Email Address []:root@localhost

Wie erstelle ich ein Zertifikat für den Apache Webserver?

Wir geben folgenden Befehl ein:

sudo openssl genrsa -des3 -out /etc/ssl/apache2/certs/apache.key 4096

Jetzt haben wir einen Schlüssel erzeugt.  Wie bekannt müssen wir auch hier ein Passwort vergeben. Es sollte ein anderes sein, als das zuvor verwendete um die Sicherheit deutlich zu erhähen.

Anders als oben, müssen wir nun einen „Certificate Signing Request (CSR)“ erstellen:

sudo openssl req -new -key /etc/ssl/apache2/certs/apache.key -out /etc/ssl/apache2/certs/apache.csr

Was passiert hier? Wir sagen openssl, nimm den Schlüssen des Servers und mache mir einen Request daraus. Die erzeugte Datei wird also erst noch weiterverarbeitet, nämlich von einer CA (die wir glücklicherweise ja weiter oben schon erstellt haben). Wir werden erneut aufgefordert ein paar Daten einzugeben.

Im Prinzip können wir die selben nochmal verwenden, allerdings ist bei der Eingabe des Domainnamens diesmal die Adresse einzugeben, unter der der Webserver angesprochen wird. Ist dies localhost (also nur im internen Heimnetzwerk) kein Problem, ansonsten sollte man seinen DynDNS Domainnamen parat haben! Ich benutze hierzu meine MyFritz! Adresse.

Mit der so erzeugten Datei können wir auch gleich weiterarbeiten und das tatsächliche Zertifikat für den Webserver erstellen:

sudo openssl x509 -req -in /etc/ssl/apache2/certs/apache.csr -out /etc/ssl/apache2/certs/apache.crt -sha1 -CA /etc/ssl/apache2/certs/caprivat.crt -CAkey /etc/ssl/apache2/certs/caprivat.key -CAcreateserial -days 3650

Wir fordern also openssl auf. Das CSR (Certifikat Sign Request) in ein echtes Zertifikat (CRT) umzuwandeln. Hierfür soll bitte die CA caprivat (caprivat.crt) mit dem Schlüssel caprivat.key verwendet werden. Die Gültigkeit mit „days“ wird wieder auf 10 Jahre gesetzt. (Andere Zeiträume sind natürlich auch möglich).

Jetzt habe ich das Zertifikat.. was jetzt?

Zunächst einmal erstellen wir eine Sicherungskopie:

sudo cp /etc/ssl/apache2/certs/apache.key /etc/ssl/apache2/certs/apache.key.org

danach erfolgt ein Schritt, der etwas zweischneidig ist, weil er einerseits den Kompfort erhöht, aber die Sicherheit minimal verringert. Im Moment ist es so, dass bei jedem Serverneustart (also auch nach einem reboot des raspberry pi’s) das Passwort abgefragt wird. Dies wollen wir umgehen, dass der „Server“ unbeaufsichtigt laufen kann (Wir entfernen das Passwort!):

sudo openssl rsa -in /etc/ssl/apache2/certs/apache.key.org -out /etc/ssl/apache2/certs/apache.key
sudo chmod 0600 /etc/ssl/apache2/certs/*

Der letzte Schritt sorgt für eine Anpassung der Zugriffsreche, die wirklich sinnvoll ist.

 Fertig? …leider nein!

Bisher haben wir mit viel Mühe überhaupt erst mal ein Zertifikat erstellt. Diese Schritte sind notwendig um ein Fälschen von Zertifikaten so unwahrscheinlich und schwierig wie möglich zu machen. Im Nächsten Schritt müssen wir dem Apache 2 Server noch mitteilen, dass er das Zertifikat verwenden soll und wie er das tun soll:

1. Verzeichnis für das Zertifikat und den Schlüssel erstellen

sudo mkdir -p /etc/apache2/ssl

2. Zertifikate und Schlüssel einfügen
sudo cp /etc/ssl/apache2/certs/caprivat.crt /etc/ssl/apache2/certs/apache.crt /etc/ssl/apache2/certs/apache.key /etc/apache2/ssl/

3. Apache 2 Konfigurieren
sudo nano /etc/apache2/sites-available/default-ssl

Hier  folgendes Einfügen, oder ändern:

SSLCertificateFile /etc/apache2/ssl/apache.crt

SSLCertificateKeyFile /etc/apache2/ssl/apache.key

SSLCertificateChainFile /etc/apache2/ssl/caprivat.crt

SSLCACertificateFile /etc/apache2/ssl/caprivat.crt

4. Änderungen übernehmen/aktivieren

Wir machen jetzt die Verwendung von SSL etc. allgemein Schritt für Schritt bekannt:

sudo a2ensite default-ssl
service apache2 reload
sudo a2enmod ssl
service apache2 restart
sudo /etc/init.d/apache2 restart

Der Server sollte jetzt unter “ https://“ im Browser bzw. Port 443 erreichbar sein.

Wie erstelle ich ein Zertifikat für den installierten proftpd FTP-Server?

Zunächst erstellen wir auch hier ein Verzeichnis in dem das Zertifikat abgelegt werden soll:

mkdir /etc/proftpd/ssl

Da wir bereits ein Zertifikat besitzen können wir es weiter benutzen wenn wir abgesichertes SFTP mit TLS verwenden wollen. Wir werden allerdings das Format der Datei ändern um es für proftpd für diesen Zweck nutzbar zu machen:

openssl x509 -in /etc/ssl/apache2/certs/apache.crt -out /etc/proftpd/ssl/proftpd.pem -outform PEM

 

Somit ist das Zertifikat umgewandelt und kann in proftpd verwendet werden.

Proftpd konfigurieren

Wir öffnen die Konfigurationsdatei für proftpd:

sudo nano /etc/proftpd/proftpd.conf

Hier passen wir die Werte an wie wir es benötigen:

DefaultRoot ~
UseReverseDNS off
IdentLookups off
ServerName "Raspian OS FTP Server"
ServerType standalone
DenyFilter \*.*/
RequireValidShell off
Include /etc/proftps/tls.conf

In diesem Fall sichern wir einiges im Gegensatz zu vorher deutlich besser ab. Zum einen verhindern wir, dass sich beliebige Benutzer frei im Dateisystem bewegen können, geben dem Server einen netten Namen (Hier: Raspian OS FTP Server). Dieser ist frei wählbar. Würden wir RequireValidShell auf on setzen, müsste man die Shell benutzen, die als valide gekennzeichnet ist. Manchmal ist ein solches Verhalten unerwünscht. Wer dies nutzen möchte muss seine in /etc/passwd zugeordnete Shell in /etc/shell  eintragen.

Mit dem Include-Befehl aktivieren wir TLS-Support. Im  nächsten Schritt erstellen wir auch sofort diese Datei und bearbeiten diese:

sudo touch /etc/proftpd/tls.conf

sudo nano /etc/proftpd/tls.conf

Folgendes fügen wir ein:

TLSEngine                  on
TLSLog                     /var/log/proftpd/tls.log
TLSProtocol                SSLv23
TLSOptions                 NoCertRequest
TLSRSACertificateFile      /etc/proftpd/ssl/proftpd.pem
TLSVerifyClient            off
TLSRequired                on

Ein Neustart des FTP-Servers ist jetzt sinnvoll!

sudo /etc/init.d/proftpd restart

Übrigens: Die Option TLSRequired sorgt dafür, dass ab sofort nur noch SSL-verschlüsselte Verbindungen ablaufen. Da diese über den Standardport 22 laufen, werden alle Anfragen über Port 21 abgewiesen!

Im letzten Schritt müssen wir die Weiterleitungen in unserem Router anpassen und neu definieren.

0
0

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.