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 25 von 47)

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.

Raspberry Pi als FM-Radiosender mit PiFM

Kinder sind etwas Wunderbares, so auch meine beiden. Die Größere hört zum Einschlafen gerne ein Hörspiel, beim Spielen hören und tanzen beide zu Kindermusik. Klar haben sie eine kleine Kompaktanlage im Kinderzimmer. Aber Kinderhörspiele gibt es kaum noch auf Kassette — fast nur noch auf CD oder als MP3. Keine Ahnung wie es bei euren Kindern ist, bei uns leben CDs nicht sonderlich lange. Ich grille in der Woche 3 bis 4 Stück. Noch schlimmer: Die Lieblings-CD trifft nach 38 Minuten auf einen Kratzer und macht nur noch unverständlichen Lärm.

MPD als CD-Ersatz

Ich hatte noch einen Raspberry Pi herumliegen. Den zusammen mit dem Music Player Daemon (MPD) als Musikspieler nutzen — die gekauften MP3-Alben liegen eh auf dem Server und lassen sich per NFS mounten. WLAN ist im ganzen Haus, und wir Eltern steuern alles per Android-App. Das Projekt war in anderthalb Stunden erledigt, getestet und von den Kindern abgenommen.

Seitdem fristet der CD-Spieler ein ungenutztes Leben. Nur das Radio läuft hin und wieder am Abend. Radio… irgendwo hatte ich doch im Zusammenhang mit dem Raspberry Pi etwas zu FM-Radio gelesen.

PiFM — FM-Sender über GPIO

PiFM (mittlerweile weiterentwickelt als rpitx) nutzt den GPIO-Pin 4 des Raspberry Pi, um ein FM-Signal zu erzeugen. Eine ca. 15 cm lange Antenne — ein Stück Draht — reicht. Der Pi generiert per DMA ein Taktsignal auf dem GPIO, das direkt als FM-moduliertes HF-Signal abstrahlt. Kein zusätzlicher Sender-IC nötig.

Eine WAV-Datei auf 90,0 MHz senden:

sudo ./pifm musik.wav 90.0

Einen Web-Stream — zum Beispiel einen Kinderradiosender — per sox umwandeln und direkt an PiFM pipen:

sox -t mp3 http://stream-url -t wav -r 22050 -c 1 - | sudo ./pifm - 90.0

MPD kann auch streamen — so lässt sich die gesamte Musikbibliothek per FM ins Kinderzimmerradio schicken.

Verstärkerschaltung

Das reine GPIO-Signal ist schwach. Um es etwas zu verstärken und sauber zu filtern, habe ich eine kleine Schaltung gebaut — den handgezeichneten Schaltplan mit Bauteileliste findet ihr in den Bildern unten. Mit der Schaltung reicht das Signal für das ganze Haus inklusive Garten.

Oberwellen: der eigentliche Grund für den Filter

Der GPIO liefert kein sauberes Sinussignal, sondern ein Rechteck. Ein Rechteck hat neben der Grundfrequenz eine lange Reihe Oberwellen bei 2f, 3f, 4f und so weiter, und durch die DMA-getaktete Frequenzmodulation entstehen zusätzlich Splatter-Anteile im Nachbarkanal. Bei 90 MHz Grundfrequenz heißt das: 180 MHz, 270 MHz, 360 MHz und höher. Mindestens eine dieser Harmonischen liegt mit Sicherheit in einem Band, das belegt oder sicherheitskritisch ist. Ohne Tiefpass strahlt PiFM also nicht nur auf der gewählten UKW-Frequenz, sondern breitbandig quer durch VHF und UHF. Der Filter in der Verstärkerschaltung ist deshalb nicht Kür, sondern der einzige Grund, warum man keinen Flugfunk, Amateurfunk oder Rundfunk stört. Wer PiFM ohne Filter betreibt, wird im Zweifel nicht nur von der Bundesnetzagentur, sondern auch von jedem Amateurfunker im Umkreis sehr schnell gefunden.

Rechtliches

In Deutschland darf man im FM-Band senden — aber nur mit extrem geringer Leistung. Die Bundesnetzagentur erlaubt ohne Genehmigung Sendeanlagen mit wenigen Nanowatt, was in der Praxis etwa einen Meter Reichweite ergibt. Der Raspberry Pi mit Verstärkerschaltung überschreitet das deutlich. Dieses Projekt bleibt deshalb ein einmaliger Versuchsaufbau.

Schade eigentlich — der WDR-Kinderkanal MausLive (ehemals KiRaKa) ist nur per DAB+ oder Internet-Stream zu empfangen. Per PiFM könnte man den Stream als FM-Signal im Haus verteilen und die Kinder könnten überall mit einem einfachen Radio hören. Aber so ist die Rechtslage.

Update 2026: zeitgemäße Alternativen

Der Beitrag ist von 2014. Heute wäre mein Weg ein anderer: Bluetooth-Audio direkt ans Kinderzimmerradio (falls es Bluetooth kann) oder ein kleiner Multi-Room-Audio-Setup mit Snapcast, squeezelite oder einem fertigen Smart Speaker. DLNA/UPnP und AirPlay decken den Rest ab, alles legal und ohne Frequenz-Diskussion. rpitx gibt es übrigens immer noch, inzwischen mit deutlich mehr Modi (SSB, FSK, LoRa, sogar DVB-T), und ist als Experimentierplattform für die SDR-Ecke weiterhin spannend. Nur eben nichts, was man offen im Wohnzimmer laufen lassen sollte.


