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

Kategorie: Self-Hosting & Infrastruktur (Seite 6 von 9)

Server selbst betreiben — Erfahrungen mit FreeBSD-Jails, Nginx, Postfix, Dovecot, Matrix und der eigenen Infrastruktur.

Spam im Jabber / XMPP

Aktuell beobachte ich sehr für SPAM mit teils russsichem Inhalt zu Exploits und ähnlichem, der von vielen verschiedenen Domains bei meinem Server ankommt.

Die Admins dieser Server kommen zum Teil aktuell nicht mit dem Aussortieren der Spamaccounts nach. Ich selbst habe ebenfalls schon viele Anmeldeversuche dieser Spamaccounts bewundert. Diese werden automatisch erstellt, dann etwas später wird darüber ein einem riesigen Schwung versucht Spam zu verteilen und nach knapp 1Stunde verstaubt der Account wieder. Dagegen hilft fast nur die einfache Benutzeranmeldung über xmpp zu deaktivieren.

Derzeit bei mir also nur möglich über (Gott ist das hässlich): https://jabber.kernel-error.de:9091/plugins/registration/sign-up.jsp

Oh ja, die Spamserver habe ich aktuell geblockt. Im Moment sind es die folgenden:

ajabber.me     
anonymitaet-im-inter.net     
codingteam.net     
exploit.im     
igniterealtime.org     
jabber.co.za     
jabber.no     
jabber.zerties.org     
jabbim.cz     
jclub.pw     
jumbo.li     
justnet.pl     
km-net.pl     
lih.im     
pandion.im     
qip.ru     
svnet.fr     
sync-hv.de     
talkers.im     
tigase.im     
xmpp.svnet.fr

Siehe auch: Eigenen Jabber-Server betreiben

Fragen? Einfach melden.

Apache 2.4 und Diffie-Hellman DHE mit 4096bit

Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:

Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?

Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.

Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<

Wer gerne nachträglich generieren möchte macht es mir:

$ openssl gendh 4096 > dh_4096.pem

Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.

Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.

easy

So long….

Fragen? Einfach melden.

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

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

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.

Kein Jabber/XMPP mehr ohne Transportverschlüsselung

Hallo zusammen,

wie ja bereits vor einiger Zeit angekündigt, habe ich heute TLS als Transportverschlüsselung zwischen den Server to Server Verbindungen erzwungen. Für die Clients s2c besteht dieser Zwang bereits seit langem, nun also auch für die Verbindungen zwischen der Server.

Ich habe mir natürlich vorher die Mühe gemacht, andere Serverbetreiber anzuschreiben, wenn ich zu ihnen keine verschlüsselte s2s Verbindung aufbauen konnte. Ein paar sind aktiv geworden, ein paar nicht. Die Anzahl der nicht verschlüsselten s2s Verbindungen ist denn noch verschwindend gering! Ich habe diese Verbindungen also hiermit bewusst „abgehängt“.

Sollte ihr also aktuell Probleme mit der Verbindung zu oder von meinem System haben, bitte einfach melden!

So long…

Siehe auch: Openfire: Unsichere TLS-Cipher deaktivieren

Fragen? Einfach melden.

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

IP-Reverse-Map-Delegation nach RFC 2317 mit Provider-Zone, Kunden-Subzone, CNAME-Verweisen, PTR-Antwort und Troubleshooting-Hinweisen.

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

Citrix XenServer: Festplattenpriorität im Storage-Pool konfigurieren​

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die Storage-Pool-Konfiguration hat sich grundlegend geändert. Alternativen: Proxmox VE oder XCP-ng.

Hat man in seinem Citrix XenServer mehrere virtuelle Festplatte in einem Storage liegen, kann es vorkommen dass man einzelnen davon eine höhere Priorität zuweisen möchte als anderen.

Leider gibt es diese Option nicht klickbar im Citrix XenCenter, sondern man muss die Konsole (CLI) bemühen.

Das Einstellen dieser Prioritäten ist etwas komplexer, ich beschränke mich in meinem Beispiel auf die „schnell und einfach“ Version. Damit möchte ich sagen, bitte selbst damit beschäftigen.

Zum Thema… Es gibt verschiedene Algorithmen, welche man für sein QOS der virtuellen Festplatten wählen kann. Ich nehme gerne ionice, da es bei mehreren Systemen eher um IO-Probleme als reine Durchsatzprobleme geht. Diesem Algorithmus gebe ich die Information mit das es hier um realtime geht und die Klasse in welche die virtuelle Festplatte gesteckt werden soll. Bei der Klassifizierung ist zu beachten, dass es ein ganzzahliger Wert zwischen 0 und 7 sein muss. Die Klasse 0 hat dabei die höchste Priorität und die Klasse 7 die geringste.

Kleines Beispiel gefällig?

Wir sind auf der root Konsole des XenServers. Ich lasse mir die VMs mit ihren Platten anzeigen, in diesem Fall gibt es keine Snapshots. Würde es welche geben, gleiches Vorgehen, es sieht nur etwas „unübersichtlicher“ aus.

