Hallo zusammen,
ich war grad erstaunt, als ich im heruntergeladenen Konfigurationsfile (XML) mein Passwort für die Nextcloud (Server für die Sicherungen) im Klartext gelesen hab. Ich finde, das ist nicht mehr zulässig, ev. sogar gesetzlich verboten.
Wie seht ihr das ?
Geht es um die Konfiguration von OPNsense?
QuoteIch finde, das ist nicht mehr zulässig, ev. sogar gesetzlich verboten.
.
1. Nun das ist ja wohl jedem selbst überlassen. Ich würde die Aussage mal als "bull..." bezeichen.
2. Es muss ja nicht so sein! Siehe Screenshot.
(http://na_na.png)
Verboten ist es nicht, in diesem Kontext ist es nicht einmal sinnvoll. Aber vielleicht hast Du das Problem auch nicht ganz richtig verstanden:
Was man heutzutage typischerweise nicht mehr tun soll, ist, Passworte im Klartext dort zu speichern, wo sie geprüft werden (also serverseitig). Das soll dazu dienen, im Fall von Datenlecks oder Einbrüchen das Passwort zu schützen - vor allem, um ein eventuell auch bei anderen Diensten mehrfach verwendetes Passwort nicht offenzulegen.
Stell' Dir vor, Dein Passwort "supergeheim" würde bei Ebay und bei Amazon für Deine E-Mail-Adresse verwendet. Dann würde bei Klartextspeicherung und Einbruch bei Ebay auch Dein Amazon-Passwort offengelegt. Ist es aber verschlüsselt, geht das (hoffentlich) nicht.
Nun gibt es noch ein kleines Problem: Es gibt einen Unterschied zwischen Einweg-Verschlüsselung (Hashing) und Zweiweg-Verschlüsselung. Wenn die Passworte Zweiweg-Verschlüsselt sind, kann der Dienst aus dem Chiffrat das Passwort wiederherstellen und dann prüfen, ob es mit dem eingegebenen Passwort übereinstimmt. In diesem Fall könnte ein Einbruch aber eben doch zu einer Offenlegung führen, wenn das Verschlüsselungsverfahren (und die verwendeten Schlüssel) bekannt sind. Deshalb verwenden viele Dienste heute eine Einweg-Verschlüsselung (mit zufälligem Salt), womit nur geprüft wird, ob das eingegebene Passwort den selben Hashwert ergibt, der gespeichert wurde. Mit dem Hash allein ist aber eine Rückrechnung nicht möglich (deswegen: Einweg-Verschlüsselung).
Was nun die Speicherung Deines NextCloud-Passworts in OpnSense angeht, handelt es sich um die Speicherung nicht auf dem Server, sondern auf dem Client. Und dort benötigt man immer zwingend das Klartext-Passwort. Anderenfalls kann man es dem Server ja nicht zeigen. Den Hashwert kann man ebenfalls nicht vorlegen, da man nicht weiß, wie dieser auf dem Server gebildet wird, bzw. mit welchem zufälligen Wert (Salt) das Passwort kombiniert wurde.
Das bedeutet also automatisch, dass ein Hashing auf der Client-Seite nicht möglich ist. Möglich wäre eine Zweiweg-Verschlüsselung, bei der in der Konfigurationsdatei ein (umkehrbares) verschlüsseltes Passwort abgelegt würde.
Das hilft aber leider gar nichts, denn im Quelltext von OpnSense könnte man dann nachlesen, wie dieses Passwort entschlüsselt werden kann - damit wäre es bei einem Datenleck genauso offengelegt wie im Klartext.
Also: Es ist weder vorgeschrieben, das Passwort auf der Client-Seite (zweiweg) zu verschlüsseln (einweg wäre nicht einmal möglich), noch ist es technisch sinnvoll.
P.S.: Was tatsächlich einweg-verschlüsselt ist in der OpnSense-Konfigurationsdatei, sind die Benutzerpassworte. Da tritt OpnSense ja auch nicht in der Rolle als Client, sondern als Server auf.
1. Das verschlüsselte Speichern des Konfigurationsfile löst das Problem nicht, weil das Passwort nach dem Entschlüsseln wieder offen vorliegt. Wenn ich diese Konfigurationsdatei zu irgendeinem Zweck intern oder an einen Support weiterreiche, darf ein Passwort nicht offen lesbar sein.
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.
3. Natürlich kann das Passwort nicht gehasht werden. Es muss zur Anmeldung an die Nextcloud ja wieder vorliegen. Aber man könnte das Passwort z.B. mit Blowfish, Twofish oder was anderem verschlüsseln. Damit lässt sich das Passwort wieder herstellen.
Das OPnsense Passwort ist ja auch verschlüsselt. Es gibt keinen Grund, dies nicht auch hier mit diesem Passwort zu machen. Ich kenn auch kein professionelles Gerät, dass Passwörter unverschlüsselt speichert (ausser chinesische).
Quote from: NickFrost on May 20, 2024, 04:46:06 PM
3. Natürlich kann das Passwort nicht gehasht werden. Es muss zur Anmeldung an die Nextcloud ja wieder vorliegen. Aber man könnte das Passwort z.B. mit Blowfish, Twofish oder was anderem verschlüsseln. Damit lässt sich das Passwort wieder herstellen.
Das OPnsense Passwort ist ja auch verschlüsselt. Es gibt keinen Grund, dies nicht auch hier mit diesem Passwort zu machen. Ich kenn auch kein professionelles Gerät, dass Passwörter unverschlüsselt speichert (ausser chinesische).
Eben in der Wiederherstellbarkeit liegt das Problem: Es hilft nichts. Und wie ich schon schrieb, es gibt einen eklatanten Unterschied je nach Rolle Client oder Server. Auch mit der DSGVO hast Du Unrecht:
Siehe: https://dsgvo-gesetz.de/themen/verschluesselung/
Quote
Dabei sind der Stand der Technik, die Implementierungskosten, sowie die Art, der Umfang, die Umstände und der Zweck der Verarbeitung zu berücksichtigen. Neben diesen Kriterien sind auch die unterschiedlichen Eintrittswahrscheinlichkeiten und die Schwere des Risikos für die Rechte und Freiheiten der Betroffenen mit einzubeziehen. Dementsprechend sollte der Grad der getroffenen Sicherheitsmaßnahmen angepasst werden. Die Verschlüsselung wird dabei explizit als eine solche Maßnahme im nicht abschließenden Katalog des Art. 32 Abs. 1 EU-DSGVO angeführt.
Lies:
1. Der Kontext ist relevant (Client vs. Server)
2. Verschlüsselung als Maßnahme ist nicht vorgeschrieben, sondern wird lediglich empfohlen. Und wo sie keinen Sinn macht, macht sie keinen Sinn.
P.S.: Die OpnSense-Passworte sind nicht (zweiweg)-verschlüsselt, sondern gehasht, was viel besser ist (aber eben für das NextCloud-Passwort unmöglich).
In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...
Das CMS ist gegenüber der Datenbank ebenfalls ein Client.
Klingt nach faulen Ausreden :)
Ein Passwort ist ein Passwort. Egal wo es gebraucht wird. Es kann kostenlos so verschlüsselt werden, dass es wieder vollständig hergestellt werden kann. Damit entfallen auch alle deine angebrachten Argumente.
Ein Passwört verschlüsselt in einem Konfigurationsfile zu speichern ist einfach Stand der Technik.
Quote from: Patrick M. Hausen on May 20, 2024, 05:03:59 PM
In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...
Das CMS ist gegenüber der Datenbank ebenfalls ein Client.
Das ist klar, aber diese Datei gibt man ja auch nicht weiter. Das ist praktisch sowas wie die Passwortdatei.
Wie soll es denn mitten in der Nacht, wenn der Cronjob für das Nextcloud-Backup läuft, entschlüsselt werden, ohne Benutzereingriff?
Dann musst du das Blowfish-Secret eben im Klartext irgendwo hin legen. Gewonnen ist damit dann nichts.
Quote from: Patrick M. Hausen on May 20, 2024, 05:03:59 PM
In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...
Rischtisch. Und zwar aus genau den angeführten Gründen.
Quote from: NickFrost on May 20, 2024, 05:07:12 PM
Klingt nach faulen Ausreden :)
Ein Passwort ist ein Passwort. Egal wo es gebraucht wird. Es kann kostenlos so verschlüsselt werden, dass es wieder vollständig hergestellt werden kann. Damit entfallen auch alle deine angebrachten Argumente.
Ein Passwört verschlüsselt in einem Konfigurationsfile zu speichern ist einfach Stand der Technik.
Nochmal: Das wäre zwar kosten-, aber auch zwecklos, wenn ich das Verfahren zum Entschlüsseln im Quelltext von OpnSense nachlesen kann, wie Patrick richtig schreibt.
Wirksamer Schutz böte nur ein Hashing - und das ist für Clients funktionsverhindernd.
Quote from: NickFrost on May 20, 2024, 05:09:30 PM
Quote from: Patrick M. Hausen on May 20, 2024, 05:03:59 PM
In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...
Das CMS ist gegenüber der Datenbank ebenfalls ein Client.
Das ist klar, aber diese Datei gibt man ja auch nicht weiter. Das ist praktisch sowas wie die Passwortdatei.
Quatsch. Das ist die Konfigurationsdatei des CMS, die natürlich mit Git versioniert, und automatisiert deployed wird. Dafür gibt es dann Techniken wie Ansible Vault, aber auf dem produktiven System landet sie wieder im Klartext. Und im nächtlichen Backup landet sie im Klartext. Etc.
Quote from: Patrick M. Hausen on May 20, 2024, 05:12:12 PM
Quatsch. Das ist die Konfigurationsdatei des CMS, die natürlich mit Git versioniert, und automatisiert deployed wird. Dafür gibt es dann Techniken wie Ansible Vault, aber auf dem produktiven System landet sie wieder im Klartext. Und im nächtlichen Backup landet sie im Klartext. Etc.
Keine Ahnung, was du für Software hast. Aber die config.php mit den Zugangsdaten gehe ich sicher nicht mit Git versionieren. Dafür gibt es .gitignore. Aber klar, es gibt auch normale Backups. Aber auch diese bleiben intern und werden nicht weitergegeben.
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.
Quote from: meyergru on May 20, 2024, 05:11:00 PM
Nochmal: Das wäre zwar kosten-, aber auch zwecklos, wenn ich das Verfahren zum Entschlüsseln im Quelltext von OpnSense nachlesen kann, wie Patrick richtig schreibt.
Das Verfahren ist bei OpenSource immer bekannt. Aber nicht die Schlüssel (oder Secrets oder was auch immer) zum Verschlüsseln. Die werden individuell separat beim Anwender generiert.
Quote from: NickFrost on May 20, 2024, 05:21:03 PM
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.
Pruuust ;D
Die Passwort-Hashes in Cisco IOS sind reversibel, also nicht wirklich Hashes, und Algorithmus und Secret sind bekannt. Das ist nur Obfuscation.
Quote from: NickFrost on May 20, 2024, 05:21:03 PM
Das Verfahren ist bei OpenSource immer bekannt. Aber nicht die Schlüssel (oder Secrets oder was auch immer) zum Verschlüsseln. Die werden individuell separat beim Anwender generiert.
Ach! Aber damit das Gerät das Passwort selbständig im Klartext bekommen kann, z.B. bei jedem Nextcloud-Backup am Beispiel der OPNsense, muss dann der Schüssel ebenfalls wieder im Klartext auf dem Gerät vorliegen, oder?
Und damit Bestandteil eines Konfigurations-Backups sein. Schließlich ist der Sinn eines Konfigurations-Backups, dass man das System nur damit vollständig wiederherstellen kann.
Quote from: Patrick M. Hausen on May 20, 2024, 05:31:17 PM
Die Passwort-Hashes in Cisco IOS sind reversibel, also nicht wirklich Hashes, und Algorithmus und Secret sind bekannt. Das ist nur Obfuscation.
Gut aber das kann ich ja nicht wissen :) Ich glaube ja immer noch an das Gute im Menschen ;) Aber nur weil die das ev. nicht richtig machen, ist es kein Argument es bei OPNsense nicht richtig zu machen.
Quote
Ach! Aber damit das Gerät das Passwort selbständig im Klartext bekommen kann, z.B. bei jedem Nextcloud-Backup am Beispiel der OPNsense, muss dann der Schüssel ebenfalls wieder im Klartext auf dem Gerät vorliegen, oder?
Und damit Bestandteil eines Konfigurations-Backups sein. Schließlich ist der Sinn eines Konfigurations-Backups, dass man das System nur damit vollständig wiederherstellen kann.
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.
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.
Quote from: NickFrost on May 20, 2024, 05:43:26 PM
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.
Quote from: NickFrost on May 20, 2024, 05:43:26 PM
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.
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.
Quote from: NickFrost on May 20, 2024, 04:46:06 PM
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.
Quote from: NickFrost on May 20, 2024, 05:21:03 PM
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.
Quote
...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.
Quote
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.
Quote
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.
Quote
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.
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.
@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:
<?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:
<?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.
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
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.