1
General Discussion / Re: DNS not resolving after reboot
« on: May 20, 2024, 07:47:54 pm »
Via CLI "date ...".
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2023-01-01T16:05:43-06:00 Error unbound [32138:0] error: remote control failed ssl crypto error:0A000412:SSL routines::sslv3 alert bad certificate
2023-01-01T16:01:03-06:00 Error unbound [32138:0] error: ssl handshake cert error: certificate is not yet valid
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.
In jedem CMS liegt das Datenbank-Passwort im Klartext z.B. in LocalConfiguration.php ...
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.
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).
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.
ich habe bei
NAT -> Port Forward:
- Interface: LAN und WAN
- Protocol: TCP
- Source: any
- Source port range: any
- Destination: meine externe IP
- Destination Port Range: HTTPS/443
- Redirect target IP: 192.168.0.2 (IP von meinem Webserver)
- Redirect target port: HTTPS/443
igc0@pci0:87:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-V'
class = network
subclass = ethernet
igc1@pci0:88:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125b subvendor=0x8086 subdevice=0x0000
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-LM'
class = network
subclass = ethernet