IT-Blog von Sebastian van de Meer

Kategorie: IT-Security (Seite 10 von 14)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

Alternative SPF-RECORDS im DNS

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

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.

SSLv3 ist tot…

Veraltet: Dieser Beitrag ist eine Momentaufnahme von 2014. SSLv3 ist seit dem POODLE-Angriff in allen Browsern und Servern deaktiviert. TLS 1.0 und 1.1 wurden ebenfalls inzwischen aus allen Browsern entfernt.

Nein, ich habe es nicht überlesen. SSLv3 ist damit wohl hoffentlich tot!

Es ist ja nicht so als wenn man nicht schon davor gewarnt hätte. Oh was hat diese Meldung bei mir für gute Laune geführt! Wieder mal ein richtiger „Told you so“ Moment für mich.

Oh ja, was zum Lesen gefällig?

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Bäääähhhhmmmm! Das schreit nach einem GIF!

Told you so reaction GIF about SSLv3 deprecation

Auf die schnell böse Dinge deaktivieren…

Postfix:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Dovecot:

ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
ssl_protocols = !SSLv2 !SSLv3

Apache2:

SSLEngine on
SSLProtocol +ALL -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
SSLCompression off
Header always set Strict-Transport-Security "max-age=15552000"

Linux Backintime Datensicherung / Backup

Kaum schreibe ich etwas zur Datensicherung meines FreeBSD Notebooks, schon kommt die Frage, wie ich einen/meinen Linux Desktop sichern würde….

Um es kurz zu machen, ich nutze dazu seit langem bereits das Programm backintime. Es arbeitet mit rsync und hardlinks ebenfalls bietet es die Möglichkeit seine Sicherungen auf alle möglichen Ziele zu schieben, so auch per SSH nach irgendwo.

Wer rsnapshot für Unix Server kennt… Es ist so ähnlich nur bei Bedarf mit GUI. Zusätzlich lässt sich noch schnell und einfach etwas Krypto ins Spiel bringen. Die Datensicherungen lassen sich so sehr schnell und vor allem einfach erstellen und wiederherstellen. Probiert es einfach mal!

Fragen? Dann fragen.

Siehe auch: ZFS Encryption

Fragen? Einfach melden.

Die ersten Zertifikate mit SHA-256 Checksumme und SNI

Veraltet: SHA-256 ist seit vielen Jahren der Standard für TLS-Zertifikate, SHA-1 wird von keinem Browser mehr akzeptiert. SNI wird von allen modernen Clients unterstützt. Die hier beschriebene Umstellung ist längst abgeschlossen.

Auf meiner privaten Kisten sind nun die ersten Zertifikate mit SHA256 Checksumme aktiv. Zum ersten mal auch auf einer IPv4 per SNI. Damit habe ich nun zwar alle Windows XP User an der Stelle abgehängt… 2014 kann ich damit aber mehr als gut leben.

Gewarnt hatte ich ja bereits und inzwischen geht Google hier ja auch nach vorne: Google Browser Chrome wirft SHA1 Zertifikate weg…

