vServer, Debian, Let's encrypt und Coturn - Sicherheit

Trefoil80 · 19. März 2018

Moin zusammen,

ich habe mir einen kleinen vServer bei Netcup bestellt, da ich für meine Nextcloud-Installation bei All-Inkl.com (shared hosting) noch einen TURN-Server einrichten wollte, damit Nextcloud-Talk auch funktioniert, wenn die Smartphones sich in unterschiedlichen Netzen befinden.

Habe enthusiastisch losgelegt, und es funktioniert auch alles (Let's encrypt über Certbot mit automatischem Cron zur Aktualisierung, Coturn mit Shared Secret und Einbindung in meine Nextcloud-Installation via SSL (inkl. ein paar apt-get update).

Jetzt habe ich gesehen, dass "nur" Debian Jessie 8.10 mit Kernel 3.16.0.5 installiert ist.

Möchte jetzt durch ein Upgrade/Update allerdings nur ungern den Server wieder "zerschießen". Welche Aktualisierungen sind im Zuge von Meltdown/Spectre ratsam?

Sollte ich auf Debian 9 Stretch upgraden? Oder nur den Kernel (wenn ja, auf welchen)?
Wie upgrade ich den Kernel? Habe das sonst nur in Linux Mint via GUI gemacht, aber noch nie in der Bash auf dem Server.

Für eine kleine Hilfestellung wäre ich Euch sehr dankbar.

Viele Grüße
Trefoil

uburoi · 19. März 2018

Wenn du nur den Kernel aktualisieren willst, schau mal im Netz unter dem Stichwort "Backports" nach. Du musst im Grunde nur unter /etc/apt/sources.list die entsprechende Zeile hinzufügen und kannst nach dem Update der Paketquellen einen neueren Kernel installieren. (Genauer kann ich gerade leider nicht werden, weil unterwegs...)

Gruß Jens

Trefoil80 · 19. März 2018

Backports sind drin (wg. Certbot). Aber welchen Kernel sollte ich wie installieren?

Falc410 · 19. März 2018

Du kannst einen Snapshot machen. Ich würde trotzdem zu einem Dist-Upgrade raten. Wenn danach etwas nicht richtig läuft kannst du den Snapshot zur Not wieder herstellen. Den Kernel kann man wie als Paket installieren - allerdings müsste ich auch erst nachschauen welche Version die entsprechenden Spectre Fixes drin hat. Aber da es ein vServer ist, läuft das sicher über den Kernel des Host Systems - da musst du dir selber wegen Spectre / Meltdown keine Gedanken machen. Das macht der Provider schon.

Sn0oze · 19. März 2018

Kommt drauf an welche Virtualisierung dort läuft. Ist es KVM, hast du wohl deinen eigenen Kernel. Ist es OpenVZ nutzt du den Kernel des Host mit. Ansonsten würde ich den Kernel verwenden, der auch beim Upgrade angeboten wird. Und ja, auf Debian 9 upgraden solltest du. Wirst du über kurz oder lang sowieso nicht drum rumkommen.

fax668 · 19. März 2018

Lies dir das hier einmal bis zum Ende durch bevor du loslegst: https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.de.html

Dann befolge alle Schritte genau. Dann sollte es eigentlich keine größeren Schwierigkeiten geben. Viele der Schritte scheinen evtl. überflüssig, aber lieber auf Nummer sicher gehen als dann am Ende doch die falsche Abkürzung genommen haben.

Und davor solltest du dir eigentlich schon längst automatisierte Backups eingerichtet haben.

Y-Chromosome · 19. März 2018

wieso willst Du eigentlich den Kernel aktualisieren?
Wenn Du unbedingt einen neuen Kernel willst kannst Du z.B. "old-bpo" installieren halte ich aber v.a. bei einer VM für völlig sinnfrei.
siehe hier: https://tracker.debian.org/pkg/linux

Code:

 sudo apt-get -t jessie-backports install linux-base

Code:

sudo apt-get -t jessie-backports install linux-image-amd64

Trefoil80 · 19. März 2018

Hmm, habe jetzt das Upgrade auf Debian 9 Stretch gewagt. Die turnserver.conf habe ich beim Upgrade übernommen ("N"). Es lief auch alles ohne Fehlermeldungen durch, aber wenn ich die Seite des TURN-Servers aufrufe, erscheint:

SSL_ERROR_NEXT_PROTOCOL_DATA_INVALID

Hat jemand eine Idee? Ich habe jetzt erstmal den Snapshot zurückgesichert und bin wieder auf dem alten Stand.

Den Kernel sollte ich, denke ich, schon updaten, da KVM (siehe Beitrag von Snooze).
Y-Chromosome, warum genau hältst Du ein Kernel-Upgrade unter einer VM sinnfrei?
Stichwörter Meltdown/Spectre/Retpoline.

Würde aber gern Kernel UND die Distri upgraden (auf Stretch).

Der Grund: Habe heute in die Logdatei des Turnservers geschaut und hatte so manche
unauthorisierte Zugriffsversuche von IP-Adressen aus Russland, China und den USA.

Möchte einfach ein maximal sicheres System haben.

Ergänzung (20. März 2018)

So, Kernel ist auf die 4.9.0.0 geupgraded (unter Debian Jessie).

Wie komme ich auf die aktuellste Version 4.9.87?

Y-Chromosome · 20. März 2018

Ist jetzt nicht böse gemeint, aber Du solltest schon wissen, dass Debian, wie jede andere Distro Sicherheitspatches für ihren eigenen Kernel zurückportiert und es damit für den Nutzer einer Langzeitdistro recht egal ist welche Kernelversion man fährt.

außerdem hast Du sicher nicht 4.9.0.0 sondern 4.9.65-3

gib doch einmal folgende sein:

Code:

uname -r

Auf meinem Fedora 27 liefert das:

Code:

4.15.6-300.fc27.x86_64

(Ich sollte mal neustarten Fedora ist schon bei .9

)

Trefoil80 · 20. März 2018

uname -r liefert:
4.9.0-0.bpo.5-amd64

Also ist tatsächlich der 4.9.0-0 installiert, wie ich geschrieben habe.
Wie kann ich diesen denn auf die neueste Version des 4.9er-Zweiges aktualisieren?

Bezügl. der Kernel-Versionen war ich immer davon ausgegangen, dass es zwar sicherheitstechnisch egal ist, auf welchem Kernelzweig (z.B. 3.16er oder 4.9er) man sich bewegt (aktueller Support vorausgesetzt), aber man sollte innerhalb des Zweiges schon regelmäßig updaten, gerade aktuell wg. Spectre und Co.

Große, neue Feature gibt es in der Regel mit einem neuen Kernelzweig.

So ist mein Verständnis. Wenn ich damit falsch liege, bitte korrigiert mich.

Y-Chromosome · 20. März 2018

dann ist doch alles richtig und der korrekte Kernel installiert:
https://packages.debian.org/search?keywords=linux-image-4.9.0-0.bpo.5-amd64

vielleicht braucht es bei dem Kernel ein

Code:

uname -a

ach ja und der Kernel ist von:
[2018-01-06] Accepted linux 4.9.65-3+deb9u2~bpo8+1 (source all amd64) into jessie-backports->backports-policy, jessie-backports (Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
siehe https://tracker.debian.org/pkg/linux

teste doch einmal mit einem spectre / meltdown checker, würde mich auch interessieren ...

Sn0oze · 20. März 2018

Da Meltdown und Spectre sicherheitsrelevant sind, werden die natürlich auch bei Sicherheitsupdates des Kernels berücksichtigt. Ob du nun unbedingt die neuen Features (wie Support für die neuste Webcam oder die neuste CPU des Supercomputer XYZ) brauchst, wage ich mal zu bezweifeln. Wenn der vServer läuft, dann läuft er.

Trefoil80 · 21. März 2018

uname -a zeigt in der zweiten Hälfte "...4.9.65-3..."

Ergebnis des Spectre/Meltdown-Checks wie erwartet:

Meltdown: Not vulnerable
Spectre 1: Vulnerable (Kernel source needs to be patched to mitigate that vulnerability)
Spectre 2: Vulnerable (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate that vulnerability)

Also, die Frage bleibt: Wie aktualisiere ich den Kernel auf eine Version von März (innerhalb des 4.9er-Zweiges), zur Not auch einen anderen Zweig?

Y-Chromosome · 21. März 2018

Lies das mal hier:
https://www.decadent.org.uk/ben/blog/meltdown-and-spectre-in-debian.html

Code:

Spectre

Spectre needs to be mitigated in the kernel, browsers, and potentially other software. Currently the kernel changes to mitigate it are still under discussion upstream. Mozilla has started mitigating Spectre in Firefox and some of these changes are now in Debian unstable (version 57.0.4-1). Chromium has also started mitigating Spectre but no such changes have landed in Debian yet.

bzw. lies hier:
https://wiki.debian.org/DebianSecurity/SpectreMeltdown
und nutze deren Testtool.

Code:

Current Status

Kernel updates have been shipped for Debian stable/stretch and later.

The gcc compiler toolchain was updated in Debian buster/unstable (gcc 7.3), stretch (gcc 6) through DSA-4121 and jessie (gcc 4.9) through DSA-4117. No archive rebuild is planned at this point so user-space fixes (particularly for Spectre v1) vary according to the affected binary package, as the fix is basically per-program. The compiler updates were still required to provide fixes for the Linux kernel.

Spectre Variant 2 can be exploited both locally (within the same OS) and through the virtualization guest boundary. Fixes require CPU microcode/firmware to activate. Subscribers are advised to contact their hardware OEM to receive the appropriate microcode/firmware for their processor. In particular, qemu and other hypervisors need to pass through certain CPU features to allow guest operating systems to correctly configuration mitigation mechanisms.

Kurzum, es geht noch nicht besser, da die GCC Toolchain nicht aktualisiert ist.

Ich würde Dir folgendes raten wenn Dir die Absicherung so wichtig ist. Sichere Deine Config Dateien und mach die Maschine platt und lass vom Hoster ein frisches Debian 9 aufspielen. Danach baust Du Deine Config erneut auf.

Trefoil80 · 21. März 2018

Hatte ich auch überlegt, ist mir aber zu aufwändig. Mich interessieren aber Antworten zu den Fragen:

1) Warum läuft der TURN-Server nach dem Upgrade auf Debian 9 nicht richtig (siehe Post Nummer #8)?
2) Mein Desktop-Linux (Mint 17.3, basierend auf Ubuntu 14.04.4 LTS) ist mit Kernel 4.4.0.112 bereits (neben Meltdown) zumindest gegen Spectre V1 geschützt. Es handelt sich dabei also weder um die aktuellste Distri noch um den aktuellsten Kernel-Zweig. Im Vergleich zu den Ubuntu-Entwicklern scheinen solch kritische Sicherheitsupdates bei Debian sehr lange zu dauern, wenn man nicht gerade Debian 9 einsetzt. Gibt es denn zumindest eine grobe Idee, wann Debian 8 auch zumindest gegen Spectre V1 geschützt ist?

Y-Chromosome · 22. März 2018

zu 1)
das sehe ich mir morgen mal an.

