Bitte ein BYD – zum Update
Allgemein
Nextcloud: aus Alt mach Neu
NextcloudEine nette, kleine Aufgabe: Ziehe ein Nextcloud-System von einem Webserver auf einen anderen um. Klingt zu einfach – der Haken an der Geschichte war rasch gefunden: Nextcloud „alt“ ist Version 24, aktuell ist die Version 29. Somit „alt“ PHP 7.4, „neu“ PHP 8.3. Auf dem alten System kann man nicht updaten, da das PHP zu alt und keine ausreichend neue Version vorhanden ist – auf dem neuen System kann man kein altes Nextcloud installieren, da das PHP dort zu neu und kein ausreichend altes PHP vorhanden ist. Dann halt ganz anders.
Achtung: ein sauberes Update von Nextcloud wird, gemäß Dokumentation, immer von einer auf die nächste Hauptversion gemacht. Also zuerst die aktuell laufende Version auf den letzten Patchstand gehoben, dann der Wechsel der Hauptversion. Also 24.x aktualisieren, dann der Wechsel auf 25. 25.x aktualisieren, dann der Wechsel auf 26. Und dies macht man so lange, bis man bei der aktuellsten Version angekommen ist.
Den Weg wollte ich allerdings nicht gehen – die Quelldistribution war mit RHEL 7 mindestens genauso alt wie Nextcloud 24, somit kam ein Update auf Ubuntu 24.04. Egal welche Distribution: die alte Umgebung hat ein altes PHP, die neue ein neues. Und irgendwie sind die nur bedingt kompatibel zueinander. Also hätte ich im ersten Schritt ein Ubuntu nehmen können, welches ebenfalls PHP 7.4 anbietet. Das grundlegend einrichten, Nextcloud 24 darauf migrieren. Solange Nextcloud Updates machen wie Nextcloud das zulässt. Sobald das Ende erreicht ist, kann man das Ubuntu auf das nächste Release heben. Mit dem nun aktuelleren PHP kann man Nextcloud weiter updaten. Bis auch hier nichts mehr geht, da das PHP zu alt ist. Also wieder Ubuntu auf die nächste Variante bringen und das Spiel nochmals von vorn.
Das wäre „sauber“. Und wäre auch konsequenterweise richtig, wenn am Quellsystem regelmäßig Updates eingespielt worden wären. Dem war aber nicht so, ich bin derjenige der es korrigieren darf. Der obige Weg dauert mir zu lange, deswegen habe ich eine alternative Lösung gesucht.
Nextcloud ist eines der Systeme, welches nach einem Update erkennt, dass die Datenbank eine Aktualisierung braucht. Gegebenenfalls darf man via CLI und occ Befehl noch ein paar Indizies einfügen oder die ein oder andere Anpassung vornehmen. Das war es. Und an genau der Stelle setze ich an:
- Ich installiere auf dem neuen Server ein aktuelles, leeres Nextcloud. Grundlegende Dinge richte ich bereits ein, allerdings nur das allernötigste. Die meisten Einstellungen werden durch die Übernahme der Daten aus dem Altsystem eh überschrieben. Du bist unsicher, was man bereits jetzt tun kann oder nicht? Dann warte bis zum Schluss.
- Nun lösche ich die Datenbank und lege eine neue, aber leere Datenbank an.
- Vom alten System kopiere ich die Datenbank auf den neuen Server.
- Ebenso kopiere ich vom data Verzeichnis die Verzeichnisse der Benutzer. Achtung: Nicht alles, sondern wirklich nur dass, was ein Benutzer ist. Solche Dinge wie die Update-Daten sollte man wirklich überspringen.
- Und nun beginnt die Magie: Es gibt Fälle, da ging der folgende Schritt per WebUI schief. Deswegen lieber die Kommandozeile verwenden. Sobald die Installation etwas größer wird, macht dies eh mehr Sinn. Also an die CLI gewechselt und occ upgrade aufgerufen. Nextcloud entdeckt, dass die Datenbankversion zu alt ist und beginnt deswegen mit den notwendigen Aktualisierungen.
- Im nächsten Schritt meldete ich mich an der WebUI an. Ein grober Blick über die sichtbaren Daten sowie die Benutzer sollte jetzt bereits wieder erfolgreich sein.
- Als Nächstes habe unter Administrationseinstellungen/Verwaltung/Übersicht die Sicherheits- und Einrichtungswarnungen angeschaut und entsprechend alles umgesetzt.
- Hat das alte System Apps, die noch fehlen? Oder das neue, ein paar zu viel davon? Jetzt ist eine gute Gelegenheit.
- Neue Systeme kennen neue Einstellungen. Mal alles auf Plausibilität prüfen – ob das so noch alles heute passt wie damals erdacht.
- Testen, testen, testen …
- Fertig
Das System läuft und ist zudem auf den aktuellsten Stand. Damit das so bleibt, kann man zum Beispiel folgenden Beitrag noch umsetzen: https://gehirn-mag.net/nextcloud-auto-update-via-cli/
Das Kopieren der Daten braucht halt die Zeit, die das Kopieren der Daten nun mal braucht. Allerdings habe ich mir die Update-Orgie erspart. Mal wieder die Welt eines Kunden gerettet, dieser ist glücklich. Mal schauen, welche Herausforderung mich als nächstes erwartet.
Ein IPv6 Homeserver via OPNsense
FirewallEigentlich ist es zu verlockend: Neben einer einzigen IPv4-Adresse weist mir mein Internetprovider auch gleich noch eine IPv6-Adresse zu. Doch halt: Ist das wirklich nur eine einzelne IP-Adresse? Eben nicht, man bekommt einen Netzwerkblock zugewiesen. Ich könnte also jedem einzelnen Rechner, sogar jedem einzelnen Dienst in meinem Heimnetzwerk eine eigene IPv6-Adresse zuweisen. Das eröffnet ungeahnte Möglichkeiten – Es ist Zeit das mal auszuprobieren!
In meiner Umgebung steht eine OPNsense Firewall welche sich ums Internet kümmert. Mein Testserver, welcher von extern erreichbar sein soll, ist ein Ubuntu basiertes System welches sich bei mir in einem Netzwerk mit dem Namen PREP befindet. Der Name ist eigentlich egal, für dieses Beispiel sinniger wäre vermutlich der Begriff DMZ. Als Internetanschluss besitze ich Glasfaser (FTTH), das Prinzip hier gilt jedoch sinngemäß genauso für ADSL. Sogar für statische IP-Adressen ist dieses Beispiel sinngemäß anzuwenden.
Noch eine kurze Anmerkung: Unter IPv6 ist das fehleranfällige NAT für solche Aufgaben unerwünscht. Jeder sollte genügend IPv6 Adressen erhalten, um alle internen Systeme via IPv6 erreichbar zu machen – sofern man möchte. Da man genügend öffentliche IP-Adresse hat, ist kein NAT notwendig.
OPNsense
Meine OPNsense ist via Dualstack am Internet verbunden, d.h. ich habe neben meiner IPv4 noch eine IPv6 Adresse mit einem /56er Präfix anliegen. Obwohl ich Glasfaser habe, ist es vom Verfahren her so wie hier in der Dokumentation von OPNsense beschrieben für DSL. Das macht keinen Unterschied. Hier der Link zur Doku: https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html. Schreibe mir einen Kommentar oder eine Nachricht, falls hierzu weitere Details erwünscht sind.
Meine IPv4 Adresse für dieses Netzwerk ist manuell gesetzt. Für IPv6 ist Track Interface eingetragen. Das zu verfolgende Interface ist WAN, als Prefix-ID verwende ich df (223 dezimal = df hexadezimal).
Sollte ich von meinem Internetprovider als Prefix 2001:0db8:1234:5600/56 erhalten, so beginnen alle IPv6 Adressen in meinem PREP Netzwerk mit dem Prefix 2001:0db8:1234:56df/64. Die letzten zwei Stellen, welche bisher als 00 dargestellt waren, werden durch die gesetzte Prefix-ID ersetzt. Hierbei handelt es sich um zwei hexadezimale Ziffern mit je 4 Bit. Eine hexadezimale Ziffer kennt 16 verschiedene Möglichkeiten von 0 bis f. Das sind 2⁴ = 16 Möglichkeiten. Zwei hexadezimale Ziffern sind somit 8 Bit. Mein Prefix wird also von /56 zu /64 „verlängert“. Das ist auch genauso gewollt, dass man mehrere Netze mit IPv6 Adressen bestücken kann – deswegen bekomme ich von meinem Provider ein /56er Prefix.
Linux
Als Linux verwende ich ein Ubuntu basiertes System. Letztendlich ist egal welches Linux zum Einsatz kommt. Die gezeigten Verfahren sollten bei den gängigsten Distributionen sinngemäß übertragbar sein.
Wie im Screenshot gezeigt, hat mein Ubuntu als IPv6-Adresse unter anderem die 2a00:79c0:72b:2edf::2000/128 erhalten. Das ist ein Beispiel einer Adresse, welche tatsächlich bei mir mal vergeben war. Allerdings nur bis zum nächsten Tag, da wählt sich mein System neu ein und bekommt eine andere IP-Adresse. Zusammengefasst: Diese Adresse ist gültig, allerdings wird dort sicherlich kein System mehr erreichbar sein 😉
Diese IP täte bereits reichen und kann entsprechend verwendet werden. Das Linux-System bekommt bei jedem Neustart erneut diese Adresse zugewiesen. Der Trick ist ziemlich einfach: Unter OPNsense die Seite Services/ISC DHCPv6/Leases öffnen und man findet folgenden Eintrag:
Unter Ubuntu ist es ebenfalls möglich eine eigene Adresse zu setzen, in dem man einen passenden Token definiert. Dieser Token wird einfach an das Prefix angefügt. In diesem Beispiel verwende ich hierfür diesen: 0000:0000:cafe:0001. Abgekürzt wird dies als ::cafe:0001 dargestellt. Dafür wird in der /etc/netplan/00-installer-config.yaml folgende Zeile ergänzt:
network:
ethernets:
ens34:
dhcp4: true
ipv6-address-token: "::cafe:0001"
version: 2
Dies ist eine weitere Möglichkeit eine „statische“ IP zu erhalten, trotz wechselndem Prefix. Mittels „netplan apply“ wird der Eintrag aktiviert.
Nochmals zusammengefasst: Das PREP Netzwerk erhält von OPNsense ein IPv6 Prefix welches in diesem Beispiel um df erweitert wurde um auf 64 Bit zu kommen. Die ersten 56 Bit sind dynamisch und ändern sich bei jeder Einwahl erneut. Die letzten 64 Bit können selbst vergeben werden. Wie oben gezeigt entweder per DHCPv6 oder per ipv6-address-token. Funktionieren tun beide Varianten.
Statische oder dynamische IPv6-Adresse
Sollte man, wie ich ein wechselndes IPv6 Prefix haben, sollte man die IP-Adresse über einen der gängigen DynDNS-Dienste erreichbar machen. Einfach dessen Anleitung befolgen, wie man einen IPv6 Eintrag anlegt. Hat man ein statisches Prefix, kann man den Eintrag direkt in der DNS-Verwaltung vornehmen.
OPNsense Alias
Nun benötigt man in der OPNsense Firewall noch eine Regel, welche übers WAN-Interface den Zugriff auf den Server erlaubt. In diesem Beispiel habe ich ein Apache auf dem Ubuntu installiert, welcher lediglich an Port 80 für http ran geht.
In der OPNsense verwende ich für interne Adressen ganz gerne Aliase. Hat man eine statische IP-Adresse, ist dieser rasch angelegt. Allerdings habe ich ein wechselndes Prefix. Hierfür hat OPNsense allerdings die passende Lösung parat: Ein Alias vom Typ „Dynamic IPv6 Host“. Ich lege also unter Firewall/Aliase einen neuen Alias an, trage einen Namen ein, wählte den erwähnten Typ und setze als Content den Token welcher ebenfalls unter Ubuntu eingetragen wurde: ::cafe:0001 – oder gekürzt als ::cafe:1 dargestellt. Selbstverständlich funktioniert das ebenso für das oben gezeigte ::2000. Als Interface, damit OPNsense das passende Prefix wählt, gebe ich noch mein PREP Netzwerk an.
Funktionskontrolle gefällig? Hierzu unter Firewall/Diagnostic/Aliases wechseln und den neu angelegten Aliase auswählen. In der Liste der IP-Adressen steht bei mir der folgende Eintrag: 2a00:79c0:72b:2edf::cafe:1. Zu Beginn ist das Prefix welches ich von meinem Internetprovider erhalten habe, die Prefix-ID des PREP Interfaces ist df und als Token ist ::cafe:1 hinterlegt. Sobald sich OPNsense neu mit dem Internet verbindet, werden die ersten 56 Bit der Adresse automatisch angepasst.
Firewall Regel
Die Regel für die Firewall ist nun rasch erledigt. Auf dem WAN-Interface eingehend für IPv6, Quelle any und als Ziel der neu angelegte Alias eingetragen. Das war es.
Funktionstest und Fazit
Zum Schluss ein kurzer Funktionstest: Der DNS-Aufruf zeigt die richtige IPv6-Adresse an, ein einfacher Aufruf via curl zeigt die Ausgabe vom Webserver an. Alternativ kann das natürlich ebenso mit einem Webbrowser geöffnet werden – falls man die Konsole nicht mag.
Wie gezeigt, ist es mit OPNsense rasch erledigt einen Homeserver via IPv6 im Internet erreichbar zu machen. Da man genügend öffentliche IPs erhält, kann man jeden Dienst mit einer eigenen IP ausstatten. Und, das angewendete Schema, kann man durchaus auf andere Systeme übertragen: Es muss kein Linux-Server sein, hier geht jedes andere IPv6 fähige Betriebssystem, welches den passenden Dienst anbietet. Ebenso kann OPNsense auf Firewall- bzw. Router-Seite durch alternativen ersetzt werden – solange diese mit wechselnden IPv6 Prefixen umgehen können.
Ich sehe was, was Du nicht siehst …
DNS
2 Punkte für ssh
LinuxZwei Server an verschiedenen Standorten bei irgendeinem der großen Hosting-Provider: Irgendwie möchte man die sogar verbinden. Nur wie? Eine Lösung ganz ohne VPN, mit SSH. (mehr …)
Das Runde muss durch die eckige Leitung
Gestern war alles besserNeulich führte ich ein Gespräch mit einem Techniker. In hitziger Diskussion über die Performance von Kopiervorgängen von Daten hat er mir folgendes an den Kopf geworfen: „… neulich habe ich die gleiche Datenmenge von 500 GB in 4 Stunden über eine 80 MBit Leitung übertragen…“ (mehr …)
Einsame Menschen sollten die Firewall kontrollieren
Gestern war alles besser„Die Warenwirtschaft meldet Benutzername oder Passwort falsch – das muss am VPN bzw. der Firewall liegen…“ „Aha, Du bist also bereits per VPN verbunden und bekommst von der Anwendung die Meldung, dass es da ein Problem mit den Zugangsdaten gibt? Ja, glasklar, dass muss am VPN liegen. Oder sogar an der Firewall…“
„Ich bekomme keine Emails mehr, die Firewall ist schuld.“ „Gestern ging es noch?“ „Ja, gestern war alles in Ordnung.“ „Habt ihr an der Firewall etwas geändert?“ „Nein“ Auch hier wieder: Glasklar, die Firewall ist schuld. Oder vielleicht doch der Postfachspeicher bei dem sich einfach nur ein Service verheddert hat.
Eins meiner persönlichen Highlights: „Ich bekomme keine Emails mehr, die Firewall ist schuld.“ „Gestern ging es noch?“ „Ja, gestern war alles in Ordnung.“ Meine Erfahrung hat mich gelehrt erstmal eine Testnachricht zu schreiben. „Wie, die kam an? Ja kann es einfach nur sein, dass Dir seit gestern niemand mehr eine Email geschickt hat?“ Ergo: Wer an Einsamkeit leidet, sollte die Firewall kontrollieren. Richtig gemein: Die Emailadresse in einschlägigen Newslettern angemeldet: Das Postfach steht nie wieder still. Helfen kann so viel Freude bereiten.
Zurück zum Thema: „Die Webesite lässt sich nicht öffnen, die Firewall ist schuld.“ So langsam kann ich es nicht mehr hören. „Den Stuttgarter Automobilbauer schreibt man übrigens ohne ‚ä'“ „Ach, wirklich?“ „Ja, und es ist sogar egal welchen von beiden Du meinst…“ Also auch hier: Rechtschreibfehler in der URL? Muss an der Firewall liegen welche arglistig Buchstaben vertauscht.
Nebenbei: Missing Feature in Webbrowsern: Eine Rechtschreibkorrektur für URLs. Kann doch so schwer gar nicht sein. Oder warum ist eigentlich nie besetzt wenn man sich verwählt hat? Ach, ich mag solche Themen. Wir schweifen gerade allerdings ab.
Zurück zur eigentlichen Problematik: Hier kommt das Mensch sein einfach nur voll zum tragen. Sobald irgendetwas anders läuft wie von mir erwartet und ich verstehe die Ursache nicht, dann schiebe ich die Schuld auf das was ich am wenigsten kapiere. Also letztendlich auf das was am weitesten weg von mir ist. Einfaches Prinzip, oder? Und dann wird klar was die Aussage „da geht was nicht, die Firewall ist schuld“ wirklich bedeutet: Den Menschen heute ist gar nicht mehr klar warum man überhaupt eine Firewall braucht. Firewalls sind unbequem und schränken nur ein. Eine any-to-any-allow-Regel ist doch sicher genug? Was soll da schon passieren?
Das ist aber nur die Hälfte der Wahrheit: Wenn ich irgendetwas nicht kapiere und die Schuld auf das, was mir am weitesten entfernt liegt schiebe, dann habe ich doch bereits die erste Hälfte der Problematik nicht verstanden: Mir ist gar nicht mehr klar wie eine Anmeldung an einer Warenwirtschaft funktioniert, ich kenne gar keine Details mehr über den Fluss einer Email, der Rechner weiß doch was ich meine – egal ob ich mich vertippe oder nicht.
Aber hey, da hab ich einen Tipp für Dich – weil es ist doch total leicht und eigentlich absolut simpel: Wenn das, was weit weg von mir ist, eine Firewall ist, dann doch hoffentlich auch von dem mir gegenüber. Wie peinlich wäre es zuzugeben, dass ich mein Passwort 3x falsch eingegeben habe. Wie gut, dass mein gegenüber von der Firewall vermutlich genauso wenig Ahnung hat wie ich. Win-Win für beide Seiten. Wunderbar. Mal wieder die Welt gerettet. Ein hoch auf die Firewall. Ironie Ende.
Gecloude, paranoide Sicherheit
EmailDu hast etwas Zeit über und magst lange Texte? Sicherheit in der IT ist genau Dein Ding? Dann lies Dir mal bitte folgende zwei Fallbeispiele durch und entscheide für Dich selbst wie funktionierende Sicherheit hier jeweils aussehen müsste.
Runde 1: Passwortaustausch hipp und modern
Wie überträgt man Passwörter für zum Beispiel IpSec? In derselben Email wie die Proposals? Wohl besser nicht. Also per Fax? Nein, Fax ist total veraltet – wer nutzt den noch so etwas? Per Telefon? Nein, sicherlich nicht. Ist ja noch älter als Fax und das hatten wir ja bereits. Brief? Zu langsam. Email wäre besser. Ach, moment: Stopp. Nein. Zwar gut aber irgendwie doof. Modern und hipp ist „Cloud“. Warum also nicht eine Passwort-Austauch-Cloud? Mit Ende-zu-Ende-Verschlüsselung. Jetzt wird alles gut.
Die Idee ist doch super. Und sicher ist das auch. Ich erkläre mal das Verfahren: Ich erstelle ein zufälliges Passwort welches ich jemand Drittem übertragen muss. Nun melde ich mich an der Webseite eines Cloud-Dienstes an. Das Formularfeld mit dem Passwort wird allerdings bevor es an die Cloud geschickt wird noch entsprechend verschlüsselt. Per Javasript in meinem Webbrowser. Was da also übertragen wird ist ein bereits verschlüsseltes Passwort. Dazu kommt, dass die Seite per https geöffnet ist. Also nochmals verschlüsselt. Das so verschlüsselt übertragene verschlüsselte Passwort wird in der Passwort-Austausch-Cloud abgelegt. Nun muss die Cloud-Plattform dem Empfänger noch mitteilen, dass es hier ein Passwort für ihn gibt. Zum Beispiel per Mail. Also erhält der Empfänger einen Download-Link, kann via https das verschlüsselte Passwort verschlüsselt übertragen und in seinem Webbrowser per JavaScript wieder entschlüsseln. Voila, schon sieht er das von mir erstellte Passwort im Klartext.
Doch Moment, das Ganze hat doch irgendwo einen Haken. Eine Plattform, welche jemand Drittes darüber informiert, dass ein Passwort da ist. Eine Plattform in der Cloud. Die wird wohl via Email benachrichtigen. Könnte ich, anstatt eine zusätzliche Plattform zu verwenden, hier nicht direkt eine Email an den Empfänger senden? Ja, klar – das könnte ich tun. Das würde die Cloud-Plattform einsparen. An der Sicherheit des Verfahrens hätte sich so noch nichts geändert: Ich verschlüssele das Passwort bevor ich es übertrage, übertrage es irgendwie, der Empfänger entschlüsselt das Passwort. Das „übertrage es irgendwie“: Ist doch egal ob Cloud-Plattform oder Email?
Doch schon wieder stopp, halt. Die Cloud-Plattform könnte den Download auf einmal beschränken. Ok, da seh ich jetzt gedanklich zwei Dinge über die man mal nachdenken könnte:
- Es gibt Virenscanner die aus Sicherheitsgründen von zu herunter ladenden Inhalten einen Prefetch machen. Der erste Downloadversuch könnte also bereits beim Scanner scheitern. Zugegeben selten, habe ich aber schon mehrfach erlebt.
- Das hier finde ich ist der spannendere Punkt: Was macht der Empfänger mit diesem einmaligen Download? Er speichert ihn. Damit er ihn öfters lesen kann. Einmal übertragen, aber beliebig oft lesen. Das kann ich nicht beeinflussen. Richtig? Richtig. Dann hätte es auch eine Mail getan: Einmal übertragen, aber beliebig oft lesen. Finde den Unterschied.
Ihr seht schon, es braucht vom Grundsatz her keine Passwort-Austausch-Cloud-Plattform. Email kann das auch. Doch schon wieder Moment, stopp: Da ist doch noch was anderes? Einen ganz wichtigen Punkt habe ich noch gar nicht angesprochen: Ich verschlüssele das Passwort im Browser bzw. für die Mail und übertrage… Ja mit was hab ich den das Passwort verschlüsselt? Mit einem Passwort? Ach, spannend. Und wie übertrage ich dies? Per Email? Ja klar, mit dem Link zum Download bzw. dem verschlüsselten Passwort… Ach nein, Selbstironie Ende. Ich versuche dem gegenüber das Passwort via Telefon zu übertragen. 64 Zeichen: Groß- und Kleinbuchstaben. Dazu noch Ziffern. Schlimmer sind die Sonderzeichen. Da sind einige dabei wo ich nicht mal weiß wie die heißen. Kann Dir nicht passieren? Ok, wie heißen den die beiden hier `und ´? Oder diese beiden hier: ° und µ? Vor allem letzterer: Zeichen wie µ gibt es viele. Bei mir auf meiner Tastatur ist sogar das hier drauf ». Nur weil keine Taste damit beschriftet ist, ist es trotzdem da und kann verwendet werden. Was jetzt?
Nein, Telefon macht hier wenig Spaß. Dann lieber eine Textdatei an eine Email angefügt: 50 nummeriere Zeilen mit möglichen Passwörtern. Dazu geht der Telefonanruf an den Empfänger mit dem Hinweis Zeile 12, allerdings alle „a“ durch „@“ ersetzen, das gleiche für „3“ welches zum „Ä“ wird usw.
Diese Variante braucht einen Telefonanruf und eine Email. Wer will kann die vermeintliche Sicherheit noch zusätzlich erhöhen in dem er die Datei per einmaligem Downloadlink anbietet. Das können inzwischen viele der Dateiplattformen für die Cloud. Bevor wir jetzt an der Stelle ebenfalls wieder ausschweifen mal eine Zusammenfassung der bisherigen Situation.
Zusammenfassung Fall 1
Ok, lasst uns mal 1:1 zusammenzählen was wir erarbeitet haben: Eine Plattform welche Passwörter verschlüsselt um diese verschlüsselt zu übertragen… Irgendwann müssen diese Daten entschlüsselt werden. Wieder per Passwort? Das hat das Problem der Klartextübertragung des Passwortes nur an eine andere Stelle verschoben. Es gibt weiterhin ein Passwort welches im Klartext vorliegt. Aber hat sich die Sicherheit dadurch verbessert? Nicht wirklich: Das Verfahren wurde komplexer, komplexere Verfahren sind anfälliger für Fehler. Und was ist wenn der Download nur einmal angeboten wird? Das würde ja bedeuten, dass es möglich ist das verschlüsselte Passwort bei der Übertragung abzufangen. Ansonsten könnte man den Download mehrfach anbieten: Es kommt doch eh nur die berechtigte Person dort hin. Oder doch nicht? Dieses Problem versuche ich zu umgehen indem ich den Download nur einmal anbiete. Es ist möglich, die Daten abzugreifen. Jetzt speichert der Empfänger die Daten irgendwo. Weil er sie nicht gleich braucht sondern erst in ein paar Tagen dazu kommt. Warum auch immer. Es ist möglich, die Daten abzugreifen. Ihr seht schon: Hat nichts an der Sicherheit geändert, nur der Ort wo ich die Daten abgreifen muss wurde geändert. Komplexität löst keine einfachen Probleme.
Und eine kritische Frage zum Schluss: Gibt es eine große, bekannte und etablierte Plattform zum Austauschen von Passwörtern die diesem Verfahren folgt? Was wäre wenn diese von einem der großen Konzernen mit fragwürdigem Ruf zum Thema Datenschutz angeboten werden würde? Na dann lieber auf den Codeplattformen git und Co gesucht. Da findet sich was. Dank opensource ist das sicher. Ach, ist das so? Den Quellcode selbst geprüft? Du vertraust der Person welche behauptet sie hätte den Quellcode geprüft? Was soll schon passieren, ist doch opensource. Ich mag opensource, das ist kein Geheimnis. Aber wenn das so wäre, wäre opensource per Defintion fehlerfrei. Das ist ein Reifegrad an Software den selbst kommerzielle Produkte wohl nie erreichen werden.
Runde 2: Emails abholen
Die Woche war noch nicht vorbei als folgende Anfrage auf meinem Schreibtisch gelandet ist: Der Besitzer einer Domain betreibe eine Groupware Lösung. Wenn nun Emails von einem Postfach an ein anderes Postfach innerhalb dieser Groupware Lösung übertragen werden, werden diese Daten verschlüsselt übertragen. Ja, das machen moderne Groupware Systeme so. Wenn aber nun eins der Postfächer an jemand externes weitergeleitet werden müsste: Was ist dann? An dieser Stelle will der Kunde ebenfalls sicher stellen, dass die Emails verschlüsselt übertragen werden. So wie wenn das intern wäre. Den Kunden treibt die Angst vor Man-In-The-Middle Angriffen. Ein verständliches Anliegen.
Als Lösung für dieses Thema wurde folgendes Vorgehen vorgeschlagen: Eine Weiterleitung an den extern Mailserver via SMTP ist unerwünscht. Stattdessen wäre ein abholen der Mails via IMAP gewünscht. Allerdings sollte sichergestellt werden, dass der IMAP-Server das richtige Zertifikat vorweist. Doch wann ist ein Zertifikat gültig? Die übliche Vorgehensweise ist prüfe ob der Name des Zertifikats zum zu kontaktierenden Host passt, dass das Zertifikat im Gültigkeitszeitraum liegt und, dass der Aussteller des Zertifikats in der Liste der vertrauenswürdigen Herausgeber liegt.
Hilft das allerdings gegen Man-In-The-Middle? Nein, nur bedingt. „Gültige“ Zertifikate sind ein leichtes zu bekommen. Am sichersten wäre dies Prüfung zu erweitern: In dem man den Fingerabdruck des Zertifikats mit prüft. Allerdings muss man jetzt jedes mal den Fingerabdruck aktualisieren wenn die Gegenseite das Zertifikat verlängert. Und das kann oft der Fall sein – vor allem dann, wenn eines der kostengünstigen Zertifikate mit kurzer Laufzeit verwendet wird. Aber nein, das will der Kunde nicht. Zu aufwändig. Eine allgemeine Prüfung des Zertifikats reicht aus.
Finde den Fehler. Schon einmal darüber nachgedacht was eigentlich erreicht werden sollte? Und was tatsächlich erreicht wird? Da passt eins und eins alles andere als zusammen. Der Kunde will, dass Emails von seinem System sicher zu einem Dritten weitergeleitet werden. Erreicht wird, dass der Dritte prüft von welchem Server er die Mails abholt. Spannende Frage: Was ist wenn er das nicht prüft? Würde das der Kunde mitbekommen? Nein, tut er nicht. Nächste Frage: Der Kunde will, dass die Daten sicher zum Dritten übertragen werden. Per IMAP. Prüft der Kunde wer da gerade die Emails abholt? Also ob der wo gerade den Benutzernamen und das Passwort eingibt auch wirklich der ist den er vorgibt zu sein? Die Sicherheit ist an der Stelle reduziert auf den Benutzernamen und das Passwort. Egal wo und wie verschlüsselt wird. Benutzername und Passwort. Die kann jeder eingeben und verwenden wo diese Daten kennt. Egal ob berechtigt oder nicht.
Das kann so also nicht funktionieren und muss anders gelöst werden. Nur wie? Deswegen rasch nochmal die vier Gründe für Verschlüsselung aufgetischt:
- Vertraulichkeit
- Integrität
- Authentizität
- Verbindlichkeit
Na, das trifft es doch! Der Kunde will, dass nur der berechtigte Dritte die Daten, also die Emails, lesen darf. Seine Beweggründe sind gefunden, es sind die üblichen Verdächtigen. Nur wie werden die bei IMAP erreicht? Das Ziel, welches der Kunde will sind die 4 gezeigten Punkte. Und die erreicht man über die üblichen, verdächtigen Wege: Der IMAP-Server muss sicherstellen, dass er nur dann Emails überträgt wenn der Benutzer „ausreichend“, gemäß den 4 Punkte, authentifiziert ist. Das kann zum Beispiel dadurch passieren, dass der IMAP-Server neben seinem eigenen Zertifikat noch gleich noch für die Authentifizierung das vom IMAP-Client prüft. Nur wenn er dieses kennt, dann ist alles ok. Oder, wer den Schritt nicht mag: Den IMAP-Server hinter ein VPN gepackt. VPN bringt von sich aus ebenfalls die obigen 4 Punkte mit.
Zusammenfassung Runde 2
Es ist hilfreich zu erkennen welche Ziele erreicht werden sollen. Mit dem Blick auf die genau definierten Ziele lassen sich geeignete Wege dorthin erarbeiten. Schwammige Ziele ergeben schwammige Lösungen die in der Regel nur bedingt das tun was man eigentlich erreichen wollte.
Die Absicht des Zieles war klar, der vorgeschlagene Lösungsweg mag im ersten Moment stimmig klingen. Eine kritische Prüfung ob das Ziel damit wirklich zu erreichen ist kann allerdings nie schaden. Der genaue, zweite Blick lohnt sich.
Finale
Ist das oben erklärte die ultimative Lösung für die beiden Fälle? Sicherlich nicht. Zeigt die Diskussion, dass beim Thema Sicherheit durchaus Gesprächsbedarf besteht? Sicherlich ja.
Die Schwierigkeit beim Katz- und Mausspiel ist zu wissen wer die Katze ist. Übertragen auf die beiden Beispiele: Die Schwierigkeit ist zu erkennen welches Ziel wirklich erreicht werden sollte. Sobald dieser wichtige Punkt erkannt ist, ist der Rest rasch erledigt.
Sicherheit first, Bedenken last. Mein Bedenken first wegen der Sicherheit die last endlich auf der Strecke bleibt: total out. Ich bin wohl genauso rückständig und zurückgeblieben wie die alte analoge Telefonie: Total out. Wer jetzt Parallelen zu den aktuellen Bezahlterminals für eletronic cash sucht: Total out. Aber es mag sich am Horizont ein Licht auftun: Man könnte der analogen und veralteten Telefonie einen modernen, digitalen Anstrich verpassen. Dann wäre man eventuell wieder mehr bereit einfach mal zum Telefonhörer zu greifen und nachzufragen…
Sie haben kein Recht auf Ihre Meinung. Sie haben ein Recht auf Ihre fundierte Meinung. Niemand ist berechtigt zur Ignoranz.
Quelle Bild: Wikipedia (https://de.wikipedia.org/wiki/Harlan_Ellison#/media/Datei:Harlan_Ellison_at_the_LA_Press_Club_(cropped).jpg)
Das One-Way-Ticket für eine Netzwerk-Route inkl. Rückfahrt
NetzwerkEs ist mal wieder… öhm… Montag? Ok, dann halt mal Montags. Ein Problem aus der Kategorie seltene Wunder. Kann man auch mal Montags machen. Zwei Rechner, zwei Netze, mitten drin die Firewall. Ping von einem Rechner auf den anderen geht, ein Netzlaufwerk verbinden geht allerdings nicht. Klingt nach Firewall. Oder doch nicht? (mehr …)