-=Kernel-Error=-

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

Autor: Sebastian van de Meer (Seite 26 von 46)

Openfire und IPv6: NumberFormatException bei S2S-Authentifizierung

20. Juni 2014 / / Keine Kommentare

Openfire hat ein Problem wenn in der /etc/resolv.conf der Nameserver als IPv6-Localhost eingetragen ist (::1). Der Java-DNS-Client kann die IPv6-Adresse nicht parsen und wirft eine NumberFormatException. Das Ergebnis: Keine S2S-Verbindungen, keine Authentifizierung mit Remote-Servern.

Fehlerbild

Im /var/log/openfire/error.log findet sich:

org.jivesoftware.openfire.session.LocalOutgoingServerSession
  - Error authenticating domain with remote server: jabber.ccc.de
java.lang.NumberFormatException: For input string: ":1"
    at java.lang.Integer.parseInt(Integer.java:492)
    at com.sun.jndi.dns.DnsClient.(DnsClient.java:125)
    at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:192)
    at org.jivesoftware.openfire.session.LocalOutgoingServerSession
        .createOutgoingSession(LocalOutgoingServerSession.java:270)

Java versucht ::1 als Portnummer zu parsen und scheitert an dem Doppelpunkt. Der Bug steckt in Javas DnsClient-Klasse die IPv6-Adressen in der resolv.conf nicht korrekt behandelt.

Lösung

In der /etc/resolv.conf den Nameserver von ::1 auf 127.0.0.1 umstellen:

# vorher
nameserver ::1

# nachher
nameserver 127.0.0.1

Openfire neu starten. Der lokale DNS-Resolver lauscht in der Regel auf beiden Adressen, die Namensauflösung funktioniert über IPv4 genauso. Neuere Java-Versionen haben den Bug behoben, aber wer eine ältere Version nutzt oder nicht updaten kann, ist mit dem IPv4-Workaround auf der sicheren Seite.

Weitere Openfire-Probleme mit S2S-Verbindungen: 404 Remote Server Not Found behandelt fehlende Intermediate-Zertifikate.

Fragen? Einfach melden.

DNSSEC-fähiger Registrar

18. Juni 2014 / / Keine Kommentare

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registrar ich zusammenarbeite. Vor allem im Hinblick auf DNSSEC und die DS-Records, die man beim Registrar hinterlegen muss.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Damals habe ich dort gerne mit Herrn Metz zusammengearbeitet. Es war immer jemand erreichbar, und auch etwas ungewöhnliche Dinge ließen sich schnell umsetzen. Das Webinterface konnte 2014 noch keine DS-Records entgegennehmen, der Weg per E-Mail funktionierte aber binnen Minuten.

Es kommt selten vor, dass ich hier Werbung für ein Unternehmen mache — dieses hatte es damals verdient.

Mehr zu DNSSEC und BIND gibt es im DNSSEC-HowTo. Fragen? Einfach melden.

TLSA DANE Record für E-Mail in Postfix prüfen: Schritt-für-Schritt-Anleitung

3. Juni 2014 / / Keine Kommentare

Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint.

KLICK: https://de.ssl-tools.net/mailservers/kernel-error.de

Siehe auch: TLSA und DANE manuell prüfen

Fragen? Einfach melden.

IPv6 und Carrier Grade NAT: Warum nicht der ISP schuld ist

30. Mai 2014 / / Keine Kommentare

Nach dem IPv6-Kongress 2014 war die Verbreitung mal wieder kurz im Rampenlicht. Nach über 15 Jahren IPv6 war die Umstellung noch immer nicht weit genug. Alle Empfehlungen von Experten wurden ignoriert. Es gab ja keine Nachfrage. Bis den ISPs die IPv4-Adressen ausgingen.

Carrier Grade NAT

Wer in Deutschland einen neuen Internetanschluss bei einem Kabelnetzbetreiber bekommt, bekommt oft einen Carrier Grade NAT (CGN) Anschluss. Das bedeutet: Keine eigene öffentliche IPv4-Adresse mehr. Stattdessen eine private Adresse hinter einem zentralen NAT-Router des ISPs. Versteckt wird das hinter Bezeichnungen wie DS-Lite oder DS64-Lite.

Das Port-Problem

Jede TCP-Verbindung verbraucht auf der abgehenden IP-Adresse einen Port. Ports sind 16-Bit-Zahlen, maximal 65.535. Abzüglich der reservierten Ports bleiben rund 64.500 gleichzeitige Verbindungen pro IP. Ein einzelner Benutzer baut schnell 50 und mehr Verbindungen gleichzeitig auf: E-Mail, Messenger, Browser mit parallelen Requests. Dazu kommen Verbindungen die nicht sauber geschlossen werden und bis zum Timeout offen bleiben.

Offene Verbindungen anzeigen:

netstat -tapen