zu 2) mit welchem Tool hast Du das geprüft?
damit? https://github.com/speed47/spectre-meltdown-checker

poste doch davon bitte einmal einen Screenshot

Trefoil80 · 22. März 2018

Super, das ist nett

Ja, dieses Tool habe ich verwendet. Den Screenshot habe ich mal angehängt.

Ergänzung (22. März 2018)

Habe jetzt doch neu aufgesetzt. Ging schneller, als ich dachte.

Mit Debian 9 bin ich gegen Meltdown und die beiden Spectre-Varianten geschützt.

Y-Chromosome · 22. März 2018

Habe heut viel zu tun, schaffe es nicht mehr ...
Melde mich

Trefoil80 · 23. März 2018

Mist, das Problem mit

"Ein Fehler ist während einer Verbindung mit xyz.domain.de aufgetreten. SSL hat ungültige NPN-Erweiterungsdaten erhalten. Fehlercode: SSL_ERROR_NEXT_PROTOCOL_DATA_INVALID"

ist wieder aufgetreten. Ist also ein Problem mit meiner Config in Bezug auf Stretch, nicht mit einem potentiell fehlgeschlagenen Upgrade auf Stretch.

Bin nach dieser Anleitung vorgegangen:
https://blog.netways.de/2017/08/16/setting-up-a-turn-server-for-nextcloud-video-calls/

