-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: InfoSec (Seite 9 von 15)

FreeBSD: Verschlüsseltes ZFS-Backup auf USB-Platte mit geli

23. Mai 2015 / / Keine Kommentare
FreeBSD-Notebook erstellt per ZFS-Snapshot und zfs send ein verschlüsseltes Backup auf eine USB-Platte mit geli, Schlüsseldatei, Passphrase und sicherem Aushängen.

Ein Notebook mit Full-Disk-Encryption verdient auch ein verschlüsseltes Backup. Plan: ZFS-Snapshots per zfs send auf eine USB-Platte schieben, die komplett mit geli verschlüsselt ist. Schlüssel und Passphrase sicher aufbewahren, fertig.

Hinweis: Seit OpenZFS 2.0 (FreeBSD 13+) gibt es native ZFS-Verschlüsselung (zfs create -o encryption=aes-256-gcm). Damit entfällt geli als Zwischenschicht. Auf älteren Systemen oder wenn man die gesamte Platte unabhängig vom Dateisystem verschlüsseln will, bleibt geli die richtige Wahl.

USB-Platte verschlüsseln

Platte einstecken und per dmesg das Device identifizieren, in diesem Fall da0. Dann mit gpart eine neue GPT-Partitionstabelle anlegen und eine Partition erstellen.

geli braucht einen Schlüssel aus Zufallsdaten:

dd if=/dev/random of=./backup-key bs=256 count=1

Mit diesem Schlüssel die verschlüsselte Partition einrichten:

geli init -s 4096 -K ./backup-key -l 256 /dev/da0s1
Enter new passphrase:
Reenter new passphrase:

Metadata backup can be found in /var/backups/da0s1.eli and
can be restored with the following command:

    # geli restore /var/backups/da0s1.eli /dev/da0s1

Partition öffnen:

geli attach -k ./backup-key /dev/da0s1
Enter passphrase:

ZFS-Pool anlegen

Auf der geöffneten geli-Partition (da0s1.eli) den ZFS-Pool erstellen:

zpool create usb-backup /dev/da0s1.eli

zpool list
NAME         SIZE  ALLOC   FREE  CAP  HEALTH
zroot        460G   184G   276G  40%  ONLINE
usb-backup   928G   296K   928G   0%  ONLINE

Backup starten

Initiales Vollbackup per zfs send -R (rekursiv, alle Datasets und Snapshots):

zfs send -R zroot@auto-2015-05-23-21-00-00 | zfs recv -u usb-backup/notebook

Die Option -R sendet alles rekursiv. Die Option -u beim Empfänger verhindert, dass die Datasets auf der USB-Platte gemountet werden. Bei allen folgenden Backups muss nur noch die Differenz zwischen zwei Snapshots übertragen werden.

Platte sicher aushängen

Drei Schritte in der richtigen Reihenfolge:

  • Sync erzwingen, alle Daten sicher auf die Platte schreiben
  • ZFS-Pool exportieren
  • geli-Partition schließen
sync
zpool export usb-backup
geli detach /dev/da0s1

Wichtig: Den Schlüssel (backup-key) an einem dritten Ort aufbewahren, weder auf dem Notebook noch auf der Backup-Platte. Ohne Schlüssel und Passphrase sind die Daten nicht wiederherstellbar.

Mehr zu ZFS-Backups: Automatische ZFS-Snapshots und ZFS send/recv Fehler beheben. Fragen? Einfach melden.

Neues StartSSL S/MIME Zertifikat

9. Mai 2015 / / Keine Kommentare

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht vertrauenswürdig eingestuft und eingestellt. Kostenlose S/MIME-Zertifikate gibt es bei Actalis.

Zwei Jahre sind schon wieder um. Das bedeutet es gibt ein neues S/MIME Zertifikat, da mein altes bald ungültig wird. Hier nun die Daten für interessierte zum Abgleich!

So long

ALT
Zertifikat-Fingerabdruck
SHA1:	7F 8B 92 19 FF 07 BF EB 8E E0 18 D4 98 B8 48 DF E3 0E 4A 85
Läuft ab: 16.05.2015
Signatur-Algorithmus:	SHA1 mit RSA 2048 Bit

 

