Messages

...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.

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.

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.

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.

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.

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.

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.

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).

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 ?

Das mit den VLAN-Brücken hab ich schon anderswo gelesen. Wenn ich das richtig verstehe, müsste es z.B. so gehen: Für 10 VLANs und 6 physische Schnittstellen müsste man 60 VLANs und 10 Brücken erstellen. Das ist natürlich eine Monsterkonfiguration. Da ist mir ein externer Switch dann doch lieber.

Der Rest mit dem VLAN999 habe ich nicht genau verstanden :)

Aber was nun definitiv zu gehen scheint, sind folgende Varianten:

1. Ein physisches Interface definieren, aber keine IP zuordnen.
2. Alle VLANs mit IP und DHCP drauf setzen.

Dieses Interface ist dann der Trunkport für externe gemanagte Switches. Man kann jedoch daran bei Bedarf auch erstmal einen unmanagten Switch hängen, das ist dann wie eine Vielfachsteckdose für Trunkports.

Falls man noch zusätzlich ein untagged (natives) Netz möchte, erstellt man an der OPNsense ein 2. physisches Interface und macht darauf eine IP und DHCP.

Dieses 2. Interface verbindet man einfach mit einem weiteren externen Trunkport oder eben mit dem unmanagten Switch.

Ich hoffe, ich habe es damit richtig verstanden.

Hallo zusammen,

mit Schrecken hab ich festgestellt, dass OPNsense bzw. FreeBSD offenbar Brücken von Trunkports nicht unterstützt. Also die Idee war, die vielen physischen SFP+ und RJ45 Ports auf dem Gerät zu brücken (als Trunkports mit VLAN) und davon dann auf die Trunkports mehrerer externer Switches zu verbinden.

Das geht nach wie vor nicht, oder? Zumindest nachdem, was ich hier so gelesen habe.

Also neues Setting und die alte Konfiguration wieder gelöscht:

Ich hab jetzt nur noch eine physische Schnittstelle, welche auf den Trunkport eines externen Switches geht.
Auf dieser Schnittstelle sind VLANs und natürlich das native (untagged) (V-)LAN konfiguriert.

Alle Verbindungen mit VLANs funktionieren nun so einwandfrei.

Aber wenn ich Geräte am Switch in den Trunkport stecke, bzw. in einen entsprechend ungetaggen Port, passiert folgendes:
- Alle Geräte erhalten eine IP per DHCP aus dem Subnet 192.168.1.0/24
- Alle Geräte können untereinander kommunizieren, was logisch ist, da alles über den Switch läuft.

Aber die Geräte kommen nicht ins Internet oder auf andere VLANs. Die Firewall blockt alles auf dem Interface igc1 mit "default deny". Dabei hab ich auf diesem Interface 2 Regeln: eingehend und ausgehend, alles freigegeben.

Allerdings habe ich hier an verschiedenen Stellen gelesen, dass man bei OPNsense auch nicht ungetaggten und getaggten Traffic auf einer Leitung haben sollte. Ist das so und was hat es damit auf sich? Oder hab ich bei den Firewall Regeln etwas vergessen?

Und was ist dann die empfohlene Variante? Alles in VLANs zu legen, also auch alle Access Points und Switches mit dem Management Interface?

Ja, das war's. Danke.

Sehr intuitiv ist das natürlich nicht ;) Das hätte man auch automatisch anwenden können, ist ja kein zeitaufwändiger Prozess. Oder in der Liste anzeigen, dass es noch nicht angewendet wurde.

Egal, es geht jetzt auch ohne Restart.

Hallo zusammen

Ich habe mein erstes VLAN erstellt und zugewiesen und es funktioniert. Soviel ich weiss, gab's auch bei der Zuweisung keine Probleme.

Nun wollte ich aber zusätzliche VLANs erstellen und erhalte jeweils bei der Zuweisung eine Fehlermeldung.

1. Schnittstellen->Andere Typen->VLAN:   Mit + Button eine neues VLAN erstellen und ein Interface (igc1) als Parent angeben. Funktioniert.

2. Schnittstellen->Zuweisungen: Das neu erstellte VLAN erscheint im Drop-Down Feld zur Auswahl. Bestens.

3. Mit Button 'Hinzufügen' erscheint nun folgende Fehlermeldung:
Die folgenden Eingabefehler wurden entdeckt:  The interface "vlan040" does not exist. Make sure to apply its configuration first.

Abhilfe schafft nur ein Neustart des Systems. Danach ist das VLAN bereits zugewiesen oder kann zugewiesen werden.

Ich habe den Vorgang nun mehrfach mit mehreren VLANs gemacht und muss jedesmals das Systen neu starten. Danach geht es. Mache ich da im Ablauf etwas falsch?

Verstehe. Also mit DHCP eigentlich gar nichts zu tun. Sondern eine Anzeige, ob da ein Minimalmass an Traffic vorhanden ist.

Besten Dank.

Hallo zusammen

In der DHCP Lease Tabelle hat es 2 Status-Spalten.

Was bedeutet die Farbe rot oder grün bei dem Stecker Symbol?

Oft ist die Farbe rot, obwohl das Gerät online ist und auch der Lease nicht ausgelaufen ist.