Wenn sich hunderte Kunden eine öffentliche IP teilen, sind die Ports schnell aufgebraucht. Der ISP könnte bestehende Verbindungen nach einer Zeit hart zurücksetzen. Oder die maximale Anzahl gleichzeitiger Verbindungen pro Kunde begrenzen. Beides führt zu Problemen.

Dazu kommt: Viele Webserver und Mailserver begrenzen die Anzahl gleichzeitiger Verbindungen pro IP-Adresse, als Schutz gegen DDoS. Wenn hundert Kunden hinter einer IP sitzen, trifft dieses Limit schnell.

Wer ist schuld?

Ein gutes Beispiel war Sipgate. Der VoIP-Anbieter beschwerte sich öffentlich darüber, dass seine Kunden hinter CGN-Anschlüssen Probleme mit ihren Sipgate-Leitungen hatten. Sipgate schob den schwarzen Peter an Unitymedia und hoffte, dass sich jemand meldet um das Problem gemeinsam zu lösen.

Was dabei unterging: Unitymedia hatte auf eigene Kosten einen Workaround eingerichtet, damit Dienste die es nach Jahren noch nicht geschafft hatten IPv6 zu unterstützen überhaupt noch erreichbar waren. Und dann kommt ein Diensteanbieter und sagt: Dein Workaround funktioniert nicht perfekt mit unserem System, bitte nachbessern.

Facepalm reaction GIF about IPv6 adoption delays

Der Schuldige ist nicht der ISP. Der Schuldige ist der Diensteanbieter, der es nach über 15 Jahren Vorlaufzeit nicht geschafft hat seinen Dienst IPv6-fähig zu machen. Wer Probleme mit seinem Internetanschluss hat die auf CGN zurückzuführen sind: Nicht den ISP anrufen, sondern den Diensteanbieter fragen wann IPv6 kommt.

Fragen? Einfach melden.

Gestohlene FTP-Zugangsdaten BSI

28. Mai 2014 / / Keine Kommentare

WOOOOHOOOOO… Ich habe auch mal so eine E-Mail bekommen.

CERT-Bund Reports <noreply@reports.certbund.net> schrieb am 27.05.2014 11:31:10:

Von: CERT-Bund Reports <noreply@reports.certbund.net>
An: registry@domain.tld
Datum: 27.05.2014 11:31
Betreff: [CERT-Bund#2014052612345678] Gestohlene FTP-Zugangsdaten

Sehr geehrte Damen und Herren,

CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste
gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten.
Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden
und werden offenbar dazu verwendet, um in mit dem FTP-Account
verbundene Webseiten schädlichen Code einzuschleusen, welcher auf
Drive-by-Exploits verweist. Es liegen leider keine Informationen vor,
wann und wie die Zugangsdaten ausgespäht wurden.

Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in
Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.

Format: ASN | IP-Adresse | FTP-Login

Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden
entsprechend zu informieren.

Bitte bestätigen Sie den Eingang dieser Benachrichtigung und
informieren Sie uns über die von Ihnen getroffenen Maßnahmen.

Liste der Zugangsdaten für Server in Ihrem Netzbereich:

 12345 | 123.123.123.123  | benutzername:IG******@ftp21.domain.tld

Mit freundlichen Grüßen
Team CERT-Bund

Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat C21 –
CERT-Bund Godesberger Allee 185-189
D-53175 Bonn

————————————————————————
Dies ist eine automatisch generierte Nachricht.
Bitte beachten Sie beim Antworten die Reply-To Adresse.

Siehe auch: E-Mail-Benachrichtigung bei Root-Login

Fragen? Einfach melden.

Pockethernet – Will haben Gerät!

23. Mai 2014 / / Keine Kommentare

Achtung, böser YouTube-Link!

Ich habe vor einiger Zeit ein „Will haben Gerät!“ gesehen… Bzw. den Prototyp eines solchen Gerätes. Zu dem Zeitpunkt wurde noch Geld für das Projekt gesammelt. Inzwischen ist die nötige Summe mehr als vorhanden und es geht seinen Weg… 

Das Teil nennt sich Pockethernet, ein Video gibt es unten und einen Link zum Projekt gibt es hier: http://pockethernet.com/

Klar wird es kaum mit einem guten Fluke Gerät mithalten können… Für viele kleine Tests scheint es aber mehr als ausreichend zu sein. Schaut einfach mal ins Video! Wer will es noch?

Fragen? Einfach melden.

TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL

19. Mai 2014 / / Keine Kommentare

Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.

Zertifikat holen

Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:

openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 \
  -servername smtp.kernel-error.de 2>/dev/null | \
  openssl x509 -outform PEM > /tmp/server.crt

Das Zertifikat liegt jetzt in /tmp/server.crt.

Hash berechnen

Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:

Usage0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512

Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:

dig _25._tcp.smtp.kernel-error.de TLSA +short

Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):

# Selector 0 (Full Certificate), SHA-256
openssl x509 -in /tmp/server.crt -outform DER | openssl sha256
# Ausgabe: SHA2-256(stdin)= 94c8e1bd...

