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!
Der Jabber/XMPP Server von Ignite Realtime, Openfire ist ein ganz nettes System. Leider ist das Thema Sicherheit noch nicht ganz in der aktuellen Version angekommen. Bei den Entwicklern schon. In den aktuellen Nightly Builds sind bereits die „unsichern“ Protokolle und cipher im Default aus. In der Beta geht es so… Die aktuelle stable Openfire Version 3.9.3 bietet leider weder etwas einstellbares, noch eine zufriedenstellende standard Konfiguration.
Sucht man nun im Internet nach: „how to disable weak ciphers“ in Verbindung mit Openfire findet man derzeit nur viele Menschen, welche auf der Suche nach einer gangbaren Lösung sind. Leider finden sich kaum welche 🙁
Eine Lösung möchte ich hier kurz vorstellen….
Openfire basiert auf Java. Ab Oracle Java 8 gibt es eines hier Möglichkeiten die Protokolle und Cipher zu deaktivieren, welche nicht genutzt werden sollen.
Wenn ich also von einem Debian oder Ubuntu System ausgehe und ich hinsichtlich Java nur über Openfire nachdenken muss, lässt sich mit folgender Konfiguration von Oracle Java 8 ein brauchbares Ergebnis erzielen.
In der Konfigurationsdatei: /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security sollten folgende zwei Optionen gesetzte werden. Dabei ist natürlich darauf zu achten, dass sie nicht noch einmal in der Konfiguration vorkommen 😉
Damit wird SSLv3 deaktiviert, MD5 sowie RC4 werden ebenso wie einige recht schlechte Cipher nicht weiter verwendet. Mehr Informationen erhält man über die Schlagwörter: Java8 Algorithm restrictions for Secure Socket Layer/Transport Layer Security processing sowie Java8 Algorithm restrictions for certification path processing
Ein Starten und Stoppen des Openfire sollte diese Einstellungen nun aktivieren. In diesem Zusammenhang sollte natürlich noch auf die JCE Unlimited Strength Jurisdiction Policy Files geachtet werden. Diese ermöglichen höhere Bit-Stärken als 128!
Dazu passend findet sich im Postfix Logfile folgendes:
Feb 2 12:15:21 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 2 12:15:21 postfix/smtp[1520]: 30E4E7461347: Server certificate not verified
Feb 2 12:15:22 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 2 12:15:22 postfix/smtp[1520]: 30E4E7461347: to=<mailer@domain.tld>, relay=domain.tld[1.2.3.4]:25, delay=433522, delays=433521/0.09/0.63/0, dsn=4.7.5, status=deferred (Server certificate not verified)
Na? Schon eine Idee? Erst soll die TLS Verbindung trusted sein und dann doch wieder nicht? Ganz einfach 🙂 Es ist DANE…. Postfix würde ja selbst eine E-Mail zustellen, wenn er das Zertifikat nicht prüfen könnte. Hat der Empfänger aber einen TLSA-Record für sein Mailserver Zertifikat veröffentlicht und Postfix prüft dieses mit negativem Ergebnis, dann kann man wohl davon ausgehen, dass da etwas nicht stimmt. Entweder der Empfänger hat ein Problem mit seiner Konfiguration oder es versucht sich gerade jemand „dazwischen“ zu drängen.
Weiter prüfen konnte ich es mit posttls-finger:
$ posttls-finger -t30 -T180 -c -L verbose,summary domain.tld
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.domain.tld IN TLSA 3 0 1 B3:E7:94:4A:CE:14:0D:CE:53:08:C6:D8:A5:D3:8C:EE:DD:94:FC:8A:B4:DD:8E:DD:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: setting up TLS connection to domain.tld[2001:1111:1:1111::1]:25
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=0 verify=1 subject=/C=DE/CN=www.domain.tld/emailAddress=hostmaster@domain.tld
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: subject_CN=www.domain.tld, issuer_CN=StartCom Class 1 Primary Intermediate Server CA, fingerprint=65:76:45:E3:50:1A:54:5D:BE:30:8F:DD:DD:DD:DD:DD:DD:DD:DD:DD, pkey_fingerprint=63:53:F8:60:76:8D:01:E8:57:93:EA:3C:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: Untrusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Passt also wirklich nicht… Gleicher Test auf verschiedenen Systemen, gleiches Ergebnis. Ebenfalls die einschlägigen Webseiten bringen diese Meldung (https://de.ssl-tools.net/mailservers/).
Ich muss zugeben, ist eine Premiere für mich. Also ein wirklich echt fehlgeschlagener DANE Test von Postfix, welcher die Mailzustellung verhindert hat. Natürlich hat postfix nicht nach dem ersten Versuch aufgegben, diese Prüfung führt zu einem temporären Fehler der 4xx Reihe. Postfix versucht es also ein paar Tage. In meinem Fall hat also alles genau so funktioniert, wie ich es mir gewünscht habe. Postfix testet die TLSA-Records, bemerkt einen Fehler, logt diese und probiert es noch einmal. Der Fehler bestand dauerhaft und Postfix gab mir die Mail zurück, mit der Info das etwas mit dem Zertifikat des Empfängers nicht stimmt. Das hat Postfix wirklich gut gemacht *tätschel*
Inzwischen hat ja fast jeder bei uns „schnelles“ Internet…. So lassen sich per E-Mail auch mal etwas größere Dateien verschicken. Dennoch sollte man so ab 5MB ein schlechtes Gefühl haben und sich ab 10MB Anhängen nicht mehr über abgewiesene E-Mails ärgern.
Das Problem mit großen Dateianhängen bei E-Mails ist ja nicht nur die Verstopfung der Leitungen… Mailserver arbeiten sich daran ab, der absendende und empfangende Client ebenfalls. Hängt dann noch ein Virenscanner dazwischen rechnet noch jemand. Dann liegt die Datei auf dem System des Absenders, in dessen Postfach, im Postfach dem Empfängers und natürlich noch auf dem System des Empfängers. Bei einem 500MB Anhang sind das schon mal 2GB für nix.
Inzwischen gibt es 1000 Möglichkeiten um große Dateien schnell und einfach auszutauschen. Selbst ohne seine Daten auf irgendeinen Server bei irgendeinem Anbieter zu legen. So zum Beispiel über owncloud….. Hochladen muss man die Datei ja in jedem Fall zu seinem Mailserver, warum also nicht lieber in die „Cloud“? Ok, es ist etwas aufwendig. Erst hochladen, dann teilen, dann den Link kopieren und in die E-Mail packen, usw. usw…
Für Anwender des Mailclients Thunderbird gibt es in diesem Zusammenhang eine noch schönere Lösung. Sie nennt sich filelink. Im Grunde nichts weiter als eine kleine Funktion, welche dem Anwender etwas Arbeit abnimmt!
Hängt der Anwender eine Datei an seine E-Mail an, welche einen einstellbaren Schwellwert überschreitet, schlägt Thunderbird diesem vor, den Anhang für den Anwender in einen dieser „Austauschservices“ zu laden. Stimmt der Anwender zu, schiebt Thunderbird die Datei hoch und verlinkt sie automatisch in den E-Mail Body. Dieses hält die E-Mai klein und der Empfänger kann selbst entscheiden, ob und wann er den „Anhang“ herunterladen möchte.
Aktuell bringt Thunderbird aus dem Karton leider nur die Verknüpfung zu den bekannten großen Anbietern wie z.B.: dopbox mit. Dort möchte man ja nicht unbedingt seine Daten ablegen. Für owncloud habe ich vor kurzem eine gut funktionierendes Thunderbird Plugin gefunden:
Einfach herunterladen, installieren, zwei drei Kleinigkeiten in der eigenen Cloud einstellen und glücklich sein 🙂 Mit zwei/drei erklärenden Sätzen in der E-Mail versteht es zudem fast jeder Empfänger. Noch Fragen?
Ich experimentiere in der letzten Zeit etwas mehr mit PC-BSD herum und so langsam verdrängt es sogar seinen Vater FreeBSD von meinem Desktop….
Der angenehme Vorteil von PC-BSD ist, dass es bereits viele Kleinigkeiten für den Desktopeinsatz „fertig“ vorhält. Man muss nicht erste jede Kleinigkeit selbst konfigurieren (ich werde SO faul). Der Nachteil ist, man lernt nix mehr 🙁 Wie auch immer…
Ich wollte gerade eine CD brennen, starte mein xfburn und dieses erzählt mir es könne keinen Brenner finden oder die Berechtigungen würden nicht stimmen.
** (xfburn:12447): WARNING **: No drives were found! If this is in error, check the permissions
Nanu?!?! Als erstes wollte ich die Berechtigungen ausschließen:
$ pc-su xfburn
Passwort:** Message: Using elementar transcoder.
Brennen klappt… Also wirklich ein Problem mit den Berechtigungen. Dann schauen wir sie uns mal durch..
Der Brenner ist im Notebook das Device /dev/cd0 mal sehen…
$ ls -lisa /dev/cd0
105 0 crw-rw-rw- 1 root operator 0x69 21 Jan 07:40 /dev/cd0
Sieht doch gut aus… Viele Anwendungen nutzen aber einen Link um auf das jeweilige Laufwerk zuzugreifen, auch wenn es der Brenner nicht tun sollte, denn… (dazu später)… mal schauen und gelesen haben stört aber nicht 🙂
$ ls -lisa /dev/cdrom
131 0 lrw-rw-rw- 1 root wheel 3 21 Jan 07:43 /dev/cdrom -> cd0
$ ls -lisa /dev/dvd
132 0 lrw-rw-rw- 1 root wheel 3 21 Jan 07:43 /dev/dvd -> cd0
Pass bei mir aber auch, sollte es nicht passen hilft bei Symlinks ein chmod -h 0666…. Nur würde es beim Problem mit dem Brenner nicht helfen! Warum? Nun ja, wer sich an „früher“ unter Linux erinnert, da musste man auch ein Modul laden, welches aus dem ATA Brenner einen SCSI Brenner für den Kernel macht. Funktioniert noch immer ähnlich, ist aber inzwischen im Linux Kernel verklappt. Unter BSD muss man noch immer dafür sorgen. Dafür müssen in der Datei /boot/loader.conf folgende Einträge erstellt werden:
atapicam_load="YES"
hw.ata.atapi_dma="1"
Der erste Eintrag sorgt dafür, dass der ATA Brenner als „SCSI“ Laufwerk ~erkannt~ wird, der zweite aktiviert den DMA Zugriff auf ATA Laufwerke. Ich meine dass im Kernel vom PC-BSD bereits per Default DMA für ATA Geräte aktiviert ist, schadet aber nicht! Ach ja, in meiner PC-BSD loader.conf gab es den nötigen Eintrag bereits. Es war also schon richtig, denn noch ging es nicht 🙁
Macht nix, weiter suchen! Ist das Modul geladen, sollte mir camcontrol nun meine ATA Geräte auflisten können, inkl. deren SCSI ID und dem zugehörigen passthrue Device:
cd0 stimmt, habe ich bereits kontrolliert. pass1? Mal sehen:
$ ls -lisa /dev/pass1
76 0 crw------- 1 root operator 0x4c Jan 21 07:40 /dev/pass1
Na schau mal einer an 😀 Zum Test setzte ich mal passende Rechte auf das Device und starte dann als User mein Brennprogramm.
$ chmod 0666 /dev/pass1
Geht… Dann soll es so bleiben! Nach einem Reboot wären meine vergebenen Rechte wieder weg. Damit diese bleiben muss ich meinen Wunsch in der Datei /dev/devfs.conf hinterlegen. Ein Blick in diese verrät mit, dass sich schon jemand Gedanken gemacht hat (pc-bsd halt…). So sind bereits passende Rechte für das Gerät /dev/pass0 gesetzt. Nur eben nicht für /dev/pass1. Es lässt sich also einfach der Eintrag von pass0 für pass1 kopieren:
/etc/devfs.conf
....
# Commonly used by many ports
link cd0 cdrom
link cd0 dvd
....
# Allow all users to access CD's
perm /dev/acd0 0666
perm /dev/cd0 0666
....
# Misc other devices
own /dev/lpt0 root:cups
perm /dev/lpt0 0666
own /dev/lpt1 root:cups
perm /dev/lpt1 0666
perm /dev/pass0 0666
perm /dev/pass1 0666
....
Nur ein Detail welches noch beim PC-BSD fehlt um es für den Benutzer beim Brennen noch einfacher zu machen. Wenn auch ein Detail, was Benutzer ohne FreeBSD Vorkentnisse ins Straucheln bringen könnte.
Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!
Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….
Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀
Um noch mal ein paar Themen zusammen zu fassen:
1. Basis von allem ist DNSsec 2. TLSA Records „ist DANE“ 3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.
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
Ich räume gerade etwas auf und da finde ich einen Merker für das IPv6 Buch von Jens Link…. Eigentlich etwas dass ich mir in den „Schrank“ stellen wollte. Leider scheint es noch immer nicht kaufbar 🙁 So als einfaches „Einsteigerbüchlein“ schien es mir perfekt. Schade… Werde es dann wohl mal aus meiner Merkliste löschen.
Mal etwas ganz anderes…. Keine Ahnung was ihr so zwischen den Feiertagen macht, ich repariere kaputte Abwasserrohre. Mit Vorliebe hinter der Dusche!
Nein, Scherz! Zumindest zum Teil… Irgendwas machte seit kurzem hinter der Dusche meiner Kinder „Probleme“. Irgendwo in der Wand war etwas undicht. Zwischen den Feiertagen hatte ich Zeit, so zumindest die Einschätzung meiner Frau 😛
Also habe ich alles auf gestemmt und ganz zuletzt das Problem gefunden. Das Abwasserrohr vom Waschbecken war dort undicht. Getauscht und jetzt muss ich wohl eine neue Dusche bauen, TOP.
