Passwort im Klartext im Konfigurationsfile? Darf man das noch?

[meyergru]

Richtig, der Schlüssel muss vorliegen. Aber so wie ich das kenne, eben nicht im Konfigurations-Backup.

Der könnte ja in einer 2. Datei liegen, welche man nicht weiterreicht.

...und die dann wie gesichert und zum Wiederherstellen genutzt wird? Das ist doch der Hauptzweck dieser Datei, nicht, dass Du sie ungefiltert weiterreichst. Du kannst sie ja insgesamt verschlüsseln.

Es geht mir primär nur darum, dass das Passwort nicht unverschlüsselt in der Konfigurationsdatei ist. So aus meiner Erfahrung liegen Kopien von diesen Dateien mit der Zeit an allen möglichen Orten Sie werden auf dem Desktop gespeichert, sie werden dem Kollegen weitergereicht, sie werden an ungeschützen Orten gespeichert oder eben an Supportleute weitergereicht etc., etc.

Dann ließe sich aus dem Konfigurationsbackup nicht mehr der Zustand wiederherstellen. Anders gesagt: Der Konfigurationsbackup wäre funktional kaputt.

[Patrick M. Hausen]

Zum letzten Mal: der einzige (!) Sinn und Zweck dieser Konfigurationsdatei ist ein vollständiges Backup der gesamten Konfiguration einer produktiven Firewall. Kiste geht kaputt, Ersatzgerät aus dem Schrank ziehen, OPNsense drauf bügeln, Konfigurationsdatei einspielen - Firma hat wieder Netzwerk. Dazu ist das da, und entsprechend hat der geneigte Adminsitrator mit diesen Daten umzugehen.

[cadzen]

2. Das ist natürlich kein Bullshit, sondern insbesondere für Firmen in der DS-GVO vorgeschrieben. Der sorgfältige Umgang mit Daten und insbesondere Passwörtern kann nicht mehr so sorglos gemacht werden.

Na dann hast Du wohl deine Sorgfaltspflicht verletzt, wenn du Dateien mit Passwörtern durch die Gegend schickst.

Es mir nur darum, dass man nicht unbedingt damit rechnet, dass ein Gerät eine Konfigurationsdatei erstellt mit Klartextpasswörtern. Es ist nicht unüblich, dass man solche Dateien gelegentlich mal einem Support z.B. bei Cisco oder Zyxel einschickt.

Wenn du weißt, dass deine Passwörter da im Klartext drinstehen, nimm sie raus, bevor du die Datei an wen auch immer schickst. Fertig. Da brauch ich keine gesetzlichen Vorgaben dazu und schon gar keine DS-GVO.

[NickFrost]

...und die dann wie gesichert und zum Wiederherstellen genutzt wird? Das ist doch der Hauptzweck dieser Datei, nicht, dass Du sie ungefiltert weiterreichst. Du kannst sie ja insgesamt verschlüsseln.

Verschlüsselt z.B. an den Support weiterreichen? Macht wohl keinen Sinn.

Sinn und Zweck dieser Konfigurationsdatei ist ein vollständiges Backup der gesamten Konfiguration einer produktiven Firewall. Kiste geht kaputt, Ersatzgerät aus dem Schrank ziehen, OPNsense drauf bügeln, Konfigurationsdatei einspielen - Firma hat wieder Netzwerk.

Funktioniert als Industriestandar eigentlich so: Ersatzgerät aus dem Schrank ziehen, Konfigurationsdatei raufladen, Secrets wieder herstellen - Firma hat wieder Netzwerk. Klar, ist ein Schritt mehr, aber wen kümmern schon vertrauliche Daten.

Na dann hast Du wohl deine Sorgfaltspflicht verletzt, wenn du Dateien mit Passwörtern durch die Gegend schickst.

Das ist genau der springende Punkt. Der Anwender ist dann der Dumme kann in Haftung genommen werden.

Allerdings wird heutzutage selbstverständlich erwartet, dass auch Hersteller alles technisch mögliche unternehmen, damit so ein Fall eben nicht eintreten kann.

Wenn du weißt, dass deine Passwörter da im Klartext drinstehen, nimm sie raus, bevor du die Datei an wen auch immer schickst. Fertig. Da brauch ich keine gesetzlichen Vorgaben dazu und schon gar keine DS-GVO.

Das muss man aber erst wissen, dass hier unverschlüsselte Passwörter drin sind. Die Datei ist recht gross und in der heutigen Zeit rechnet man (eben wegen den geltenden Sicherheitsstandards) nicht mehr damit, dass Passwörter offen da liegen. Auch in der GUI wird nicht darauf hingeweisen, dass dieses Passwort unverschlüsselt abgespeichert wird. Aber hey, DSGVO ist ja eh nur für Idioten, was geht uns das an.


Für mich ist die Diskussion hier abgeschlossen. Danke für die Beteiligung. Ich komm mir im Umgang mit vertraulichen Daten allerdings grad vor wie vor 40 Jahren. Es ist aus meiner Sicht einfach die Passwörter oder ein Masterpasswort/Schlüssel/Secrets separat von der Konfiguration zu speichern. Das kostet nichts, ist einfach zu implementieren, ist heute Industriestandard und würde auch die Wiederherstellung eines Backup keinesfalls erschweren.