Damit ist nun mein munin (https://munin.kernel-error.com/) und der ampache (https://ampache.kernel-error.com) nur noch über diesen Weg und mit diesen Zertifikaten erreichbar \o/

https://www.ssllabs.com/ssltest/analyze.html?d=ampache.kernel-error.com

https://www.ssllabs.com/ssltest/analyze.html?d=munin.kernel-error.com

So long…

Google Browser Chrome wirft SHA1 Zertifikate weg…

Veraltet: SHA-1 in TLS-Zertifikaten ist seit Januar 2017 von allen großen Browsern abgelehnt. Dieser Beitrag ist ein Zeitdokument aus 2014, als Google den Ausstieg ankündigte.

Dass SHA-1 nicht der Brüller ist, wissen wir inzwischen alle. Dass man nicht so lange warten sollte wie bei MD5, bis es nicht nur ein theoretisches, sondern ein echtes Problem gibt, können sich viele denken. Leider bekommt man viele Entscheider nicht so einfach davon überzeugt, denn es hängt meist viel Geld an so einer Entscheidung. Softwaremodule müssen getauscht werden, Hardware könnte ersetzt werden müssen. Windows XP wird so zum Beispiel abgehängt.

Googles Ankündigung

Google hat angekündigt, SHA-1 aus Chrome zu entfernen. Nutzt man Zertifikate mit SHA-1-Checksumme, gibt es eine Meldung im Browser: „Diese Seite ist nicht ganz sicher.“ Danach folgt eine deutliche rote Warnung, bis hin zum Punkt, dass solche Zertifikate nicht mehr unterstützt werden. Zeitplan damals: ab ca. 2017. Bei einer durchschnittlichen Gültigkeitsdauer von zwei Jahren für Kaufzertifikate konnte man zum letzten Mal mit gutem Gewissen am 31.12.2014 ein SHA-1-Zertifikat kaufen.

Was mir an Google damals gefiel: Sie haben sanften Druck auf die Entscheider ausgeübt, um mehr Sicherheit ins Internet zu bringen. SHA-1 ist Käse, als Checksumme im Zertifikat oder in den Ciphern. Genau wie RC4 oder MD5. Kein Anwender prüft das von sich aus. Aber wenn die Software anfängt zu meckern, gibt es schnell Bewegung bei den Entscheidern und den „Weiter, weiter, fertigstellen“-Admins. Microsoft und Mozilla hatten sehr ähnliche Pläne.

Die CAs reagieren

Kurz nach der Ankündigung kamen die ersten E-Mails von den großen CAs. Hier die von Symantec:

Wichtiger Servicehinweis

Sie haben vielleicht bereits gehört, dass Google beabsichtigt, die
Unterstützung für SSL-Zertifikate mit dem Hash-Algorithmus SHA-1
einzustellen. Das wird voraussichtlich ab Chrome 39 im November 2014
geschehen.

Symantec empfiehlt:
1. Nutzen Sie die SSL Toolbox, um herauszufinden, welche Ihrer
   Zertifikate SHA-1 nutzen.
2. Ersetzen Sie Zertifikate mit SHA-1, die nach dem 31. Dezember 2015
   ablaufen, kostenlos durch Zertifikate mit SHA-2.

Hinweis: Root-Zertifikate mit SHA-1 sind nicht betroffen.

Ihr Support-Team von Symantec Website Security Solutions

Wie es ausgegangen ist

Im Januar 2017 hat Chrome 56 SHA-1-Zertifikate endgültig abgelehnt. Firefox und Edge zogen nach. Heute signiert jede CA mit SHA-256 oder besser. Wer sich für den aktuellen Stand von TLS und Zertifikaten interessiert: Da hat sich seit 2014 einiges getan.

Fragen? Einfach melden.

Google will sicheres Internet.

In den letzten Tagen häufen sich die Meldungen über Google bezüglich verschlüsselter Webseiten. Zugegeben… Etwas überraschend für mich! So hat Google angekündigt künftig Webseiten, die verschlüsselt HTTPS ( also per SSL / TLS ) erreichbar sind. In seinem Ranking bei den Suchergebnissen zu bevorzugen. (HTTPS as a ranking signal)

Na da werden sich wohl einige CAs die Hände reiben und die SEOs wieder viel arbeiten haben. Hoffen wir mal das inzwischen alle Hoster SNI können, sonst wird diese Aktion sicher dem IPv4 Pool noch mal ordentlich etwas abziehen. BTW. Habe ich schon gesagt das es Zeit ist sich mit IPv6 zu beschäftigen?

Jetzt lese ich gerade das Google eine kleine Liste für seinen Browser Chrome führt. Eine Liste für HTTPS only Seiten. In genau diese Liste kann sich nun jeder mit seiner Webseite eintragen, der dafür gesorgt hat, dass seine Webseite nur per HTTPS zu erreichen ist. Dazu setzt Google auf HSTS (HTTP Strict Transport Security). Das Thema Stirct Transport Security habe ich ja bereits, unter anderem, vor einigen Wochen hier beschrieben: Apache und sichere SSL / TLS Verschlüsselung

Nun kann man sich also über diese Seite https://hstspreload.appspot.com/ in die Liste eintragen. Dabei erwartet Google zum Header max-age noch includeSubDomains und preload. Ist die Seite eingetragen bedankt sich Google und verweist als nächsten Schritt zur SSLlabs Testseite um ggf. vorhandene Probleme mit seiner SSL/TLS Konfiguration zu beheben.

Google tut dieses alles ganz sicher nicht aus Nächstenliebe, denn noch wird es die allgemeine Sicherheit, vor allem aber das Theme selbst, mehr in den Vordergrund ziehen. So wird sich vielleicht der eine oder andere „Entscheider“ nun doch mit einer positiven Rückmeldung zu dem Thema bei der IT melden!

Fragen? Einfach melden.

E-Mail-Benachrichtigung bei Root-Login einrichten

Kein Server lässt sich zu 100 Prozent absichern. Wenn sich jemand eine Root-Shell öffnet, will ich das zeitnah wissen. Nicht erst wenn Kunden sich melden oder Abuse-Mails eintrudeln. Eine kurze E-Mail mit IP-Adresse und Zeitstempel bei jedem Root-Login gibt zumindest einen Anhaltspunkt.

Vorweg: Das ist kein Security-Feature. Ein Angreifer mit Root-Rechten kann die Benachrichtigung deaktivieren, die Mail abfangen oder die .bashrc löschen. Es ist Schlangenöl, wenn man es als Schutzmaßnahme verkauft. Aber als ergänzender Hinweis funktioniert es gut, weil die Mail meist schon raus ist bevor der Angreifer sie verhindern kann. Vorausgesetzt, die Mail geht an einen anderen Server.

Variante 1: .bashrc

Die einfachste Methode. Eine Zeile in /root/.bashrc schickt bei jedem Öffnen einer interaktiven Shell eine Mail:

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@example.com

Das Ergebnis sieht dann so aus:

Subject: Alert: Root Access from 203.0.113.42
ALERT - Root Shell Access (bsd01) on: Mi 12. Mär 14:22:03 CET 2026 root pts/0 2026-03-12 14:22 (203.0.113.42)

Damit die IP-Adresse statt eines Hostnamens in der Mail steht, sollte der SSH-Server keine DNS-Abfragen machen:

# /etc/ssh/sshd_config
UseDNS no

Variante 2: PAM

Robuster als die .bashrc-Methode, weil PAM vor der Shell greift und nicht so leicht umgangen werden kann. In /etc/pam.d/sshd am Ende:

session optional pam_exec.so /usr/local/bin/login-notify.sh

Das Script /usr/local/bin/login-notify.sh:

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
echo "SSH Login: $PAM_USER von $PAM_RHOST auf $(hostname) um $(date)" | \
  mail -s "SSH Login: $PAM_USER@$(hostname) von $PAM_RHOST" root-logins@example.com

PAM setzt die Umgebungsvariablen PAM_USER, PAM_RHOST und PAM_TYPE automatisch. Das Script prüft auf open_session, damit es nur beim Login feuert und nicht beim Logout.

FreeBSD

Unter FreeBSD heißt die PAM-Konfiguration /etc/pam.d/sshd (gleicher Pfad). Statt mail steht dort mailx zur Verfügung, oder man nutzt direkt sendmail. Die .bashrc-Variante funktioniert genauso, die Datei liegt unter /root/.profile wenn csh/tcsh die Standard-Shell ist.

Einordnung

Login-Benachrichtigungen ersetzen kein Monitoring und kein Intrusion Detection System. Sie sind ein einfacher Stolperdraht, der in der Praxis überraschend oft hilft. Nicht weil er einen Angriff verhindert, sondern weil er die Reaktionszeit verkürzt. Wenn um drei Uhr nachts eine Login-Mail von einer unbekannten IP kommt, weiß man dass etwas nicht stimmt.

Wer den SSH-Zugang selbst härten will: Multi-Faktor-Authentifizierung mit Google Authenticator macht einen erfolgreichen Login ohne den zweiten Faktor deutlich unwahrscheinlicher. Fragen? Einfach melden.

Aber ich habe doch nichts zu verbergen…

Da ist nun also das Ergebnis von eurem „Ich habe doch nichts zu verbergen“! Klasse, gut gemacht….

http://www.golem.de/news/data-mining-polizei-will-straftaten-mit-predictive-policing-verhindern-1407-107638.html

Jetzt muss du nicht mal was zu verbergen haben, jetzt reicht es, wenn man statistisch leider gerade „auffällig“ ist. Am Ende treten die Jungs euch die Türe ein, verhaften euch und führen euch in Handschellen ab. OK ok… Wird nicht passieren, Rechtsstaat usw…. Riiiiiiccchhhhtttiiiigggg

Glaubt ihr das wirklich?

Klar, wenn sich am Ende herausstellt das ihr nichts zu verbergen hattet, wird schon nichts passieren…. Dem Rest kann man ja auch später erklären das die Vorwürfe völlig haltlos waren und euch nichts nachgewiesen werden konnte. Das verstehen alle und es bleibt kein ~Nachgeschmack~… Ich übertreibe? Na warten wir mal ab, ich denke es wird noch genau so kommen. Genug Metadaten habe sie ja inzwischen.

Ich denke: „It´s time for PANIC!“ Ich habe Angst 🙁

Panic reaction GIF about surveillance and privacy

Wir müssen unbedingt alle etwas mehr auf unsere Daten achten und vor allem etwas „nervöser“ werden wenn es um die Überwachung von egal was geht. Nicht alles sinnfrei glauben, sondern mal mit Hirn hinterfragen! Das Thema: „Ich habe doch nichts zu verbergen“ ist damit wohl hoffentlich erschlagen, oder?

Fragen? Einfach melden.

Openfire: AES-256-Verschlüsselung mit JCE Unlimited Strength aktivieren​

Veraltet: Seit Java 9 (2017) ist JCE Unlimited Strength standardmäßig aktiviert. Die hier beschriebene manuelle Installation der Policy Files ist bei aktuellen Java-Versionen nicht mehr nötig.

Möchte man unter seinem Java AES mit 256 Bit nutzen, muss man die JCE Unlimited Strength Jurisdiction Policy Files von Hand installieren.

Ja, man fühlt sich schnell einige Jahre zurück versetzt, als man noch aus den USA keine große Krypto exportieren durfte/darf. Daher war es ja lange nicht möglich große Krypto in Browsern einzusetzen. Das Java Thema ist sehr ähnlich!

Die Installation ist recht einfach.

Zuerst einmal die neuen Policy Files herunterladen (für Java 7):

http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html  

Im heruntergeladenen ZIP-File finden sich zwei jar Dateien. Diese müssen nun gegen die….  na, sagen wir mal beschränkten, ausgewechselt werden. Auf einem Debian finden sich diese hier:

/usr/lib/jvm/java-7-oracle/jre/lib/security
/usr/lib/jvm/jdk1.7.0_51/jre/lib/security

Nachdem beiden Dateien getauscht wurden, sind sie auch schon aktiv für jeden neuen Java Prozess. Ich will damit sagen, wenn es für den Openfire genutzt werden soll, diesen bitte einmal durchstarten.

Clientreport:

https://xmpp.net/result.php?id=42150

Serverreport:

https://xmpp.net/result.php?id=42151

Noch Fragen? Na dann fragen.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