NEU
Zertifikat-Fingerabdruck
SHA1:	F6 00 F9 B0 DB BF B9 C5 C1 58 03 B2 78 11 84 A7 F1 E8 96 6D
Läuft ab: 08.05.2017
Signatur-Algorithmus:	SHA256 mit RSA 4096 Bit

 

Fragen? Einfach melden.

OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

1. April 2015 / / Keine Kommentare
OPENPGPKEY-Record für einen GPG-Schlüssel im DNS mit Hash des E-Mail-Localparts, DNSSEC-Schutz, Base64-kodiertem Public Key und automatischem Abruf per GnuPG.

Schon länger kann man GPG-Schlüssel per CERT-Record im DNS hinterlegen, allerdings nur als Verweis auf einen Ort, an dem der Schlüssel liegt. Mit dem OPENPGPKEY Resource Record (RFC 7929) geht es einen Schritt weiter: Der komplette öffentliche Schlüssel steckt direkt im DNS-Record. Ist die Zone per DNSSEC gesichert, kann der Schlüssel nicht gefälscht werden, unabhängig von Keyservern und den dort möglicherweise kursierenden Fake-Keys.

Aufbau des Records

Der Hostname des OPENPGPKEY-Records wird aus der E-Mail-Adresse abgeleitet. Aus dem Localpart (alles vor dem @) wird ein SHA-256-Hash gebildet und die ersten 56 Zeichen davon als Subdomain unter _openpgpkey.domain verwendet. Für user@example.de:

echo -n "user" | sha256sum
# Ergebnis: 04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb
# Die ersten 56 Zeichen des Hashes werden zum Hostnamen:
04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b._openpgpkey.example.de. IN OPENPGPKEY <base64-encoded-key>

Der Wert des Records ist der GPG Public Key im Binärformat, Base64-kodiert.

Record erzeugen

Den Hash des Localparts berechnen:

echo -n "kernel-error" | sha256sum | cut -c1-56
# 4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4

Den Public Key exportieren und Base64-kodieren:

gpg --export --export-options export-minimal kernel-error@kernel-error.com \
  | base64 -w 0

Beides zusammen ergibt den Zoneneintrag:

4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4._openpgpkey.kernel-error.com. IN OPENPGPKEY mQINBF...==

Zugegeben, der Record sprengt etwas die Zonenlesbarkeit. Ein GPG-Schlüssel hat schnell mehrere Kilobyte, das wird im Zonefile eine lange Zeile. BIND kommt damit problemlos klar.

Schlüssel automatisch aus dem DNS holen

GnuPG ab Version 2.1 kann OPENPGPKEY-Records direkt abfragen. Will man eine E-Mail verschlüsseln und hat den Schlüssel des Empfängers noch nicht, reicht:

gpg --auto-key-locate dane --locate-keys kernel-error@kernel-error.com

GnuPG sucht den OPENPGPKEY-Record im DNS, prüft die DNSSEC-Signatur und importiert den Schlüssel automatisch. Kein Keyserver nötig, kein manueller Import.

Testen

Ob der Record korrekt im DNS steht, lässt sich online prüfen: openpgpkey.info, E-Mail-Adresse eingeben, der Dienst fragt den OPENPGPKEY-Record ab und zeigt den gefundenen Schlüssel an.

OPENPGPKEY vs. CERT-Record

Der ältere CERT-Record enthält nur eine URL zum Schlüssel, der Client muss den Schlüssel dann von dort herunterladen. OPENPGPKEY packt den kompletten Schlüssel ins DNS. Vorteil: Ein einziger DNS-Lookup genügt, kein zusätzlicher HTTP-Request nötig. Nachteil: Große DNS-Antworten, die bei UDP-Transport fragmentiert werden können, aber mit passender EDNS-Konfiguration kein Problem.

Siehe auch: GPG-Schlüssel per PKA im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel

Fragen? Einfach melden.

Neues Zertifikat

8. März 2015 / / Keine Kommentare

Einige haben es ja schon gesehen, ich habe nun doch vorzeitig mein Zertifikat von SHA1 auf SHA2 (SHA256) gehoben. Nein, ich habe nicht für das Widerrufen bezahlt. Wer ins Zertifikat schaut, wird schon sehen wie ich es gemacht habe. Damit bin ich dann wohl erst einmal wieder A+…. Fragt sich für wie lange. OCSP stört mich noch etwas, nicht unbedingt nötig, denn noch finde ich es ~unschön~! Jetzt nicht so unschön, dass ich es unbedingt sofort angehen muss; dennoch ist es irgendwie unschön!

 