Unter Jessie hat es exakt so funktioniert (nach Korrektur der Anleitung / da war einmal anstatt DH+AES128 nur DH+AES genannt), unter Stretch nicht. Ist es ein Problem mit der Cipher-List?

Weitere Seiten hierzu, die mich aber nicht weitergebracht haben:
https://bugs.launchpad.net/ubuntu/+source/coturn/+bug/1747948
https://github.com/coturn/coturn/issues/113

Der letzte Link ist möglicherweise interessant. Wo liegt die mainrelay.c? Die würde ich mir gern mal anschauen.

"This is caused by a typo in the ALPN callback. ta_len here should be ha_len. As a result, you're not actually spelling "http/1.1" in your ALPN callback correctly. Newer Chromes notice this and fail the connection. Previously, we would silently treat anything we didn't recognize as HTTP/1.1.

coturn/src/apps/relay/mainrelay.c

Line 2459 in 516e534
*outlen = ta_len; "

Edit:
Über apt-cache show coturn habe ich herausgefunden, dass nur die Version 4.5.0.5 installiert ist. Wie kann ich die updaten?

Edit2:
Habe Coturn 4.5.0.7 temporär über den Unstable-Zweig installiert. Das hat geklappt
Der Fehler innerhalb Coturn ist damit beseitigt, und das Testtelefonat über Nextcloud Talk war fehlerfrei.

Die Frage ist nur: Warum ist in Debian Jessie stable eine neue, fehlerfreie Version und in
Debian Stretch stable nur eine olle Uralt-Version mit Fehlern?

Y-Chromosome · 23. März 2018

poste doch mal Deine Cipher Liste.

vServer, Debian, Let's encrypt und Coturn - Sicherheit

Commodore

Lt. Commander

Commodore

Vice Admiral

Lt. Junior Grade

Lieutenant

Commander

Commodore

Commander

Commodore

Commander

Lt. Junior Grade

Commodore

Commander

Commodore

Commander

Commodore

Commander

Commodore

Commander

Ähnliche Themen

Passend zum Thema