Bei Selector 1 (nur SPKI, Public Key) und SHA-256:

# Selector 1 (SPKI), SHA-256
openssl x509 -in /tmp/server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | openssl sha256

Den berechneten Hash mit dem Wert aus dem TLSA-Record vergleichen. Stimmen sie überein, ist der Record korrekt.

Schnelltest mit posttls-finger

Wer nicht alles von Hand machen will: posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf in einem Schritt:

posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de

In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.

Wer DANE für den eigenen Mailserver einrichten will, findet die Anleitung unter Postfix mit DANE und DNSSEC absichern. Die Grundlagen zu DANE und TLSA-Records erklärt der Beitrag DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern. Fragen? Einfach melden.

dnssec validator Browser Plugin

9. Mai 2014 / / Keine Kommentare

Veraltet: Das DNSSEC Validator Browser-Plugin wird nicht mehr gepflegt und ist in aktuellen Firefox-/Chrome-Versionen nicht mehr verfügbar. DNSSEC-Validierung sollte auf dem DNS-Resolver stattfinden, nicht im Browser.

Na schau mal einer an… Das Browser Plugin für den DNSSEC Validator kann nun auch DANE / TLSA und er zeigt es angenehm übersichtlich an.

https://www.dnssec-validator.cz/pages/download.html
Ist in jedem Fall noch mal einen Klick wert.

Exchange Online und Office 365: DNS-Einträge für eine BIND-Zone

9. Mai 2014 / / Keine Kommentare

Bei mir ist die Frage aufgeschlagen, was man in seine BIND-Zone schreiben muss, wenn man Exchange Online, Lync/Skype for Business oder Office 365 nutzen will. Microsoft zeigt einem während der Einrichtung eine Tabelle mit DNS-Einträgen an. Für Webinterface-Hoster kein Problem, für BIND-Admins aber erstmal Übersetzungsarbeit.

Ich liebe es, wenn Microsoft solche Dinge ins Deutsche übersetzt. „Verweist auf die Adresse“ statt „Points to“. „Gültigkeitsdauer“ statt „TTL“. Aber gut.

Hinweis: Lync heißt inzwischen Teams, die SRV-Records für Lync Federation sind aber weiterhin nötig, solange Skype for Business im Tenant aktiv ist.

Was Microsoft verlangt

Für eine Domain (hier kernel-error.com als Beispiel) werden folgende Records benötigt:

# Exchange Online
MX    0  kernel-error-com0i.mail.protection.outlook.com
TXT      "v=spf1 include:spf.protection.outlook.com -all"
CNAME    autodiscover → autodiscover.outlook.com

# Lync / Skype for Business / Teams
SRV      _sip._tls           443  1 100  sipdir.online.lync.com
SRV      _sipfederationtls._tcp 5061 1 100  sipfed.online.lync.com
CNAME    sip → sipdir.online.lync.com
CNAME    lyncdiscover → webdir.online.lync.com

# Office 365 allgemein
TXT      "MS=ms12345678"   (Domain-Verifikation)
CNAME    msoid → clientconfig.microsoftonline-p.net

Das BIND-Zonefile

Und so sieht das dann als BIND-Zone aus:

$ORIGIN .
$TTL 86400
kernel-error.com  IN SOA ns1.kernel-error.de. root.kernel-error.de. (
                      2014010101 ; serial
                      15000      ; refresh
                      1800       ; retry
                      604800     ; expire
                      86400      ; minimum
                  )
                  NS  ns1.kernel-error.de.
                  NS  ns2.kernel-error.org.

$TTL 1H
                  IN TXT "MS=ms12345678"
                  IN TXT "v=spf1 include:spf.protection.outlook.com -all"
                  IN MX  0 kernel-error-com0i.mail.protection.outlook.com.

_sip._tls.kernel-error.com.              IN SRV 1 100 443  sipdir.online.lync.com.
_sipfederationtls._tcp.kernel-error.com. IN SRV 1 100 5061 sipfed.online.lync.com.

$ORIGIN kernel-error.com.
$TTL 1H
autodiscover  IN CNAME autodiscover.outlook.com.
sip           IN CNAME sipdir.online.lync.com.
lyncdiscover  IN CNAME webdir.online.lync.com.
msoid         IN CNAME clientconfig.microsoftonline-p.net.

Prüfen

Die gesetzten Records lassen sich mit dig prüfen:

dig +nocmd +noall +answer kernel-error.com IN MX @ns1.kernel-error.de
dig +nocmd +noall +answer kernel-error.com IN TXT @ns1.kernel-error.de
dig +nocmd +noall +answer _sip._tls.kernel-error.com IN SRV @ns1.kernel-error.de
dig +nocmd +noall +answer autodiscover.kernel-error.com IN CNAME @ns1.kernel-error.de

Viel Spaß mit den Microsoft-Online-Produkten. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