So long.

Fragen? Einfach melden.

Openfire: Unsichere TLS-Cipher und Protokolle über Java deaktivieren

6. Februar 2015 / / Keine Kommentare

Openfire bringt in der Stable-Version keine Möglichkeit mit, schwache TLS-Cipher oder veraltete Protokolle wie SSLv3 zu deaktivieren. Die Nightly Builds haben das bereits im Default behoben, die Stable hinkt hinterher. Da Openfire auf Java läuft, lässt sich das Problem über die Java-Security-Konfiguration lösen.

Openfire Logo

java.security anpassen

Die Datei /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security (Pfad je nach Distribution und Java-Version) enthält zwei relevante Einstellungen. Beide dürfen nur einmal in der Datei vorkommen.

Schwache Algorithmen für Zertifikatsketten deaktivieren:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

Unsichere TLS-Cipher und Protokolle deaktivieren. Die Liste verbietet SSLv3, alle RC4-Cipher, alle Export-Cipher, alle anonymen DH-Cipher und veraltete 3DES-Varianten:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, DESede, \
  SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, \
  SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, \
  SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, \
  SSL_DH_anon_WITH_DES_CBC_SHA, \
  SSL_DH_anon_WITH_RC4_128_MD5, \
  SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, \
  SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, \
  SSL_RSA_EXPORT_WITH_RC4_40_MD5, \
  SSL_RSA_WITH_NULL_MD5, \
  SSL_RSA_WITH_NULL_SHA, \
  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, \
  TLS_ECDH_anon_WITH_RC4_128_SHA

Das ist eine gekürzte Liste der wichtigsten Einträge. Je nach Sicherheitsanforderung kann man weitere Cipher hinzufügen. Oracle dokumentiert die Optionen unter den Stichworten "Java Algorithm restrictions for SSL/TLS" und "certification path processing".

JCE Unlimited Strength

Standardmäßig begrenzt Java die Schlüssellänge auf 128 Bit. Für AES-256 braucht man die JCE Unlimited Strength Jurisdiction Policy Files. Bei neueren Java-Versionen (ab 8u161) ist das per Default aktiv, bei älteren müssen die Policy-Dateien manuell installiert werden.

Aktivieren

Openfire neu starten. Die Änderungen in java.security wirken sofort beim nächsten Java-Start. Danach sollte ein TLS-Test nur noch aktuelle Cipher und Protokolle zeigen.

XMPP IM Observatory Score A

Wer zusätzlich Probleme mit S2S-Verbindungen hat: Im Beitrag zum 404 Remote Server Not Found ist das Thema fehlende Intermediate-Zertifikate beschrieben.

Fragen? Einfach melden.

DNSSEC, DANE und TLSA mit Postfix: Hintergründe und aktuelle Probleme

16. Januar 2015 / / Keine Kommentare

Seit ein paar Tagen scheint das Thema DNSSEC, DANE und TLSA im Zusammenhang mit Postfix im Internet besonders aktiv zu sein. Ich bekomme täglich Anfragen dazu und einige scheinen zu testen — E-Mails mit Random-Empfängern an meine Domains. Gegen Tests habe ich nichts, aber grob abgesprochen wäre schön, mein Monitoring wird sonst immer so wuschig.

Kurz zusammengefasst:

  1. Basis von allem ist DNSSEC.
  2. TLSA-Records sind DANE.
  3. Postfix kann TLSA-Records auswerten, ohne selbst welche für sein System zu haben.

Weiterführend:

Fragen? Einfach melden.

Mal wieder auffällig viele Brute-Force SSH Angriffe….

11. Januar 2015 / / Keine Kommentare

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme.

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann. Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

Siehe auch: SSH-Server absichern mit MFA, SSH Brute Force, Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi, SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen​

Fragen? Einfach melden.

Openfire: 404 Remote Server Not Found bei S2S-Verbindungen mit TLS

19. November 2014 / / Keine Kommentare

Seit ich für die Server-zu-Server-Verbindungen (S2S) auf meinem Openfire TLS erzwinge, melden sich andere Openfire-Admins: Ihre User bekommen ein „404 remote server not found“. Nachrichten gehen nur in eine Richtung durch. Wenn die Unterhaltung einmal läuft, klappt es für eine Weile. Ein seltsamer Effekt der nicht direkt auf die Ursache schließen lässt.