[Monviech (Cedrik)]

Rein theoretisch, wann das Passwort Feld in der config.xml bei allen Plugins und Core Plugins immer <password> heißt, könnte man in der GUI doch eine Checkbox anbieten die besagt "Konfigurationsdatei ohne Kennwörter exportieren".

Ich bin mir hier nicht sicher wie weit <password> ein standardisiertes Feld ist, oder wie aufwändig sowas im Konfig Exporter zu realisieren wäre.


Es scheint hier ja nur darum zu gehen, dass es keine exportierte Konfig geben kann, in der alle passwörter <password>OMITTED</password> sein kann.

Einen sicheren konfig Export mit verschlüsselung gibt es ja schon.

[meyergru]

@Nickfrost:

Den Industriestandard kaufe ich nicht und auch nicht, dass die Secrets in der Datei verschlüsselt sein müssen oder dass dies ohne Probleme für die Erzielung des eigentlichen Zwecks (nämlich: Wiederherstellung) sinnvoll möglich ist.

Du schuldest uns auch noch immer die Nennung des Paragraphen in der DSGVO, der das vorschreibt, Dein Glaube reicht mir nicht (ich mache das nämlich beruflich). Richtig ist nur, dass personenbezogene Daten (und nur die deckt die DSGVO ab) nicht ohne Einwilligung weitergegeben werden dürfen. Über die Art der Speicherung kann man, wie ich ja schon zeigte, nach technischen Erfordernissen entscheiden. Tatsache ist, dass in der Client-Rolle im Effekt die Daten im Klartext (oder in rückrechenbarer Form) vorliegen müssen. Und genau das benötigt man auch für eine Wiederherstellung.

Eine alternative Funktion zu Anonymisierung oder Ausgabe von Supportdaten bietet OpnSense derzeit nicht. Das geht aber im Effekt weit über Dein Detailproblem hinaus, da im Konfigurationsexport u.a. E-Mail-Adressen usw. enthalten sind. Gemäß laufender Rechtsprechung können sogar IP-Adressen personenbezogene Daten sein und auch die wären ggf. im Export enthalten. Was das angeht, wäre es also ohnehin fahrlässig von Dir, solche Dateien an Dritte weiterzugeben. Letztlich wäre das eine Zweckentfremdung. Und die wäre so auch bei anderen Produkten gegeben, die eine Konfigurationssicherung anbieten.

Somit ist dies kein Bug und schon gar keine rechtliche Verletzung im Konfigurationsexport, sondern eher ein Feature-Request für einen bislang fehlenden "Support-Report".

@Monviech:

Einen alternativen Export zum Zweck der Weitergabe zu bauen, klingt erstmal nach einer guten Idee. Man könnte mit XSLT Transformations so etwas machen wie:

Code: [Select]

<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:output method="xml" indent="yes"/>

    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>

    <xsl:template match="password">
        <omitted-secret/>
    </xsl:template>

</xsl:stylesheet>

Leider ist die Realität eher so:

Code: [Select]

<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:output method="xml" indent="yes"/>

    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>

    <xsl:template match="url|subnet|gateway|username|user|ipaddr|ipaddrv6|
        mac|password_encryption|otp_seed|
        *[substring(name(), string-length(name()) - 7) = 'password']|
        *[substring(name(), string-length(name()) - 3) = 'pass']|
        *[substring(name(), string-length(name()) - 2) = 'key']|
        *[substring(name(), string-length(name()) - 4) = 'email']|
        *[substring(name(), string-length(name()) - 5) = 'secret']|
        *[substring(name(), string-length(name()) - 4) = 'token']">
        <omitted-secret/>
    </xsl:template>

</xsl:stylesheet>

Und das war nur das, was in meiner Konfigurationsdatei konkret an theoretisch schutzwürdigen Daten enthalten war, erhebt also keinesfalls einen Anspruch auf Vollständigkeit.

[Monviech (Cedrik)]

Ja das ist genau das Problem, es gibt sehr viele Keys die zu anonymisierende Daten beinhalten würden.

Theoretisch wird hier dann nur die Verantwortung hin und hergeschoben. Der schwarze Peter hat immer der, der ein Feld vergessen hat.

EDIT:

Vielleicht kann man dafür einen standartisierten Field Type oder eine erweiterung eines Fieldtypes erstellen.

In dem könnte man dann z.B. einen <DoNotExport>1 UnterKey setzen, und wenn der da drin steht wird der Parent Key beim export leergelassen oder übersprungen wenn eine Daten Auslassen funktion eingeschalten ist.

Ich weiß nicht ob der jetzige Export das Modell für eine Validierung verwendet, um so einen Key in einem Fieldtype auswerten zu können.

Vielleicht ist das ein Feature Request auf Github wert?

Aber keine Ahnung. XD

[meyergru]

Man könnte es über ein XML-Attribut lösen, also z.B. <password export="false">. Dann kann man alle Elemente mit diesem Attribut per XSLT ausfiltern. Das wäre vermutlich auch abwärtskompatibel.

@NickFrost: Du kannst ja auf Github einen Feature-Request anlegen und hierauf verweisen.