Bilder vom Projekt — Platine, Schaltplan mit Bauteileliste und das Ergebnis auf dem Radio:

Fragen? Einfach melden.

Parallel SSH: Kommandos auf vielen Servern gleichzeitig ausführen

Auf fünf Servern den Besitzer einer Datei ändern geht schnell. Bei 21 wird es zäh. Puppet oder Chef für einen Einzeiler hochzufahren ist Kanonen auf Spatzen. Ich nutze dafür seit Jahren pssh (Parallel SSH). Perfekt für Bash-Einzeiler, die auf vielen Systemen gleichzeitig laufen müssen.

Installation

pssh braucht Python. Die Installation geht über pip:

pip install parallel-ssh

Voraussetzung ist ein funktionierender SSH-Agent mit geladenem Key:

ssh-agent && ssh-add

Server gruppieren

Ich lege im Home einen Ordner pssh/ an und sortiere die Server in Textdateien nach Gruppen: alle Webserver, alle Mailserver, alle Server an einem Standort. Wenn ich dann ein Kommando auf einer bestimmten Gruppe ausführen will, muss ich nicht mehr nachdenken.

$ cat ~/pssh/srv.aps.ber.txt
srv.aps01.ber
srv.aps02.ber
srv.aps03.ber
[...]
srv.aps21.ber

Kommando absetzen

Das Beispiel: Auf allen 21 Applikationsservern in Berlin den Besitzer eines Scripts ändern und das Ergebnis prüfen.

$ pssh -h srv.aps.ber.txt -l root \
    -o ~/pssh/out-$(date +"%m-%d-%y_%H:%M:%S") \
    "chown aglp02:aglp02 /home/aglp02/del_import_sync.sh; \
     ls -la /home/aglp02/del_import_sync.sh;"
[1] 10:17:35 [SUCCESS] srv.aps17.ber 22
[2] 10:17:35 [SUCCESS] srv.aps03.ber 22
[3] 10:17:35 [SUCCESS] srv.aps01.ber 22
[...]
[21] 10:17:37 [SUCCESS] srv.aps18.ber 22

Die Server werden nicht nacheinander abgearbeitet, sondern gleichzeitig. 21 Server in zwei Sekunden.

Die Parameter

-h — Datei mit der Hostliste.
-l — Benutzername für den SSH-Login.
-o — Verzeichnis für die Ausgabe jedes Servers. Ich lasse mir mit date automatisch einen Unterordner mit Zeitstempel erstellen, damit die Ergebnisse zugeordnet bleiben.
Am Ende steht das Kommando in Anführungszeichen.

Ausgabe kontrollieren

Im Output-Verzeichnis liegt pro Server eine Datei mit der Bash-Ausgabe:

$ cat ~/pssh/out-09-22-14_10:17:35/srv.aps01.ber
-rwxr-xr-x 1 aglp02 aglp02 1801 Jan 21 2009 /home/aglp02/del_import_sync.sh

So lässt sich kontrollieren, ob alles sauber gelaufen ist oder ob auf einzelnen Servern nachgearbeitet werden muss.

Einmal vorbereitet, lässt sich pssh schnell in den Arbeitsalltag integrieren. Für alles, was über Einzeiler hinausgeht, greift man dann zu Ansible oder Puppet. Für den schnellen Handgriff auf 20+ Servern ist pssh genau richtig.

Siehe auch: Z Shell als bessere Shell

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…

Mosh – mobile shell

Langsame SSH Verbindungen sind nicht nur nervig, sie regen mich auf und reizen mich unnötig. Ich werde verrückt, wenn ich etwas in ein Terminal tippe und versetzt eine Rückmeldung über meine Eingaben bekomme. Und wehe man hat sich vertippt.

Besonders wenn man „mal eben“ unterwegs die Welt retten muss und das Terminal hängt oder durch die wechselnde IP Adresse am mobilen Client gleich die ganze Verbindung gekillt wird.

OK, gegen die gekillte Verbindung hilft screen und gegen Vertipper, aufpassen und der Umweg über ein Textfile (copy & paste). Beides sind Notnägel, nicht wirklich dafür gedacht und nicht DIE Lösung.

Vor kurzem hatte ich das Problem auf einigen, weit entfernten, Systemen arbeiten zu müssen. Auf dem Weg dort hin hatte ich leider mit 60 – 80% Paketverlust zu kämpfen. So ist natürlich kaum ein Arbeiten möglich. Glücklicherweise erinnerte ich mich daran mal etwas von Mosh gelesen zu haben. Mosh ist ein sehr guter Name, denn er ist in meinem Hirn hängen geblieben.

Ich bin so begeistert von dem Programm, dass ich es einfach einmal kurz verlinken muss.
https://mosh.mit.edu/

Es lässt sich grob bedienen wie ssh, muss auf dem Client und dem Server installiert sein und arbeitet am Ende mit UDP Paketen. UDP?!?!? Japp UDP…. Genau erlesen kann man es auf der Webseite vom Projekt und dort werden direkt ein paar Bedenken erschlagen hinsichtlich Verschlüsselung und Konsistenz.

Auf meinen Arbeitsplätzen gehört es in jedem Fall ab jetzt zur standard Ausstattung.

So long….

Fragen? Einfach melden.

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