[root@fra.srv.ha.xen.05 ~]# xe vbd-list
uuid ( RO)             : 66a3903c-8eba-4d8a-92d9-c435d399d3ac
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): VM-Kennzeichnung
         vdi-uuid ( RO): <not in database>
            empty ( RO): true
           device ( RO):

uuid ( RO)             : 4e004302-c32e-4c90-b986-9efc0b1995a1
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): 47e5ab14-9cf8-4e7f-88b8-fe20247efa85
            empty ( RO): false
           device ( RO): xvdb

uuid ( RO)             : 5b4f70ec-07cb-47a5-aa05-91647cf38b78
          vm-uuid ( RO): 577e39d4-e771-477b-8829-8648b05b682b
    vm-name-label ( RO): Laufwerkskennzeichnung
         vdi-uuid ( RO): e6796376-995f-4a99-8ba6-893c30aa6a14
            empty ( RO): false
           device ( RO): xvda

Zu erkennen ist ein System (577e39d4-e771-477b-8829-8648b05b682b) mit zwei virtuellen Festplatten (4e004302-c32e-4c90-b986-9efc0b1995a1 / 5b4f70ec-07cb-47a5-aa05-91647cf38b78).

Versorgt mit diesen Informationen kann ich nun direkt die beiden Platten mit neuer Priorität versehen.

$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=4e004302-c32e-4c90-b986-9efc0b1995a1 qos_algorithm_params:class=5

$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_type=ionice
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_paramsched=rt
$ xe vbd-param-set uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 qos_algorithm_params:class=5

Als Test lasse ich mir nun noch einmal die gesetzten Einstellungen auf der Konsole ausgeben. Einmal den gewählten QOS-Algorithmus und dann dessen gesetzte Optionen.

$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_type
ionice
$ xe vbd-param-get uuid=5b4f70ec-07cb-47a5-aa05-91647cf38b78 param-name=qos_algorithm_params
class: 5; sched: rt

Noch Fragen? Dann fragen…

 

Der eingeschlafene Hintern im DataCenter

Da hocke ich heute mal wieder im DataCenter und arbeite an den Systemen. Wie immer, im Schneidersitz auf dem Boden und mit den Notebook auf den Beinen. Nach einiger Zeit merke ich, dass mein Hintern aufgehört hat sich über die Temperatur zu beschweren. Dieses ist in der Regel ein untrügerisches Zeichen dafür, dass er eingeschlafen ist. Was nun Vor- und Nachteile hat. Vorteil, ich kann noch länger so sitzen ohne das es fühlbar unbequem wird; Nachteil, wenn ich später versuche aufzustehen, wird es lustig!

Das muss doch irgendwie besser gehen, oder? OK, ok… Es gibt in der Regel einen hässlichen Hocker, der ist aber so hässlich das man doch besser auf dem Boden sitzt, weil es dann doch bequemer ist. Dann könnte ich mir noch ein Kissen mitbringen und es unterlegen.. ne, doch nicht! Wenn ich so überlege dann finden sich in meiner Erinnerung nur Bilder, von auf dem Boden hockenden Technikern vor einem Schrank. Alle mit kaltem Hintern und jedem schläft dieser früher oder später ein. Da sollte mal jemand was erfinden *AUFRUF*.

Wie auch immer, wenn ich mir schon über solche Dinge Gedanken mache… Dann kann es mir nicht so schlecht gehen, oder vielleicht genau aus diesem Grund doch? Na dann werde ich wohl nun mal jemanden aufwecken, wünscht mir Glück.

Fragen? Einfach melden.

ownCloud Sync Client Sabayon

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt und Sabayon Linux wurde 2020 eingestellt. Der ownCloud-Nachfolger ist Nextcloud.

Auf meinem Sabayon System findet mein Rigo leider keinen owncloud-client. Glücklicherweise baut sich dieser fast von alleine.

Ich lade mir also einfach die beiden Quellpakete qtkeychain-master.zip und mirall-1.6.1rc1.tar.bz2 herunter. Entpacke sie qtkeychain-master in qtkeychain-master und mirall-1.6.1rc1 in mirall. Dann beginne ich mit dem bauen, dabei lege ich den späteren Installationsprefix auf /usr fest damit es am Ende nicht alles unter /usr/local… liegt. Dieses aber, wie so oft, selbst denkend nachmachen, es wird schnell unordentlich.

$ mkdir qtkeychain-build
$ cd qtkeychain-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../qtkeychain-master
$ make
$ sudo make install

Jetzt noch der eigentliche owncloud-client.

$ mkdir mirall-build
$ cd mirall-build
$ cmake -DCMAKE_BUILD_TYPE="Debug" cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ../mirall
$ make
$ sudo make install

Schon lässt sich alles aufrufen und wie gewünscht nutzen. Ach ja, sollten noch Abhängigkeiten fehlen, finden sich diese aktuell alle mit Rigo! Sauberer wäre es ebenfalls direkt Pakete zu erstellen, dann könnte man sie sauberer ersetzten, löschen usw.. Ist mir gerade für diese Nummer zu aufwendig.

Viel Spaß!

Openfire und IPv6: NumberFormatException bei S2S-Authentifizierung

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