Das Problem

Das Problem liegt nicht am eigenen Server und nicht am DNS. Es liegt am Java-Keystore auf der Gegenseite. Java 6 und einige Versionen von Java 7 können die Zertifikatskette nicht korrekt aufbauen, wenn das Intermediate-Zertifikat der CA fehlt. Mein Server sendet es zwar mit, aber Java ignoriert es und versucht die Kette allein aus dem lokalen Truststore zu bauen.

Im warn.log des betroffenen Openfire findet man dann:

org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation

Die Lösung: Intermediate-Zertifikat importieren

Der Admin des betroffenen Openfire muss das Intermediate-Zertifikat der CA in den Java-Truststore importieren. Auf einem Debian-System:

cd /etc/openfire/security/
/etc/init.d/openfire stop

# Intermediate-Zertifikat der CA herunterladen
wget "https://example-ca.com/intermediate.crt"

# In den Truststore importieren
keytool -import -keystore truststore -alias ca-intermediate -file intermediate.crt
# Passwort: changeit (Java-Default)

/etc/init.d/openfire start

Das Prinzip gilt für jede CA. Das Intermediate-Zertifikat von der Webseite der CA herunterladen und mit keytool in den Truststore importieren. Falls das Zertifikat bereits vorhanden ist, meldet keytool das und man kann den Import überspringen.

Prüfen ob die Kette stimmt

Mit openssl lässt sich prüfen ob der Server das Intermediate-Zertifikat korrekt ausliefert:

openssl s_client -showcerts -connect jabber.example.com:5222 -starttls xmpp

Entscheidend ist die letzte Zeile der Ausgabe:

Verify return code: 0 (ok)

Steht dort etwas anderes, fehlt ein Zertifikat in der Kette oder das Intermediate-Zertifikat wird nicht mitgesendet. In dem Fall muss der Serverbetreiber seine Zertifikatskonfiguration in Openfire prüfen.

Wer schon dabei ist die TLS-Konfiguration anzufassen: Im Beitrag zu unsicheren Ciphern und Protokollen in Openfire steht wie man die veralteten Algorithmen loswird.

Fragen? Einfach melden.

DNSSEC: KSK auf 4096 Bit aktualisieren und SHA-512 vorbereiten

18. November 2014 / / Keine Kommentare

Ich habe nach längerem dann mal meinen KSK (Key Signing Key) für DNSSEC getauscht. Der alte war ein 1024-Bit NSEC3RSASHA1. Damit ist auch klar, warum er weg musste: 1024 Bit RSA gilt seit Jahren als zu schwach für langfristige Sicherheit, und SHA-1 steht ebenfalls auf der Abschussliste.

Die neuen Schlüssel

Zwei neue KSKs, beide mit 4096 Bit:

1. NSEC3RSASHA1, 4096 Bit  (primär, abwärtskompatibel)
2. RSASHA512, 4096 Bit     (Reserve, ohne SHA-1)

Die Idee: Der NSEC3RSASHA1 als primärer Schlüssel, weil ihn jede halbwegs aktuelle Software versteht. Der RSASHA512 liegt als Backup bereit, falls SHA-1 irgendwann komplett fällt. Inzwischen sollte jede aktuelle Software mit beiden Algorithmen umgehen können. Wenn nicht, wird es wirklich Zeit für ein Update.

KSK-Rollover

Ein KSK-Tausch ist kein Schalter den man umlegt. Man muss den neuen Schlüssel veröffentlichen, warten bis sich der DS-Record bei der übergeordneten Zone (also bei DENIC, Verisign etc.) verbreitet hat, und erst dann den alten entfernen. Dazwischen signiert man mit beiden gleichzeitig. Das dauert je nach TTL einige Tage.

Das Ergebnis auf DNSViz sieht sauber aus. Alle drei Zonen validieren korrekt:

Wer DNSSEC von Grund auf einrichten will, findet die Anleitung unter DNSSEC einrichten mit BIND. Fragen? Einfach melden.

Alternative SPF-RECORDS im DNS

2. November 2014 / / Keine Kommentare

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 als deprecated eingestuft. SPF wird ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem. Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir.

So long

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