IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
Ihr erinnert euch daran das man bei GlobalSign keine Sonderzeichen im Kennwort für die Zertifikatsverwaltung nutzen kann? Nun ratet doch mal was man beim Kennwort für p12 auch nicht nutzen kann! ….Richtig… Sonderzeichen im Kennwort.
Siehe auch: GlobalSign S/MIME, S/MIME-Zertifikat per DNS veröffentlichen – SMIMEA
Fragen? Einfach melden.
Neues S/MIME Zertifikat, neuer SMIMEA-Record. Weil E-Mail-Verschlüsselung nicht nur für Paranoide ist. Oder doch? Egal, ich mache es trotzdem.
Wie angekündigt habe ich ein neues S/MIME Zertifikat. Wer mir verschlüsselt schreiben will, braucht den neuen öffentlichen Schlüssel. Den gibt es wie immer über die üblichen Wege oder halt per erster unverschlüsselter Mail an mich.
Das Spannende daran: ich habe direkt einen SMIMEA-Record dazu im DNS hinterlegt. SMIMEA ist quasi DANE für S/MIME. Statt nur TLS-Zertifikate von Servern im DNS zu veröffentlichen, kann man damit auch S/MIME-Zertifikate von E-Mail-Adressen per DNS verifizierbar machen. Der RFC dazu war 2017 noch im Draft-Status (RFC 8162), inzwischen ist er finalisiert.
Die Idee ist simpel: Du hast DNSSEC für deine Domain (habe ich), du hast ein S/MIME-Zertifikat (habe ich jetzt neu) und du packst den Fingerprint oder das ganze Zertifikat als SMIMEA-Record in deine DNS-Zone. Jeder der mir eine verschlüsselte Mail schicken will, kann mein Zertifikat dann per DNS-Abfrage verifizieren. Kein Rumsuchen auf Keyservern, keine manuelle Prüfung ob das Zertifikat echt ist.
In der Praxis nutzt das aktuell fast niemand. Mailclient-Support ist mager, die meisten Leute wissen nicht mal was S/MIME ist, geschweige denn SMIMEA. Aber genau deshalb mache ich es. Jemand muss ja anfangen.
Wer sich für DANE, SMIMEA oder E-Mail-Sicherheit interessiert, kann mich gerne fragen.
Nach dem „tot“ von StartSSL brauche ich ja auch mal ein neues S/MIME Zertifikat. Class 2 bei GlobalSign sollte für mich privat reichen (auch wenn ich schon auf Class 3 geschielt habe, mal sehen ob ich das noch nachziehe). Als erstes habe ich da trocken angerufen und gefragt ob ich auf sie bauen kann oder mich am Ende so ärgere wie über StartSSL / Symantec usw… Klar es ist eine große CA die zu viel Geld für Mist bekommen und der Anruf war total nutzlos. Er hat dennoch für Spaß bei mir und da bin ich mir sicher, ebenfalls bei GlobalSign geführt.
Nun klicke ich mich also gerade durch die Anmeldung und muss alle möglichen Daten eingeben sowie Vereinbarungen zustimmen usw. an einer Stelle soll ich dann schon mal mein Kennwort für die Zertifikatsverwaltung festlegen. Ich überzeuge also wie immer pwgen mir eines zu würfeln werfe es rein. Die Info unter dem Kennwortformular lese ich natürlich nicht und bekomme direkt die Quittung. Ich habe unerlaubte Sonderzeichen in meinem Passwort für die Zertifikatsverwaltung angegeben. Unerlaubte Sonderzeichen?!?!? Stimmt… Die Kennwörter dürfen nur aus Zahlen und Buchstaben (groß/klein) bestehen..
Das Kennwort für die Zertifikatsverwaltung darf also keine Sonderzeichen enthalten. Den Satz habe ich jetzt schon ein paar mal gesagt aber öhm ich begreife ihn irgendwie noch nicht. *kopfschüttel* Kann mir das bitte mal jemand verständlich machen? Am besten ich ruf da noch mal an, oder?
Siehe auch: S/MIME per DNS mit SMIMEA, Kleiner Nachtrag zum GlobalSign S/MIME Zertifikat…, Neues StartSSL S/MIME Zertifikat
Fragen? Einfach melden.
Das IPv6 eines meiner Lieblingsthemen ist muss ich ja keinem von euch erzählen. Auf das Thema bringt mich gerade sixxs. Die Jungs stellen nämlich ihren Service ein…. War ja fast zu erwarten! Sixxs kann sicher für sich behaupten eines der Projekte zu sein/gewesen zu sein welches extrem stark an der Verbreitung von IPv6 mitgewirkt hat!
Passend dazu saß ich vor kurzem in einem Bewerbungsgespräch irgendwann sind wir ebenfalls kurz auf das Thema IPv6 gekommen und da hat der Bewerber etwas gesagt was mir bis jetzt nicht mehr aus dem Kopf gegangen ist. Er sagt: „IPv6, ja… das war vor 5/6 Jahren mal so ein Hype, weil ja alle Adressen aufgebraucht sind, das ist aber inzwischen vorbei.“ Der Mann hat recht! OK, Adressen sind wirklich leer aber merkt man es denn wirklich? Also normaler User nicht. Von jedem gängigen ISP bekommt man IPv6 einfach in den Router geworfen und ob man jetzt noch eine „echte“ IPv4 Adresse hat oder man wie im Mobilfunk hinter einem carrier grade nat versteckt wird merken die normalen Nutzer eh nicht. Wenn man nicht gerade ein /24 haben will ist ebenfalls jeder DataCenterbetreiber oder Business ISP ohne großes hin und her gewillt einem das Netz zu geben. Selbst Unitymedia bekommt das hin!
Dabei kommt mit Unitymedia immer als der unprofessionellste Verein aller Zeiten vor. *kopfschüttel* Gut gut… Sie haben noch nicht SO viel Zeit als ISP verbracht wie der rosa Haufen. Habt ihr da mal versucht einen PTR Record zu setzen? Ach was schreib ich… Nicht setzten, setzten zu lassen?!?! Das geht per Fax. Echt jetzt PER FAX!!! Man bekommt so ein tolles PDF Formular OHNE Felder! Also so als PDF Bild zum Ausdrucken und dann muss man mit der Hand in so Kästchen seinen Wunsch PTR, die IP seine Kundennummer usw. eintragen und es dann zu ihnen zurück FAXEN. Nicht mal einscannen und E-Mail… Echt FAXEN! Jetzt ratet doch mal was passiert ist nachdem ich mein Fax mit 4 PTR Wünschen geschrieben habe? Richtig… Ich habe eine E-Mail vom Support bekommen, das sie leider nicht alles lesen konnten und ich das Fax doch bitte noch mal schicken solle *aaaarrrrggggghhhhh*
Siehe auch: IPv6 Grundlagen
Fragen? Einfach melden.
Mit zfs send und zfs recv lassen sich Datasets über SSH auf ein anderes System replizieren. Das Schöne daran: Nach einem initialen Vollabgleich muss man nur noch die Differenz zwischen zwei Snapshots übertragen. Bei großen Datasets spart das enorm Bandbreite und Zeit.
Beispiel: Eine FreeBSD Jail mit 100 GB Mediadaten. Wöchentliche Snapshots werden automatisch erstellt. Der initiale Transfer:
zfs send zroot/jails/subsonic@weekly-2017-03-12 | ssh zfsrecv@system02 zfs recv zroot/backup/subsonic
Ab jetzt nur noch das Delta zum nächsten Snapshot:
zfs send -i zroot/jails/subsonic@weekly-2017-03-12 zroot/jails/subsonic@weekly-2017-03-19 \ | ssh zfsrecv@system02 zfs recv zroot/backup/subsonic
Das funktioniert nur, solange das Ziel-Dataset seit dem letzten Snapshot nicht verändert wurde. Jede Änderung — und sei es nur ein Update der Access-Time (atime) durch einen Lesezugriff — reicht aus, damit ZFS den inkrementellen Stream ablehnt:
cannot receive incremental stream: destination zroot/backup/subsonic has been modified since most recent snapshot warning: cannot send 'zroot/jails/subsonic@weekly-2017-03-19': signal received
ZFS sagt damit: Zwischen dem letzten gemeinsamen Snapshot und jetzt hat sich am Ziel etwas geändert. Das Delta passt nicht mehr.
Man muss nicht alles neu übertragen. Mit -F weist man zfs recv an, das Ziel-Dataset auf den letzten gemeinsamen Snapshot zurückzurollen und dann das Delta anzuwenden:
zfs send -i zroot/jails/subsonic@weekly-2017-03-12 zroot/jails/subsonic@weekly-2017-03-19 \ | ssh zfsrecv@system02 zfs recv -F zroot/backup/subsonic
Damit das Problem gar nicht erst auftritt, setzt man das Ziel-Dataset auf readonly:
zfs set readonly=on zroot/backup/subsonic
So kann nichts am Ziel verändert werden — kein atime-Update, kein versehentliches Schreiben. Das -F im Skript schadet trotzdem nicht als Sicherheitsnetz. Und nicht vergessen: Auf dem Zielsystem regelmäßig alte Snapshots aufräumen, sonst wächst der Plattenverbrauch stetig.
Mehr Details in der OpenZFS-Dokumentation zu zfs send. Mehr zu ZFS: ZFS Compression und Deduplication und TRIM im ZFS-Pool aktivieren. Fragen? Einfach melden.
Wie angekündigt habe ich nun meinen Apachen in den Ruhestand geschickt… Damit ist nun also ebenfalls mein Webserver auf FreeBSD und ebenfalls auf NGINX.
Siehe auch: HTTP/3 und QUIC
Fragen? Einfach melden.
Auf fast jedem Unix ähnlichen System haben Benutzer nicht das Recht das komplette System herunterfahren oder neustarten zu können. Macht ja nur Sinn… Nutzt man dieses System aber als Desktop könnte es in gewissen Fällen ebenfalls nicht dumm sein, wenn Benutzer nicht in der Lage sind das System zu rebooten und einen shutdown abzusetzten. In den Meisten Fällen ist man dann wohl doch alleine auf seinem System und es ist eher eine Einschränkung wenn man sich erst als privilegierter Benutzer anmelden muss um seinen Comupter/Laptop abschalten zu können.
Dafür wurden nun verschiedenste Dienste entwickelt um dieses so einfach wie möglich zu erledigen. Das wohl bekannteste und verbreitetste ist consolekit / policykit / polkit. Dieses System ermöglicht es bestimmte Rechte basierend auf Benutzer oder Gruppen zu verteilen. Die gängigen Logonmanager sowie Displaymanager haben in der Regel bereits die Möglichkeit eingebaut um sich damit auszutauschen. Der normale Linux Benutzer wird damit wohl kaum noch in Berührung kommen.
Am einfachsten schaut man sich als Benutzer einmal in einem xterminal an welche Möglichkeiten einem geboten werden:
$ pkaction
Schon gibt es eine Liste der aktuell konfigurierbaren „Berechtigungen“. Ob shutdown und reboot dabei ist sagt einem:
$ pkaction | grep -E 'stop|restart' org.freedesktop.consolekit.system.restart org.freedesktop.consolekit.system.restart-multiple-users org.freedesktop.consolekit.system.stop org.freedesktop.consolekit.system.stop-multiple-users
Ob der eigene Benutzer es bereits darf sagt einem:
$ pkaction --action-id org.freedesktop.consolekit.system.restart --verbose org.freedesktop.consolekit.system.restart: description: Restart the system message: System policy prevents restarting the system vendor: vendor_url: icon: implicit any: no implicit inactive: no implicit active: yes
Implicit active ist hier der spannende Eintrag… Dieser ergibt sich für mich aus der von mir angelegten Regel 05-shutreboot.rules unter /usr/local/etc/polkit-1/rules.d diese schaut wie folgt aus:
polkit.addRule(function (action, subject) {
if (action.id == "org.freedesktop.consolekit.system.restart" ||
action.id == "org.freedesktop.consolekit.system.stop"
&& subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
Die Regel besagt das org.freedesktop.consolekit.system.stop sowie restart das Ergebnis YES zurückgeben soll, wenn der Benutzer in der Gruppe wheel ist. ist diese Regel eingetragen, und man ist sich sicher das alles klappen müsste, es dennoch nicht funktioniert sind ein beliebter Fehler die Rechte vom Ordner. Hier könnte folgendes helfen:
$ chown polkitd:wheel /usr/local/etc/polkit-1
In diesem Sinne…
Siehe auch: FreeBSD auf dem Desktop
Fragen? Einfach melden.
Ich nutze privat das SmartHome-System der Telekom mit der QIVICON Home Base. Die alte Version 1.0 war funktional in Ordnung, aber langsam. Kein WLAN, kein ZigBee ohne USB-Stick, und je mehr Geräte dranhingen desto zäher wurde die Oberfläche. Die neuen HomeMatic IP Geräte von eQ-3 haben den Rest gegeben. Die Home Base 1.0 war damit überfordert.
Das Endergebnis vorweg: Die 2.0 ist besser. Kamerastreams laufen flüssig, keine Verbindungsabbrüche mehr zu den Sensoren, die App reagiert spürbar schneller. Soweit die gute Nachricht.
Die offizielle Wechselanleitung der Telekom sieht so aus:
1. Alle Geräte auf der Home Base 1.0 löschen 2. Reset der Home Base 1.0 3. Alte abklemmen, neue anklemmen 4. Neue Home Base registrieren und aktivieren 5. Alle Geräte neu einrichten
Punkt 1 und 5 sind das Problem. Jedes Gerät einzeln löschen, über eine App die alle paar Klicks die Verbindung verliert und einen gefühlten Delay von ein bis zwei Sekunden auf jede Aktion hat. Manche Geräte wollen vor dem Löschen eine physische Bestätigung am Gerät selbst. Also knapp eine Stunde durch die Wohnung rennen und Knöpfe drücken. Bei Unterputz-Schaltern besonders viel Freude.
Nach dem Löschen aller Geräte und dem Reset der alten Home Base wollte die App keine Verbindung mehr herstellen. Logisch, die alte Base war ja zurückgesetzt. Im QIVICON-Webportal gab es einen Button „Exchange Gateway“ der in der Anleitung nicht vorkam. Seriennummer der neuen Base eingeben, fertig. Die Aktivierung, die laut Anleitung nötig sein soll, war es nicht. In der Anleitung steht man solle die Fehlermeldung bei der Aktivierung ignorieren. Fehlermeldung ignorieren als offizieller Schritt.
Nach dem Gateway-Tausch passierte etwas Unerwartetes: Die neue Home Base hatte meine komplette Konfiguration und alle Geräte. Die ich vorher gelöscht hatte. Die Geräte kannten aber den Funkschlüssel der alten Base und weigerten sich mit der neuen zu reden. Das Ergebnis war ein Dauerbeschuss des Funkmoduls mit ungültigem Traffic. Die Base war alle paar Sekunden überlastet.
Zum Löschen der Geräte brauchte man das Funkmodul. Also hatte man immer ein paar Sekunden Zeit bevor es wieder abschmierte. Ein Neustart der Home Base dauerte 15 Minuten. Das ganze Löschen und Neu-Anlernen hat knapp drei Stunden gedauert, inklusive Geräte die vor dem Neu-Anlernen einen eigenen Factory-Reset brauchten.
Die Hardware ist ein klares Upgrade. Der Migrationsprozess ist eine Katastrophe. Ein Gateway-Tausch sollte eine Sache von Minuten sein, nicht von Stunden. Das Telekom SmartHome hat den Vorteil verschiedene Hersteller kombinieren zu können. Das ist nach wie vor der Grund warum ich dabei bleibe. Die Bilder zeigen die alte und neue Home Base, innen und aussen.
Siehe auch: Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2, Magenta SmartHome Lüften: Lösung für Android-Probleme gefunden
Fragen? Einfach melden.
Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud
Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.
Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!
So long…
Siehe auch: MTA-STS einrichten
Fragen? Einfach melden.
Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.
Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!
Oh ja, die abuse Mail:
Sehr geehrte Damen und Herren, ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch von Daten. Das Unternehmen Nextcloud GmbH hat offen aus dem Internet erreichbare Installationen von ownCloud und Nextcloud geprft. Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit veralteten Software-Versionen laufen, welche verschiedene Sicherheitslcken aufweisen. Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen. Dabei knnen die Angreifer ggf. sensible Informationen wie z.B. persnliche Dokumente, Fotos oder Kundendaten von Unternehmen aussphen und diese anschlieend im Internet verffentlichen oder fr kriminelle Zwecke wie Erpressungen nutzen. Andere Schwachstellen ermglichen Angreifern die Ausfhrung beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf. zu einer vollstndigen Kompromittierung des Systems und dessen Missbrauch fr weitere kriminelle Aktivitten fhren. Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen zur Untersttzung bei der Benachrichtigung betroffener Server- Betreiber bereitgestellt. Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann die verwundbare Cloud-Installation identifiziert wurde. Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine eindeutige ID (UUID) angegeben. Die Nextcloud GmbH stellt unter folgender URL detaillierte Informationen zu den bei der jeweiligen Cloud-Instanz erkannten Schwachstellen und deren Behebung zur Verfgung: https://scan.nextcloud.com/results/[UUID] Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz angegebene UUID ersetzt werden. Beispiel: https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur Aktualisierung der Cloud-Installationen auf den betroffenen Systemen zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle auf den betroffenen Systemen identifizierten Schwachstellen stehen entsprechende Sicherheitsupdates der Hersteller zur Verfgung. Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen wenden Sie sich bitte direkt an die Nextcloud GmbH unter <cloud-security-scan@nextcloud.com>. Diese E-Mail ist mittels PGP digital signiert. Informationen zu dem verwendeten Schlssel finden Sie unter <https://reports.cert-bund.de>. Bitte beachten Sie: Dies ist eine automatisch generierte Nachricht. An die Absenderadresse kann nicht geantwortet werden. Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte unter Beibehaltung der Ticketnummer in der Betreffzeile an <certbund@bsi.bund.de>. ====================================================================== Betroffene Systeme in Ihrem Netzbereich: Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname 12345 | 1.2.3.4 | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high | 80 | cloud.domain.de 12345 | 1.2.3.5 | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium | 80 | cloud.wurst.com 12345 | 1.2.3.6 | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low | 80 | cloud.alalaa.de 12345 | 1.2.3.7 | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high | 443 | cloud.butani.cn 12345 | 1.2.3.8 | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high | 80 | cloud.bima.org 12345 | 1.2.3.9 | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high | 80 | cloud.2083a.net 12345 | 1.2.3.10 | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low | 443 | cloud.lutzola.nl 12345 | 1.2.3.11 | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high | 80 | cloud.weglaa.wu 12345 | 1.2.3.12 | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium | 80 | cloud.breck.aa [.....] Mit freundlichen Gren / Kind regards Team CERT-Bund Bundesamt fr Sicherheit in der Informationstechnik (BSI) Federal Office for Information Security Referat CK22 - CERT-Bund Godesberger Allee 185-189, D-53175 Bonn, Germany
Fragen? Einfach melden.
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